Distributed Mobility Management [dmm]
Internet Engineering Task Force (IETF)                        C. Perkins
Internet-Draft
Request for Comments: 8371                                     Futurewei
Intended status:
Category: Standards Track                                 V. Devarapalli
Expires: September 19, 2018
ISSN: 2070-1721                                          Vasona Networks
                                                          March 18,
                                                               July 2018

     MN Identifier Types for RFC 4283

                 Mobile Node Identifier Option
                    draft-ietf-dmm-4283mnids-08.txt Types for MIPv6

Abstract

   Additional Identifier Type Numbers are defined

   This document defines additional identifier type numbers for use with
   the
   Mobile Node Identifier Option mobile node identifier option for MIPv6 (RFC 4283). Mobile IPv6 (MIPv6) as defined
   by RFC 4283.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 19, 2018.
   https://www.rfc-editor.org/info/rfc8371.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  New Mobile Node Identifier Types  . . . . . . . . . . . . . .   3
   4.  Descriptions of MNID types  . . . . MN Identifier Types . . . . . . . . . . . . .   3   4
     4.1.  Description of the IPv6 address type Address Type  . . . . . . . . . .   3   4
     4.2.  Description of the IMSI MNID type . . . . . MN Identifier Type  . . . . . . .   4
     4.3.  Description of the EUI-48 address type Address Type  . . . . . . . . .   4
     4.4.  Description of the EUI-64 address type Address Type  . . . . . . . . .   4
     4.5.  Description of the DUID type Type  . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  RFID types Types . . . . . . . . . . . . . . . . . . . . .   7
     A.1.  Description of the RFID types Types . . . . . . . . . . . . . .  11  12
       A.1.1.  Description of the RFID-SGTIN-64 type Type . . . . . . . .  12  13
       A.1.2.  Description of the RFID-SGTIN-96 type Type . . . . . . . .  12  13
       A.1.3.  Description of the RFID-SSCC-64 type Type  . . . . . . . .  12  13
       A.1.4.  Description of the RFID-SSCC-96 type Type  . . . . . . . .  12  13
       A.1.5.  Description of the RFID-SGLN-64 type Type  . . . . . . . .  12  13
       A.1.6.  Description of the RFID-SGLN-96 type Type  . . . . . . . .  12  13
       A.1.7.  Description of the RFID-GRAI-64 type Type  . . . . . . . .  13  14
       A.1.8.  Description of the RFID-GRAI-96 type Type  . . . . . . . .  13  14
       A.1.9.  Description of the RFID-GIAI-64 type Type  . . . . . . . .  13  14
       A.1.10. Description of the RFID-GIAI-96 type Type  . . . . . . . .  13  14
       A.1.11. Description of the RFID-DoD-64 type Type . . . . . . . . .  14
       A.1.12. Description of the RFID-DoD-96 Type . . . . . . . . .  14
       A.1.13. Description of the RFID URI Types . . . . . . . . . .  14
   Acknowledgements  . .  13
       A.1.12. Description of the RFID-DoD-96 type . . . . . . . . .  13
       A.1.13. Description of the RFID URI types . . . . . . . . . .  13 . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14  15

1.  Introduction

   The Mobile "Mobile Node Identifier Option for MIPv6 Mobile IPv6 (MIPv6)" [RFC4283]
   has proved to be a popular design tool for providing identifiers for
   mobile nodes during authentication procedures with AAA Authentication,
   Authorization, and Accounting (AAA) protocols such as Diameter
   [RFC3588].
   [RFC6733].  To date, only a single type of identifier has been
   specified, namely the MN Mobile Node (MN) NAI.  Other types of
   identifiers are in common use, use and are even referenced in RFC 4283.
   In this document, we propose adding some basic identifier types that
   are defined in various telecommunications standards, including types
   for IMSI International Mobile Subscriber Identity (IMSI) [ThreeGPP-IDS], P-TMSI
   Packet - Temporary Mobile Subscriber Identity (P-TMSI)
   [ThreeGPP-IDS], IMEI International Mobile station Equipment Identities
   (IMEI) [ThreeGPP-IDS], and GUTI Globally Unique Temporary UE Identity
   (GUTI) [ThreeGPP-IDS].  In addition, we specify the IPv6 address
   itself and IEEE MAC-layer addresses as mobile node Mobile Node identifiers.
   Defining identifiers that are tied to the physical elements of the
   device ( (e.g., the MAC address etc.) address) help in deployment of Mobile IP because
   because, in many
   cases cases, such identifiers are the most natural means
   for uniquely identifying the device, device and will avoid additional look-up lookup
   steps that might be needed if other identifiers were used.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "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

   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.

                    Mobile Node Identifier Description identifier.

   +--------------+-----------------------------------+----------------+
   | Identifier   | Description                       | Reference      |
   | Type         |                                   |                |
   +--------------+-----------------------------------+----------------+
   | IPv6 Address |                                   | [RFC4291]      |
   |              |                                   |                |
   | IMSI         | International Mobile Subscriber   | [ThreeGPP-IDS] |
   |              | Identity                          |                |
   |              |                                   |                |
   | P-TMSI       | Packet-Temporary Packet - Temporary Mobile         | [ThreeGPP-IDS] |
   |              | Subscriber Identity               |                |
   |              |                                   |                |
   | GUTI         | Globally Unique Temporary ID UE      | [ThreeGPP-IDS] |
   |              | Identity                          |                |
   |              |                                   |                |
   | EUI-48       | 48-bit 48-Bit Extended Unique Identifier | [IEEE802]      |
   | address Address      |                                   |                |
   |              |                                   |                |
   | EUI-64       | 64-bit 64-Bit Extended Unique Identifier | [IEEE802]      |
   | address Address      |                                   |                |
   |              | Identifier-64 bit                                   |                |
   | DUID         | DHCPv6 Unique Identifier          | [RFC3315]      |
   +--------------+-----------------------------------+----------------+

                Table 1 1: Mobile Node Identifier Description

4.  Descriptions of MNID types

   In this MN Identifier Types

   This section provides descriptions for the various MNID types are provided. MN identifier
   types.

4.1.  Description of the IPv6 address type Address Type

   The IPv6 address [RFC4291] is encoded as a 16 octet 16-octet string containing
   a full IPv6 address which that has been assigned to the mobile node.  The
   IPv6 address MUST be a unicast routable IPv6 address.  Multicast
   addresses, link-local addresses, and the unspecified IPv6 address
   MUST NOT be used.  IPv6 Unique Local Addresses (ULAs) MAY be used, used as
   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.

4.2.  Description of the IMSI MNID type MN Identifier Type

   The International Mobile Subscriber Identity (IMSI) [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 (i.e., high-
   to-low high to
   low for all digits), where each digit occupies 4 bits.  If needed for
   full octet size, the last digit MUST be padded with 0xf.  For
   example
   instance, an example IMSI 123456123456789 would be encoded as
   follows:

      0x12, 0x34, 0x56, 0x12, 0x34, 0x56, 0x78, 0x9f

4.3.  Description of the EUI-48 address type Address Type

   The IEEE EUI-48 address [IEEE802-eui48] [IEEE802-GUIDELINES] is encoded as 6 octets
   containing the IEEE EUI-48 address.

4.4.  Description of the EUI-64 address type Address Type

   The IEEE EUI-64 address [IEEE802-eui64] [IEEE802-GUIDELINES] is encoded as 8 octets
   containing the full IEEE EUI-64 address.

4.5.  Description of the DUID type Type

   The DUID is the DHCPv6 Unique Identifier (DUID) [RFC3315].  There are
   various types of DUID, DUIDs, which are distinguished by an initial two-
   octet type field.  Clients and servers MUST treat DUIDs as opaque
   values and MUST only compare DUIDs for equality.

5.  Security Considerations

   This document does not introduce any security mechanisms, mechanisms and does not
   have any impact on existing security mechanisms.

   Mobile Node Identifiers node identifiers such as those described in this document are
   considered to be private information.  If used in the MNID MN identifier
   extension as defined in [RFC4283], the packet including the MNID MN
   identifier extension MUST be encrypted so that no personal
   information or trackable identifiers
   is are inadvertently disclosed to
   passive observers.  Operators can potentially apply IPsec
   Encapsulating Security Payload (ESP)
   [RFC4303], [RFC4303] in transport mode, mode with
   confidentiality and integrity protection for protecting the identity
   and location information in
   Mobile IPv6 MIPv6 signaling messages.

   Some MNIDs MN identifiers contain sensitive identifiers which, that, as used in
   protocols specified by other SDOs, Standards Development Organizations
   (SDOs), are only used for signaling during initial network entry.  In
   such protocols, subsequent exchanges then rely on a temporary
   identifier allocated during the initial network entry.  Managing the
   association between long-lived and temporary identifiers is outside
   the scope of this document.

6.  IANA Considerations

   The new mobile node identifier types defined in the this document should
   be have
   been assigned values from the "Mobile Node Identifier Option
   Subtypes" registry.  The following values should be assigned.

                     New Mobile Node Identifier Types have been registered.

               +-----------------+------------------------+
               | Identifier Type | Identifier Type Number |
               +-----------------+------------------------+
               | IPv6 Address    | 2                      |
               | IMSI            | 3                      |
               | P-TMSI          | 4                      |
               | EUI-48 address  | 5                      |
               | EUI-64 address  | 6                      |
               | GUTI            | 7                      |
               | DUID-LLT DUID            | 8                      |
               | DUID-EN         | 9                      |
               | DUID-LL Reserved        | 10                     |
               | DUID-UUID       | 11                     |
               |                 | 12-15 reserved 9-15                   |
               | Unassigned      | 16-255 unassigned                 |
               +-----------------+------------------------+

                 Table 2 2: New Mobile Node 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
   must ascertain that the identifier type allows unique identification
   of the mobile device; since all MNIDs MN identifiers require
   encryption encryption,
   there is no additional privacy exposure attendent attendant to the use of new
   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

8.1.

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <https://www.rfc-editor.org/info/rfc3315>.

   [RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
              (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005,
              <https://www.rfc-editor.org/info/rfc4283>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

8.2.
              <https://www.rfc-editor.org/info/rfc8126>.

   [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]
              EAN International and the Uniform Code Council, "General
              EAN.UCC Specifications Specifications", Version 5.0", Jan 5.0, January 2004.

   [EPC-Tag-Data]
              EPCglobal
              EPCglobal, Inc., "EPC(TM) "EPC 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", January 2005. Rev.1.27", May 2005,
              <https://www.gs1.org/sites/default/files/docs/epc/
              tds_1_1_rev_1_27-standard-20050510.pdf>.

   [IEEE802]  IEEE, "IEEE Std 802: IEEE Standards Standard for Local and Metropolitan Area
              Networks: Overview and Architecture", 2001.

   [IEEE802-eui48] IEEE 802.

   [IEEE802-GUIDELINES]
              IEEE, "Guidelines for 48-Bit Global Use of Extended Unique Identifier (EUI-48)
              https://standards.ieee.org/develop/regauth/tut/eui48.pdf",
              2001.

   [IEEE802-eui64]
              IEEE, "Guidelines for 64-Bit Global
              (EUI), Organizationally Unique Identifier (EUI-64)
              https://standards.ieee.org/develop/regauth/tut/eui.pdf64",
              2001.

   [RFC3588]  Calhoun, P., (OUI), and
              Company ID (CID)", August 2018,
              <http://standards.ieee.org/develop/regauth/tut/eui.pdf>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, G. Zorn,
              Ed., "Diameter Base Protocol", RFC 3588, 6733,
              DOI 10.17487/RFC3588, September 2003,
              <https://www.rfc-editor.org/info/rfc3588>. 10.17487/RFC6733, October 2012,
              <https://www.rfc-editor.org/info/rfc6733>.

   [RFID-DoD-spec]
              Department of Defense, "United States Department of
              Defense Suppliers Suppliers' Passive RFID Information Guide (Version
              15.0)", Guide",
              Version 15.0, January 2010.

   [RFID-framework]
              Institut National des Telecommunication, ""Heterogeneous
              Botero, O., "Heterogeneous RFID framework design, analysis
              and evaluation"", evaluation", Institut National des Telecommunications,
              July 2012.

   [ThreeGPP-IDS]
              3rd
              3GPP, "3rd Generation Partnership Project, "3GPP Technical
              Specification 23.003 V8.4.0: Project; Technical
              Specification Group Core Network and Terminals; Numbering,
              addressing and identification (Release 8)", 15)", 3GPP
              TS 23.003, V15.3.0, March 2009. 2018.

   [TRACK-IoT]
              IPv6.com, ""Heterogeneous
              Chaouchi, H., "Heterogeneous IoT Network : TRACK-IoT"", Network: TRACK-IoT
              Plateform", Telecom SudParis, Internal Report, March 2012.

   [Using-RFID-IPv6]
              IPv6.com, ""Using "Using RFID & IPv6"", IPv6", September 2006.

Appendix A.  RFID types Types

   The material in this non-normative appendix was originally composed
   for inclusion in the main body of the specification, specification but was moved
   into an appendix because there was insufficient support for
   allocating RFID Radio Frequency Identification (RFID) types at this the time.
   It was observed that RFID-based mobile devices may create privacy
   exposures unless confidentiality is assured for signaling.  A
   specification for eliminating unauthorized RFID tracking based on layer-2
   Layer 2 addresses would be helpful.

   Much of the following text is due to contributions from Hakima
   Chaouchi.  For an overview and some initial suggestions about using
   RFID with IPv6 on mobile devices, see [Using-RFID-IPv6].

   In the context of IoT Internet of Things (IoT) and industry 4.0 Industry 4.0, vertical
   domain, efficient
   inventory inventory, and tracking items is are of major
   interest, and RFID technology is the identification technology in the
   hardware design of many such items.

   The "TRACKIOT: Heterogeneous IoT control" "TRACK-IoT" project ([TRACK-IoT],
   [RFID-framework]) [TRACK-IoT] [RFID-framework] explored Mobile
   IPv6 as a mobility management protocol for RFID-based mobile devices.

   1.  Passive RFID tags (that have no processing resources) need to be
       handled by the gateway (likely also the RFID Reader), reader), which is
       then the end point endpoint of the mobility protocol.  It is also the point
       where the CoA Change of Address (CoA) will be created based on some
       combination such as the RFID tag and the prefix of that gateway.
       The point here is to offer the possibility to passive RFID items
       to get an IPv6 address and take advantage of the mobility
       framework to follow the mobile device (passive tag on the item).
       One example scenario that has been proposed, showing which shows the need
       for mobility management of passive RFID items, would be pieces of
       art tagged with passive tags that need to be monitored while
       transported.

   2.  Using active RFID tags (where the processing resource is
       available on the tag), the end point endpoint of the mobility protocol can
       be pushed up
       to hosted directly on the RFID Active tag.  We name it active tag, which is also called
       an identification sensor.  Use cases include  A use case for active RFID tags for
       includes traceability of cold food respect during mobility (transport) of food.  Mobility (transport).
       Also, mobility of cars equiped equipped with active RFID tags that we
       already use for toll payement payment can be added with mobility
       management.

   One major effort of connecting to connect IETF efforts to the EPCGlobal EPCglobal (RFID
   standardisation)
   standardization) led to the ONS (DNS Object Name Service (ONS), which is the
   DNS version applied for RFID logical names and page information retrieval).
   retrieval.  Attempts have tried been made to connect IPv6 on the address
   space to RFID identifier format.  Other initiatives started working
   on gateways to map tag identifiers with IPv6 addresses and build
   signaling protocols for the application level.  For instance instance,
   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 IPv6-to-RFID tag translation.  One option is to
   build a Home home IPv6 address of that tagged item by using the prefix of
   the Home 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  Then, the visiting RFID reader will compose the IPV6
   IPv6 care of address of the tagged mobile item by combining the
   prefix of the RFID reader with the tag ID of the item). item.  MIPv6 can
   then provide normally provide the mobility management of that RFID
   tagged RFID-tagged
   item.  A different different, useful example of tagged items involves items of
   a factory that can be tracked while they are transported, especially
   for real time localisation real-time localization and tracking of precious items transported
   without GPS.  An automotive car manufacturer can assign IPv6
   addresses corresponding to RFID tagged RFID-tagged cars or mechanical car
   parts, parts
   and build a tracking dataset data set of the mobility not only of the cars,
   but also of the mechanical pieces.

   The Tag Data standard Standard promoted by Electronic Product Code(TM)
   (abbreviated EPC) Code (EPC)
   [EPC-Tag-Data] supports several encoding systems or schemes, which
   are commonly used in RFID (radio-frequency
   identification) applications, including the following:

   o  RFID-GID (Global Identifier),

   o  RFID-SGTIN (Serialized Global Trade Item Number),

   o  RFID-SSCC (Serial Shipping Container), Container Code),

   o  RFID-SGLN (Global (Serialized Global Location Number),

   o  RFID-GRAI (Global Returnable Asset Identifier),

   o  RFID-DOD (Department of Defense ID), and

   o  RFID-GIAI (Global Individual Asset Identifier).

   For each RFID scheme except GID, there are three representations:

   o  a 64-bit binary representation (for example, SGLN-64) (except for
      GID) SGLN-64), excluding
      GID,

   o  a 96-bit binary representation (SGLN-96) (SGLN-96), and

   o  a representation as a URI URI.

   The URI representation for the RFID is actually a URN.  The EPC
   document has the following language:

      All categories of URIs are represented as Uniform Reference Names
      (URNs) as defined by [RFC2141], where the URN Namespace is epc.

   The following list includes the above RFID types.

                  Mobile Node RFID Identifier Description

   +----------------+--------------------------------+-----------------+
   | Identifier     | Description                    | Reference       |
   | Type           |                                |                 |
   +----------------+--------------------------------+-----------------+
   | RFID-SGTIN-64  | 64-bit Serialized Global Trade | [EPC-Tag-Data]  |
   |                | Item Number                    |                 |
   | RFID-SSCC-64   | 64-bit Serial Shipping         | [EPC-Tag-Data]  |
   |                | Container Code                 |                 |
   | RFID-SGLN-64   | 64-bit Serialized Global       | [EPC-Tag-Data]  |
   |                | Location Number                |                 |
   | RFID-GRAI-64   | 64-bit Global Returnable Asset | [EPC-Tag-Data]  |
   |                | Identifier                     |                 |
   | RFID-DOD-64    | 64-bit Department of Defense   | [RFID-DoD-spec] |
   |                | ID                             |                 |
   | RFID-GIAI-64   | 64-bit Global Individual Asset | [EPC-Tag-Data]  |
   |                | Identifier                     |                 |
   | RFID-GID-96    | 96-bit Global Identifier       | [EPC-Tag-Data]  |
   | RFID-SGTIN-96  | 96-bit Serialized Global Trade | [EPC-Tag-Data]  |
   |                | Item Number                    |                 |
   | RFID-SSCC-96   | 96-bit Serial Shipping         | [EPC-Tag-Data]  |
   |                | Container                      |                 |
   | RFID-SGLN-96   | 96-bit Serialized Global       | [EPC-Tag-Data]  |
   |                | Location Number                |                 |
   | RFID-GRAI-96   | 96-bit Global Returnable Asset | [EPC-Tag-Data]  |
   |                | Identifier                     |                 |
   | RFID-DOD-96    | 96-bit Department of Defense   | [RFID-DoD-spec] |
   |                | ID                             |                 |
   | RFID-GIAI-96   | 96-bit Global Individual Asset | [EPC-Tag-Data]  |
   |                | Identifier                     |                 |
   | RFID-GID-URI   | Global Identifier represented  | [EPC-Tag-Data]  |
   |                | as a URI                       |                 |
   | RFID-SGTIN-URI | Serialized Global Trade Item   | [EPC-Tag-Data]  |
   |                | Number represented as a URI    |                 |
   | RFID-SSCC-URI  | Serial Shipping Container Code | [EPC-Tag-Data]  |
   |                | represented as a URI           |                 |
   | RFID-SGLN-URI  | Global Location Number         | [EPC-Tag-Data]  |
   |                | represented as a URI           |                 |
   | RFID-GRAI-URI  | Global Returnable Asset        | [EPC-Tag-Data]  |
   |                | Identifier represented as a    |                 |
   |                | URI                            |                 |
   | RFID-DOD-URI   | Department of Defense ID       | [RFID-DoD-spec] |
   |                | represented as a URI           |                 |
   | RFID-GIAI-URI  | Global Individual Asset        | [EPC-Tag-Data]  |
   |                | Identifier represented as a    |                 |
   |                | URI                            |                 |
   +----------------+--------------------------------+-----------------+

             Table 3 3: Mobile Node RFID Identifier Description

A.1.  Description of the RFID types 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
   three fields - the fields: General Manager Number, Object Class 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.

   Some of the RFID types depend on the Global Trade Item Number (GTIN)
   code defined in the General EAN.UCC General Specifications [EANUCCGS].  A
   GTIN identifies a particular class of object, such as a particular
   kind of product or SKU.

   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).

   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).

   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.

   The Global Returnable Asset Identifier (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.

   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, Prefix and Individual Asset Reference.

   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 Commercial and Government Entity) Entity (CAGE) code.

A.1.1.  Description of the RFID-SGTIN-64 type Type

   The RFID-SGTIN-64 is encoded as specified in [EPC-Tag-Data].  The
   SGTIN-64 includes five fields: Header, Filter Value (additional data
   that is used for fast filtering and pre-selection), preselection), Company Prefix
   Index, Item Reference, and Serial Number.  Only a limited number of
   Company Prefixes can be represented in the 64-bit tag.

A.1.2.  Description of the RFID-SGTIN-96 type Type

   The RFID-SGTIN-96 is encoded as specified in [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.

A.1.3.  Description of the RFID-SSCC-64 type Type

   The RFID-SSCC-64 is encoded as specified in [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.

A.1.4.  Description of the RFID-SSCC-96 type Type

   The RFID-SSCC-96 is encoded as specified in [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
   unallocated and must be zero.

A.1.5.  Description of the RFID-SGLN-64 type Type

   The RFID-SGLN-64 type is encoded as specified in [EPC-Tag-Data].  The
   SGLN-64 includes five fields: Header, Filter Value, Company Prefix
   Index, Location Reference, and Serial Number.

A.1.6.  Description of the RFID-SGLN-96 type Type

   The RFID-SGLN-96 type is encoded as specified in [EPC-Tag-Data].  The
   SGLN-96 includes six fields: Header, Filter Value, Partition, Company
   Prefix, Location Reference, and Serial Number.

A.1.7.  Description of the RFID-GRAI-64 type Type

   The RFID-GRAI-64 type is encoded as specified in [EPC-Tag-Data].  The
   GRAI-64 includes five fields: Header, Filter Value, Company Prefix
   Index, Asset Type, and Serial Number.

A.1.8.  Description of the RFID-GRAI-96 type Type

   The RFID-GRAI-96 type is encoded as specified in [EPC-Tag-Data].  The
   GRAI-96 includes six fields: Header, Filter Value, Partition, Company
   Prefix, Asset Type, and Serial Number.

A.1.9.  Description of the RFID-GIAI-64 type Type

   The RFID-GIAI-64 type is encoded as specified in [EPC-Tag-Data].  The
   GIAI-64 includes four fields: Header, Filter Value, Company Prefix
   Index, and Individual Asset Reference.

A.1.10.  Description of the RFID-GIAI-96 type Type

   The RFID-GIAI-96 type is encoded as specified in [EPC-Tag-Data].  The
   GIAI-96 includes five fields: Header, Filter Value, Partition,
   Company Prefix, and Individual Asset Reference.

A.1.11.  Description of the RFID-DoD-64 type Type

   The RFID-DoD-64 type is encoded as specified in [RFID-DoD-spec].  The
   DoD-64 type includes four fields: Header, Filter Value, Government
   Managed Identifier, and Serial Number.

A.1.12.  Description of the RFID-DoD-96 type Type

   The RFID-DoD-96 type is encoded as specified in [RFID-DoD-spec].  The
   DoD-96 type includes four fields: Header, Filter Value, Government
   Managed Identifier, and Serial Number.

A.1.13.  Description of the RFID URI types Types

   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.

   For this purpose, the fields as represented the in 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 [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 Kuhlewind 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

   Charles E. Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA  95050
   USA
   United States of America

   Phone: +1-408-330-4586
   Email: charliep@computer.org

   Vijay Devarapalli
   Vasona Networks
   2900 Lakeside Drive, Suite 180
   Santa Clara, CA 95054
   USA
   United States of America

   Email: dvijay@gmail.com