[要約] RFC 4581は、Cryptographically Generated Addresses(CGA)拡張フィールドのフォーマットに関する仕様です。CGAは、IPv6ネットワークでのアドレス生成にセキュリティを提供するために使用されます。このRFCの目的は、CGA拡張フィールドの構造と使用方法を定義することです。

Network Working Group                                         M. Bagnulo
Request for Comments: 4581                                          UC3M
Updates: 3972                                                   J. Arkko
Category: Standards Track                                       Ericsson
                                                            October 2006
        

Cryptographically Generated Addresses (CGA) Extension Field Format

暗号で生成されたアドレス(CGA)拡張フィールド形式

Status of This Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2006).

Copyright(C)The Internet Society(2006)。

Abstract

概要

This document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972.

このドキュメントでは、Cryptographically Generated Address(CGA)ExtensionsのType-Length-Value形式を定義しています。このドキュメントはRFC 3972を更新します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. CGA Extension Field Format ......................................2
   3. IANA Considerations .............................................2
   4. Security Considerations .........................................3
   5. Acknowledgements ................................................3
   6. Normative References ............................................3
        
1. Introduction
1. はじめに

The Cryptographically Generated Address (CGA) specification [1] defines Extension Fields that allow additional information to be included in the CGA Parameter Data Structure. So far there seems to be enough interest in including additional data items into the CGA Parameter Data Structure through these Extension Fields that it seems reasonable to expect that more than one mechanism will require its usage. In order to simplify the addition of multiple data items, this document updates RFC 3972 [1], and it defines a Type-Length-Value format for the Extension Fields.

暗号生成アドレス(CGA)仕様[1]は、CGAパラメータデータ構造に追加情報を含めることを可能にする拡張フィールドを定義します。これまでのところ、これらの拡張フィールドを介してCGAパラメータデータ構造に追加のデータ項目を含めることに十分な関心があり、1つ以上のメカニズムがその使用を必要とすると予想するのが妥当だと思われます。複数のデータ項目の追加を簡略化するために、このドキュメントではRFC 3972 [1]を更新し、拡張フィールドのType-Length-Value形式を定義しています。

2. CGA Extension Field Format
2. CGA拡張フィールド形式

Data items to be included in Extension Fields of the CGA Parameter Data Structure MUST be encoded using the following Type-Length-Value (TLV) format:

CGAパラメータデータ構造の拡張フィールドに含めるデータ項目は、次のType-Length-Value(TLV)形式を使用してエンコードする必要があります。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Extension Type        |   Extension Data Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Extension Data                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Extension Type: 16-bit identifier of the type of the Extension Field.

拡張タイプ:拡張フィールドのタイプの16ビット識別子。

Extension Data Length: 16-bit unsigned integer. Length of the Extension Data field of this option, in octets.

拡張データ長:16ビットの符号なし整数。このオプションの拡張データフィールドの長さ(オクテット単位)。

Extension Data: Variable-length field. Extension-Type-specific data.

拡張データ:可変長フィールド。拡張タイプ固有のデータ。

3. IANA Considerations
3. IANAに関する考慮事項

The IANA has created and will maintain a registry entitled, "CGA Extension Type". The values in this name space are 16-bit unsigned integers. Initial values for the CGA Extension Type field are given below; future assignments are to be made through Standards Action [2]. Assignments consist of a name and the value.

IANAは「CGA拡張タイプ」という名前のレジストリを作成し、維持します。この名前空間の値は、16ビットの符号なし整数です。 CGA拡張タイプフィールドの初期値を以下に示します。今後の割り当ては、標準アクション[2]を通じて行われます。割り当ては、名前と値で構成されます。

As recommended in [3], this document makes the following assignments for experimental and testing use: the value 0xFFFD, with name Exp_FFFD; the value 0xFFFE, with name Exp_FFFE, and the value 0xFFFF, with name Exp_FFFF.

[3]で推奨されているように、このドキュメントでは、実験およびテスト用に次の割り当てを行います。値0xFFFD、名前はExp_FFFD。 Exp_FFFEという名前の値0xFFFE、およびExp_FFFFという名前の値0xFFFF。

4. Security Considerations
4. セキュリティに関する考慮事項

No security concerns are raised by the adoption of the CGA Extension format described in this document. However, proper security analysis is required when new CGA Extensions are defined in order to make sure that they introduce no new vulnerabilities to the existing CGA schemes.

このドキュメントで説明されているCGA拡張形式を採用しても、セキュリティ上の懸念はありません。ただし、新しいCGA拡張が定義されている場合は、既存のCGAスキームに新しい脆弱性が生じないようにするために、適切なセキュリティ分析が必要です。

5. Acknowledgements
5. 謝辞

Comments to this document were provided by Sam Hartman, Allison Mankin, Pekka Savola, Thomas Narten, Tuomas Aura, Stefan Rommer, Julien Laganier, and James Kempf.

このドキュメントへのコメントは、Sam Hartman、Allison Mankin、Pekka Savola、Thomas Narten、Tuomas Aura、Stefan Rommer、Julien Laganier、およびJames Kempfによって提供されました。

6. Normative References
6. 引用文献

[1] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.

[1] Aura、T。、「Cryptographically Generated Addresses(CGA)」、RFC 3972、2005年3月。

[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[2] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。

[3] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.

[3] Narten、T。、「実験的およびテスト番号の割り当ては有用と見なされた」、BCP 82、RFC 3692、2004年1月。

Authors' Addresses

著者のアドレス

Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN

Marcelo Bagnulo Carlos IIIマドリッド大学Av。Universidad 30 Leganes、Madrid 28911スペイン

   Phone: 34 91 6249500
   EMail: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es
        

Jari Arkko Ericsson Jorvas 02420 Finland

Jari Arkko Ericsson Jorvas 02420フィンランド

   EMail: jari.arkko@ericsson.com
        

Full Copyright Statement

完全な著作権表示

Copyright (C) The Internet Society (2006).

Copyright(C)The Internet Society(2006)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または(もしあれば)組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、この規格の実装に必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディター機能の資金は、IETF管理サポート活動(IASA)によって提供されます。