draft-ietf-dmm-4283mnids-08.txt		rfc8371.txt
	Distributed Mobility Management [dmm] C. Perkins		Internet Engineering Task Force (IETF) C. Perkins
	Internet-Draft Futurewei		Request for Comments: 8371 Futurewei
	Intended status: Standards Track V. Devarapalli		Category: Standards Track V. Devarapalli
	Expires: September 19, 2018 Vasona Networks		ISSN: 2070-1721 Vasona Networks
	March 18, 2018		July 2018
	MN Identifier Types for RFC 4283 Mobile Node Identifier Option		Mobile Node Identifier Types for MIPv6
	draft-ietf-dmm-4283mnids-08.txt
	Abstract		Abstract
	Additional Identifier Type Numbers are defined for use with the		This document defines additional identifier type numbers for use with
	Mobile Node Identifier Option for MIPv6 (RFC 4283).		the mobile node identifier option for Mobile IPv6 (MIPv6) as defined
			by RFC 4283.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on September 19, 2018.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8371.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. New Mobile Node Identifier Types . . . . . . . . . . . . . . 3		3. New Mobile Node Identifier Types . . . . . . . . . . . . . . 4
	4. Descriptions of MNID types . . . . . . . . . . . . . . . . . 3		4. Descriptions of MN Identifier Types . . . . . . . . . . . . . 4
	4.1. Description of the IPv6 address type . . . . . . . . . . 3		4.1. Description of the IPv6 Address Type . . . . . . . . . . 4
	4.2. Description of the IMSI MNID type . . . . . . . . . . . . 4		4.2. Description of the IMSI MN Identifier Type . . . . . . . 5
	4.3. Description of the EUI-48 address type . . . . . . . . . 4		4.3. Description of the EUI-48 Address Type . . . . . . . . . 5
	4.4. Description of the EUI-64 address type . . . . . . . . . 4		4.4. Description of the EUI-64 Address Type . . . . . . . . . 5
	4.5. Description of the DUID type . . . . . . . . . . . . . . 4		4.5. Description of the DUID Type . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6		7.2. Informative References . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 6		Appendix A. RFID Types . . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. RFID types . . . . . . . . . . . . . . . . . . . . . 7		A.1. Description of the RFID Types . . . . . . . . . . . . . . 13
	A.1. Description of the RFID types . . . . . . . . . . . . . . 11		A.1.1. Description of the RFID-SGTIN-64 Type . . . . . . . . 14
	A.1.1. Description of the RFID-SGTIN-64 type . . . . . . . . 12		A.1.2. Description of the RFID-SGTIN-96 Type . . . . . . . . 14
	A.1.2. Description of the RFID-SGTIN-96 type . . . . . . . . 12		A.1.3. Description of the RFID-SSCC-64 Type . . . . . . . . 14
	A.1.3. Description of the RFID-SSCC-64 type . . . . . . . . 12		A.1.4. Description of the RFID-SSCC-96 Type . . . . . . . . 14
	A.1.4. Description of the RFID-SSCC-96 type . . . . . . . . 12		A.1.5. Description of the RFID-SGLN-64 Type . . . . . . . . 14
	A.1.5. Description of the RFID-SGLN-64 type . . . . . . . . 12		A.1.6. Description of the RFID-SGLN-96 Type . . . . . . . . 14
	A.1.6. Description of the RFID-SGLN-96 type . . . . . . . . 12		A.1.7. Description of the RFID-GRAI-64 Type . . . . . . . . 15
	A.1.7. Description of the RFID-GRAI-64 type . . . . . . . . 13		A.1.8. Description of the RFID-GRAI-96 Type . . . . . . . . 15
	A.1.8. Description of the RFID-GRAI-96 type . . . . . . . . 13		A.1.9. Description of the RFID-GIAI-64 Type . . . . . . . . 15
	A.1.9. Description of the RFID-GIAI-64 type . . . . . . . . 13		A.1.10. Description of the RFID-GIAI-96 Type . . . . . . . . 15
	A.1.10. Description of the RFID-GIAI-96 type . . . . . . . . 13		A.1.11. Description of the RFID-DoD-64 Type . . . . . . . . . 15
	A.1.11. Description of the RFID-DoD-64 type . . . . . . . . . 13		A.1.12. Description of the RFID-DoD-96 Type . . . . . . . . . 15
	A.1.12. Description of the RFID-DoD-96 type . . . . . . . . . 13		A.1.13. Description of the RFID URI Types . . . . . . . . . . 15
	A.1.13. Description of the RFID URI types . . . . . . . . . . 13		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to		The "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)" [RFC4283]
	be a popular design tool for providing identifiers for mobile nodes		has proved to be a popular design tool for providing identifiers for
	during authentication procedures with AAA protocols such as Diameter		mobile nodes during authentication procedures with Authentication,
	[RFC3588]. To date, only a single type of identifier has been		Authorization, and Accounting (AAA) protocols such as Diameter
	specified, namely the MN NAI. Other types of identifiers are in		[RFC6733]. To date, only a single type of identifier has been
	common use, and even referenced in RFC 4283. In this document, we		specified, namely the Mobile Node (MN) NAI. Other types of
	propose adding some basic types that are defined in various		identifiers are in common use and are even referenced in RFC 4283.
	telecommunications standards, including types for IMSI		In this document, we propose adding some basic identifier types that
	[ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and GUTI		are defined in various telecommunications standards, including types
	[ThreeGPP-IDS]. In addition, we specify the IPv6 address itself and		for International Mobile Subscriber Identity (IMSI) [ThreeGPP-IDS],
	IEEE MAC-layer addresses as mobile node identifiers. Defining		Packet - Temporary Mobile Subscriber Identity (P-TMSI)
	identifiers that are tied to the physical elements of the device (		[ThreeGPP-IDS], International Mobile station Equipment Identities
	MAC address etc.) help in deployment of Mobile IP because in many		(IMEI) [ThreeGPP-IDS], and Globally Unique Temporary UE Identity
	cases such identifiers are the most natural means for uniquely		(GUTI) [ThreeGPP-IDS]. In addition, we specify the IPv6 address
	identifying the device, and will avoid additional look-up steps that		itself and IEEE MAC-layer addresses as Mobile Node identifiers.
	might be needed if other identifiers were used.		Defining identifiers that are tied to the physical elements of the
			device (e.g., the MAC address) 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 lookup
			steps that might be needed if other identifiers were used.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. New Mobile Node Identifier Types		3. New Mobile Node Identifier Types
	The following types of identifiers are commonly used to identify		The following types of identifiers are commonly used to identify
	mobile nodes. For each type, references are provided with full		mobile nodes. For each type, references are provided with full
	details on the format of the type of identifer.		details on the format of the type of identifier.
	Mobile Node Identifier Description
	+--------------+-----------------------------------+----------------+		+--------------+-----------------------------------+----------------+
	| Identifier | Description | Reference |		| Identifier | Description | Reference |
	| Type | | |		| Type | | |
	+--------------+-----------------------------------+----------------+		+--------------+-----------------------------------+----------------+
	| IPv6 Address | | [RFC4291] |		| IPv6 Address | | [RFC4291] |
			| | | |
	| IMSI | International Mobile Subscriber | [ThreeGPP-IDS] |		| IMSI | International Mobile Subscriber | [ThreeGPP-IDS] |
	| | Identity | |		| | Identity | |
	| P-TMSI | Packet-Temporary Mobile | [ThreeGPP-IDS] |		| | | |
			| P-TMSI | Packet - Temporary Mobile | [ThreeGPP-IDS] |
	| | Subscriber Identity | |		| | Subscriber Identity | |
	| GUTI | Globally Unique Temporary ID | [ThreeGPP-IDS] |		| | | |
	| EUI-48 | 48-bit Extended Unique Identifier | [IEEE802] |		| GUTI | Globally Unique Temporary UE | [ThreeGPP-IDS] |
	| address | | |		| | Identity | |
	| EUI-64 | 64-bit Extended Unique | [IEEE802] |		| | | |
	| address | Identifier-64 bit | |		| EUI-48 | 48-Bit Extended Unique Identifier | [IEEE802] |
			| Address | | |
			| | | |
			| EUI-64 | 64-Bit Extended Unique Identifier | [IEEE802] |
			| Address | | |
			| | | |
	| DUID | DHCPv6 Unique Identifier | [RFC3315] |		| DUID | DHCPv6 Unique Identifier | [RFC3315] |
	+--------------+-----------------------------------+----------------+		+--------------+-----------------------------------+----------------+
	Table 1		Table 1: Mobile Node Identifier Description
	4. Descriptions of MNID types		4. Descriptions of MN Identifier Types
	In this section descriptions for the various MNID types are provided.		This section provides descriptions for the various MN identifier
			types.
	4.1. Description of the IPv6 address type		4.1. Description of the IPv6 Address Type
	The IPv6 address [RFC4291] is encoded as a 16 octet string containing		The IPv6 address [RFC4291] is encoded as a 16-octet string containing
	a full IPv6 address which has been assigned to the mobile node. The		a full IPv6 address that has been assigned to the mobile node. The
	IPv6 address MUST be a unicast routable IPv6 address. Multicast		IPv6 address MUST be a unicast routable IPv6 address. Multicast
	addresses, link-local addresses, and the unspecified IPv6 address		addresses, link-local addresses, and the unspecified IPv6 address
	MUST NOT be used. IPv6 Unique Local Addresses (ULAs) MAY be used, as		MUST NOT be used. IPv6 Unique Local Addresses (ULAs) MAY be used as
	long as any security operations making use of the ULA also take into		long as any security operations making use of the ULA also take into
	account the domain in which the ULA is guaranteed to be unique.		account the domain in which the ULA is guaranteed to be unique.
	4.2. Description of the IMSI MNID type		4.2. Description of the IMSI MN Identifier Type
	The International Mobile Subscriber Identity (IMSI) [ThreeGPP-IDS] is		The International Mobile Subscriber Identity (IMSI) [ThreeGPP-IDS] is
	at most 15 decimal digits (i.e., digits from 0 through 9). The IMSI		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 (i.e., high-		MUST be encoded as a string of octets in network order (i.e., high to
	to-low for all digits), where each digit occupies 4 bits. If needed		low for all digits), where each digit occupies 4 bits. If needed for
	for full octet size, the last digit MUST be padded with 0xf. For		full octet size, the last digit MUST be padded with 0xf. For
	example an example IMSI 123456123456789 would be encoded as follows:		instance, an example IMSI 123456123456789 would be encoded as
			follows:
	0x12, 0x34, 0x56, 0x12, 0x34, 0x56, 0x78, 0x9f		0x12, 0x34, 0x56, 0x12, 0x34, 0x56, 0x78, 0x9f
	4.3. Description of the EUI-48 address type		4.3. Description of the EUI-48 Address Type
	The IEEE EUI-48 address [IEEE802-eui48] is encoded as 6 octets		The IEEE EUI-48 address [IEEE802-GUIDELINES] is encoded as 6 octets
	containing the IEEE EUI-48 address.		containing the IEEE EUI-48 address.
	4.4. Description of the EUI-64 address type		4.4. Description of the EUI-64 Address Type
	The IEEE EUI-64 address [IEEE802-eui64] is encoded as 8 octets		The IEEE EUI-64 address [IEEE802-GUIDELINES] is encoded as 8 octets
	containing the full IEEE EUI-64 address.		containing the full IEEE EUI-64 address.
	4.5. Description of the DUID type		4.5. Description of the DUID Type
	The DUID is the DHCPv6 Unique Identifier (DUID) [RFC3315]. There are		The DUID is the DHCPv6 Unique Identifier [RFC3315]. There are
	various types of DUID, which are distinguished by an initial two-		various types of DUIDs, which are distinguished by an initial two-
	octet type field. Clients and servers MUST treat DUIDs as opaque		octet type field. Clients and servers MUST treat DUIDs as opaque
	values and MUST only compare DUIDs for equality.		values and MUST only compare DUIDs for equality.
	5. Security Considerations		5. Security Considerations
	This document does not introduce any security mechanisms, and does		This document does not introduce any security mechanisms and does not
	not have any impact on existing security mechanisms.		have any impact on existing security mechanisms.
	Mobile Node Identifiers such as those described in this document are		Mobile node identifiers such as those described in this document are
	considered to be private information. If used in the MNID extension		considered to be private information. If used in the MN identifier
	as defined in [RFC4283], the packet including the MNID extension MUST		extension as defined in [RFC4283], the packet including the MN
	be encrypted so that no personal information or trackable identifiers		identifier extension MUST be encrypted so that no personal
	is inadvertently disclosed to passive observers. Operators can		information or trackable identifiers are inadvertently disclosed to
	potentially apply IPsec Encapsulating Security Payload (ESP)		passive observers. Operators can potentially apply IPsec
	[RFC4303], in transport mode, with confidentiality and integrity		Encapsulating Security Payload (ESP) [RFC4303] in transport mode with
	protection for protecting the identity and location information in		confidentiality and integrity protection for protecting the identity
	Mobile IPv6 signaling messages.		and location information in MIPv6 signaling messages.
	Some MNIDs contain sensitive identifiers which, as used in protocols		Some MN identifiers contain sensitive identifiers that, as used in
	specified by other SDOs, are only used for signaling during initial		protocols specified by other Standards Development Organizations
	network entry. In such protocols, subsequent exchanges then rely on		(SDOs), are only used for signaling during initial network entry. In
	a temporary identifier allocated during the initial network entry.		such protocols, subsequent exchanges then rely on a temporary
	Managing the association between long-lived and temporary identifiers		identifier allocated during the initial network entry. Managing the
	is outside the scope of this document.		association between long-lived and temporary identifiers is outside
			the scope of this document.
	6. IANA Considerations		6. IANA Considerations
	The new mobile node identifier types defined in the document should		The new mobile node identifier types defined in this document have
	be assigned values from the "Mobile Node Identifier Option Subtypes"		been assigned values from the "Mobile Node Identifier Option
	registry. The following values should be assigned.		Subtypes" registry. The following values have been registered.
	New Mobile Node Identifier Types
	+-----------------+------------------------+		+-----------------+------------------------+
	| Identifier Type | Identifier Type Number |		| Identifier Type | Identifier Type Number |
	+-----------------+------------------------+		+-----------------+------------------------+
	| IPv6 Address | 2 |		| IPv6 Address | 2 |
	| IMSI | 3 |		| IMSI | 3 |
	| P-TMSI | 4 |		| P-TMSI | 4 |
	| EUI-48 address | 5 |		| EUI-48 address | 5 |
	| EUI-64 address | 6 |		| EUI-64 address | 6 |
	| GUTI | 7 |		| GUTI | 7 |
	| DUID-LLT | 8 |		| DUID | 8 |
	| DUID-EN | 9 |		| Reserved | 9-15 |
	| DUID-LL | 10 |		| Unassigned | 16-255 |
	| DUID-UUID | 11 |
	| | 12-15 reserved |
	| | 16-255 unassigned |
	+-----------------+------------------------+		+-----------------+------------------------+
	Table 2		Table 2: New Mobile Node Identifier Types
	See Section 4 for additional information about the identifier types.		See Section 4 for additional information about the identifier types.
	Future new assignments are to be made only after Expert Review		The registration procedure is Standards Action [RFC8126]. The expert
	[RFC8126]. The expert must ascertain that the identifier type allows		must ascertain that the identifier type allows unique identification
	unique identification of the mobile device; since all MNIDs require		of the mobile device; since all MN identifiers require encryption,
	encryption there is no additional privacy exposure attendent to the		there is no additional privacy exposure attendant to the use of new
	use of new types.		types.
	7. Acknowledgements
	The authors wish to acknowledge Hakima Chaouchi, Tatuya Jinmei, Jouni
	Korhonen, Sri Gundavelli, Suresh Krishnan, Dapeng Liu, Dale Worley,
	Joseph Salowey, Linda Dunbar, and Mirja Kuehlewind for their helpful
	comments.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,		[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
	C., and M. Carney, "Dynamic Host Configuration Protocol		C., and M. Carney, "Dynamic Host Configuration Protocol
	for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July		for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
	2003, <https://www.rfc-editor.org/info/rfc3315>.		2003, <https://www.rfc-editor.org/info/rfc3315>.
	skipping to change at page 6, line 37 ¶		skipping to change at page 7, line 23 ¶
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	8.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			7.2. Informative References
	[EANUCCGS]		[EANUCCGS]
	EAN International and the Uniform Code Council, "General		EAN International and the Uniform Code Council, "General
	EAN.UCC Specifications Version 5.0", Jan 2004.		EAN.UCC Specifications", Version 5.0, January 2004.
	[EPC-Tag-Data]		[EPC-Tag-Data]
	EPCglobal Inc., "EPC(TM) Generation 1 Tag Data Standards		EPCglobal, Inc., "EPC Generation 1 Tag Data Standards
	Version 1.1 Rev.1.27		Version 1.1 Rev.1.27", May 2005,
	http://www.gs1.org/gsmp/kc/epcglobal/tds/		<https://www.gs1.org/sites/default/files/docs/epc/
	tds_1_1_rev_1_27-standard-20050510.pdf", January 2005.		tds_1_1_rev_1_27-standard-20050510.pdf>.
	[IEEE802] IEEE, "IEEE Std 802: IEEE Standards for Local and
	Metropolitan Networks: Overview and Architecture", 2001.
	[IEEE802-eui48]		[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area
	IEEE, "Guidelines for 48-Bit Global Identifier (EUI-48)		Networks: Overview and Architecture", IEEE 802.
	https://standards.ieee.org/develop/regauth/tut/eui48.pdf",
	2001.
	[IEEE802-eui64]		[IEEE802-GUIDELINES]
	IEEE, "Guidelines for 64-Bit Global Identifier (EUI-64)		IEEE, "Guidelines for Use of Extended Unique Identifier
	https://standards.ieee.org/develop/regauth/tut/eui.pdf64",		(EUI), Organizationally Unique Identifier (OUI), and
	2001.		Company ID (CID)", August 2018,
			<http://standards.ieee.org/develop/regauth/tut/eui.pdf>.
	[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.		[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
	Arkko, "Diameter Base Protocol", RFC 3588,		Ed., "Diameter Base Protocol", RFC 6733,
	DOI 10.17487/RFC3588, September 2003,		DOI 10.17487/RFC6733, October 2012,
	<https://www.rfc-editor.org/info/rfc3588>.		<https://www.rfc-editor.org/info/rfc6733>.
	[RFID-DoD-spec]		[RFID-DoD-spec]
	Department of Defense, "United States Department of		Department of Defense, "United States Department of
	Defense Suppliers Passive RFID Information Guide (Version		Defense Suppliers' Passive RFID Information Guide",
	15.0)", January 2010.		Version 15.0, January 2010.
	[RFID-framework]		[RFID-framework]
	Institut National des Telecommunication, ""Heterogeneous		Botero, O., "Heterogeneous RFID framework design, analysis
	RFID framework design, analysis and evaluation"", July		and evaluation", Institut National des Telecommunications,
	2012.		July 2012.
	[ThreeGPP-IDS]		[ThreeGPP-IDS]
	3rd Generation Partnership Project, "3GPP Technical		3GPP, "3rd Generation Partnership Project; Technical
	Specification 23.003 V8.4.0: Technical Specification Group		Specification Group Core Network and Terminals; Numbering,
	Core Network and Terminals; Numbering, addressing and		addressing and identification (Release 15)", 3GPP
	identification (Release 8)", March 2009.		TS 23.003, V15.3.0, March 2018.
	[TRACK-IoT]		[TRACK-IoT]
	IPv6.com, ""Heterogeneous IoT Network : TRACK-IoT"", March		Chaouchi, H., "Heterogeneous IoT Network: TRACK-IoT
	2012.		Plateform", Telecom SudParis, Internal Report, March 2012.
	[Using-RFID-IPv6]		[Using-RFID-IPv6]
	IPv6.com, ""Using RFID & IPv6"", September 2006.		IPv6.com, "Using RFID & IPv6", September 2006.
	Appendix A. RFID types		Appendix A. RFID Types
	The material in this non-normative appendix was originally composed		The material in this non-normative appendix was originally composed
	for inclusion in the main body of the specification, but was moved		for inclusion in the main body of the specification but was moved
	into an appendix because there was insufficient support for		into an appendix because there was insufficient support for
	allocating RFID types at this time. It was observed that RFID-based		allocating Radio Frequency Identification (RFID) types at the time.
	mobile devices may create privacy exposures unless confidentiality is		It was observed that RFID-based mobile devices may create privacy
	assured for signaling. A specification for eliminating unauthorized		exposures unless confidentiality is assured for signaling. A
	RFID tracking based on layer-2 addresses would be helpful.		specification for eliminating unauthorized RFID tracking based on
			Layer 2 addresses would be helpful.
	Much of the following text is due to contributions from Hakima		Much of the following text is due to contributions from Hakima
	Chaouchi. For an overview and some initial suggestions about using		Chaouchi. For an overview and some initial suggestions about using
	RFID with IPv6 on mobile devices, see [Using-RFID-IPv6].		RFID with IPv6 on mobile devices, see [Using-RFID-IPv6].
	In the context of IoT and industry 4.0 vertical domain, efficient		In the context of Internet of Things (IoT) and Industry 4.0, vertical
	inventory and tracking items is of major interest, and RFID		domain, efficient inventory, and tracking items are of major
	technology is the identification technology in the hardware design of		interest, and RFID technology is the identification technology in the
	many such items.		hardware design of many such items.
	The "TRACKIOT: Heterogeneous IoT control" project ([TRACK-IoT],		The "TRACK-IoT" project [TRACK-IoT] [RFID-framework] explored Mobile
	[RFID-framework]) explored Mobile IPv6 as a mobility management		IPv6 as a mobility management protocol for RFID-based mobile devices.
	protocol for RFID-based mobile devices.
	1. Passive RFID tags (that have no processing resources) need to be		1. Passive RFID tags (that have no processing resources) need to be
	handled by the gateway (likely also the RFID Reader), which is		handled by the gateway (likely also the RFID reader), which is
	then the end point of the mobility protocol. It is also the		then the endpoint of the mobility protocol. It is also the point
	point where the CoA will be created based on some combination		where the Change of Address (CoA) will be created based on some
	such as the RFID tag and the prefix of that gateway. The point		combination such as the RFID tag and the prefix of that gateway.
	here is to offer the possibility to passive RFID items to get an		The point here is to offer the possibility to passive RFID items
	IPv6 address and take advantage of the mobility framework to		to get an IPv6 address and take advantage of the mobility
	follow the mobile device (passive tag on the item). One example		framework to follow the mobile device (passive tag on the item).
	scenario that has been proposed, showing the need for mobility		One example scenario that has been proposed, which shows the need
	management of passive RFID items, would be pieces of art tagged		for mobility management of passive RFID items, would be pieces of
	with passive tags that need to be monitored while transported.		art tagged with passive tags that need to be monitored while
	2. Using active RFID tags (where processing resource is available on		transported.
	the tag), the end point of the mobility protocol can be pushed up
	to the RFID Active tag. We name it also an identification
	sensor. Use cases include active RFID tags for traceability of
	cold food respect during mobility (transport) of food. Mobility
	of cars equiped with active RFID tags that we already use for
	toll payement can be added with mobility management.
	One major effort of connecting IETF efforts to the EPCGlobal (RFID		2. Using active RFID tags (where the processing resource is
	standardisation) led to the ONS (DNS version applied for RFID logical		available on the tag), the endpoint of the mobility protocol can
	names and page information retrieval). Attempts have tried to		be hosted directly on the RFID active tag, which is also called
	connect IPv6 on the address space to RFID identifier format. Other		an identification sensor. A use case for active RFID tags
	initiatives started working on gateways to map tag identifiers with		includes traceability of cold food during mobility (transport).
	IPv6 addresses and build signaling protocols for the application		Also, mobility of cars equipped with active RFID tags that we
	level. For instance tracking of mobile items equipped with a tag can		already use for toll payment can be added with mobility
	be triggered remotely by a remote correspondent node until a visiting		management.
	area where a mobile item equipped with an RFID tag is located. An
	RFID reader will be added with an IPv6 to RFID tag translation. One
	option is to build a Home IPv6 address of that tagged item by using
	the prefix of the Home agent combined with the tag RFID identifier of
	the mobile item; as the tag ID is unique, the home IPv6 address of
	that item will be also unique. Then the visiting RFID reader will
	compose the IPV6 care of address of the tagged mobile item by
	combining the prefix of the RFID reader with the tag ID of the item).
	MIPv6 can then provide normally the mobility management of that RFID		One major effort to connect IETF efforts to EPCglobal (RFID
	tagged item. A different useful example of tagged items involves		standardization) led to the Object Name Service (ONS), which is the
	items of a factory that can be tracked while they are transported,		DNS version applied for RFID logical names and page information
	especially for real time localisation and tracking of precious items		retrieval. Attempts have been made to connect IPv6 on the address
	transported without GPS. An automotive car manufacturer can assign		space to RFID identifier format. Other initiatives started working
	IPv6 addresses corresponding to RFID tagged cars or mechanical car		on gateways to map tag identifiers with IPv6 addresses and build
	parts, and build a tracking dataset of the mobility not only of the		signaling protocols for the application level. For instance,
	cars, but also of the mechanical pieces.		tracking of mobile items equipped with a tag can be triggered
			remotely by a remote correspondent node until a visiting area where a
			mobile item equipped with an RFID tag is located. An RFID reader
			will be added with an IPv6-to-RFID tag translation. One option is to
			build a home IPv6 address of that tagged item by using the prefix of
			the home agent combined with the tag RFID identifier of the mobile
			item; as the tag ID is unique, the home IPv6 address of that item
			will be also unique. Then, the visiting RFID reader will compose the
			IPv6 care of address of the tagged mobile item by combining the
			prefix of the RFID reader with the tag ID of the item. MIPv6 can
			then normally provide the mobility management of that RFID-tagged
			item. A different, useful example of tagged items involves items of
			a factory that can be tracked while they are transported, especially
			for real-time localization and tracking of precious items transported
			without GPS. An automotive car manufacturer can assign IPv6
			addresses corresponding to RFID-tagged cars or mechanical car parts
			and build a tracking data set of the mobility not only of the cars,
			but also of the mechanical pieces.
	The Tag Data standard promoted by Electronic Product Code(TM)		The Tag Data Standard promoted by Electronic Product Code (EPC)
	(abbreviated EPC) [EPC-Tag-Data] supports several encoding systems or		[EPC-Tag-Data] supports several encoding systems or schemes, which
	schemes, which are commonly used in RFID (radio-frequency		are commonly used in RFID applications, including the following:
	identification) applications, including
	o RFID-GID (Global Identifier),		o RFID-GID (Global Identifier),
	o RFID-SGTIN (Serialized Global Trade Item Number),		o RFID-SGTIN (Serialized Global Trade Item Number),
	o RFID-SSCC (Serial Shipping Container),
	o RFID-SGLN (Global Location Number),		o RFID-SSCC (Serial Shipping Container Code),
			o RFID-SGLN (Serialized Global Location Number),
	o RFID-GRAI (Global Returnable Asset Identifier),		o RFID-GRAI (Global Returnable Asset Identifier),
	o RFID-DOD (Department of Defense ID), and		o RFID-DOD (Department of Defense ID), and
	o RFID-GIAI (Global Individual Asset Identifier).		o RFID-GIAI (Global Individual Asset Identifier).
	For each RFID scheme except GID, there are three representations:		For each RFID scheme except GID, there are three representations:
	o a 64-bit binary representation (for example, SGLN-64) (except for		o a 64-bit binary representation (for example, SGLN-64), excluding
	GID)		GID,
	o a 96-bit binary representation (SGLN-96)
	o a representation as a URI		o a 96-bit binary representation (SGLN-96), and
			o a representation as a URI.
	The URI representation for the RFID is actually a URN. The EPC		The URI representation for the RFID is actually a URN. The EPC
	document has the following language:		document has the following language:
	All categories of URIs are represented as Uniform Reference Names		All categories of URIs are represented as Uniform Reference Names
	(URNs) as defined by [RFC2141], where the URN Namespace is epc.		(URNs) as defined by [RFC2141], where the URN Namespace is epc.
	The following list includes the above RFID types.		The following list includes the above RFID types.
	Mobile Node RFID Identifier Description
	+----------------+--------------------------------+-----------------+		+----------------+--------------------------------+-----------------+
	| Identifier | Description | Reference |		| Identifier | Description | Reference |
	| Type | | |		| Type | | |
	+----------------+--------------------------------+-----------------+		+----------------+--------------------------------+-----------------+
	| RFID-SGTIN-64 | 64-bit Serialized Global Trade | [EPC-Tag-Data] |		| RFID-SGTIN-64 | 64-bit Serialized Global Trade | [EPC-Tag-Data] |
	| | Item Number | |		| | Item Number | |
	| RFID-SSCC-64 | 64-bit Serial Shipping | [EPC-Tag-Data] |		| RFID-SSCC-64 | 64-bit Serial Shipping | [EPC-Tag-Data] |
	| | Container | |		| | Container Code | |
	| RFID-SGLN-64 | 64-bit Serialized Global | [EPC-Tag-Data] |		| RFID-SGLN-64 | 64-bit Serialized Global | [EPC-Tag-Data] |
	| | Location Number | |		| | Location Number | |
	| RFID-GRAI-64 | 64-bit Global Returnable Asset | [EPC-Tag-Data] |		| RFID-GRAI-64 | 64-bit Global Returnable Asset | [EPC-Tag-Data] |
	| | Identifier | |		| | Identifier | |
	| RFID-DOD-64 | 64-bit Department of Defense | [RFID-DoD-spec] |		| RFID-DOD-64 | 64-bit Department of Defense | [RFID-DoD-spec] |
	| | ID | |		| | ID | |
	| RFID-GIAI-64 | 64-bit Global Individual Asset | [EPC-Tag-Data] |		| RFID-GIAI-64 | 64-bit Global Individual Asset | [EPC-Tag-Data] |
	| | Identifier | |		| | Identifier | |
	| RFID-GID-96 | 96-bit Global Identifier | [EPC-Tag-Data] |		| RFID-GID-96 | 96-bit Global Identifier | [EPC-Tag-Data] |
	| RFID-SGTIN-96 | 96-bit Serialized Global Trade | [EPC-Tag-Data] |		| RFID-SGTIN-96 | 96-bit Serialized Global Trade | [EPC-Tag-Data] |
	skipping to change at page 10, line 37 ¶		skipping to change at page 12, line 35 ¶
	| | Container | |		| | Container | |
	| RFID-SGLN-96 | 96-bit Serialized Global | [EPC-Tag-Data] |		| RFID-SGLN-96 | 96-bit Serialized Global | [EPC-Tag-Data] |
	| | Location Number | |		| | Location Number | |
	| RFID-GRAI-96 | 96-bit Global Returnable Asset | [EPC-Tag-Data] |		| RFID-GRAI-96 | 96-bit Global Returnable Asset | [EPC-Tag-Data] |
	| | Identifier | |		| | Identifier | |
	| RFID-DOD-96 | 96-bit Department of Defense | [RFID-DoD-spec] |		| RFID-DOD-96 | 96-bit Department of Defense | [RFID-DoD-spec] |
	| | ID | |		| | ID | |
	| RFID-GIAI-96 | 96-bit Global Individual Asset | [EPC-Tag-Data] |		| RFID-GIAI-96 | 96-bit Global Individual Asset | [EPC-Tag-Data] |
	| | Identifier | |		| | Identifier | |
	| RFID-GID-URI | Global Identifier represented | [EPC-Tag-Data] |		| RFID-GID-URI | Global Identifier represented | [EPC-Tag-Data] |
	| | as URI | |		| | as a URI | |
	| RFID-SGTIN-URI | Serialized Global Trade Item | [EPC-Tag-Data] |		| RFID-SGTIN-URI | Serialized Global Trade Item | [EPC-Tag-Data] |
	| | Number represented as URI | |		| | Number represented as a URI | |
	| RFID-SSCC-URI | Serial Shipping Container | [EPC-Tag-Data] |		| RFID-SSCC-URI | Serial Shipping Container Code | [EPC-Tag-Data] |
	| | represented as URI | |		| | represented as a URI | |
	| RFID-SGLN-URI | Global Location Number | [EPC-Tag-Data] |		| RFID-SGLN-URI | Global Location Number | [EPC-Tag-Data] |
	| | represented as URI | |		| | represented as a URI | |
	| RFID-GRAI-URI | Global Returnable Asset | [EPC-Tag-Data] |		| RFID-GRAI-URI | Global Returnable Asset | [EPC-Tag-Data] |
	| | Identifier represented as URI | |		| | Identifier represented as a | |
			| | URI | |
	| RFID-DOD-URI | Department of Defense ID | [RFID-DoD-spec] |		| RFID-DOD-URI | Department of Defense ID | [RFID-DoD-spec] |
	| | represented as URI | |		| | represented as a URI | |
	| RFID-GIAI-URI | Global Individual Asset | [EPC-Tag-Data] |		| RFID-GIAI-URI | Global Individual Asset | [EPC-Tag-Data] |
	| | Identifier represented as URI | |		| | Identifier represented as a | |
			| | URI | |
	+----------------+--------------------------------+-----------------+		+----------------+--------------------------------+-----------------+
	Table 3		Table 3: Mobile Node RFID Identifier Description
	A.1. Description of the RFID types		A.1. Description of the RFID Types
			The material in this appendix has been either quoted or loosely
			adapted from [EPC-Tag-Data].
	The General Identifier (GID) that is used with RFID is composed of		The General Identifier (GID) that is used with RFID is composed of
	three fields - the General Manager Number, Object Class and Serial		three fields: General Manager Number, Object Class, and Serial
	Number. The General Manager Number identifies an organizational		Number. The General Manager Number identifies an organizational
	entity that is responsible for maintaining the numbers in subsequent		entity that is responsible for maintaining the numbers in subsequent
	fields. GID encodings include a fourth field, the header, to		fields. GID encodings include a fourth field, the header, to
	guarantee uniqueness in the namespace defined by EPC.		guarantee uniqueness in the namespace defined by EPC.
	Some of the RFID types depend on the Global Trade Item Number (GTIN)		Some of the RFID types depend on the Global Trade Item Number (GTIN)
	code defined in the General EAN.UCC Specifications [EANUCCGS]. A		code defined in the EAN.UCC General Specifications [EANUCCGS]. A
	GTIN identifies a particular class of object, such as a particular		GTIN identifies a particular class of object, such as a particular
	kind of product or SKU.		kind of product or SKU.
	The EPC encoding scheme for SGTIN permits the direct embedding of		The EPC encoding scheme for SGTIN permits the direct embedding of
	EAN.UCC System standard GTIN and Serial Number codes on EPC tags. In		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		all cases, the check digit is not encoded. Two encoding schemes are
	specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits).		specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits).
	The Serial Shipping Container Code (SSCC) is defined by the EAN.UCC		The Serial Shipping Container Code (SSCC) is defined by the EAN.UCC
	Specifications. Unlike the GTIN, the SSCC is already intended for		Specifications. Unlike the GTIN, the SSCC is already intended for
	skipping to change at page 11, line 48 ¶		skipping to change at page 13, line 51 ¶
	The Global Returnable Asset Identifier (GRAI) is defined by the		The Global Returnable Asset Identifier (GRAI) is defined by the
	General EAN.UCC Specifications. Unlike the GTIN, the GRAI is already		General EAN.UCC Specifications. Unlike the GTIN, the GRAI is already
	intended for assignment to individual objects and therefore does not		intended for assignment to individual objects and therefore does not
	require any additional fields to serve as an EPC pure identity. The		require any additional fields to serve as an EPC pure identity. The
	GRAI includes the Company Prefix, Asset Type, and Serial Number.		GRAI includes the Company Prefix, Asset Type, and Serial Number.
	The Global Individual Asset Identifier (GIAI) is defined by the		The Global Individual Asset Identifier (GIAI) is defined by the
	General EAN.UCC Specifications. Unlike the GTIN, the GIAI is already		General EAN.UCC Specifications. Unlike the GTIN, the GIAI is already
	intended for assignment to individual objects and therefore does not		intended for assignment to individual objects and therefore does not
	require any additional fields to serve as an EPC pure identity. The		require any additional fields to serve as an EPC pure identity. The
	GRAI includes the Company Prefix, and Individual Asset Reference.		GRAI includes the Company Prefix and Individual Asset Reference.
	The DoD Construct identifier is defined by the United States		The DoD Construct identifier is defined by the United States
	Department of Defense (DoD). This tag data construct may be used to		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		encode tags for shipping goods to the DoD by a supplier who has
	already been assigned a CAGE (Commercial and Government Entity) code.		already been assigned a Commercial and Government Entity (CAGE) code.
	A.1.1. Description of the RFID-SGTIN-64 type		A.1.1. Description of the RFID-SGTIN-64 Type
	The RFID-SGTIN-64 is encoded as specified in [EPC-Tag-Data]. The		The RFID-SGTIN-64 is encoded as specified in [EPC-Tag-Data]. The
	SGTIN-64 includes five fields: Header, Filter Value (additional data		SGTIN-64 includes five fields: Header, Filter Value (additional data
	that is used for fast filtering and pre-selection), Company Prefix		that is used for fast filtering and preselection), Company Prefix
	Index, Item Reference, and Serial Number. Only a limited number of		Index, Item Reference, and Serial Number. Only a limited number of
	Company Prefixes can be represented in the 64-bit tag.		Company Prefixes can be represented in the 64-bit tag.
	A.1.2. Description of the RFID-SGTIN-96 type		A.1.2. Description of the RFID-SGTIN-96 Type
	The RFID-SGTIN-96 is encoded as specified in [EPC-Tag-Data]. The		The RFID-SGTIN-96 is encoded as specified in [EPC-Tag-Data]. The
	SGTIN-96 includes six fields: Header, Filter Value, Partition (an		SGTIN-96 includes six fields: Header, Filter Value, Partition (an
	indication of where the subsequent Company Prefix and Item Reference		indication of where the subsequent Company Prefix and Item Reference
	numbers are divided), Company Prefix Index, Item Reference, and		numbers are divided), Company Prefix Index, Item Reference, and
	Serial Number.		Serial Number.
	A.1.3. Description of the RFID-SSCC-64 type		A.1.3. Description of the RFID-SSCC-64 Type
	The RFID-SSCC-64 is encoded as specified in [EPC-Tag-Data]. The		The RFID-SSCC-64 is encoded as specified in [EPC-Tag-Data]. The
	SSCC-64 includes four fields: Header, Filter Value, Company Prefix		SSCC-64 includes four fields: Header, Filter Value, Company Prefix
	Index, and Serial Reference. Only a limited number of Company		Index, and Serial Reference. Only a limited number of Company
	Prefixes can be represented in the 64-bit tag.		Prefixes can be represented in the 64-bit tag.
	A.1.4. Description of the RFID-SSCC-96 type		A.1.4. Description of the RFID-SSCC-96 Type
	The RFID-SSCC-96 is encoded as specified in [EPC-Tag-Data]. The		The RFID-SSCC-96 is encoded as specified in [EPC-Tag-Data]. The
	SSCC-96 includes six fields: Header, Filter Value, Partition, Company		SSCC-96 includes six fields: Header, Filter Value, Partition, Company
	Prefix, and Serial Reference, as well as 24 bits that remain		Prefix, and Serial Reference, as well as 24 bits that remain
	Unallocated and must be zero.		unallocated and must be zero.
	A.1.5. Description of the RFID-SGLN-64 type		A.1.5. Description of the RFID-SGLN-64 Type
	The RFID-SGLN-64 type is encoded as specified in [EPC-Tag-Data]. The		The RFID-SGLN-64 type is encoded as specified in [EPC-Tag-Data]. The
	SGLN-64 includes five fields: Header, Filter Value, Company Prefix		SGLN-64 includes five fields: Header, Filter Value, Company Prefix
	Index, Location Reference, and Serial Number.		Index, Location Reference, and Serial Number.
	A.1.6. Description of the RFID-SGLN-96 type		A.1.6. Description of the RFID-SGLN-96 Type
	The RFID-SGLN-96 type is encoded as specified in [EPC-Tag-Data]. The		The RFID-SGLN-96 type is encoded as specified in [EPC-Tag-Data]. The
	SGLN-96 includes six fields: Header, Filter Value, Partition, Company		SGLN-96 includes six fields: Header, Filter Value, Partition, Company
	Prefix, Location Reference, and Serial Number.		Prefix, Location Reference, and Serial Number.
	A.1.7. Description of the RFID-GRAI-64 type		A.1.7. Description of the RFID-GRAI-64 Type
	The RFID-GRAI-64 type is encoded as specified in [EPC-Tag-Data]. The		The RFID-GRAI-64 type is encoded as specified in [EPC-Tag-Data]. The
	GRAI-64 includes five fields: Header, Filter Value, Company Prefix		GRAI-64 includes five fields: Header, Filter Value, Company Prefix
	Index, Asset Type, and Serial Number.		Index, Asset Type, and Serial Number.
	A.1.8. Description of the RFID-GRAI-96 type		A.1.8. Description of the RFID-GRAI-96 Type
	The RFID-GRAI-96 type is encoded as specified in [EPC-Tag-Data]. The		The RFID-GRAI-96 type is encoded as specified in [EPC-Tag-Data]. The
	GRAI-96 includes six fields: Header, Filter Value, Partition, Company		GRAI-96 includes six fields: Header, Filter Value, Partition, Company
	Prefix, Asset Type, and Serial Number.		Prefix, Asset Type, and Serial Number.
	A.1.9. Description of the RFID-GIAI-64 type		A.1.9. Description of the RFID-GIAI-64 Type
	The RFID-GIAI-64 type is encoded as specified in [EPC-Tag-Data]. The		The RFID-GIAI-64 type is encoded as specified in [EPC-Tag-Data]. The
	GIAI-64 includes four fields: Header, Filter Value, Company Prefix		GIAI-64 includes four fields: Header, Filter Value, Company Prefix
	Index, and Individual Asset Reference.		Index, and Individual Asset Reference.
	A.1.10. Description of the RFID-GIAI-96 type		A.1.10. Description of the RFID-GIAI-96 Type
	The RFID-GIAI-96 type is encoded as specified in [EPC-Tag-Data]. The		The RFID-GIAI-96 type is encoded as specified in [EPC-Tag-Data]. The
	GIAI-96 includes five fields: Header, Filter Value, Partition,		GIAI-96 includes five fields: Header, Filter Value, Partition,
	Company Prefix, and Individual Asset Reference.		Company Prefix, and Individual Asset Reference.
	A.1.11. Description of the RFID-DoD-64 type		A.1.11. Description of the RFID-DoD-64 Type
	The RFID-DoD-64 type is encoded as specified in [RFID-DoD-spec]. The		The RFID-DoD-64 type is encoded as specified in [RFID-DoD-spec]. The
	DoD-64 type includes four fields: Header, Filter Value, Government		DoD-64 type includes four fields: Header, Filter Value, Government
	Managed Identifier, and Serial Number.		Managed Identifier, and Serial Number.
	A.1.12. Description of the RFID-DoD-96 type		A.1.12. Description of the RFID-DoD-96 Type
	The RFID-DoD-96 type is encoded as specified in [RFID-DoD-spec]. The		The RFID-DoD-96 type is encoded as specified in [RFID-DoD-spec]. The
	DoD-96 type includes four fields: Header, Filter Value, Government		DoD-96 type includes four fields: Header, Filter Value, Government
	Managed Identifier, and Serial Number.		Managed Identifier, and Serial Number.
	A.1.13. Description of the RFID URI types		A.1.13. Description of the RFID URI Types
	In some cases, it is desirable to encode in URI form a specific		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		encoding of an RFID tag. For example, an application may prefer a
	URI representation for report preparation. Applications that wish to		URI representation for report preparation. Applications that wish to
	manipulate any additional data fields on tags may need some		manipulate any additional data fields on tags may need some
	representation other than the pure identity forms.		representation other than the pure identity forms.
	For this purpose, the fields as represented the previous sections are		For this purpose, the fields as represented in previous sections are
	associated with specified fields in the various URI types. For		associated with specified fields in the various URI types. For
	instance, the URI may have fields such as CompanyPrefix,		instance, the URI may have fields such as CompanyPrefix,
	ItemReference, or SerialNumber. For details and encoding specifics,		ItemReference, or SerialNumber. For details and encoding specifics,
	consult [EPC-Tag-Data].		consult [EPC-Tag-Data].
			Acknowledgements
			The authors wish to acknowledge Hakima Chaouchi, Tatuya Jinmei, Jouni
			Korhonen, Sri Gundavelli, Suresh Krishnan, Dapeng Liu, Dale Worley,
			Joseph Salowey, Linda Dunbar, and Mirja Kuehlewind for their helpful
			comments. The authors also wish to acknowledge the RFC Editor for a
			number of valuable suggestions and updates during the final stages of
			producing this document.
	Authors' Addresses		Authors' Addresses
	Charles E. Perkins		Charles E. Perkins
	Futurewei Inc.		Futurewei Inc.
	2330 Central Expressway		2330 Central Expressway
	Santa Clara, CA 95050		Santa Clara, CA 95050
	USA		United States of America
	Phone: +1-408-330-4586		Phone: +1-408-330-4586
	Email: charliep@computer.org		Email: charliep@computer.org
	Vijay Devarapalli		Vijay Devarapalli
	Vasona Networks		Vasona Networks
	2900 Lakeside Drive, Suite 180		2900 Lakeside Drive, Suite 180
	Santa Clara, CA 95054		Santa Clara, CA 95054
	USA		United States of America
	Email: dvijay@gmail.com		Email: dvijay@gmail.com
End of changes. 95 change blocks.
	271 lines changed or deleted		291 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/