Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

PROPOSED STANDARD
Internet Engineering Task Force (IETF)                        C. PerkinsRequest for Comments: 8371                                     FutureweiCategory: Standards Track                                 V. DevarapalliISSN: 2070-1721                                          Vasona Networks                                                               July 2018Mobile Node Identifier Types for MIPv6Abstract   This document defines additional identifier type numbers for use with   the mobile node identifier option for Mobile IPv6 (MIPv6) as defined   byRFC 4283.Status of This Memo   This is an Internet Standards Track document.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Further information on   Internet Standards is available inSection 2 of RFC 7841.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttps://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 toBCP 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.Perkins & Devarapalli        Standards Track                    [Page 1]

RFC 8371              MN Identifier Types for MIPv6            July 2018Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .32.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .33.  New Mobile Node Identifier Types  . . . . . . . . . . . . . .44.  Descriptions of MN Identifier Types . . . . . . . . . . . . .44.1.  Description of the IPv6 Address Type  . . . . . . . . . .44.2.  Description of the IMSI MN Identifier Type  . . . . . . .54.3.  Description of the EUI-48 Address Type  . . . . . . . . .54.4.  Description of the EUI-64 Address Type  . . . . . . . . .54.5.  Description of the DUID Type  . . . . . . . . . . . . . .55.  Security Considerations . . . . . . . . . . . . . . . . . . .56.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .67.  References  . . . . . . . . . . . . . . . . . . . . . . . . .67.1.  Normative References  . . . . . . . . . . . . . . . . . .67.2.  Informative References  . . . . . . . . . . . . . . . . .7Appendix A.  RFID Types . . . . . . . . . . . . . . . . . . . . .9A.1.  Description of the RFID Types . . . . . . . . . . . . . .13A.1.1.  Description of the RFID-SGTIN-64 Type . . . . . . . .14A.1.2.  Description of the RFID-SGTIN-96 Type . . . . . . . .14A.1.3.  Description of the RFID-SSCC-64 Type  . . . . . . . .14A.1.4.  Description of the RFID-SSCC-96 Type  . . . . . . . .14A.1.5.  Description of the RFID-SGLN-64 Type  . . . . . . . .14A.1.6.  Description of the RFID-SGLN-96 Type  . . . . . . . .14A.1.7.  Description of the RFID-GRAI-64 Type  . . . . . . . .15A.1.8.  Description of the RFID-GRAI-96 Type  . . . . . . . .15A.1.9.  Description of the RFID-GIAI-64 Type  . . . . . . . .15A.1.10. Description of the RFID-GIAI-96 Type  . . . . . . . .15A.1.11. Description of the RFID-DoD-64 Type . . . . . . . . .15A.1.12. Description of the RFID-DoD-96 Type . . . . . . . . .15A.1.13. Description of the RFID URI Types . . . . . . . . . .15   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .16   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .16Perkins & Devarapalli        Standards Track                    [Page 2]

RFC 8371              MN Identifier Types for MIPv6            July 20181.  Introduction   The "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)" [RFC4283]   has proved to be a popular design tool for providing identifiers for   mobile nodes during authentication procedures with Authentication,   Authorization, and Accounting (AAA) protocols such as Diameter   [RFC6733].  To date, only a single type of identifier has been   specified, namely the Mobile Node (MN) NAI.  Other types of   identifiers are in common use and are even referenced inRFC 4283.   In this document, we propose adding some basic identifier types that   are defined in various telecommunications standards, including types   for International Mobile Subscriber Identity (IMSI) [ThreeGPP-IDS],   Packet - Temporary Mobile Subscriber Identity (P-TMSI)   [ThreeGPP-IDS], International Mobile station Equipment Identities   (IMEI) [ThreeGPP-IDS], and Globally Unique Temporary UE Identity   (GUTI) [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 (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   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 inBCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all   capitals, as shown here.Perkins & Devarapalli        Standards Track                    [Page 3]

RFC 8371              MN Identifier Types for MIPv6            July 20183.  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 identifier.   +--------------+-----------------------------------+----------------+   | Identifier   | Description                       | Reference      |   | Type         |                                   |                |   +--------------+-----------------------------------+----------------+   | IPv6 Address |                                   | [RFC4291]      |   |              |                                   |                |   | IMSI         | International Mobile Subscriber   | [ThreeGPP-IDS] |   |              | Identity                          |                |   |              |                                   |                |   | P-TMSI       | Packet - Temporary Mobile         | [ThreeGPP-IDS] |   |              | Subscriber Identity               |                |   |              |                                   |                |   | GUTI         | Globally Unique Temporary UE      | [ThreeGPP-IDS] |   |              | Identity                          |                |   |              |                                   |                |   | EUI-48       | 48-Bit Extended Unique Identifier | [IEEE802]      |   | Address      |                                   |                |   |              |                                   |                |   | EUI-64       | 64-Bit Extended Unique Identifier | [IEEE802]      |   | Address      |                                   |                |   |              |                                   |                |   | DUID         | DHCPv6 Unique Identifier          | [RFC3315]      |   +--------------+-----------------------------------+----------------+                Table 1: Mobile Node Identifier Description4.  Descriptions of MN Identifier Types   This section provides descriptions for the various MN identifier   types.4.1.  Description of the IPv6 Address Type   The IPv6 address [RFC4291] is encoded as a 16-octet string containing   a full IPv6 address 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 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.Perkins & Devarapalli        Standards Track                    [Page 4]

RFC 8371              MN Identifier Types for MIPv6            July 20184.2.  Description of the IMSI 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 for all digits), where each digit occupies 4 bits.  If needed for   full octet size, the last digit MUST be padded with 0xf.  For   instance, an example IMSI 123456123456789 would be encoded as   follows:      0x12, 0x34, 0x56, 0x12, 0x34, 0x56, 0x78, 0x9f4.3.  Description of the EUI-48 Address Type   The IEEE EUI-48 address [IEEE802-GUIDELINES] is encoded as 6 octets   containing the IEEE EUI-48 address.4.4.  Description of the EUI-64 Address Type   The IEEE EUI-64 address [IEEE802-GUIDELINES] is encoded as 8 octets   containing the full IEEE EUI-64 address.4.5.  Description of the DUID Type   The DUID is the DHCPv6 Unique Identifier [RFC3315].  There are   various types of 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 and does not   have any impact on existing security mechanisms.   Mobile node identifiers such as those described in this document are   considered to be private information.  If used in the MN identifier   extension as defined in [RFC4283], the packet including the MN   identifier extension MUST be encrypted so that no personal   information or trackable identifiers are inadvertently disclosed to   passive observers.  Operators can potentially apply IPsec   Encapsulating Security Payload (ESP) [RFC4303] in transport mode with   confidentiality and integrity protection for protecting the identity   and location information in MIPv6 signaling messages.   Some MN identifiers contain sensitive identifiers that, as used in   protocols specified by other Standards Development Organizations   (SDOs), are only used for signaling during initial network entry.  In   such protocols, subsequent exchanges then rely on a temporaryPerkins & Devarapalli        Standards Track                    [Page 5]

RFC 8371              MN Identifier Types for MIPv6            July 2018   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 this document have   been assigned values from the "Mobile Node Identifier Option   Subtypes" registry.  The following values 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            | 8                      |               | Reserved        | 9-15                   |               | Unassigned      | 16-255                 |               +-----------------+------------------------+                 Table 2: New Mobile Node Identifier Types   SeeSection 4 for additional information about the identifier types.   The registration procedure is Standards Action [RFC8126].  The expert   must ascertain that the identifier type allows unique identification   of the mobile device; since all MN identifiers require encryption,   there is no additional privacy exposure attendant to the use of new   types.7.  References7.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>.Perkins & Devarapalli        Standards Track                    [Page 6]

RFC 8371              MN Identifier Types for MIPv6            July 2018   [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>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase inRFC2119 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", Version 5.0, January 2004.   [EPC-Tag-Data]              EPCglobal, Inc., "EPC Generation 1 Tag Data Standards              Version 1.1 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 Standard for Local and Metropolitan Area              Networks: Overview and Architecture", IEEE 802.   [IEEE802-GUIDELINES]              IEEE, "Guidelines for Use of Extended Unique Identifier              (EUI), Organizationally Unique Identifier (OUI), and              Company ID (CID)", August 2018,              <http://standards.ieee.org/develop/regauth/tut/eui.pdf>.   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,              Ed., "Diameter Base Protocol",RFC 6733,              DOI 10.17487/RFC6733, October 2012,              <https://www.rfc-editor.org/info/rfc6733>.Perkins & Devarapalli        Standards Track                    [Page 7]

RFC 8371              MN Identifier Types for MIPv6            July 2018   [RFID-DoD-spec]              Department of Defense, "United States Department of              Defense Suppliers' Passive RFID Information Guide",              Version 15.0, January 2010.   [RFID-framework]              Botero, O., "Heterogeneous RFID framework design, analysis              and evaluation", Institut National des Telecommunications,              July 2012.   [ThreeGPP-IDS]              3GPP, "3rd Generation Partnership Project; Technical              Specification Group Core Network and Terminals; Numbering,              addressing and identification (Release 15)", 3GPP              TS 23.003, V15.3.0, March 2018.   [TRACK-IoT]              Chaouchi, H., "Heterogeneous IoT Network: TRACK-IoT              Plateform", Telecom SudParis, Internal Report, March 2012.   [Using-RFID-IPv6]              IPv6.com, "Using RFID & IPv6", September 2006.Perkins & Devarapalli        Standards Track                    [Page 8]

RFC 8371              MN Identifier Types for MIPv6            July 2018Appendix A.  RFID Types   The material in this non-normative appendix was originally composed   for inclusion in the main body of the specification but was moved   into an appendix because there was insufficient support for   allocating Radio Frequency Identification (RFID) types at 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 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 Internet of Things (IoT) and Industry 4.0, vertical   domain, efficient inventory, and tracking items are of major   interest, and RFID technology is the identification technology in the   hardware design of many such items.   The "TRACK-IoT" project [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), which is       then the endpoint of the mobility protocol.  It is also the point       where the 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, 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 endpoint of the mobility protocol can       be hosted directly on the RFID active tag, which is also called       an identification sensor.  A use case for active RFID tags       includes traceability of cold food during mobility (transport).       Also, mobility of cars equipped with active RFID tags that we       already use for toll payment can be added with mobility       management.   One major effort to connect IETF efforts to EPCglobal (RFID   standardization) led to the Object Name Service (ONS), which is the   DNS version applied for RFID logical names and page informationPerkins & Devarapalli        Standards Track                    [Page 9]

RFC 8371              MN Identifier Types for MIPv6            July 2018   retrieval.  Attempts have 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,   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 (EPC)   [EPC-Tag-Data] supports several encoding systems or schemes, which   are commonly used in RFID applications, including the following:   o  RFID-GID (Global Identifier),   o  RFID-SGTIN (Serialized Global Trade Item Number),   o  RFID-SSCC (Serial Shipping Container Code),   o  RFID-SGLN (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).Perkins & Devarapalli        Standards Track                   [Page 10]

RFC 8371              MN Identifier Types for MIPv6            July 2018   For each RFID scheme except GID, there are three representations:   o  a 64-bit binary representation (for example, SGLN-64), excluding      GID,   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   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.Perkins & Devarapalli        Standards Track                   [Page 11]

RFC 8371              MN Identifier Types for MIPv6            July 2018   +----------------+--------------------------------+-----------------+   | 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: Mobile Node RFID Identifier DescriptionPerkins & Devarapalli        Standards Track                   [Page 12]

RFC 8371              MN Identifier Types for MIPv6            July 2018A.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   three fields: 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.   Some of the RFID types depend on the Global Trade Item Number (GTIN)   code defined in the 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 and Individual Asset Reference.Perkins & Devarapalli        Standards Track                   [Page 13]

RFC 8371              MN Identifier Types for MIPv6            July 2018   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 Commercial and Government Entity (CAGE) code.A.1.1.  Description of the RFID-SGTIN-64 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 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   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   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   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 and must be zero.A.1.5.  Description of the RFID-SGLN-64 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   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.Perkins & Devarapalli        Standards Track                   [Page 14]

RFC 8371              MN Identifier Types for MIPv6            July 2018A.1.7.  Description of the RFID-GRAI-64 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   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   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   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   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   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   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 in previous sections are   associated with specified fields in the various URI types.  For   instance, the URI may have fields such as CompanyPrefix,Perkins & Devarapalli        Standards Track                   [Page 15]

RFC 8371              MN Identifier Types for MIPv6            July 2018   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 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   Charles E. Perkins   Futurewei Inc.   2330 Central Expressway   Santa Clara, CA  95050   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   United States of America   Email: dvijay@gmail.comPerkins & Devarapalli        Standards Track                   [Page 16]

[8]ページ先頭

©2009-2026 Movatter.jp