[要約] RFC 8371は、MIPv6のためのモバイルノード識別子のタイプに関する規格です。このRFCの目的は、異なるタイプのモバイルノード識別子を定義し、MIPv6の実装と展開をサポートすることです。
Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 8371 Futurewei
Category: Standards Track V. Devarapalli
ISSN: 2070-1721 Vasona Networks
July 2018
Mobile Node Identifier Types for MIPv6
MIPv6のモバイルノード識別子タイプ
Abstract
概要
This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283.
このドキュメントでは、RFC 4283で定義されているモバイルIPv6（MIPv6）のモバイルノード識別子オプションで使用する追加の識別子タイプ番号を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8371.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Mobile Node Identifier Types . . . . . . . . . . . . . . 4
4. Descriptions of MN Identifier Types . . . . . . . . . . . . . 4
4.1. Description of the IPv6 Address Type . . . . . . . . . . 4
4.2. Description of the IMSI MN Identifier Type . . . . . . . 5
4.3. Description of the EUI-48 Address Type . . . . . . . . . 5
4.4. Description of the EUI-64 Address Type . . . . . . . . . 5
4.5. Description of the DUID Type . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. RFID Types . . . . . . . . . . . . . . . . . . . . . 9
A.1. Description of the RFID Types . . . . . . . . . . . . . . 13
A.1.1. Description of the RFID-SGTIN-64 Type . . . . . . . . 14
A.1.2. Description of the RFID-SGTIN-96 Type . . . . . . . . 14
A.1.3. Description of the RFID-SSCC-64 Type . . . . . . . . 14
A.1.4. Description of the RFID-SSCC-96 Type . . . . . . . . 14
A.1.5. Description of the RFID-SGLN-64 Type . . . . . . . . 14
A.1.6. Description of the RFID-SGLN-96 Type . . . . . . . . 14
A.1.7. Description of the RFID-GRAI-64 Type . . . . . . . . 15
A.1.8. Description of the RFID-GRAI-96 Type . . . . . . . . 15
A.1.9. Description of the RFID-GIAI-64 Type . . . . . . . . 15
A.1.10. Description of the RFID-GIAI-96 Type . . . . . . . . 15
A.1.11. Description of the RFID-DoD-64 Type . . . . . . . . . 15
A.1.12. Description of the RFID-DoD-96 Type . . . . . . . . . 15
A.1.13. Description of the RFID URI Types . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 in RFC 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.
「モバイルIPv6のモバイルノード識別子オプション（MIPv6）」[RFC4283]は、Diameter [RFC6733]などの認証、承認、およびアカウンティング（AAA）プロトコルを使用した認証手順中にモバイルノードの識別子を提供する一般的な設計ツールであることが証明されています。現在までのところ、1種類の識別子、つまりモバイルノード（MN）NAIのみが指定されています。他のタイプの識別子が一般的に使用されており、RFC 4283でも参照されています。このドキュメントでは、国際モバイル加入者識別（IMSI）[ThreeGPP-IDS]のタイプを含む、さまざまな電気通信規格で定義されている基本的な識別子タイプを追加することを提案します。 、パケット-Temporary Mobile Subscriber Identity（P-TMSI）[ThreeGPP-IDS]、International Mobile Station Equipment Identities（IMEI）[ThreeGPP-IDS]、Globally Unique Temporary UE Identity（GUTI）[ThreeGPP-IDS]。さらに、IPv6アドレス自体とIEEE MACレイヤーアドレスをモバイルノード識別子として指定します。デバイスの物理要素（MACアドレスなど）に関連付けられた識別子を定義すると、モバイルIPの導入に役立ちます。これは、多くの場合、このような識別子がデバイスを一意に識別するための最も自然な手段であり、追加のルックアップ手順を回避するためです。他の識別子が使用された場合、必要になる可能性があります。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
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 Description
表1：モバイルノード識別子の説明
This section provides descriptions for the various MN identifier types.
このセクションでは、さまざまなMN識別子タイプについて説明します。
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.
IPv6アドレス[RFC4291]は、モバイルノードに割り当てられた完全なIPv6アドレスを含む16オクテット文字列としてエンコードされます。 IPv6アドレスは、ユニキャストルーティング可能なIPv6アドレスである必要があります。マルチキャストアドレス、リンクローカルアドレス、および未指定のIPv6アドレスは使用してはなりません（MUST NOT）。 IPv6の一意のローカルアドレス（ULA）は、ULAを使用するセキュリティ操作でも、ULAが一意であることが保証されているドメインを考慮に入れている限り使用できます。
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:
国際モバイルサブスクライバーアイデンティティ（IMSI）[ThreeGPP-IDS]は、最大15桁の10進数字（つまり、0から9までの数字）です。 IMSIは、ネットワークの順序でオクテットの文字列としてエンコードする必要があります（つまり、すべての桁で高から低）。各桁は4ビットを占めます。完全なオクテットサイズが必要な場合は、最後の桁に0xfを埋め込む必要があります。たとえば、IMSI 123456123456789の例は次のようにエンコードされます。
0x12, 0x34, 0x56, 0x12, 0x34, 0x56, 0x78, 0x9f
0x12、0x34、0x56、0x12、0x34、0x56、0x78、0x9f
The IEEE EUI-48 address [IEEE802-GUIDELINES] is encoded as 6 octets containing the IEEE EUI-48 address.
IEEE EUI-48アドレス[IEEE802-GUIDELINES]は、IEEE EUI-48アドレスを含む6オクテットとしてエンコードされます。
The IEEE EUI-64 address [IEEE802-GUIDELINES] is encoded as 8 octets containing the full IEEE EUI-64 address.
IEEE EUI-64アドレス[IEEE802-GUIDELINES]は、完全なIEEE EUI-64アドレスを含む8オクテットとしてエンコードされます。
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.
DUIDはDHCPv6の一意の識別子です[RFC3315]。 DUIDにはさまざまなタイプがあり、最初の2オクテットタイプフィールドで区別されます。クライアントとサーバーはDUIDを不透明な値として扱い、DUIDが等しいかどうかのみを比較しなければなりません（MUST）。
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.
このドキュメントで説明されているようなモバイルノード識別子は、個人情報と見なされます。 [RFC4283]で定義されているMN識別子拡張で使用される場合、MN識別子拡張を含むパケットは、個人情報や追跡可能な識別子がパッシブオブザーバーに誤って開示されないように暗号化する必要があります。オペレーターは、MIPv6シグナリングメッセージのIDと位置情報を保護するための機密性と整合性保護を備えたトランスポートモードでIPsecカプセル化セキュリティペイロード（ESP）[RFC4303]を適用する可能性があります。
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 temporary identifier allocated during the initial network entry. Managing the association between long-lived and temporary identifiers is outside the scope of this document.
一部のMN識別子には機密識別子が含まれており、他の標準開発機構（SDO）によって指定されたプロトコルで使用されているように、最初のネットワークエントリ時のシグナリングにのみ使用されます。そのようなプロトコルでは、その後の交換は、最初のネットワークエントリ中に割り当てられた一時的な識別子に依存します。長期間有効な識別子と一時的な識別子の間の関連付けの管理は、このドキュメントの範囲外です。
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
表2：新しいモバイルノード識別子のタイプ
See Section 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.
識別子タイプの詳細については、セクション4を参照してください。登録手続きは、Standards Action [RFC8126]です。専門家は、識別子の種類によってモバイルデバイスを一意に識別できることを確認する必要があります。すべてのMN識別子は暗号化を必要とするため、新しいタイプの使用に伴うプライバシーの露出はありません。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[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、2003年7月、<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>.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6（MIPv6）のモバイルノード識別子オプション」、RFC 4283、DOI 10.17487 / RFC4283、11月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>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<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>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<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>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[EANUCCGS] EAN International and the Uniform Code Council, "General EAN.UCC Specifications", Version 5.0, January 2004.
[EANUCCGS] EAN International and Uniform Code Council、「General EAN.UCC Specifications」、バージョン5.0、2004年1月。
[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>.
[EPC-Tag-Data] EPCglobal、Inc。、「EPC Generation 1 Tag Data Standards Version 1.1 Rev.1.27」、2005年5月、<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] 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>.
[IEEE802-GUIDELINES] IEEE、「Extended Unique Identifier（EUI）、Organizationally Unique Identifier（OUI）、およびCompany ID（CID）の使用に関するガイドライン」、2018年8月、<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>.
[RFC6733] Fajardo、V。、編、Arkko、J.、Loughney、J。、およびG. Zorn、編、「Diameter Base Protocol」、RFC 6733、DOI 10.17487 / RFC6733、2012年10月、<https：/ /www.rfc-editor.org/info/rfc6733>。
[RFID-DoD-spec] Department of Defense, "United States Department of Defense Suppliers' Passive RFID Information Guide", Version 15.0, January 2010.
[RFID-DoD-spec]国防総省、「米国国防総省サプライヤーのパッシブRFID情報ガイド」、バージョン15.0、2010年1月。
[RFID-framework] Botero, O., "Heterogeneous RFID framework design, analysis and evaluation", Institut National des Telecommunications, July 2012.
[RFIDフレームワーク]ボテロ、O。、「異種RFIDフレームワークの設計、分析および評価」、Institut National des Telecommunications、2012年7月。
[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.
[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、2018年3月。
[TRACK-IoT] Chaouchi, H., "Heterogeneous IoT Network: TRACK-IoT Plateform", Telecom SudParis, Internal Report, March 2012.
[TRACK-IoT] Chaouchi、H。、「Heterogeneous IoT Network：TRACK-IoT Plateform」、Telecom SudParis、内部レポート、2012年3月。
[Using-RFID-IPv6] IPv6.com, "Using RFID & IPv6", September 2006.
[Using-RFID-IPv6] IPv6.com、「Using RFID＆IPv6」、2006年9月。
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.
この非規範的な付録の資料は、当初は仕様の本文に含めるように構成されていましたが、当時は無線周波数識別（RFID）タイプの割り当てに対するサポートが不十分だったため、付録に移動されました。シグナリングの機密性が保証されていない限り、RFIDベースのモバイルデバイスがプライバシーの危険にさらされる可能性があることが観察されました。レイヤー2アドレスに基づく不正なRFID追跡を排除するための仕様が役立つでしょう。
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].
次のテキストの多くは、Hakima Chaouchiからの寄稿によるものです。モバイルデバイスでのIPv6でのRFIDの使用に関する概要といくつかの最初の提案については、[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.
モノのインターネット（IoT）とインダストリー4.0のコンテキストでは、垂直ドメイン、効率的な在庫、追跡項目が大きな関心事であり、RFID技術は、そのような多くの項目のハードウェア設計における識別技術です。
The "TRACK-IoT" project [TRACK-IoT] [RFID-framework] explored Mobile IPv6 as a mobility management protocol for RFID-based mobile devices.
「TRACK-IoT」プロジェクト[TRACK-IoT] [RFID-framework]は、RFIDベースのモバイルデバイスのモビリティ管理プロトコルとしてモバイルIPv6を調査しました。
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.
1. パッシブRFIDタグ（処理リソースを持たない）は、ゲートウェイ（おそらくRFIDリーダーも）で処理する必要があります。ゲートウェイは、モビリティプロトコルのエンドポイントになります。また、RFIDタグとそのゲートウェイのプレフィックスなどの組み合わせに基づいてアドレス変更（CoA）が作成されるポイントでもあります。ここでのポイントは、パッシブRFIDアイテムにIPv6アドレスを取得する可能性を提供し、モビリティフレームワークを利用してモバイルデバイス（アイテムのパッシブタグ）を追跡することです。パッシブRFIDアイテムのモビリティ管理の必要性を示す、提案されている1つのシナリオ例は、輸送中に監視する必要があるパッシブタグでタグ付けされた芸術作品です。
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.
2. アクティブなRFIDタグ（処理リソースがタグで利用可能な場合）を使用すると、モビリティプロトコルのエンドポイントを、識別センサーとも呼ばれるRFIDアクティブタグで直接ホストできます。アクティブRFIDタグの使用例には、移動中（輸送中）の冷たい食品のトレーサビリティが含まれます。また、既に料金支払いに使用しているアクティブRFIDタグを搭載した車のモビリティをモビリティ管理で追加できます。
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 information 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.
IETFの取り組みをEPCglobal（RFID標準化）に接続するための主要な取り組みの1つは、RFID論理名とページ情報の取得に適用されるDNSバージョンであるオブジェクトネームサービス（ONS）です。アドレス空間のIPv6をRFID識別子形式に接続する試みが行われました。他のイニシアチブは、ゲートウェイに取り組み、タグ識別子をIPv6アドレスにマップし、アプリケーションレベルのシグナリングプロトコルを構築し始めました。たとえば、タグを備えたモバイルアイテムの追跡は、RFIDタグを備えたモバイルアイテムが配置されている訪問エリアまで、リモートコレスポンデントノードによってリモートでトリガーできます。 RFIDリーダーは、IPv6-to-RFIDタグ変換とともに追加されます。 1つのオプションは、モバイルアイテムのタグRFID識別子と組み合わせたホームエージェントのプレフィックスを使用して、そのタグ付きアイテムのホームIPv6アドレスを構築することです。タグIDは一意であるため、そのアイテムのホームIPv6アドレスも一意になります。次に、訪問RFIDリーダーは、RFIDリーダーのプレフィックスとアイテムのタグIDを組み合わせることにより、タグ付きモバイルアイテムのIPv6気付アドレスを作成します。 MIPv6は通常、そのRFIDタグ付きアイテムのモビリティ管理を提供できます。タグ付けされたアイテムの別の便利な例には、特にGPSなしで輸送される貴重なアイテムのリアルタイムの位置特定と追跡のために、輸送中に追跡できる工場のアイテムが含まれます。自動車メーカーは、RFIDタグ付きの自動車や機械式自動車部品に対応するIPv6アドレスを割り当て、自動車だけでなく機械式部品の可動性の追跡データセットを構築できます。
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:
Electronic Product Code（EPC）[EPC-Tag-Data]によって推進されているタグデータ規格は、以下を含むRFIDアプリケーションで一般的に使用されるいくつかのエンコードシステムまたはスキームをサポートしています。
o RFID-GID (Global Identifier),
o RFID-GID（グローバル識別子）、
o RFID-SGTIN (Serialized Global Trade Item Number),
o RFID-SGTIN（シリアル化されたグローバルトレードアイテム番号）、
o RFID-SSCC (Serial Shipping Container Code),
o RFID-SSCC（シリアル輸送コンテナコード）、
o RFID-SGLN (Serialized Global Location Number),
o RFID-SGLN（Serialized Global Location Number）、
o RFID-GRAI (Global Returnable Asset Identifier),
o RFID-GRAI（Global Returnable Asset Identifier）、
o RFID-DOD (Department of Defense ID), and
o RFID-DOD（国防総省ID）、および
o RFID-GIAI (Global Individual Asset Identifier).
o RFID-GIAI（Global Individual Asset Identifier）。
For each RFID scheme except GID, there are three representations:
GIDを除く各RFIDスキームには、3つの表現があります。
o a 64-bit binary representation (for example, SGLN-64), excluding GID,
o GIDを除く64ビットのバイナリ表現（SGLN-64など）
o a 96-bit binary representation (SGLN-96), and
o 96ビットのバイナリ表現（SGLN-96）、および
o a representation as a URI.
o URIとしての表現。
The URI representation for the RFID is actually a URN. The EPC document has the following language:
RFIDのURI表現は実際にはURNです。 EPCドキュメントの言語は次のとおりです。
All categories of URIs are represented as Uniform Reference Names (URNs) as defined by [RFC2141], where the URN Namespace is epc.
URIのすべてのカテゴリは、[RFC2141]で定義されているように、統一参照名（URN）として表されます。URN名前空間はepcです。
The following list includes the above RFID types.
以下のリストには、上記のRFIDタイプが含まれています。
+----------------+--------------------------------+-----------------+
| 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 Description
表3：モバイルノードのRFID識別子の説明
The material in this appendix has been either quoted or loosely adapted from [EPC-Tag-Data].
この付録の内容は、[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.
RFIDで使用されるGeneral Identifier（GID）は、General Manager Number、Object Class、およびSerial Numberの3つのフィールドで構成されています。ゼネラルマネージャー番号は、後続のフィールドで番号を維持する責任がある組織エンティティを識別します。 GIDエンコードには、EPCによって定義された名前空間の一意性を保証するための4番目のフィールドであるヘッダーが含まれます。
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.
RFIDタイプの一部は、EAN.UCC一般仕様[EANUCCGS]で定義されているグローバルトレードアイテム番号（GTIN）コードに依存しています。 GTINは、特定の種類の製品や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).
SGTINのEPCエンコードスキームでは、EPCタグにEAN.UCCシステムの標準GTINおよびシリアル番号コードを直接埋め込むことができます。すべての場合において、チェックディジットはエンコードされません。 SGTIN-64（64ビット）とSGTIN-96（96ビット）の2つのコード化スキームが指定されています。
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).
Serial Shipping Container Code（SSCC）は、EAN.UCC仕様で定義されています。 GTINとは異なり、SSCCはすでに個々のオブジェクトへの割り当てを目的としているため、EPCの純粋なIDとして機能するために追加のフィールドを必要としません。 SSCC-64（64ビット）とSSCC-96（96ビット）の2つのエンコード方式が指定されています。
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.
グローバルロケーション番号（GLN）は、EAN.UCC仕様で定義されています。 GLNは、倉庫スロットなどの個別の一意の物理的な場所、または倉庫全体などの集合的な物理的な場所のいずれかを表すことができます。さらに、GLNは、注文などのビジネス機能を実行する論理エンティティを表すことができます。シリアル化されたグローバルロケーション番号（SGLN）には、会社のプレフィックス、ロケーション参照、およびシリアル番号が含まれます。
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.
Global Returnable Asset Identifier（GRAI）は、一般的なEAN.UCC仕様で定義されています。 GTINとは異なり、GRAIはすでに個々のオブジェクトへの割り当てを目的としているため、EPCの純粋なIDとして機能する追加のフィールドは必要ありません。 GRAIには、会社のプレフィックス、資産タイプ、およびシリアル番号が含まれています。
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.
グローバル個別資産識別子（GIAI）は、一般的なEAN.UCC仕様で定義されています。 GTINとは異なり、GIAIはすでに個々のオブジェクトへの割り当てを目的としているため、EPCの純粋なIDとして機能するために追加のフィールドを必要としません。 GRAIには、会社の接頭辞と個別の資産参照が含まれています。
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.
DoD構成IDは、米国国防総省（DoD）によって定義されています。このタグデータ構成は、商業および政府機関（CAGE）コードが既に割り当てられているサプライヤがDoDに商品を出荷するためのタグをエンコードするために使用できます。
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.
RFID-SGTIN-64は、[EPC-Tag-Data]で指定されているようにエンコードされます。 SGTIN-64には、ヘッダー、フィルター値（高速フィルタリングと事前選択に使用される追加データ）、会社接頭辞インデックス、アイテム参照、およびシリアル番号の5つのフィールドが含まれています。 64ビットのタグで表現できる会社のプレフィックスの数は限られています。
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.
RFID-SGTIN-96は、[EPC-Tag-Data]で指定されているようにエンコードされます。 SGTIN-96には、ヘッダー、フィルター値、パーティション（後続の会社接頭辞とアイテム参照番号が分割される場所を示す）、会社接頭辞インデックス、アイテム参照、およびシリアル番号の6つのフィールドが含まれます。
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.
RFID-SSCC-64は、[EPC-Tag-Data]で指定されているようにエンコードされます。 SSCC-64には、ヘッダー、フィルター値、会社接頭辞インデックス、シリアル参照の4つのフィールドがあります。 64ビットのタグで表現できる会社のプレフィックスの数は限られています。
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.
RFID-SSCC-96は、[EPC-Tag-Data]で指定されているようにエンコードされます。 SSCC-96には、ヘッダー、フィルター値、パーティション、会社プレフィックス、シリアル参照の6つのフィールドと、未割り当てのままでゼロでなければならない24ビットが含まれています。
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.
RFID-SGLN-64タイプは、[EPC-Tag-Data]での指定に従ってエンコードされます。 SGLN-64には、ヘッダー、フィルター値、会社接頭辞インデックス、場所参照、およびシリアル番号の5つのフィールドが含まれています。
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.
RFID-SGLN-96タイプは、[EPC-Tag-Data]での指定に従ってエンコードされます。 SGLN-96には、ヘッダー、フィルター値、パーティション、会社のプレフィックス、場所の参照、シリアル番号の6つのフィールドがあります。
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.
RFID-GRAI-64タイプは、[EPC-Tag-Data]での指定に従ってエンコードされます。 GRAI-64には、ヘッダー、フィルター値、会社接頭辞インデックス、資産タイプ、シリアル番号の5つのフィールドがあります。
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.
RFID-GRAI-96タイプは、[EPC-Tag-Data]で指定されているようにエンコードされます。 GRAI-96には、ヘッダー、フィルター値、パーティション、会社プレフィックス、資産タイプ、シリアル番号の6つのフィールドがあります。
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.
RFID-GIAI-64タイプは、[EPC-Tag-Data]で指定されているようにエンコードされます。 GIAI-64には、ヘッダー、フィルター値、会社接頭辞インデックス、個別資産参照の4つのフィールドがあります。
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.
RFID-GIAI-96タイプは、[EPC-Tag-Data]で指定されているようにエンコードされます。 GIAI-96には、ヘッダー、フィルター値、パーティション、会社プレフィックス、および個別資産参照の5つのフィールドがあります。
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.
RFID-DoD-64タイプは、[RFID-DoD-spec]で指定されているようにエンコードされます。 DoD-64タイプには、ヘッダー、フィルター値、政府管理識別子、シリアル番号の4つのフィールドが含まれます。
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.
RFID-DoD-96タイプは、[RFID-DoD-spec]で指定されているようにエンコードされます。 DoD-96タイプには、ヘッダー、フィルター値、政府管理識別子、シリアル番号の4つのフィールドが含まれます。
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.
場合によっては、RFIDタグの特定のエンコードをURI形式でエンコードすることが望ましいことがあります。たとえば、アプリケーションは、レポートの準備のためにURI表現を好む場合があります。タグの追加のデータフィールドを操作するアプリケーションでは、純粋なIDフォーム以外の表現が必要になる場合があります。
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, ItemReference, or SerialNumber. For details and encoding specifics, consult [EPC-Tag-Data].
この目的のために、前のセクションで表されているフィールドは、さまざまなURIタイプの指定されたフィールドに関連付けられています。たとえば、URIにはCompanyPrefix、ItemReference、SerialNumberなどのフィールドが含まれる場合があります。詳細とエンコードの詳細については、[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.
著者らは、有益なコメントを寄せられたハキマチャウチー、タトゥヤジンメイ、ジョウニコロホネン、スリガンダヴェッリ、スレーシュクリシュナン、ダペンリュー、デールウォーリー、ジョセフサロウイ、リンダダンバー、およびミルジャキューレウィンドに感謝します。著者はまた、この文書を作成する最終段階で、多くの貴重な提案と更新についてRFC Editorを承認したいと考えています。
Authors' Addresses
著者のアドレス
Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 United States of America
Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara、CA 95050アメリカ合衆国
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
Vijay Devarapalli Vasona Networks 2900 Lakeside Drive、Suite 180 Santa Clara、CA 95054アメリカ合衆国
Email: dvijay@gmail.com