idnits 2.17.00 (12 Aug 2021) /tmp/idnits41791/draft-ietf-dmm-4283mnids-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2018) is 1518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2141' is mentioned on line 417, but not defined ** Obsolete undefined reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Distributed Mobility Management [dmm] C. Perkins 3 Internet-Draft Futurewei 4 Intended status: Standards Track V. Devarapalli 5 Expires: September 19, 2018 Vasona Networks 6 March 18, 2018 8 MN Identifier Types for RFC 4283 Mobile Node Identifier Option 9 draft-ietf-dmm-4283mnids-08.txt 11 Abstract 13 Additional Identifier Type Numbers are defined for use with the 14 Mobile Node Identifier Option for MIPv6 (RFC 4283). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 19, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. New Mobile Node Identifier Types . . . . . . . . . . . . . . 3 53 4. Descriptions of MNID types . . . . . . . . . . . . . . . . . 3 54 4.1. Description of the IPv6 address type . . . . . . . . . . 3 55 4.2. Description of the IMSI MNID type . . . . . . . . . . . . 4 56 4.3. Description of the EUI-48 address type . . . . . . . . . 4 57 4.4. Description of the EUI-64 address type . . . . . . . . . 4 58 4.5. Description of the DUID type . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 8.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Appendix A. RFID types . . . . . . . . . . . . . . . . . . . . . 7 66 A.1. Description of the RFID types . . . . . . . . . . . . . . 11 67 A.1.1. Description of the RFID-SGTIN-64 type . . . . . . . . 12 68 A.1.2. Description of the RFID-SGTIN-96 type . . . . . . . . 12 69 A.1.3. Description of the RFID-SSCC-64 type . . . . . . . . 12 70 A.1.4. Description of the RFID-SSCC-96 type . . . . . . . . 12 71 A.1.5. Description of the RFID-SGLN-64 type . . . . . . . . 12 72 A.1.6. Description of the RFID-SGLN-96 type . . . . . . . . 12 73 A.1.7. Description of the RFID-GRAI-64 type . . . . . . . . 13 74 A.1.8. Description of the RFID-GRAI-96 type . . . . . . . . 13 75 A.1.9. Description of the RFID-GIAI-64 type . . . . . . . . 13 76 A.1.10. Description of the RFID-GIAI-96 type . . . . . . . . 13 77 A.1.11. Description of the RFID-DoD-64 type . . . . . . . . . 13 78 A.1.12. Description of the RFID-DoD-96 type . . . . . . . . . 13 79 A.1.13. Description of the RFID URI types . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to 85 be a popular design tool for providing identifiers for mobile nodes 86 during authentication procedures with AAA protocols such as Diameter 87 [RFC3588]. To date, only a single type of identifier has been 88 specified, namely the MN NAI. Other types of identifiers are in 89 common use, and even referenced in RFC 4283. In this document, we 90 propose adding some basic types that are defined in various 91 telecommunications standards, including types for IMSI 92 [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and GUTI 93 [ThreeGPP-IDS]. In addition, we specify the IPv6 address itself and 94 IEEE MAC-layer addresses as mobile node identifiers. Defining 95 identifiers that are tied to the physical elements of the device ( 96 MAC address etc.) help in deployment of Mobile IP because in many 97 cases such identifiers are the most natural means for uniquely 98 identifying the device, and will avoid additional look-up steps that 99 might be needed if other identifiers were used. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119]. 108 3. New Mobile Node Identifier Types 110 The following types of identifiers are commonly used to identify 111 mobile nodes. For each type, references are provided with full 112 details on the format of the type of identifer. 114 Mobile Node Identifier Description 116 +--------------+-----------------------------------+----------------+ 117 | Identifier | Description | Reference | 118 | Type | | | 119 +--------------+-----------------------------------+----------------+ 120 | IPv6 Address | | [RFC4291] | 121 | IMSI | International Mobile Subscriber | [ThreeGPP-IDS] | 122 | | Identity | | 123 | P-TMSI | Packet-Temporary Mobile | [ThreeGPP-IDS] | 124 | | Subscriber Identity | | 125 | GUTI | Globally Unique Temporary ID | [ThreeGPP-IDS] | 126 | EUI-48 | 48-bit Extended Unique Identifier | [IEEE802] | 127 | address | | | 128 | EUI-64 | 64-bit Extended Unique | [IEEE802] | 129 | address | Identifier-64 bit | | 130 | DUID | DHCPv6 Unique Identifier | [RFC3315] | 131 +--------------+-----------------------------------+----------------+ 133 Table 1 135 4. Descriptions of MNID types 137 In this section descriptions for the various MNID types are provided. 139 4.1. Description of the IPv6 address type 141 The IPv6 address [RFC4291] is encoded as a 16 octet string containing 142 a full IPv6 address which has been assigned to the mobile node. The 143 IPv6 address MUST be a unicast routable IPv6 address. Multicast 144 addresses, link-local addresses, and the unspecified IPv6 address 145 MUST NOT be used. IPv6 Unique Local Addresses (ULAs) MAY be used, as 146 long as any security operations making use of the ULA also take into 147 account the domain in which the ULA is guaranteed to be unique. 149 4.2. Description of the IMSI MNID type 151 The International Mobile Subscriber Identity (IMSI) [ThreeGPP-IDS] is 152 at most 15 decimal digits (i.e., digits from 0 through 9). The IMSI 153 MUST be encoded as a string of octets in network order (i.e., high- 154 to-low for all digits), where each digit occupies 4 bits. If needed 155 for full octet size, the last digit MUST be padded with 0xf. For 156 example an example IMSI 123456123456789 would be encoded as follows: 158 0x12, 0x34, 0x56, 0x12, 0x34, 0x56, 0x78, 0x9f 160 4.3. Description of the EUI-48 address type 162 The IEEE EUI-48 address [IEEE802-eui48] is encoded as 6 octets 163 containing the IEEE EUI-48 address. 165 4.4. Description of the EUI-64 address type 167 The IEEE EUI-64 address [IEEE802-eui64] is encoded as 8 octets 168 containing the full IEEE EUI-64 address. 170 4.5. Description of the DUID type 172 The DUID is the DHCPv6 Unique Identifier (DUID) [RFC3315]. There are 173 various types of DUID, which are distinguished by an initial two- 174 octet type field. Clients and servers MUST treat DUIDs as opaque 175 values and MUST only compare DUIDs for equality. 177 5. Security Considerations 179 This document does not introduce any security mechanisms, and does 180 not have any impact on existing security mechanisms. 182 Mobile Node Identifiers such as those described in this document are 183 considered to be private information. If used in the MNID extension 184 as defined in [RFC4283], the packet including the MNID extension MUST 185 be encrypted so that no personal information or trackable identifiers 186 is inadvertently disclosed to passive observers. Operators can 187 potentially apply IPsec Encapsulating Security Payload (ESP) 188 [RFC4303], in transport mode, with confidentiality and integrity 189 protection for protecting the identity and location information in 190 Mobile IPv6 signaling messages. 192 Some MNIDs contain sensitive identifiers which, as used in protocols 193 specified by other SDOs, are only used for signaling during initial 194 network entry. In such protocols, subsequent exchanges then rely on 195 a temporary identifier allocated during the initial network entry. 196 Managing the association between long-lived and temporary identifiers 197 is outside the scope of this document. 199 6. IANA Considerations 201 The new mobile node identifier types defined in the document should 202 be assigned values from the "Mobile Node Identifier Option Subtypes" 203 registry. The following values should be assigned. 205 New Mobile Node Identifier Types 207 +-----------------+------------------------+ 208 | Identifier Type | Identifier Type Number | 209 +-----------------+------------------------+ 210 | IPv6 Address | 2 | 211 | IMSI | 3 | 212 | P-TMSI | 4 | 213 | EUI-48 address | 5 | 214 | EUI-64 address | 6 | 215 | GUTI | 7 | 216 | DUID-LLT | 8 | 217 | DUID-EN | 9 | 218 | DUID-LL | 10 | 219 | DUID-UUID | 11 | 220 | | 12-15 reserved | 221 | | 16-255 unassigned | 222 +-----------------+------------------------+ 224 Table 2 226 See Section 4 for additional information about the identifier types. 227 Future new assignments are to be made only after Expert Review 228 [RFC8126]. The expert must ascertain that the identifier type allows 229 unique identification of the mobile device; since all MNIDs require 230 encryption there is no additional privacy exposure attendent to the 231 use of new types. 233 7. Acknowledgements 235 The authors wish to acknowledge Hakima Chaouchi, Tatuya Jinmei, Jouni 236 Korhonen, Sri Gundavelli, Suresh Krishnan, Dapeng Liu, Dale Worley, 237 Joseph Salowey, Linda Dunbar, and Mirja Kuehlewind for their helpful 238 comments. 240 8. References 242 8.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, 246 DOI 10.17487/RFC2119, March 1997, 247 . 249 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 250 C., and M. Carney, "Dynamic Host Configuration Protocol 251 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 252 2003, . 254 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 255 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 256 (MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005, 257 . 259 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 260 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 261 2006, . 263 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 264 RFC 4303, DOI 10.17487/RFC4303, December 2005, 265 . 267 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 268 Writing an IANA Considerations Section in RFCs", BCP 26, 269 RFC 8126, DOI 10.17487/RFC8126, June 2017, 270 . 272 8.2. Informative References 274 [EANUCCGS] 275 EAN International and the Uniform Code Council, "General 276 EAN.UCC Specifications Version 5.0", Jan 2004. 278 [EPC-Tag-Data] 279 EPCglobal Inc., "EPC(TM) Generation 1 Tag Data Standards 280 Version 1.1 Rev.1.27 281 http://www.gs1.org/gsmp/kc/epcglobal/tds/ 282 tds_1_1_rev_1_27-standard-20050510.pdf", January 2005. 284 [IEEE802] IEEE, "IEEE Std 802: IEEE Standards for Local and 285 Metropolitan Networks: Overview and Architecture", 2001. 287 [IEEE802-eui48] 288 IEEE, "Guidelines for 48-Bit Global Identifier (EUI-48) 289 https://standards.ieee.org/develop/regauth/tut/eui48.pdf", 290 2001. 292 [IEEE802-eui64] 293 IEEE, "Guidelines for 64-Bit Global Identifier (EUI-64) 294 https://standards.ieee.org/develop/regauth/tut/eui.pdf64", 295 2001. 297 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 298 Arkko, "Diameter Base Protocol", RFC 3588, 299 DOI 10.17487/RFC3588, September 2003, 300 . 302 [RFID-DoD-spec] 303 Department of Defense, "United States Department of 304 Defense Suppliers Passive RFID Information Guide (Version 305 15.0)", January 2010. 307 [RFID-framework] 308 Institut National des Telecommunication, ""Heterogeneous 309 RFID framework design, analysis and evaluation"", July 310 2012. 312 [ThreeGPP-IDS] 313 3rd Generation Partnership Project, "3GPP Technical 314 Specification 23.003 V8.4.0: Technical Specification Group 315 Core Network and Terminals; Numbering, addressing and 316 identification (Release 8)", March 2009. 318 [TRACK-IoT] 319 IPv6.com, ""Heterogeneous IoT Network : TRACK-IoT"", March 320 2012. 322 [Using-RFID-IPv6] 323 IPv6.com, ""Using RFID & IPv6"", September 2006. 325 Appendix A. RFID types 327 The material in this non-normative appendix was originally composed 328 for inclusion in the main body of the specification, but was moved 329 into an appendix because there was insufficient support for 330 allocating RFID types at this time. It was observed that RFID-based 331 mobile devices may create privacy exposures unless confidentiality is 332 assured for signaling. A specification for eliminating unauthorized 333 RFID tracking based on layer-2 addresses would be helpful. 335 Much of the following text is due to contributions from Hakima 336 Chaouchi. For an overview and some initial suggestions about using 337 RFID with IPv6 on mobile devices, see [Using-RFID-IPv6]. 339 In the context of IoT and industry 4.0 vertical domain, efficient 340 inventory and tracking items is of major interest, and RFID 341 technology is the identification technology in the hardware design of 342 many such items. 344 The "TRACKIOT: Heterogeneous IoT control" project ([TRACK-IoT], 345 [RFID-framework]) explored Mobile IPv6 as a mobility management 346 protocol for RFID-based mobile devices. 348 1. Passive RFID tags (that have no processing resources) need to be 349 handled by the gateway (likely also the RFID Reader), which is 350 then the end point of the mobility protocol. It is also the 351 point where the CoA will be created based on some combination 352 such as the RFID tag and the prefix of that gateway. The point 353 here is to offer the possibility to passive RFID items to get an 354 IPv6 address and take advantage of the mobility framework to 355 follow the mobile device (passive tag on the item). One example 356 scenario that has been proposed, showing the need for mobility 357 management of passive RFID items, would be pieces of art tagged 358 with passive tags that need to be monitored while transported. 359 2. Using active RFID tags (where processing resource is available on 360 the tag), the end point of the mobility protocol can be pushed up 361 to the RFID Active tag. We name it also an identification 362 sensor. Use cases include active RFID tags for traceability of 363 cold food respect during mobility (transport) of food. Mobility 364 of cars equiped with active RFID tags that we already use for 365 toll payement can be added with mobility management. 367 One major effort of connecting IETF efforts to the EPCGlobal (RFID 368 standardisation) led to the ONS (DNS version applied for RFID logical 369 names and page information retrieval). Attempts have tried to 370 connect IPv6 on the address space to RFID identifier format. Other 371 initiatives started working on gateways to map tag identifiers with 372 IPv6 addresses and build signaling protocols for the application 373 level. For instance tracking of mobile items equipped with a tag can 374 be triggered remotely by a remote correspondent node until a visiting 375 area where a mobile item equipped with an RFID tag is located. An 376 RFID reader will be added with an IPv6 to RFID tag translation. One 377 option is to build a Home IPv6 address of that tagged item by using 378 the prefix of the Home agent combined with the tag RFID identifier of 379 the mobile item; as the tag ID is unique, the home IPv6 address of 380 that item will be also unique. Then the visiting RFID reader will 381 compose the IPV6 care of address of the tagged mobile item by 382 combining the prefix of the RFID reader with the tag ID of the item). 384 MIPv6 can then provide normally the mobility management of that RFID 385 tagged item. A different useful example of tagged items involves 386 items of a factory that can be tracked while they are transported, 387 especially for real time localisation and tracking of precious items 388 transported without GPS. An automotive car manufacturer can assign 389 IPv6 addresses corresponding to RFID tagged cars or mechanical car 390 parts, and build a tracking dataset of the mobility not only of the 391 cars, but also of the mechanical pieces. 393 The Tag Data standard promoted by Electronic Product Code(TM) 394 (abbreviated EPC) [EPC-Tag-Data] supports several encoding systems or 395 schemes, which are commonly used in RFID (radio-frequency 396 identification) applications, including 398 o RFID-GID (Global Identifier), 399 o RFID-SGTIN (Serialized Global Trade Item Number), 400 o RFID-SSCC (Serial Shipping Container), 401 o RFID-SGLN (Global Location Number), 402 o RFID-GRAI (Global Returnable Asset Identifier), 403 o RFID-DOD (Department of Defense ID), and 404 o RFID-GIAI (Global Individual Asset Identifier). 406 For each RFID scheme except GID, there are three representations: 408 o a 64-bit binary representation (for example, SGLN-64) (except for 409 GID) 410 o a 96-bit binary representation (SGLN-96) 411 o a representation as a URI 413 The URI representation for the RFID is actually a URN. The EPC 414 document has the following language: 416 All categories of URIs are represented as Uniform Reference Names 417 (URNs) as defined by [RFC2141], where the URN Namespace is epc. 419 The following list includes the above RFID types. 421 Mobile Node RFID Identifier Description 423 +----------------+--------------------------------+-----------------+ 424 | Identifier | Description | Reference | 425 | Type | | | 426 +----------------+--------------------------------+-----------------+ 427 | RFID-SGTIN-64 | 64-bit Serialized Global Trade | [EPC-Tag-Data] | 428 | | Item Number | | 429 | RFID-SSCC-64 | 64-bit Serial Shipping | [EPC-Tag-Data] | 430 | | Container | | 431 | RFID-SGLN-64 | 64-bit Serialized Global | [EPC-Tag-Data] | 432 | | Location Number | | 433 | RFID-GRAI-64 | 64-bit Global Returnable Asset | [EPC-Tag-Data] | 434 | | Identifier | | 435 | RFID-DOD-64 | 64-bit Department of Defense | [RFID-DoD-spec] | 436 | | ID | | 437 | RFID-GIAI-64 | 64-bit Global Individual Asset | [EPC-Tag-Data] | 438 | | Identifier | | 439 | RFID-GID-96 | 96-bit Global Identifier | [EPC-Tag-Data] | 440 | RFID-SGTIN-96 | 96-bit Serialized Global Trade | [EPC-Tag-Data] | 441 | | Item Number | | 442 | RFID-SSCC-96 | 96-bit Serial Shipping | [EPC-Tag-Data] | 443 | | Container | | 444 | RFID-SGLN-96 | 96-bit Serialized Global | [EPC-Tag-Data] | 445 | | Location Number | | 446 | RFID-GRAI-96 | 96-bit Global Returnable Asset | [EPC-Tag-Data] | 447 | | Identifier | | 448 | RFID-DOD-96 | 96-bit Department of Defense | [RFID-DoD-spec] | 449 | | ID | | 450 | RFID-GIAI-96 | 96-bit Global Individual Asset | [EPC-Tag-Data] | 451 | | Identifier | | 452 | RFID-GID-URI | Global Identifier represented | [EPC-Tag-Data] | 453 | | as URI | | 454 | RFID-SGTIN-URI | Serialized Global Trade Item | [EPC-Tag-Data] | 455 | | Number represented as URI | | 456 | RFID-SSCC-URI | Serial Shipping Container | [EPC-Tag-Data] | 457 | | represented as URI | | 458 | RFID-SGLN-URI | Global Location Number | [EPC-Tag-Data] | 459 | | represented as URI | | 460 | RFID-GRAI-URI | Global Returnable Asset | [EPC-Tag-Data] | 461 | | Identifier represented as URI | | 462 | RFID-DOD-URI | Department of Defense ID | [RFID-DoD-spec] | 463 | | represented as URI | | 464 | RFID-GIAI-URI | Global Individual Asset | [EPC-Tag-Data] | 465 | | Identifier represented as URI | | 466 +----------------+--------------------------------+-----------------+ 468 Table 3 470 A.1. Description of the RFID types 472 The General Identifier (GID) that is used with RFID is composed of 473 three fields - the General Manager Number, Object Class and Serial 474 Number. The General Manager Number identifies an organizational 475 entity that is responsible for maintaining the numbers in subsequent 476 fields. GID encodings include a fourth field, the header, to 477 guarantee uniqueness in the namespace defined by EPC. 479 Some of the RFID types depend on the Global Trade Item Number (GTIN) 480 code defined in the General EAN.UCC Specifications [EANUCCGS]. A 481 GTIN identifies a particular class of object, such as a particular 482 kind of product or SKU. 484 The EPC encoding scheme for SGTIN permits the direct embedding of 485 EAN.UCC System standard GTIN and Serial Number codes on EPC tags. In 486 all cases, the check digit is not encoded. Two encoding schemes are 487 specified, SGTIN-64 (64 bits) and SGTIN-96 (96 bits). 489 The Serial Shipping Container Code (SSCC) is defined by the EAN.UCC 490 Specifications. Unlike the GTIN, the SSCC is already intended for 491 assignment to individual objects and therefore does not require 492 additional fields to serve as an EPC pure identity. Two encoding 493 schemes are specified, SSCC-64 (64 bits) and SSCC-96 (96 bits). 495 The Global Location Number (GLN) is defined by the EAN.UCC 496 Specifications. A GLN can represent either a discrete, unique 497 physical location such as a warehouse slot, or an aggregate physical 498 location such as an entire warehouse. In addition, a GLN can 499 represent a logical entity that performs a business function such as 500 placing an order. The Serialized Global Location Number (SGLN) 501 includes the Company Prefix, Location Reference, and Serial Number. 503 The Global Returnable Asset Identifier (GRAI) is defined by the 504 General EAN.UCC Specifications. Unlike the GTIN, the GRAI is already 505 intended for assignment to individual objects and therefore does not 506 require any additional fields to serve as an EPC pure identity. The 507 GRAI includes the Company Prefix, Asset Type, and Serial Number. 509 The Global Individual Asset Identifier (GIAI) is defined by the 510 General EAN.UCC Specifications. Unlike the GTIN, the GIAI is already 511 intended for assignment to individual objects and therefore does not 512 require any additional fields to serve as an EPC pure identity. The 513 GRAI includes the Company Prefix, and Individual Asset Reference. 515 The DoD Construct identifier is defined by the United States 516 Department of Defense (DoD). This tag data construct may be used to 517 encode tags for shipping goods to the DoD by a supplier who has 518 already been assigned a CAGE (Commercial and Government Entity) code. 520 A.1.1. Description of the RFID-SGTIN-64 type 522 The RFID-SGTIN-64 is encoded as specified in [EPC-Tag-Data]. The 523 SGTIN-64 includes five fields: Header, Filter Value (additional data 524 that is used for fast filtering and pre-selection), Company Prefix 525 Index, Item Reference, and Serial Number. Only a limited number of 526 Company Prefixes can be represented in the 64-bit tag. 528 A.1.2. Description of the RFID-SGTIN-96 type 530 The RFID-SGTIN-96 is encoded as specified in [EPC-Tag-Data]. The 531 SGTIN-96 includes six fields: Header, Filter Value, Partition (an 532 indication of where the subsequent Company Prefix and Item Reference 533 numbers are divided), Company Prefix Index, Item Reference, and 534 Serial Number. 536 A.1.3. Description of the RFID-SSCC-64 type 538 The RFID-SSCC-64 is encoded as specified in [EPC-Tag-Data]. The 539 SSCC-64 includes four fields: Header, Filter Value, Company Prefix 540 Index, and Serial Reference. Only a limited number of Company 541 Prefixes can be represented in the 64-bit tag. 543 A.1.4. Description of the RFID-SSCC-96 type 545 The RFID-SSCC-96 is encoded as specified in [EPC-Tag-Data]. The 546 SSCC-96 includes six fields: Header, Filter Value, Partition, Company 547 Prefix, and Serial Reference, as well as 24 bits that remain 548 Unallocated and must be zero. 550 A.1.5. Description of the RFID-SGLN-64 type 552 The RFID-SGLN-64 type is encoded as specified in [EPC-Tag-Data]. The 553 SGLN-64 includes five fields: Header, Filter Value, Company Prefix 554 Index, Location Reference, and Serial Number. 556 A.1.6. Description of the RFID-SGLN-96 type 558 The RFID-SGLN-96 type is encoded as specified in [EPC-Tag-Data]. The 559 SGLN-96 includes six fields: Header, Filter Value, Partition, Company 560 Prefix, Location Reference, and Serial Number. 562 A.1.7. Description of the RFID-GRAI-64 type 564 The RFID-GRAI-64 type is encoded as specified in [EPC-Tag-Data]. The 565 GRAI-64 includes five fields: Header, Filter Value, Company Prefix 566 Index, Asset Type, and Serial Number. 568 A.1.8. Description of the RFID-GRAI-96 type 570 The RFID-GRAI-96 type is encoded as specified in [EPC-Tag-Data]. The 571 GRAI-96 includes six fields: Header, Filter Value, Partition, Company 572 Prefix, Asset Type, and Serial Number. 574 A.1.9. Description of the RFID-GIAI-64 type 576 The RFID-GIAI-64 type is encoded as specified in [EPC-Tag-Data]. The 577 GIAI-64 includes four fields: Header, Filter Value, Company Prefix 578 Index, and Individual Asset Reference. 580 A.1.10. Description of the RFID-GIAI-96 type 582 The RFID-GIAI-96 type is encoded as specified in [EPC-Tag-Data]. The 583 GIAI-96 includes five fields: Header, Filter Value, Partition, 584 Company Prefix, and Individual Asset Reference. 586 A.1.11. Description of the RFID-DoD-64 type 588 The RFID-DoD-64 type is encoded as specified in [RFID-DoD-spec]. The 589 DoD-64 type includes four fields: Header, Filter Value, Government 590 Managed Identifier, and Serial Number. 592 A.1.12. Description of the RFID-DoD-96 type 594 The RFID-DoD-96 type is encoded as specified in [RFID-DoD-spec]. The 595 DoD-96 type includes four fields: Header, Filter Value, Government 596 Managed Identifier, and Serial Number. 598 A.1.13. Description of the RFID URI types 600 In some cases, it is desirable to encode in URI form a specific 601 encoding of an RFID tag. For example, an application may prefer a 602 URI representation for report preparation. Applications that wish to 603 manipulate any additional data fields on tags may need some 604 representation other than the pure identity forms. 606 For this purpose, the fields as represented the previous sections are 607 associated with specified fields in the various URI types. For 608 instance, the URI may have fields such as CompanyPrefix, 609 ItemReference, or SerialNumber. For details and encoding specifics, 610 consult [EPC-Tag-Data]. 612 Authors' Addresses 614 Charles E. Perkins 615 Futurewei Inc. 616 2330 Central Expressway 617 Santa Clara, CA 95050 618 USA 620 Phone: +1-408-330-4586 621 Email: charliep@computer.org 623 Vijay Devarapalli 624 Vasona Networks 625 2900 Lakeside Drive, Suite 180 626 Santa Clara, CA 95054 627 USA 629 Email: dvijay@gmail.com