<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!--  ?rfc subcompact="no" ?  -->
<!-- keep one blank line between list items -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!--
==================================== 80 ========================================
==================================== 72 ================================
 -->

<rfc ipr="trust200902" docName='draft-ietf-dmm-4283mnids-02.txt' >
  <front>
<title abbrev="MN Identifier Types for RFC 4283">
	MN Identifier Types for RFC 4283 Mobile Node Identifier Option</title>

   <author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
      <organization abbrev="Futurewei">Futurewei Inc. </organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <code>95050</code>
          <region>CA</region>
          <country>USA</country>
        </postal>
        <phone>+1-408-330-4586</phone>
        <email>charliep@computer.org</email>
      </address>
    </author>

    <author initials="V." surname="Devarapalli" fullname="Vijay Devarapalli">
       <organization>Vasona Networks</organization>
      <address>
        <postal>
          <street>2900 Lakeside Drive, Suite 180</street>
          <city>Santa Clara</city>
          <region>CA 95054</region>
          <country>USA</country>
        </postal>
	<!-- <email>vijay@vasonanetworks.com  dvijay@gmail.com</email> -->
      </address>
    </author>

    <date/>  <!-- day="25" month="October" year="2010" /> -->

  <area>Internet</area>
  <workgroup>Distributed Mobility Management [dmm]</workgroup>
<keyword>Mobility</keyword>
<keyword>IPv6</keyword>
<keyword>Authentication</keyword>


<abstract>

<t>
	Additional Identifier Types are proposed for use with
	the Mobile Node Identifier Option for MIPv6 (RFC 4283).
</t>
</abstract>

</front>
<middle>
<section anchor='intro' title='Introduction'>

<t>
	The Mobile Node Identifier Option for MIPv6
	<xref target="RFC4283"/>
	has proved to be a popular design tool for providing
	identifiers for mobile nodes during authentication procedures
	with AAA protocols such as Diameter <xref target="RFC3588"/>.
	To date, only a single
	type of identifier has been specified, namely the MN NAI.

	Other types of identifiers are in common use, and even
	referenced in RFC 4283.  In this document, we propose adding some
	basic types that are defined in various telecommunications
	standards, including types for
		IMSI <xref target="ThreeGPP-IDS"/>,
		P-TMSI <xref target="ThreeGPP-IDS"/>,
		IMEI <xref target="ThreeGPP-IDS"/>,
		and GUTI <xref target="ThreeGPP-IDS"/>.  In addition, we
	specify the IPv6 address itself and IEEE MAC-layer addresses
	as mobile node identifiers.
	Defining identifiers that are tied to the physical elements of the
	device (RFID, MAC address etc.) help in deployment of Mobile IP
	because in many cases such identifiers are the most natural means
	for uniquely identifying the device, and will avoid additional
	look-up steps that might be needed if other identifiers were used.
</t>

</section>

<section anchor='types'
	title='New Mobile Node Identifier Types'>

<t>
	The following types of identifiers are commonly used
	to identify mobile nodes.  For each type, references are
	provided with full details on the format of the type
	of identifer.
</t>

<t>
	The Tag Data standard promoted by Electronic Product Code(TM)
	(abbreviated EPC) supports several encoding systems or schemes
	including

   <list style="symbols">
   <t> RFID-GID (Global Identifier), </t>
   <t> RFID-SGTIN (Serialized Global Trade Item Number), </t>
   <t> RFID-SSCC (Serial Shipping Container), </t>
   <t> RFID-SGLN (Global Location Number), </t>
   <t> RFID-GRAI (Global Returnable Asset Identifier), </t>
   <t> RFID-DOD (Department of Defense ID), and </t>
   <t> RFID-GIAI (Global Individual Asset Identifier). </t>
   </list>

   For each RFID scheme except GID, there are two variations:
   a 64-bit scheme (for example, SGLN-64) and a 96-bit scheme (SGLN-96).
   GID has only a 96-bit scheme.  Within each scheme, an EPC identifier
   can be represented in a binary form or other forms such as URI.
</t>

<t>
	The following list includes the above RFID types as well
	as various other common identifiers and several different
	types of DUIDs.
</t>

    <texttable anchor='mnid-types'>
	<preamble>Mobile Node Identifier Description</preamble>
	<ttcol align='left'>Identifier Type</ttcol>
	<ttcol align='left'>Description</ttcol>
	<ttcol align='left'>Reference</ttcol>
	<c> IPv6 Address </c> <c> </c> <c> <xref target="RFC4291"/> </c>
	<c> IMSI </c>
	    <c> International Mobile Subscriber Identity </c>
	        <c> <xref target="ThreeGPP-IDS"/> </c>
	<c> P-TMSI </c>
	    <c>Packet-Temporary Mobile Subscriber Identity </c>
	        <c> <xref target="ThreeGPP-IDS"/> </c>
	<c> GUTI </c>
	    <c> Globally Unique Temporary ID </c>
	        <c> <xref target="ThreeGPP-IDS"/> </c>
	<c> EUI-48 address </c>
	    <c> 48-bit Extended Unique Identifier </c>
	        <c> <xref target="IEEE802"/> </c>
	<c> EUI-64 address </c>
	    <c> 64-bit Extended Unique Identifier-64 bit </c>
	        <c> <xref target="IEEE802"/> </c>
	<c> DUID-LLT </c>
	    <c> DHCPv6 Unique Identifier: Link-Layer address plus timestamp</c>
	        <c> <xref target="RFC3315"/> </c>

	<c> DUID-EN </c>
	    <c> DHCPv6 Unique Identifier: Enterprise Number plus add'l data</c>
	        <c> <xref target="RFC3315"/> </c>
	<c> DUID-LL </c>
	    <c> DHCPv6 Unique Identifier: Link-Layer address</c>
	        <c> <xref target="RFC3315"/> </c>
	<c> DUID-UUID </c>
	    <c> DHCPv6 Unique Identifier: other conformant format</c>
	        <c> <xref target="RFC6355"/> </c>
<!-- 
	<c> 12-15 reserved </c> <c> </c> <c> </c>
	<c> 16 reserved </c> <c> </c> <c> </c>
  -->
	<c> RFID-SGTIN-64 </c>
	    <c> 64-bit Serialized Global Trade Item Number </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-SSCC-64 </c>
	    <c> 64-bit Serial Shipping Container </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-SGLN-64 </c>
	    <c> 64-bit Serialized Global Location Number </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-GRAI-64 </c>
	    <c> 64-bit Global Returnable Asset Identifier </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-DOD-64 </c>
	    <c> 64-bit Department of Defense ID </c>
	        <c> <xref target="RFID-DoD-spec"/> </c>
	<c> RFID-GIAI-64 </c>
	    <c> 64-bit Global Individual Asset Identifier </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
<!-- 
	<c> 23 reserved </c> <c> </c> <c> </c>
  -->
	<c> RFID-GID-96 </c>
	    <c> 96-bit Global Identifier </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-SGTIN-96 </c>
	    <c> 96-bit Serialized Global Trade Item Number </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-SSCC-96 </c>
	    <c> 96-bit Serial Shipping Container </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-SGLN-96 </c>
	    <c> 96-bit Serialized Global Location Number </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-GRAI-96 </c>
	    <c> 96-bit Global Returnable Asset Identifier </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-DOD-96 </c>
	    <c> 96-bit Department of Defense ID </c>
	        <c> <xref target="RFID-DoD-spec"/> </c>
	<c> RFID-GIAI-96 </c>
	    <c> 96-bit Global Individual Asset Identifier </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
<!-- 
	<c> 31 reserved </c> <c> </c> <c> </c>
  -->
	<c> RFID-GID-URI </c>
	    <c> Global Identifier represented as URI</c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-SGTIN-URI </c>
	    <c> Serialized Global Trade Item Number represented as URI </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-SSCC-URI </c>
	    <c> Serial Shipping Container represented as URI </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-SGLN-URI </c>
	    <c> Global Location Number represented as URI </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-GRAI-URI </c>
	    <c> Global Returnable Asset Identifier represented as URI </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
	<c> RFID-DOD-URI </c>
	    <c> Department of Defense ID represented as URI </c>
	        <c> <xref target="RFID-DoD-spec"/> </c>
	<c> RFID-GIAI-URI </c>
	    <c> Global Individual Asset Identifier represented as URI </c>
	        <c> <xref target="EPC-Tag-Data"/> </c>
<!-- 
	<c> 39-255 reserved </c> <c> </c> <c> </c>
  -->
	<!-- <postamble> example text </postamble>	-->
    </texttable>

<!--
http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf
     -->

</section>

<section anchor='descr' title='Descriptions of MNID types'>

<t>
	In this section descriptions for the various MNID types are provided.
</t>

<section anchor='descr-ipv6' title='Description of the IPv6 address type'>

<t>
	The IPv6 address <xref target="RFC4291"/> is encoded as a 16 octet
	string containing the full IPv6 address.
</t>

</section>	<!-- end of section 'Description of the IPv6 address type' -->

<section anchor='descr-imsi' title='Description of the IMSI MNID type'>

<t>
	The International Mobile Subscriber Identity (IMSI)
	<xref target="ThreeGPP-IDS"/> is at most 15 decimal digits
	(i.e., digits from 0 through 9).  The IMSI MUST be
	encoded as a string of octets in network order, where each digit
	occupies 4 bits.  The last digit MUST be zero padded, if needed, for
	full octet size.  For example an example IMSI 123456123456789 would
	be encoded as follows:
</t>

	<t>
	<list style='hanging'>
	<t hangText=''>	0x12, 0x34, 0x56, 0x12, 0x34, 0x56, 0x78, 0x90 </t>
	</list>
	</t>

</section>	<!-- end of section 'Description of the IMSI MNID type' -->

<section anchor='descr-eui48' title='Description of the EUI-48 address type'>

<t>
	The IEEE EUI-48 address <xref target="IEEE802-eui48"/> is encoded as
	a 6 octet string containing the IEEE EUI-48 address.
</t>

</section>	<!-- end of section 'Description of the EUI-48 address type' -->

<section anchor='descr-eui64' title='Description of the EUI-64 address type'>

<t>
	The IEEE EUI-64 address <xref target="IEEE802-eui64"/> is encoded as
	a 8 octet string containing the full IEEE EUI-64 address.
</t>

</section>	<!-- end of section 'Description of the EUI-64 address type' -->

<section anchor='descr-llt' title='Description of the DUID-LLT type'>

<t>
	The DUID-LLT is the DHCPv6 Unique Identifier (DUID) formulated by
	concatenating the link-layer address plus a timestamp
	<xref target="RFC3315"/>.
	This type of DUID consists of a two octet type field containing the
	value 1, a two octet hardware type code, four octets containing a
	time value, followed by link-layer address of any one network
	interface that is connected to the DHCP device at the time that the
	DUID is generated.  The time value is the time that the DUID is
	generated represented in seconds since midnight (UTC), January 1,
	2000, modulo 2^32.  Since the link-layer address can be of variable
	length <xref target="RFC2464"/>, the DUID-LLT is of variable length.
</t>

</section>	<!-- end of section 'Description of the DUID-LLT type' -->

<section anchor='descr-en' title='Description of the DUID-EN type'>

<t>
	The DUID-EN is the DHCPv6 Unique Identifier (DUID) formulated by
	concatenating the Enterprise Number plus some additional data
	<xref target="RFC3315"/>.
	This form of DUID is assigned by the vendor to the device.  It
	consists of a two octet type field containing the
	value 2, the vendor's registered Private Enterprise Number as
	maintained by IANA, followed by a unique identifier assigned by
	the vendor.  Since the vendor's unique identifier can be of variable
	length, the DUID-EN is of variable length.
</t>

</section>	<!-- end of section 'Description of the DUID-EN type' -->

<section anchor='descr-ll' title='Description of the DUID-LL type'>

<t>
	The DUID-LL is the DHCPv6 Unique Identifier (DUID) formulated by
	concatenating the network hardware type code and the link-layer
	address <xref target="RFC3315"/>.
	This type of DUID consists of two octets containing the DUID type 3,
	a two octet network hardware type code, followed by the link-layer
	address of any one network interface that is permanently connected to
	the client or server device.  For example, a host that has a network
	interface implemented in a chip that is unlikely to be removed and
	used elsewhere could use a DUID-LL.  Since the link-layer address can
	be of variable length, the DUID-LL is of variable length.
</t>

</section>	<!-- end of section 'Description of the DUID-LL type' -->


<section anchor='descr-uuid' title='Description of the DUID-UUID type'>

<t>
	The DUID-UUID <xref target="RFC6355"/> is the DHCPv6 Unique Identifier
	based on the Universally Unique IDentifier (UUID)
	<xref target="RFC4122"/>.
	This type of DUID consists of two octets containing the DUID type 4,
	followed by 128-bit UUID.
</t>

</section>	<!-- end of section 'Description of the DUID-UUID type' -->


<section anchor='descr-rfid' title='Description of the RFID types'>

<t>
	The General Identifier (GID) that is used with RFID is composed of
	three fields - the General Manager Number, Object Class and Serial
	Number.  The General Manager Number identifies an organizational
	entity that is responsible for maintaining the numbers in subsequent
	fields.  GID encodings include a fourth field, the header, to
	guarantee uniqueness in the namespace defined by EPC.
</t>

<t>
	Some of the RFID types depend on the Global Trade Item Number (GTIN)
	code defined in the General EAN.UCC Specifications
	<xref target="EANUCCGS"/>.  A GTIN identifies a particular class of
	object, such as a particular kind of product or SKU.
</t>

<t>
	The EPC encoding scheme for SGTIN permits the direct embedding of
	EAN.UCC System standard GTIN and Serial Number codes on EPC tags.
	In all cases, the check digit is not encoded. Two encoding schemes
	are specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits).
</t>

<t>
	The Serial Shipping Container Code (SSCC) is defined by the EAN.UCC 
	Specifications.  Unlike the GTIN, the SSCC is already intended 
	for assignment to individual objects and therefore does not require
	additional fields to serve as an EPC pure identity. Two encoding schemes
	are specified, SSCC-64 (64 bits) and SSCC-96 (96 bits).
</t>

<t>
	The Global Location Number (GLN) is defined by the EAN.UCC
	Specifications.  A GLN can represent either a discrete, unique
	physical location such as a warehouse slot, or an aggregate physical
	location such as an entire warehouse.  In addition, a GLN can
	represent a logical entity that performs a business function such
	as placing an order.  The Serialized Global Location Number (SGLN)
	includes the Company Prefix, Location Reference, and Serial Number. 
</t>

<t>
	The Global Returnable Asset Identifier is (GRAI) is defined by the
	General EAN.UCC Specifications.  Unlike the GTIN, the GRAI is already
	intended for assignment to individual objects and therefore does not
	require any additional fields to serve as an EPC pure identity. 
	The GRAI
	includes the Company Prefix, Asset Type, and Serial Number.
</t>

<t>
	The Global Individual Asset Identifier (GIAI) is defined by the
	General EAN.UCC Specifications.  Unlike the GTIN, the GIAI is already
	intended for assignment to individual objects and therefore does not
	require any additional fields to serve as an EPC pure identity. 
	The GRAI
	includes the Company Prefix, and Individual Asset Reference.
</t>


<t>
	The DoD Construct identifier is defined by the United States
	Department of Defense (DoD).  This tag data construct may be used to
	encode tags for shipping goods to the DoD by a supplier who has
	already been assigned a CAGE (Commercial and Government Entity) code. 
</t>

<section anchor='descr-sgtin64' title='Description of the RFID-SGTIN-64 type'>

<t>
	The RFID-SGTIN-64 is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The SGTIN-64 includes five fields: Header, Filter Value (additional
	data that is used for fast filtering and pre-selection),
	Company Prefix Index, Item Reference, and Serial Number.
	Only a limited number of Company Prefixes can be represented in the
	64-bit tag.
</t>
</section>	<!-- end of section 'Description of the RFID-SGTIN-64 type' -->

<section anchor='descr-sgtin96' title='Description of the RFID-SGTIN-96 type'>

<t>
	The RFID-SGTIN-96 is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The SGTIN-96 includes six fields: Header, Filter Value, Partition (an
	indication of where the subsequent Company Prefix and Item
	Reference numbers are divided),
	Company Prefix Index, Item Reference, and Serial Number.
	
</t>
</section>	<!-- end of section 'Description of the RFID-SGTIN-96 type' -->

<section anchor='descr-sscc64' title='Description of the RFID-SSCC-64 type'>

<t>
	The RFID-SSCC-64 is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The SSCC-64 includes four fields: Header, Filter Value,
	Company Prefix Index, and Serial Reference.
	Only a limited number of Company Prefixes can be represented in the
	64-bit tag.
</t>

</section>	<!-- end of section 'Description of the RFID-SSCC-64 type' -->

<section anchor='descr-sscc96' title='Description of the RFID-SSCC-96 type'>

<t>
	The RFID-SSCC-96 is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The SSCC-96 includes six fields: Header, Filter Value,
	Partition, Company Prefix, and Serial Reference, as well as 24 bits
	that remain Unallocated and must be zero.
</t>

</section>	<!-- end of section 'Description of the RFID-SSCC-96 type' -->


<section anchor='descr-sgln64' title='Description of the RFID-SGLN-64 type'>

<t>
	The RFID-SGLN-64 type is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The SGLN-64 includes five fields: Header, Filter Value,
	Company Prefix Index, Location Reference, and Serial Number.
</t>

</section>	<!-- end of section 'Description of the RFID-SGLN-64 type' -->

<section anchor='descr-sgln96' title='Description of the RFID-SGLN-96 type'>

<t>
	The RFID-SGLN-96 type is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The SGLN-96 includes six fields: Header, Filter Value,
	Partition, Company Prefix, Location Reference, and Serial Number.
</t>

</section>	<!-- end of section 'Description of the RFID-SGLN-96 type' -->


<section anchor='descr-grai64' title='Description of the RFID-GRAI-64 type'>

<t>
	The RFID-GRAI-64 type is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The GRAI-64 includes five fields: Header, Filter Value,
	Company Prefix Index, Asset Type, and Serial Number.
</t>

</section>	<!-- end of section 'Description of the RFID-GRAI-64 type' -->


<section anchor='descr-grai96' title='Description of the RFID-GRAI-96 type'>

<t>
	The RFID-GRAI-96 type is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The GRAI-96 includes six fields: Header, Filter Value,
	Partition, Company Prefix, Asset Type, and Serial Number.
</t>

</section>	<!-- end of section 'Description of the RFID-GRAI-96 type' -->

<section anchor='descr-giai64' title='Description of the RFID-GIAI-64 type'>

<t>
	The RFID-GIAI-64 type is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The GIAI-64 includes four fields: Header, Filter Value,
	Company Prefix Index, and Individual Asset Reference.
</t>

</section>	<!-- end of section 'Description of the RFID-GIAI-64 type' -->

<section anchor='descr-giai96' title='Description of the RFID-GIAI-96 type'>

<t>
	The RFID-GIAI-96 type is encoded as specified in
	<xref target="EPC-Tag-Data"/>.
	The GIAI-96 includes five fields: Header, Filter Value,
	Partition, Company Prefix, and Individual Asset Reference.
</t>

</section>	<!-- end of section 'Description of the RFID-GIAI-96 type' -->


<section anchor='descr-dod64' title='Description of the RFID-DoD-64 type'>

<t>
	The RFID-DoD-64 type is encoded as specified in
	<xref target="RFID-DoD-spec"/>.
	The DoD-64 type includes four fields: Header, Filter Value,
	Government Managed Identifier, and Serial Number.
</t>

</section>	<!-- end of section 'Description of the RFID-DoD-64 type' -->


<section anchor='descr-dod96' title='Description of the RFID-DoD-96 type'>

<t>
	The RFID-DoD-96 type is encoded as specified in
	<xref target="RFID-DoD-spec"/>.
	The DoD-96 type includes four fields: Header, Filter Value,
	Government Managed Identifier, and Serial Number.
</t>

</section>	<!-- end of section 'Description of the RFID-DoD-96 type' -->

<section anchor='descr-uri' title='Description of the RFID URI types'>

<t>
	In some cases, it is desirable to encode in URI form a specific
	encoding of an RFID tag.  For example, an application
	may prefer a URI representation for report preparation.  Applications
	that wish to manipulate any additional data fields on tags may need
	some representation other than the pure identity forms.
</t>

<t>
	For this purpose, the fields as represented the previous sections
	are associated with specified fields in the various URI types.
	For instance, the URI may have fields such as CompanyPrefix,
	ItemReference, or SerialNumber.  For details and encoding specifics,
	consult <xref target="EPC-Tag-Data"/>.
</t>

</section>	<!-- end of section 'Description of the RFID URI types' -->

</section>	<!-- end of section 'Description of the RFID types' -->

</section>	<!-- end of section 'Descriptions of MNID types' -->

<section anchor='sec' title='Security Considerations'>

<t>
	This document does not introduce any security mechanisms,
	and does not have any impact on existing security mechanisms.
	Insofar as the selection of a security association may be
	dependent on the exact form of a mobile node identifier,
	additional specification may be necessary when the new
	identifier types are employed with the general AAA mechanisms
	for mobile node authorizations.
</t>

<t>
	Some identifiers (e.g., IMSI) are considered to be private
	information.  If used in the MNID extension as defined in this
	document, the packet including the MNID extension should be
	encrypted so that personal information or trackable identifiers
	would not be inadvertently disclosed to passive observers.
	Operators can potentially apply IPsec Encapsulating Security Payload
	(ESP) with confidentiality and integrity protection for protecting
	the location information.
</t>
<!-- CEP: citation!  -->

<t>
	Moreover, MNIDs containing sensitive identifiers might
	only be used for signaling during initial network entry.
	Subsequent binding update exchanges might then rely on
	a temporary identifier allocated during the initial
	network entry, perhaps using mechanisms not standardized
	within the IETF.  Managing the association between
	long-lived and temporary identifiers is outside the scope
	of this document.
</t>
</section>

<section anchor='iana' title='IANA Considerations'>

<t>
	The new mobile node identifier types defined in the document should
	be assigned values from the "Mobile Node Identifier Option Subtypes"
	registry. The following values should be assigned.
</t>

    <texttable anchor='iana-mnids'>
        <preamble>New Mobile Node Identifier Types</preamble>
        <ttcol align='left'>Identifier Type</ttcol>
        <ttcol align='left'>Identifier Type Number</ttcol>
	<c> IPv6 Address </c>		<c> 2 </c>
	<c> IMSI </c>			<c> 3 </c>
	<c> P-TMSI </c>			<c> 4 </c>
	<c> EUI-48 address </c>		<c> 5 </c>
	<c> EUI-64 address </c>		<c> 6 </c>
	<c> GUTI </c>			<c> 7 </c>
	<c> DUID-LLT </c>		<c> 8 </c>
	<c> DUID-EN </c>		<c> 9 </c>
	<c> DUID-LL </c>		<c> 10 </c>
	<c> DUID-UUID </c>		<c> 11 </c>
	<c>    </c>			<c> 12-15 reserved </c>
	<c>    </c>			<c> 16 reserved </c>
	<c> RFID-SGTIN-64 </c>		<c> 17 </c>
	<c> RFID-SSCC-64 </c>		<c> 18 </c>
	<c> RFID-SGLN-64 </c>		<c> 19 </c>
	<c> RFID-GRAI-64 </c>		<c> 20 </c>
	<c> RFID-DOD-64 </c>		<c> 21 </c>
	<c> RFID-GIAI-64 </c>		<c> 22 </c>
	<c>    </c>			<c> 23 reserved </c>
	<c> RFID-GID-96 </c>		<c> 24 </c>
	<c> RFID-SGTIN-96 </c>		<c> 25 </c>
	<c> RFID-SSCC-96 </c>		<c> 26 </c>
	<c> RFID-SGLN-96 </c>		<c> 27 </c>
	<c> RFID-GRAI-96 </c>		<c> 28 </c>
	<c> RFID-DOD-96 </c>		<c> 29 </c>
	<c> RFID-GIAI-96 </c>		<c> 30 </c>
	<c>    </c>			<c> 31 reserved </c>
	<c> RFID-GID-URI </c>		<c> 32 </c>
	<c> RFID-SGTIN-URI </c>		<c> 33 </c>
	<c> RFID-SSCC-URI </c>		<c> 34 </c>
	<c> RFID-SGLN-URI </c>		<c> 35 </c>
	<c> RFID-GRAI-URI </c>		<c> 36 </c>
	<c> RFID-DOD-URI </c>		<c> 37 </c>
	<c> RFID-GIAI-URI </c>		<c> 38 </c>
	<c>    </c>			<c> 39-255 reserved </c>
	<!-- <postamble> example text </postamble>	-->
    </texttable>

<t>
	See <xref target='descr' /> for additional information
	about the identifier types.
</t>

<!--	<t>						-->
<!--	<list style='hanging'>				-->
<!--	<t hangText='IPv6 Address'>	2 </t>		-->
<!--	<t hangText='IMSI'>		3 </t>		-->
<!--	<t hangText='P-TMSI'>		4 </t>		-->
<!--	<t hangText='EUI-48 address'>	5 </t>		-->
<!--	<t hangText='EUI-64 address'>	6 </t>		-->
<!--	<t hangText='GUTI'>		7 </t>		-->
<!--	</list>						-->
<!--	</t>						-->

</section>


<section anchor='ack' title='Acknowledgements'>

<t>
	The authors wish to acknowledge Hakima Chaouchi, Jouni Korhonen
	and Sri Gundavelli for their helpful comments.
</t>

</section>	<!-- end of section 'Description of the IPv6 address type' -->

</middle>

<back>

<references title='Normative References'>
<?rfc include='reference.RFC.2464.xml'?>
<?rfc include='reference.RFC.3315.xml'?>
<?rfc include='reference.RFC.4122.xml'?>
<?rfc include='reference.RFC.4291.xml'?>
<?rfc include='reference.RFC.4283.xml'?>
<?rfc include='reference.RFC.4285.xml'?>
<?rfc include='reference.RFC.6355.xml'?>
</references>

<references title="Informative References">
<?rfc include='reference.RFC.3588.xml'?>
<reference anchor="ThreeGPP-IDS">
  <front>
    <title>3GPP Technical Specification 23.003 V8.4.0: Technical
    Specification Group Core Network and Terminals; Numbering,
    addressing and identification (Release 8)</title>
    <author surname="3rd Generation Partnership Project">
    <organization>
    </organization>
    </author>
    <date month="March" year="2009"/>
  </front>
</reference>

<reference anchor="EPC-Tag-Data">
  <front>
    <title>
	EPC(TM) Generation 1 Tag Data Standards Version 1.1 Rev.1.27 
http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf
    </title>
    <author surname="EPCglobal Inc.">
    <organization>
    </organization>
    </author>
    <date day='10' month="January" year="2005"/>
  </front>
</reference>

<reference anchor="RFID-DoD-spec">
  <front>
    <title>United States Department of Defense Suppliers Passive RFID
		  Information Guide (Version 15.0)</title>
    <author surname="Department of Defense">
    <organization>
    </organization>
    </author>
    <date month="January" year="2010"/>
  </front>
</reference>

<reference anchor="IEEE802">
  <front>
    <title>IEEE Std 802: IEEE Standards for Local and
    Metropolitan Networks: Overview and Architecture</title>
    <author surname="IEEE">
    <organization>
    </organization>
    </author>
    <date year="2001"/>
  </front>
</reference>

<reference anchor="IEEE802-eui">
  <front>
    <title>Guidelines for Use Organizationally Unique Identifier (OUI) and Company ID (CID)  https://standards.ieee.org/develop/regauth/tut/eui.pdf</title>
    <author surname="IEEE">
    <organization>
    </organization>
    </author>
    <date year="2001"/>
  </front>
</reference>

<reference anchor="IEEE802-eui48">
  <front>
    <title>Guidelines for 48-Bit Global Identifier (EUI-48)  https://standards.ieee.org/develop/regauth/tut/eui48.pdf</title>
    <author surname="IEEE">
    <organization>
    </organization>
    </author>
    <date year="2001"/>
  </front>
</reference>	

<reference anchor="IEEE802-eui64">
  <front>
    <title>Guidelines for 64-Bit Global Identifier (EUI-64)  https://standards.ieee.org/develop/regauth/tut/eui.pdf64</title>
    <author surname="IEEE">
    <organization>
    </organization>
    </author>
    <date year="2001"/>
  </front>
</reference>

<reference anchor="EANUCCGS">
  <front>
    <title>General EAN.UCC Specifications Version 5.0</title>
    <author surname="EAN International and the Uniform Code Council">
    <organization>
    </organization>
    </author>
    <date month="Jan" year="2004"/>
  </front>
</reference>

</references>

<!--  https://standards.ieee.org/develop/regauth/tut/eui48.pdf  -->
<!--  https://standards.ieee.org/develop/regauth/tut/eui64.pdf  -->
<!--  https://standards.ieee.org/develop/regauth/tut/eui.pdf  -->

</back>

</rfc>
