[要約] RFC 3972は、Cryptographically Generated Addresses（CGA）の仕様を定義しており、IPv6ネットワークでのセキュアなアドレス生成を可能にする。CGAは、アドレスの真正性を確保し、ネットワーク攻撃を防ぐために使用される。
Network Working Group T. Aura
Request for Comments: 3972 Microsoft Research
Category: Standards Track March 2005
Cryptographically Generated Addresses (CGA)
暗号的に生成されたアドレス（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 (2004).
Copyright（C）The Internet Society（2004）。
Abstract
概要
This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure.
このドキュメントでは、Secure Neighbor Discovery（SEND）プロトコルでパブリック署名キーをIPv6アドレスにバインドする方法について説明します。暗号化生成アドレス（CGA）は、公開鍵と補助パラメーターから暗号化一方向ハッシュ関数を計算することによってインターフェース識別子が生成されるIPv6アドレスです。公開鍵とアドレスの間のバインディングは、ハッシュ値を再計算し、ハッシュをインターフェイス識別子と比較することによって確認できます。 IPv6アドレスから送信されたメッセージは、公開鍵と補助パラメーターを付加し、対応する秘密鍵でメッセージに署名することによって保護できます。保護は、証明機関やセキュリティインフラストラクチャなしで機能します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. CGA Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CGA Parameters and Hash Values . . . . . . . . . . . . . . . . 5
4. CGA Generation . . . . . . . . . . . . . . . . . . . . . . . . 6
5. CGA Verification . . . . . . . . . . . . . . . . . . . . . . . 9
6. CGA Signatures . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Security Goals and Limitations . . . . . . . . . . . . . 12
7.2. Hash Extension . . . . . . . . . . . . . . . . . . . . . 13
7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 15
7.4. Related Protocols . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A. Example of CGA Generation. . . . . . . . . . . . . . . . . 20
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statements. . . . . . . . . . . . . . . . . . . . . 22
This document specifies a method for securely associating a cryptographic public key with an IPv6 address in the Secure Neighbor Discovery (SEND) protocol [RFC3971]. The basic idea is to generate the interface identifier (i.e., the rightmost 64 bits) of the IPv6 address by computing a cryptographic hash of the public key. The resulting IPv6 address is called a cryptographically generated address (CGA). The corresponding private key can then be used to sign messages sent from the address. An introduction to CGAs and their application to SEND can be found in [Aura03] and [AAKMNR02].
このドキュメントでは、Secure Neighbor Discovery（SEND）プロトコル[RFC3971]で暗号化公開鍵をIPv6アドレスに安全に関連付ける方法を指定しています。基本的な考え方は、公開鍵の暗号化ハッシュを計算することにより、IPv6アドレスのインターフェース識別子（つまり、右端の64ビット）を生成することです。結果のIPv6アドレスは、暗号化生成アドレス（CGA）と呼ばれます。次に、対応する秘密鍵を使用して、アドレスから送信されたメッセージに署名できます。 CGAの概要とSENDへの適用については、[Aura03]と[AAKMNR02]を参照してください。
This document specifies:
このドキュメントでは次のことを指定しています
o how to generate a CGA from the cryptographic hash of a public key and auxiliary parameters,
o 公開鍵と補助パラメータの暗号化ハッシュからCGAを生成する方法
o how to verify the association between the public key and the CGA, and
o 公開鍵とCGA間の関連付けを確認する方法、および
o how to sign a message sent from the CGA, and how to verify the signature.
o CGAから送信されたメッセージに署名する方法、および署名を検証する方法。
To verify the association between the address and the public key, the verifier needs to know the address itself, the public key, and the values of the auxiliary parameters. The verifier can then go on to verify messages signed by the owner of the public key (i.e., the address owner). No additional security infrastructure, such as a public key infrastructure (PKI), certification authorities, or other trusted servers, is needed.
アドレスと公開鍵の関連付けを検証するには、検証者はアドレス自体、公開鍵、および補助パラメーターの値を知っている必要があります。次に、検証者は、公開鍵の所有者（つまり、アドレスの所有者）によって署名されたメッセージを検証します。公開キー基盤（PKI）、証明機関、その他の信頼されたサーバーなどの追加のセキュリティ基盤は必要ありません。
Note that because CGAs themselves are not certified, an attacker can create a new CGA from any subnet prefix and its own (or anyone else's) public key. However, the attacker cannot take a CGA created by someone else and send signed messages that appear to come from the owner of that address.
CGA自体は認証されていないため、攻撃者はサブネットプレフィックスとそれ自体（または他の誰か）の公開鍵から新しいCGAを作成できることに注意してください。ただし、攻撃者は他の誰かが作成したCGAを取得して、そのアドレスの所有者から送信されたように見える署名付きメッセージを送信することはできません。
The address format and the CGA parameter format are defined in Sections 2 and 3. Detailed algorithms for generating addresses and for verifying them are given in Sections 4 and 5, respectively. Section 6 defines the procedures for generating and verifying CGA signatures. The security considerations in Section 7 include limitations of CGA-based security, the reasoning behind the hash extension technique that enables effective hash lengths above the 64-bit limit of the interface identifier, the implications of CGAs on privacy, and protection against related-protocol attacks.
アドレスの形式とCGAパラメータの形式は、セクション2と3で定義されています。アドレスの生成と検証の詳細なアルゴリズムについては、それぞれセクション4と5で説明します。セクション6では、CGA署名の生成と検証の手順を定義します。セクション7のセキュリティに関する考慮事項には、CGAベースのセキュリティの制限、インターフェイス識別子の64ビット制限を超える有効なハッシュ長を可能にするハッシュ拡張手法の背後にある理由、プライバシーに対するCGAの影響、および関連プロトコルに対する保護が含まれます。攻撃。
In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119].
このドキュメントでは、キーワード「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」、「必須」は、[RFC2119]で説明されているように解釈されます。
When talking about addresses, this document refers to IPv6 addresses in which the leftmost 64 bits of a 128-bit address form the subnet prefix and the rightmost 64 bits of the address form the interface identifier [RFC3513]. We number the bits of the interface identifier starting from bit zero on the left.
アドレスについて話すとき、このドキュメントは、128ビットアドレスの左端の64ビットがサブネットプレフィックスを形成し、アドレスの右端の64ビットがインターフェース識別子を形成するIPv6アドレスに言及します[RFC3513]。左側のビット0から始まるインターフェイス識別子のビットに番号を付けます。
A cryptographically generated address (CGA) has a security parameter (Sec) that determines its strength against brute-force attacks. The security parameter is a three-bit unsigned integer, and it is encoded in the three leftmost bits (i.e., bits 0 - 2) of the interface identifier. This can be written as follows:
暗号で生成されたアドレス（CGA）には、ブルートフォース攻撃に対する強度を決定するセキュリティパラメーター（Sec）があります。セキュリティパラメータは3ビットの符号なし整数であり、インターフェース識別子の左端の3ビット（ビット0〜2）でエンコードされます。これは次のように書くことができます：
Sec = (interface identifier & 0xe000000000000000) >> 61
The CGA is associated with a set of parameters that consist of a public key and auxiliary parameters. Two hash values Hash1 (64 bits) and Hash2 (112 bits) are computed from the parameters. The formats of the public key and auxiliary parameters, and the way to compute the hash values, are defined in Section 3.
CGAは、公開鍵と補助パラメーターで構成されるパラメーターのセットに関連付けられています。 2つのハッシュ値Hash1（64ビット）およびHash2（112ビット）がパラメーターから計算されます。公開鍵と補助パラメータの形式、およびハッシュ値の計算方法は、セクション3で定義されています。
A cryptographically generated address is defined as an IPv6 address that satisfies the following two conditions:
暗号で生成されたアドレスは、次の2つの条件を満たすIPv6アドレスとして定義されます。
o The first hash value, Hash1, equals the interface identifier of the address. Bits 0, 1, 2, 6, and 7 (i.e., the bits that encode the security parameter Sec and the "u" and "g" bits from the standard IPv6 address architecture format of interface identifiers [RFC3513]) are ignored in the comparison.
o 最初のハッシュ値Hash1は、アドレスのインターフェース識別子と同じです。ビット0、1、2、6、および7（つまり、セキュリティパラメータSecをエンコードするビットと、インターフェイス識別子の標準IPv6アドレスアーキテクチャフォーマット[RFC3513]の "u"および "g"ビット）は、比較。
o The 16*Sec leftmost bits of the second hash value, Hash2, are zero.
o 2番目のハッシュ値Hash2の左端の16 * Secビットはゼロです。
The above definition can be stated in terms of the following two bit masks:
上記の定義は、次の2つのビットマスクで表すことができます。
Mask1 (64 bits) = 0x1cffffffffffffff
マスク1（64ビット）= 0x1cffffffffffffff
Mask2 (112 bits) = 0x0000000000000000000000000000 if Sec=0, 0xffff000000000000000000000000 if Sec=1, 0xffffffff00000000000000000000 if Sec=2, 0xffffffffffff0000000000000000 if Sec=3, 0xffffffffffffffff000000000000 if Sec=4, 0xffffffffffffffffffff00000000 if Sec=5, 0xffffffffffffffffffffffff0000 if Sec=6, and 0xffffffffffffffffffffffffffff if Sec=7
Mask2（112ビット）= Sec = 0の場合0x0000000000000000000000000000、Sec = 1の場合0xffff000000000000000000000000、Sec = 2の場合0xffffffffff00000000000000000000、Sec = 3の場合0xffffffffffffffff000000000000 Sec = 4、0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff Sec = 7の場合
A cryptographically generated address is an IPv6 address for which the following two equations hold:
暗号的に生成されたアドレスは、次の2つの式が当てはまるIPv6アドレスです。
Hash1 & Mask1 == interface identifier & Mask1
Hash2 & Mask2 == 0x0000000000000000000000000000
Each CGA is associated with a CGA Parameters data structure, which has the following format:
各CGAは、次の形式のCGAパラメータデータ構造に関連付けられています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Modifier (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix (8 octets) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Collision Count| |
+-+-+-+-+-+-+-+-+ |
| |
~ Public Key (variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension Fields (optional, variable length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Modifier
編集する
This field contains a 128-bit unsigned integer, which can be any value. The modifier is used during CGA generation to implement the hash extension and to enhance privacy by adding randomness to the address.
このフィールドには、128ビットの符号なし整数が含まれます。これは任意の値にすることができます。修飾子はCGA生成中に使用され、ハッシュ拡張を実装し、アドレスにランダム性を追加してプライバシーを強化します。
Subnet Prefix
サブネット接頭辞
This field contains the 64-bit subnet prefix of the CGA.
このフィールドには、CGAの64ビットのサブネットプレフィックスが含まれます。
Collision Count
衝突数
This is an eight-bit unsigned integer that MUST be 0, 1, or 2. The collision count is incremented during CGA generation to recover from an address collision detected by duplicate address detection.
これは、0、1、または2でなければならない8ビットの符号なし整数です。衝突カウントは、重複アドレス検出によって検出されたアドレス衝突から回復するために、CGA生成中に増分されます。
Public Key
公開鍵
This is a variable-length field containing the public key of the address owner. The public key MUST be formatted as a DER-encoded [ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo, defined in the Internet X.509 certificate profile [RFC3280]. SEND SHOULD use an RSA public/private key pair. When RSA is used, the algorithm identifier MUST be rsaEncryption, which is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by using the RSAPublicKey type as specified in Section 2.3.1 of RFC 3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits. Other public key types are undesirable in SEND, as they may result in incompatibilities between implementations. The length of this field is determined by the ASN.1 encoding.
これは、アドレス所有者の公開鍵を含む可変長フィールドです。公開鍵は、インターネットX.509証明書プロファイル[RFC3280]で定義されているタイプSubjectPublicKeyInfoのDERエンコード[ITU.X690.2002] ASN.1構造としてフォーマットする必要があります。 SEND SHOULDは、RSA公開/秘密鍵ペアを使用する必要があります。 RSAを使用する場合、アルゴリズム識別子はrsaEncryption（1.2.840.113549.1.1.1）である必要があり、RSA公開鍵は、RFC 3279 [RFC3279]のセクション2.3.1で指定されているRSAPublicKeyタイプを使用してフォーマットする必要があります。 RSAキーの長さは少なくとも384ビットである必要があります。他の公開鍵タイプは、実装間の非互換性をもたらす可能性があるため、SENDでは望ましくありません。このフィールドの長さは、ASN.1エンコーディングによって決定されます。
Extension Fields
拡張フィールド
This is an optional variable-length field that is not used in the current specification. Future versions of this specification may use this field for additional data items that need to be included in the CGA Parameters data structure. IETF standards action is required to specify the use of the extension fields. Implementations MUST ignore the value of any unrecognized extension fields.
これは、現在の仕様では使用されないオプションの可変長フィールドです。この仕様の将来のバージョンでは、CGAパラメータデータ構造に含める必要がある追加のデータ項目にこのフィールドを使用する可能性があります。拡張フィールドの使用を指定するには、IETF標準アクションが必要です。実装は、認識されない拡張フィールドの値を無視する必要があります。
The two hash values MUST be computed as follows. The SHA-1 hash algorithm [FIPS.180-1.1995] is applied to the CGA Parameters. When Hash1 is computed, the input to the SHA-1 algorithm is the CGA Parameters data structure. The 64-bit Hash1 is obtained by taking the leftmost 64 bits of the 160-bit SHA-1 hash value. When Hash2 is computed, the input is the same CGA Parameters data structure except that the subnet prefix and collision count are set to zero. The 112-bit Hash2 is obtained by taking the leftmost 112 bits of the 160-bit SHA-1 hash value. Note that the hash values are computed over the entire CGA Parameters data structure, including any unrecognized extension fields.
2つのハッシュ値は、次のように計算する必要があります。 SGA-1ハッシュアルゴリズム[FIPS.180-1.1995]がCGAパラメータに適用されます。 Hash1が計算されるとき、SHA-1アルゴリズムへの入力はCGAパラメータデータ構造です。 64ビットのHash1は、160ビットのSHA-1ハッシュ値の左端の64ビットを取得することによって取得されます。 Hash2が計算されるとき、サブネットプレフィックスと衝突カウントがゼロに設定されていることを除いて、入力は同じCGAパラメータデータ構造です。 112ビットのHash2は、160ビットのSHA-1ハッシュ値の左端の112ビットを取得することによって取得されます。ハッシュ値は、認識されない拡張フィールドを含む、CGAパラメータデータ構造全体にわたって計算されることに注意してください。
The process of generating a new CGA takes three input values: a 64-bit subnet prefix, the public key of the address owner as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, and the security parameter Sec, which is an unsigned three-bit integer. The cost of generating a new CGA depends exponentially on the security parameter Sec, which can have values from 0 to 7.
新しいCGAを生成するプロセスは、64ビットのサブネットプレフィックス、SubjectPublicKeyInfoタイプのDERエンコードされたASN.1構造としてのアドレス所有者の公開鍵、および署名されていないセキュリティパラメータSecの3つの入力値を取ります。 3ビット整数。新しいCGAを生成するコストは、セキュリティパラメータSecに指数的に依存します。Secは0〜7の値を持つことができます。
A CGA and associated parameters SHOULD be generated as follows:
CGAと関連パラメータは、次のように生成する必要があります。
1. Set the modifier to a random or pseudo-random 128-bit value.
1. 修飾子をランダムまたは疑似ランダム128ビット値に設定します。
2. Concatenate from left to right the modifier, 9 zero octets, the encoded public key, and any optional extension fields. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2.
2. 修飾子、9つのゼロオクテット、エンコードされた公開キー、およびオプションの拡張フィールドを左から右に連結します。連結でSHA-1アルゴリズムを実行します。 SHA-1ハッシュ値の左端の112ビットを取得します。結果はHash2です。
3. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are all zero (or if Sec=0), continue with step 4. Otherwise, increment the modifier by one and go back to step 2.
3. Hash2の左端の16 * Secビットをゼロと比較します。それらがすべてゼロの場合（またはSec = 0の場合）、ステップ4に進みます。それ以外の場合は、修飾子を1つ増やして、ステップ2に戻ります。
4. Set the 8-bit collision count to zero.
4. 8ビットの衝突カウントをゼロに設定します。
5. Concatenate from left to right the final modifier value, the subnet prefix, the collision count, the encoded public key, and any optional extension fields. Execute the SHA-1 algorithm on the concatenation. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1.
5. 最終修飾子の値、サブネットプレフィックス、衝突カウント、エンコードされた公開キー、およびオプションの拡張フィールドを左から右に連結します。連結でSHA-1アルゴリズムを実行します。 SHA-1ハッシュ値の左端の64ビットを取得します。結果はHash1です。
6. Form an interface identifier from Hash1 by writing the value of Sec into the three leftmost bits and by setting bits 6 and 7 (i.e., the "u" and "g" bits) to zero.
6. Secの値を左端の3つのビットに書き込み、ビット6と7（つまり、「u」と「g」ビット）をゼロに設定して、Hash1からインターフェース識別子を形成します。
7. Concatenate the 64-bit subnet prefix and the 64-bit interface identifier to form a 128-bit IPv6 address with the subnet prefix to the left and interface identifier to the right, as in a standard IPv6 address [RFC3513].
7. 標準のIPv6アドレス[RFC3513]のように、64ビットのサブネットプレフィックスと64ビットのインターフェイス識別子を連結して、サブネットプレフィックスを左側に、インターフェイス識別子を右側に持つ128ビットIPv6アドレスを形成します。
8. Perform duplicate address detection if required, as per [RFC3971]. If an address collision is detected, increment the collision count by one and go back to step 5. However, after three collisions, stop and report the error.
8. [RFC3971]に従って、必要に応じて重複アドレス検出を実行します。アドレスの衝突が検出された場合は、衝突カウントを1つ増やし、ステップ5に戻ります。ただし、3回の衝突の後、停止してエラーを報告します。
9. Form the CGA Parameters data structure by concatenating from left to right the final modifier value, the subnet prefix, the final collision count value, the encoded public key, and any optional extension fields.
9. 最終的な修飾子の値、サブネットプレフィックス、最終的な衝突カウントの値、エンコードされた公開キー、およびオプションの拡張フィールドを左から右に連結して、CGAパラメータデータ構造を形成します。
The output of the address generation algorithm is a new CGA and a CGA Parameters data structure.
アドレス生成アルゴリズムの出力は、新しいCGAおよびCGAパラメータデータ構造です。
The initial value of the modifier in step 1 SHOULD be chosen randomly to make addresses generated from the same public key unlinkable, which enhances privacy (see Section 7.3). The quality of the random number generator does not affect the strength of the binding between the address and the public key. Implementations that have no strong random numbers available MAY use a non-cryptographic pseudo-random number generator initialized with the current time of day.
手順1の修飾子の初期値はランダムに選択して、同じ公開鍵から生成されたアドレスをリンク不可能にして、プライバシーを強化する必要があります（セクション7.3を参照）。乱数ジェネレーターの品質は、アドレスと公開鍵の間のバインディングの強さに影響しません。強力な乱数を利用できない実装では、現在の時刻で初期化された非暗号化の疑似乱数ジェネレータを使用する場合があります。
For Sec=0, the above algorithm is deterministic and relatively fast. Nodes that implement CGA generation MAY always use the security parameter value Sec=0. If Sec=0, steps 2 - 3 of the generation algorithm can be skipped.
Sec = 0の場合、上記のアルゴリズムは確定的で比較的高速です。 CGA生成を実装するノードは、常にセキュリティパラメータ値Sec = 0を使用する場合があります。 Sec = 0の場合、生成アルゴリズムのステップ2〜3はスキップできます。
For Sec values greater than zero, the above algorithm is not guaranteed to terminate after a certain number of iterations. The brute-force search in steps 2 - 3 takes O(2^(16*Sec)) iterations to complete. The algorithm has been intentionally designed so that the generation of CGAs with high Sec values is infeasible with current technology.
Sec値がゼロより大きい場合、上記のアルゴリズムは、特定の回数の反復後に終了することが保証されていません。ステップ2から3のブルートフォース検索では、完了するまでにO（2 ^（16 * Sec））の反復が必要です。このアルゴリズムは意図的に設計されており、現在のテクノロジーでは高いSec値を持つCGAの生成が不可能です。
Implementations MAY use optimized or otherwise modified versions of the above algorithm for CGA generation. However, the output of any modified versions MUST fulfill the following two requirements. First, the resulting CGA and CGA Parameters data structure MUST be formatted as specified in Sections 2 - 3. Second, the CGA verification procedure defined in Section 5 MUST succeed when invoked on the output of the CGA generation algorithm. Note that some optimizations involve trade-offs between privacy and the cost of address generation.
実装は、CGA生成のために、上記のアルゴリズムの最適化または変更されたバージョンを使用する場合があります。ただし、変更されたバージョンの出力は、次の2つの要件を満たす必要があります。最初に、結果のCGAおよびCGAパラメータのデータ構造は、セクション2〜3で指定されているようにフォーマットする必要があります。次に、セクション5で定義したCGA検証手順は、CGA生成アルゴリズムの出力で呼び出されたときに成功する必要があります。一部の最適化には、プライバシーとアドレス生成のコストの間のトレードオフが含まれることに注意してください。
One optimization is particularly important. If the subnet prefix of the address changes but the address owner's public key does not, the old modifier value MAY be reused. If it is reused, the algorithm SHOULD be started from step 4. This optimization avoids repeating the expensive search for an acceptable modifier value but may, in some situations, make it easier for an observer to link two addresses to each other.
1つの最適化が特に重要です。アドレスのサブネット接頭辞が変更されてもアドレス所有者の公開鍵は変更されない場合、古い修飾子の値が再利用される場合があります。再利用する場合、アルゴリズムはステップ4から開始する必要があります（SHOULD）。この最適化により、許容可能な修飾子値の高額な検索を繰り返す必要がなくなりますが、状況によっては、オブザーバーが2つのアドレスを互いにリンクしやすくなる場合があります。
Note that this document does not specify whether duplicate address detection should be performed and how the detection is done. Step 8 only defines what to do if some form of duplicate address detection is performed and an address collision is detected.
このドキュメントでは、重複アドレス検出を実行する必要があるかどうか、および検出を実行する方法を指定していないことに注意してください。ステップ8は、何らかの形式の重複アドレス検出が実行され、アドレスの衝突が検出された場合の対処方法のみを定義しています。
Future versions of this specification may specify additional inputs to the CGA generation algorithm that are concatenated as extension fields to the end of the CGA Parameters data structure. No such extension fields are defined in this document.
この仕様の将来のバージョンでは、CGAパラメータデータ構造の最後に拡張フィールドとして連結される、CGA生成アルゴリズムへの追加の入力を指定する可能性があります。このドキュメントでは、そのような拡張フィールドは定義されていません。
CGA verification takes an IPv6 address and a CGA Parameters data structure as input. The CGA Parameters consist of the concatenated modifier, subnet prefix, collision count, public key, and optional extension fields. The verification either succeeds or fails.
CGA検証は、IPv6アドレスとCGAパラメータデータ構造を入力として受け取ります。 CGAパラメータは、連結された修飾子、サブネットプレフィックス、衝突カウント、公開鍵、およびオプションの拡張フィールドで構成されます。検証は成功または失敗します。
The CGA MUST be verified with the following steps:
CGAは次の手順で確認する必要があります。
1. Check that the collision count in the CGA Parameters data structure is 0, 1, or 2. The CGA verification fails if the collision count is out of the valid range.
1. CGAパラメータデータ構造の衝突カウントが0、1、または2であることを確認してください。衝突カウントが有効範囲外の場合、CGA検証は失敗します。
2. Check that the subnet prefix in the CGA Parameters data structure is equal to the subnet prefix (i.e., the leftmost 64 bits) of the address. The CGA verification fails if the prefix values differ.
2. CGAパラメータデータ構造のサブネットプレフィックスがアドレスのサブネットプレフィックス（つまり、左端の64ビット）と等しいことを確認します。プレフィックス値が異なる場合、CGA検証は失敗します。
3. Execute the SHA-1 algorithm on the CGA Parameters data structure. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1.
3. CGAパラメータデータ構造でSHA-1アルゴリズムを実行します。 SHA-1ハッシュ値の左端の64ビットを取得します。結果はHash1です。
4. Compare Hash1 with the interface identifier (i.e., the rightmost 64 bits) of the address. Differences in the three leftmost bits and in bits 6 and 7 (i.e., the "u" and "g" bits) are ignored. If the 64-bit values differ (other than in the five ignored bits), the CGA verification fails.
4. Hash1をアドレスのインターフェース識別子（つまり、右端の64ビット）と比較します。左端の3ビットとビット6および7（つまり、「u」および「g」ビット）の違いは無視されます。 64ビット値が異なる場合（5つの無視されたビット以外）、CGA検証は失敗します。
5. Read the security parameter Sec from the three leftmost bits of the 64-bit interface identifier of the address. (Sec is an unsigned 3-bit integer.)
5. アドレスの64ビットインターフェイス識別子の左端の3ビットからセキュリティパラメータSecを読み取ります。 （Secは符号なし3ビット整数です。）
6. Concatenate from left to right the modifier, 9 zero octets, the public key, and any extension fields that follow the public key in the CGA Parameters data structure. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2.
6. 左から右に、修飾子、9つのゼロオクテット、公開キー、およびCGAパラメータデータ構造の公開キーに続く拡張フィールドを連結します。連結でSHA-1アルゴリズムを実行します。 SHA-1ハッシュ値の左端の112ビットを取得します。結果はHash2です。
7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one of them is not zero, the CGA verification fails. Otherwise, the verification succeeds. (If Sec=0, the CGA verification never fails at this step.)
7. Hash2の左端の16 * Secビットをゼロと比較します。それらのいずれかがゼロでない場合、CGA検証は失敗します。それ以外の場合、検証は成功します。 （Sec = 0の場合、このステップでCGA検証が失敗することはありません。）
If the verification fails at any step, the execution of the algorithm MUST be stopped immediately. On the other hand, if the verification succeeds, the verifier knows that the public key in the CGA Parameters is the authentic public key of the address owner. The verifier can extract the public key by removing 25 octets from the beginning of the CGA Parameters and by decoding the following SubjectPublicKeyInfo data structure.
検証がいずれかのステップで失敗した場合、アルゴリズムの実行は直ちに停止されなければなりません（MUST）。一方、検証が成功した場合、検証者はCGAパラメータの公開鍵がアドレス所有者の本物の公開鍵であることを認識します。検証者は、CGAパラメータの先頭から25オクテットを削除し、次のSubjectPublicKeyInfoデータ構造をデコードすることにより、公開鍵を抽出できます。
Note that the values of bits 6 and 7 (the "u" and "g" bits) of the interface identifier are ignored during CGA verification. In the SEND protocol, after the verification succeeds, the verifier SHOULD process all CGAs in the same way regardless of the Sec, modifier, and collision count values. In particular, the verifier in the SEND protocol SHOULD NOT have any security policy that differentiates between addresses based on the value of Sec. That way, the address generator is free to choose any value of Sec.
CGA検証中は、インターフェース識別子のビット6と7（「u」と「g」ビット）の値は無視されることに注意してください。 SENDプロトコルでは、検証が成功した後、検証者は、Sec、修飾子、および衝突カウントの値に関係なく、すべてのCGAを同じ方法で処理する必要があります（SHOULD）。特に、SENDプロトコルのベリファイアには、Secの値に基づいてアドレスを区別するセキュリティポリシーが必要です（SHOULD NOT）。このようにして、アドレスジェネレーターはSecの任意の値を自由に選択できます。
All nodes that implement CGA verification MUST be able to process all security parameter values Sec = 0, 1, 2, 3, 4, 5, 6, 7. The verification procedure is relatively fast and always requires at most two computations of the SHA-1 hash function. If Sec=0, the verification never fails in steps 6 - 7 and these steps can be skipped.
CGA検証を実装するすべてのノードは、すべてのセキュリティパラメータ値Sec = 0、1、2、3、4、5、6、7を処理できなければなりません（MUST）。検証手順は比較的高速で、常に最大で2つのSHAの計算が必要です。 1つのハッシュ関数。 Sec = 0の場合、手順6〜7で検証が失敗することはなく、これらの手順はスキップできます。
Nodes that implement CGA verification for SEND SHOULD be able to process RSA public keys that have the algorithm identifier rsaEncryption and, key length between 384 and 2,048 bits. Implementations MAY support longer keys. Future versions of this specification may recommend support for longer keys.
SENDのCGA検証を実装するノードは、アルゴリズム識別子rsaEncryption、および384〜2,048ビットのキー長を持つRSA公開キーを処理できる必要があります（SHOULD）。実装はより長いキーをサポートしてもよい（MAY）。この仕様の将来のバージョンでは、より長いキーのサポートが推奨される可能性があります。
Implementations of CGA verification MUST ignore the value of any unrecognized extension fields that follow the public key in the CGA Parameters data structure. However, implementations MUST include any such unrecognized data in the hash input when computing Hash1 in step 3 and Hash2 in step 6 of the CGA verification algorithm. This is important to ensure upward compatibility with future extensions.
CGA検証の実装では、CGAパラメータデータ構造内の公開キーに続く認識されない拡張フィールドの値を無視する必要があります。ただし、実装では、CGA検証アルゴリズムのステップ3でHash1を、ステップ6でHash2を計算するときに、そのような認識されないデータをハッシュ入力に含める必要があります。これは、将来の拡張機能との上位互換性を確保するために重要です。
This section defines the procedures for generating and verifying CGA signatures. To sign a message, a node needs the CGA, the associated CGA Parameters data structure, the message, and the private cryptographic key that corresponds to the public key in the CGA Parameters. The node also must have a 128-bit type tag for the message from the CGA Message Type name space.
このセクションでは、CGA署名を生成および検証する手順を定義します。メッセージに署名するには、ノードにはCGA、関連するCGAパラメータのデータ構造、メッセージ、およびCGAパラメータの公開鍵に対応する秘密暗号鍵が必要です。ノードには、CGAメッセージタイプ名前空間からのメッセージ用の128ビットタイプタグも必要です。
To sign a message, a node SHOULD do the following:
メッセージに署名するには、ノードは次のことを行う必要があります。
o Concatenate the 128-bit type tag (in network byte order) and the message with the type tag to the left and the message to the right. The concatenation is the message to be signed in the next step.
o 128ビットのタイプタグ（ネットワークバイトオーダー）とメッセージを連結し、タイプタグを左側に、メッセージを右側に連結します。連結は、次のステップで署名されるメッセージです。
o Generate the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447] signature algorithm with the SHA-1 hash algorithm. The private key and the concatenation created above are the inputs to the generation operation.
o RSASSA-PKCS1-v1_5 [RFC3447]署名アルゴリズムとSHA-1ハッシュアルゴリズムを使用して、RSA署名を生成します。上記で作成した秘密鍵と連結は、生成操作への入力です。
The SEND protocol specification [RFC3971] defines several messages that contain a signature in the Signature Option. The SEND protocol specification also defines a type tag from the CGA Message Type name space. The same type tag is used for all the SEND messages that have the Signature Option. This type tag is an IANA-allocated 128 bit integer that has been chosen at random to prevent an accidental type collision with messages of other protocols that use the same public key but that may or may not use IANA-allocated type tags.
SENDプロトコル仕様[RFC3971]は、Signature Optionに署名を含むいくつかのメッセージを定義しています。 SENDプロトコル仕様では、CGAメッセージタイプ名前空間のタイプタグも定義されています。同じタイプのタグが、署名オプションを持つすべてのSENDメッセージに使用されます。このタイプのタグは、IANAが割り当てた128ビット整数であり、ランダムに選択され、同じ公開キーを使用する他のプロトコルのメッセージとのタイプの偶発的な衝突を防止しますが、IANAが割り当てたタイプのタグを使用する場合と使用しない場合があります。
The CGA, the CGA Parameters data structure, the message, and the signature are sent to the verifier. The SEND protocol specification defines how these data items are sent in SEND protocol messages. Note that the 128-bit type tag is not included in the SEND protocol messages because the verifier knows its value implicitly from the ICMP message type field in the SEND message. See the SEND specification [RFC3971] for precise information about how SEND handles the type tag.
CGA、CGAパラメータのデータ構造、メッセージ、および署名がベリファイアに送信されます。 SENDプロトコル仕様は、これらのデータ項目がSENDプロトコルメッセージでどのように送信されるかを定義します。検証者はSENDメッセージのICMPメッセージタイプフィールドから暗黙的にその値を知っているため、128ビットタイプのタグはSENDプロトコルメッセージに含まれていないことに注意してください。 SENDがtypeタグを処理する方法の詳細については、SEND仕様[RFC3971]を参照してください。
To verify a signature, the verifier needs the CGA, the associated CGA Parameters data structure, the message, and the signature. The verifier also needs to have the 128-bit type tag for the message.
署名を検証するには、検証者はCGA、関連するCGAパラメータデータ構造、メッセージ、および署名を必要とします。ベリファイアには、メッセージの128ビットタイプのタグも必要です。
To verify the signature, a node SHOULD do the following:
署名を検証するには、ノードは次のことを行う必要があります。
o Verify the CGA as defined in Section 5. The inputs to the CGA verification are the CGA and the CGA Parameters data structure.
o セクション5で定義されているCGAを検証します。CGA検証への入力は、CGAおよびCGAパラメータのデータ構造です。
o Concatenate the 128-bit type tag and the message with the type tag to the left and the message to the right. The concatenation is the message whose signature is to be verified in the next step.
o 128ビットのtypeタグとメッセージを、typeタグを左に、メッセージを右に連結します。連結は、次のステップで署名が検証されるメッセージです。
o Verify the RSA signature by using the RSASSA-PKCS1-v1_5 [RFC3447] algorithm with the SHA-1 hash algorithm. The inputs to the verification operation are the public key (i.e., the RSAPublicKey structure from the SubjectPublicKeyInfo structure that is a part of the CGA Parameters data structure), the concatenation created above, and the signature.
o SHA-1ハッシュアルゴリズムでRSASSA-PKCS1-v1_5 [RFC3447]アルゴリズムを使用して、RSA署名を確認します。検証操作への入力は、公開鍵（つまり、CGAパラメータデータ構造の一部であるSubjectPublicKeyInfo構造のRSAPublicKey構造）、上で作成された連結、および署名です。
The verifier MUST accept the signature as authentic only if both the CGA verification and the signature verification succeed.
検証者は、CGA検証と署名検証の両方が成功した場合にのみ、署名を本物として受け入れる必要があります。
The purpose of CGAs is to prevent stealing and spoofing of existing IPv6 addresses. The public key of the address owner is bound cryptographically to the address. The address owner can use the corresponding private key to assert its ownership and to sign SEND messages sent from the address.
CGAの目的は、既存のIPv6アドレスの盗用およびなりすましを防ぐことです。アドレス所有者の公開鍵は、暗号でアドレスにバインドされています。アドレス所有者は、対応する秘密鍵を使用して、その所有権を表明し、アドレスから送信されたSENDメッセージに署名できます。
It is important to understand that an attacker can create a new address from an arbitrary subnet prefix and its own (or someone else's) public key because CGAs are not certified. However, the attacker cannot impersonate somebody else's address. This is because the attacker would have to find a collision of the cryptographic hash value Hash1. (The property of the hash function needed here is called second pre-image resistance [MOV97].)
CGAは認定されていないため、攻撃者は任意のサブネットプレフィックスとそれ自体（または他の誰か）の公開鍵から新しいアドレスを作成できることを理解することが重要です。ただし、攻撃者は他人のアドレスを偽装することはできません。これは、攻撃者が暗号化ハッシュ値Hash1の衝突を見つける必要があるためです。 （ここで必要なハッシュ関数の特性は、2番目のプリイメージレジスタンス[MOV97]と呼ばれます。）
For each valid CGA Parameters data structure, there are 4*(Sec+1) different CGAs that match the value. This is because decrementing the Sec value in the three leftmost bits of the interface identifier does not invalidate the address, and the verifier ignores the values of the "u" and "g" bits. In SEND, this does not have any security or implementation implications.
有効なCGAパラメータデータ構造ごとに、値に一致する4 *（Sec + 1）の異なるCGAがあります。これは、インターフェイス識別子の左端3ビットのSec値をデクリメントしてもアドレスが無効にならず、ベリファイアが「u」および「g」ビットの値を無視するためです。 SENDでは、これはセキュリティや実装に影響を与えません。
Another limitation of CGAs is that there is no mechanism for proving that an address is not a CGA. Thus, an attacker could take someone else's CGA and present it as a non-cryptographically generated address (e.g., as an RFC 3041 address [RFC3041]). An attacker does not benefit from this because although SEND nodes accept both signed and unsigned messages from every address, they give priority to the information in the signed messages.
CGAのもう1つの制限は、アドレスがCGAではないことを証明するメカニズムがないことです。したがって、攻撃者は他の誰かのCGAを取得し、それを暗号化されていないアドレスとして（たとえば、RFC 3041アドレス[RFC3041]として）提示する可能性があります。 SENDノードはすべてのアドレスからの署名付きメッセージと署名なしメッセージの両方を受け入れますが、署名付きメッセージ内の情報を優先するため、攻撃者はこれの恩恵を受けません。
The minimum RSA key length required for SEND is only 384 bits. So short keys are vulnerable to integer-factoring attacks and cannot be used for strong authentication or secrecy. On the other hand, the cost of factoring 384-bit keys is currently high enough to prevent most denial-of-service attacks. Implementations that initially use short RSA keys SHOULD be prepared to switch to longer keys when denial-of-service attacks arising from integer factoring become a problem.
SENDに必要な最小RSAキー長は384ビットのみです。そのため、短いキーは整数分解攻撃に対して脆弱であり、強力な認証や機密性には使用できません。一方、384ビットのキーを因数分解するコストは現在、ほとんどのサービス拒否攻撃を防ぐのに十分なほど高くなっています。短いRSAキーを最初に使用する実装では、整数の因数分解に起因するサービス拒否攻撃が問題になったときに、より長いキーに切り替える準備をする必要があります。
The impact of a key compromise on CGAs depends on the application for which they are used. In SEND, it is not a major concern. If the private signature key is compromised because the SEND node has itself been compromised, the attacker does not need to spoof SEND messages from the node. When it is discovered that a node has been compromised, a new signature key and a new CGA SHOULD be generated.
CGAに対する主要な妥協の影響は、CGAが使用されるアプリケーションによって異なります。 SENDでは、それは大きな問題ではありません。 SENDノード自体が侵害されたために秘密署名キーが侵害された場合、攻撃者はノードからのSENDメッセージを偽装する必要はありません。ノードが危険にさらされていることが発見された場合、新しい署名鍵と新しいCGAを生成する必要があります（SHOULD）。
On the other hand, if the RSA key is compromised because integer-factoring attacks for the chosen key length have become practical, the key has to be replaced with a longer one, as explained above. In either case, the address change effectively revokes the old public key. It is not necessary to have any additional key revocation mechanism or to limit the lifetimes of the signature keys.
一方、選択したキーの長さに対する整数因数分解攻撃が実用的になったためにRSAキーが危険にさらされた場合、上記で説明したように、キーをより長いキーに置き換える必要があります。どちらの場合でも、アドレスの変更により、古い公開鍵が事実上無効になります。追加のキー失効メカニズムを用意したり、署名キーの有効期間を制限したりする必要はありません。
As computers become faster, the 64 bits of the interface identifier will not be sufficient to prevent attackers from searching for hash collisions. It helps somewhat that we include the subnet prefix of the address in the hash input. This prevents the attacker from using a single pre-computed database to attack addresses with different subnet prefixes. The attacker needs to create a separate database for each subnet prefix. Link-local addresses are, however, left vulnerable because the same prefix is used by all IPv6 nodes.
コンピュータが高速になるにつれて、64ビットのインターフェイス識別子は、攻撃者がハッシュの衝突を検索するのを防ぐのに十分ではなくなります。ハッシュ入力にアドレスのサブネットプレフィックスを含めると、多少は役立ちます。これにより、攻撃者が単一の事前に計算されたデータベースを使用して、異なるサブネットプレフィックスを持つアドレスを攻撃するのを防ぎます。攻撃者は、サブネットプレフィックスごとに個別のデータベースを作成する必要があります。ただし、すべてのIPv6ノードで同じプレフィックスが使用されるため、リンクローカルアドレスは脆弱なままです。
To prevent the CGA technology from becoming outdated as computers become faster, the hash technique used to generate CGAs must be extended somehow. The chosen extension technique is to increase the cost of both address generation and brute-force attacks by the same parameterized factor while keeping the cost of address use and verification constant. This also provides protection for link-local addresses. Introduction of the hash extension is the main difference between this document and earlier CGA proposals [OR01][Nik01][MC02].
コンピュータの高速化に伴ってCGAテクノロジが古くなるのを防ぐには、CGAの生成に使用されるハッシュ手法を何らかの方法で拡張する必要があります。選択された拡張手法は、アドレスの使用と検証のコストを一定に保ちながら、同じパラメーター化された要因によってアドレス生成と総当たり攻撃の両方のコストを増やすことです。これにより、リンクローカルアドレスも保護されます。ハッシュ拡張の導入は、このドキュメントと以前のCGA提案[OR01] [Nik01] [MC02]との主な違いです。
To achieve the effective extension of the hash length, the input to the second hash function, Hash2, is modified (by changing the modifier value) until the leftmost 16*Sec bits of the hash value are zero. This increases the cost of address generation approximately by a factor of 2^(16*Sec). It also increases the cost of brute-force attacks by the same factor. That is, the cost of creating a CGA Parameters data structure that binds the attacker's public key with somebody else's address is increased from O(2^59) to O(2^(59+16*Sec)). The address generator may choose the security parameter Sec depending on its own computational capacity, the perceived risk of attacks, and the expected lifetime of the address. Currently, Sec values between 0 and 2 are sufficient for most IPv6 nodes. As computers become faster, higher Sec values will slowly become useful.
ハッシュ長の効果的な拡張を実現するために、2番目のハッシュ関数Hash2への入力は、ハッシュ値の左端の16 * Secビットがゼロになるまで（修飾子の値を変更することにより）変更されます。これにより、アドレス生成のコストが約2倍（16 *秒）増加します。また、ブルートフォース攻撃のコストも同じ要因で増加します。つまり、攻撃者の公開鍵を他の誰かのアドレスにバインドするCGAパラメータデータ構造を作成するコストは、O（2 ^ 59）からO（2 ^（59 + 16 * Sec））に増加します。アドレスジェネレーターは、自身の計算能力、知覚される攻撃のリスク、およびアドレスの予想される存続期間に応じて、セキュリティパラメーターSecを選択できます。現在、ほとんどのIPv6ノードでは、0〜2のSec値で十分です。コンピュータが高速になるにつれて、Secの値が高くなると、徐々に役に立ちます。
Theoretically, if no hash extension is used (i.e., Sec=0) and a typical attacker is able to tap into N local networks at the same time, an attack against link-local addresses is N times as efficient as an attack against addresses of a specific network. The effect could be countered by using a slightly higher Sec value for link- local addresses. When higher Sec values (such that 2^(16*Sec) > N) are used for all addresses, the relative advantage of attacking link-local addresses becomes insignificant.
理論的には、ハッシュ拡張が使用されておらず（Sec = 0）、一般的な攻撃者が同時にN個のローカルネットワークを利用できる場合、リンクローカルアドレスに対する攻撃は、アドレスに対する攻撃のN倍の効率です。特定のネットワーク。リンクローカルアドレスに少し高いSec値を使用することで、この影響を打ち消すことができます。より高いSec値（2 ^（16 * Sec）> Nなど）がすべてのアドレスに使用される場合、リンクローカルアドレスを攻撃することの相対的な利点は重要ではなくなります。
The effectiveness of the hash extension depends on the assumption that the computational capacities of the attacker and the address generator will grow at the same (potentially exponential) rate. This is not necessarily true if the addresses are generated on low-end mobile devices, for which the main design goals are to lower cost and decrease size, rather than increase computing power. But there is no reason for doing so. The expensive part of the address generation (steps 1 - 3 of the generation algorithm) may be delegated to a more powerful computer. Moreover, this work can be done in advance or offline, rather than in real time, when a new address is needed.
ハッシュ拡張の有効性は、攻撃者とアドレスジェネレーターの計算能力が同じ（潜在的に指数関数的）レートで増加するという仮定に依存します。これは、アドレスがローエンドのモバイルデバイスで生成される場合、必ずしも当てはまりません。ローエンドのモバイルデバイスの場合、主な設計目標は、計算能力を向上させるのではなく、コストを削減してサイズを小さくすることです。しかし、そうする理由はありません。アドレス生成の高価な部分（生成アルゴリズムのステップ1〜3）は、より強力なコンピュータに委任される場合があります。さらに、この作業は、新しいアドレスが必要になったときに、リアルタイムではなく事前またはオフラインで行うことができます。
To make it possible for mobile nodes whose subnet prefixes change frequently to use Sec values greater than zero, we have decided not to include the subnet prefix in the input of Hash2. The result is weaker than it would be if the subnet prefix were included in the input of both hashes. On the other hand, our scheme is at least as strong as using the hash extension technique without including the subnet prefix in either hash. It is also at least as strong as not using the hash extension but including the subnet prefix. This trade-off was made because mobile nodes frequently move to insecure networks, where they are at the risk of denial-of-service (DoS) attacks (for example, during the duplicate address detection procedure).
サブネットプレフィックスが頻繁に変更されるモバイルノードが0より大きいSec値を使用できるようにするために、Hash2の入力にサブネットプレフィックスを含めないことにしました。結果は、両方のハッシュの入力にサブネットプレフィックスが含まれている場合よりも弱くなります。一方、私たちのスキームは、どちらのハッシュにもサブネットプレフィックスを含めずに、ハッシュ拡張手法を使用する場合と少なくとも同じくらい強力です。また、少なくともハッシュ拡張を使用せず、サブネットプレフィックスを含めるのと同じくらい強力です。このトレードオフは、モバイルノードがサービス拒否（DoS）攻撃（重複アドレス検出手順中など）の危険にさらされている安全でないネットワークに頻繁に移動するために行われました。
In most networks, the goal of Secure Neighbor Discovery and CGA signatures is to prevent denial-of-service attacks. Therefore, it is usually sensible to start by using a low Sec value and to replace addresses with stronger ones only when denial-of-service attacks based on brute-force search become a significant problem. If CGAs were used as a part of a strong authentication or secrecy mechanism, it might be necessary to start with higher Sec values.
ほとんどのネットワークでは、Secure Neighbor DiscoveryとCGA署名の目的は、サービス拒否攻撃を防ぐことです。したがって、通常は低いSec値を使用して開始し、ブルートフォース検索に基づくサービス拒否攻撃が重大な問題となった場合にのみ、アドレスをより強力なアドレスに置き換えるのが賢明です。 CGAが強力な認証または秘密メカニズムの一部として使用された場合、より高いSec値から開始することが必要になる場合があります。
The collision count value is used to modify the input to Hash1 if there is an address collision. It is important not to allow collision count values higher than 2. First, it is extremely unlikely that three collisions would occur and the reason is certain to be either a configuration or implementation error or a denial-of-service attack. (When the SEND protocol is used, deliberate collisions caused by a DoS attacker are detected and ignored.) Second, an attacker doing a brute-force search to match a given CGA can try all different values of a collision count without repeating the brute-force search for the modifier value. Thus, if higher values are allowed for the collision count, the hash extension technique becomes less effective in preventing brute force attacks.
衝突カウント値は、アドレスの衝突がある場合にHash1への入力を変更するために使用されます。コリジョンカウント値を2より大きくしないことが重要です。最初に、3つのコリジョンが発生する可能性は非常に低く、その理由は、構成または実装のエラー、あるいはサービス拒否攻撃のいずれかです。 （SENDプロトコルを使用すると、DoS攻撃者による意図的な衝突が検出され、無視されます。）次に、攻撃者は、総当たり検索を行って特定のCGAに一致させることで、総当たりを繰り返さずに衝突カウントのすべての異なる値を試すことができます。修飾子の値を強制的に検索します。したがって、衝突カウントに高い値が許可されている場合、ハッシュ拡張手法はブルートフォース攻撃を防ぐ効果が低くなります。
CGAs can give the same level of pseudonymity as the IPv6 address privacy extensions defined in RFC 3041 [RFC3041]. An IP host can generate multiple pseudo-random CGAs by executing the CGA generation algorithm of Section 4 multiple times and by using a different random or pseudo-random initial value for the modifier every time. The host should change its address periodically as in [RFC3041]. When privacy protection is needed, the (pseudo)random number generator used in address generation SHOULD be strong enough to produce unpredictable and unlinkable values. Advice on random number generation can be found in [RFC1750].
CGAは、RFC 3041 [RFC3041]で定義されているIPv6アドレスプライバシー拡張と同じレベルの偽名を提供できます。 IPホストは、セクション4のCGA生成アルゴリズムを複数回実行し、毎回修飾子に異なるランダムまたは疑似ランダム初期値を使用することにより、複数の疑似ランダムCGAを生成できます。ホストは[RFC3041]のように定期的にアドレスを変更する必要があります。プライバシー保護が必要な場合、アドレス生成で使用される（疑似）乱数ジェネレーターは、予測不能でリンクできない値を生成するのに十分強力である必要があります（SHOULD）。乱数生成に関するアドバイスは[RFC1750]にあります。
There are two apparent limitations to this privacy protection. However, as will be explained below, neither is very serious.
このプライバシー保護には、明らかに2つの制限があります。ただし、以下で説明するように、どちらもそれほど深刻ではありません。
First, the high cost of address generation may prevent hosts that use a high Sec value from changing their address frequently. This problem is mitigated because the expensive part of the address generation may be done in advance or offline, as explained in the previous section. It should also be noted that the nodes that benefit most from high Sec values (e.g., DNS servers, routers, and data servers) usually do not require pseudonymity, and the nodes that have high privacy requirements (e.g., client PCs and mobile hosts) are unlikely targets for expensive brute-force DoS attacks and can make do with lower Sec values.
第1に、アドレス生成のコストが高いため、高いSec値を使用するホストが頻繁にアドレスを変更することを防ぐことができます。前のセクションで説明したように、アドレス生成の高価な部分を事前またはオフラインで実行できるため、この問題は軽減されます。また、高いSec値から最も恩恵を受けるノード（DNSサーバー、ルーター、データサーバーなど）は通常偽名を必要とせず、プライバシー要件の高いノード（クライアントPCやモバイルホストなど）にも注意する必要があります。高価なブルートフォースDoS攻撃のターゲットとなる可能性は低く、低いSec値で対処できます。
Second, the public key of the address owner is revealed in the signed SEND messages. This means that if the address owner wants to be pseudonymous toward the nodes in the local links that it accesses, it should generate not only a new address but also a new public key. With typical local-link technologies, however, a node's link-layer address is a unique identifier for the node. As long as the node keeps using the same link-layer address, it makes little sense to change the public key for privacy reasons.
第二に、アドレス所有者の公開鍵は、署名されたSENDメッセージで明らかにされます。これは、アドレスの所有者が、アクセスするローカルリンクのノードに対して偽名になりたい場合、新しいアドレスだけでなく新しい公開キーも生成する必要があることを意味します。ただし、一般的なローカルリンクテクノロジでは、ノードのリンク層アドレスはノードの一意の識別子です。ノードが同じリンク層アドレスを使用し続ける限り、プライバシー上の理由から公開鍵を変更しても意味がありません。
Although this document defines CGAs only for the purposes of Secure Neighbor Discovery, other protocols could be defined elsewhere that use the same addresses and public keys. This raises the possibility of related-protocol attacks in which a signed message from one protocol is replayed in another protocol. This means that other protocols (perhaps even those designed without an intimate knowledge of SEND) could endanger the security of SEND. What makes this threat even more significant is that the attacker could create a CGA from someone else's public key and then replay signed messages from a protocol that has nothing to do with CGAs or IP addresses.
このドキュメントでは、Secure Neighbor Discoveryの目的でのみCGAを定義していますが、同じアドレスと公開鍵を使用する他のプロトコルを他の場所で定義することもできます。これにより、あるプロトコルからの署名付きメッセージが別のプロトコルで再生される、関連プロトコル攻撃の可能性が高まります。これは、他のプロトコル（おそらくSENDの詳細な知識がなくても設計されたプロトコル）がSENDのセキュリティを危険にさらす可能性があることを意味します。この脅威をさらに重要なものにするのは、攻撃者が他の誰かの公開鍵からCGAを作成し、CGAまたはIPアドレスとは関係のないプロトコルから署名付きメッセージを再生できることです。
To prevent the related-protocol attacks, a type tag is prepended to every message before it is signed. The type tags are 128-bit randomly chosen values, which prevents accidental type collisions with even poorly designed protocols that do not use any type tags. Moreover, the SEND protocol includes the sender's CGA address in all signed messages. This makes it even more difficult for an attacker to take signed messages from some other context and to replay them as SEND messages.
関連するプロトコル攻撃を防ぐために、署名する前にすべてのメッセージにtypeタグを付加します。タイプタグは128ビットのランダムに選択された値であり、タイプタグを使用しない設計が不十分なプロトコルとの偶発的なタイプ衝突を防止します。さらに、SENDプロトコルは、すべての署名付きメッセージに送信者のCGAアドレスを含めます。これにより、攻撃者が署名されたメッセージを他のコンテキストから取得し、SENDメッセージとして再生することがさらに困難になります。
Finally, a strong cautionary note has to be made about using CGA signatures for purposes other than SEND. First, the other protocols MUST include a type tag and the sender address in all signed messages in the same way that SEND does. Each protocol MUST define its own type tag values as explained in Section 8. Moreover, because of the possibility of related-protocol attacks, the public key MUST be used only for signing, and it MUST NOT be used for encryption. Second, the minimum RSA key length of 384 bits may be too short for many applications and the impact of key compromise on the particular protocol must be evaluated. Third, CGA-based authorization is particularly suitable for securing neighbor discovery [RFC2461] and duplicate address detection [RFC2462] because these are network-layer signaling protocols for which IPv6 addresses are natural endpoint identifiers. In any protocol that uses other identifiers, such as DNS names, CGA signatures alone are not a sufficient security mechanism. There must also be a secure way of mapping the other identifiers to IPv6 addresses. If the goal is not to verify claims about IPv6 addresses, CGA signatures are probably not the right solution.
最後に、SEND以外の目的でCGA署名を使用する場合は、注意深い注意が必要です。まず、他のプロトコルは、SENDと同じ方法で、すべての署名付きメッセージにタイプタグと送信者アドレスを含める必要があります。セクション8で説明するように、各プロトコルは独自のタイプタグ値を定義する必要があります。さらに、関連するプロトコル攻撃の可能性があるため、公開鍵は署名にのみ使用し、暗号化には使用してはなりません。第2に、多くのアプリケーションにとって384ビットの最小RSAキー長は短すぎる可能性があり、特定のプロトコルに対するキーの侵害の影響を評価する必要があります。第3に、CGAベースの承認は、ネイバーディスカバリ[RFC2461]と重複アドレス検出[RFC2462]の保護に特に適しています。これらは、IPv6アドレスが自然なエンドポイント識別子であるネットワーク層シグナリングプロトコルであるためです。 DNS名などの他の識別子を使用するプロトコルでは、CGA署名だけでは十分なセキュリティメカニズムではありません。他の識別子をIPv6アドレスにマッピングする安全な方法も必要です。目標がIPv6アドレスに関する主張を検証することではない場合、CGA署名はおそらく適切なソリューションではありません。
This document defines a new CGA Message Type name space for use as type tags in messages that may be signed by using CGA signatures. The values in this name space are 128-bit unsigned integers. Values in this name space are allocated on a First Come First Served basis [RFC2434]. IANA assigns new 128-bit values directly without a review.
このドキュメントでは、CGA署名を使用して署名できるメッセージのタイプタグとして使用する新しいCGAメッセージタイプ名前空間を定義します。この名前空間の値は、128ビットの符号なし整数です。この名前空間の値は、先着順で割り当てられます[RFC2434]。 IANAは、レビューなしで新しい128ビット値を直接割り当てます。
The requester SHOULD generate the new values with a strong random-number generator. Continuous ranges of at most 256 values can be requested provided that the 120 most significant bits of the values have been generated with a strong random-number generator.
リクエスタは、強力な乱数ジェネレータで新しい値を生成する必要があります（SHOULD）。強力な乱数ジェネレータで値の最上位120ビットが生成されている場合、最大256値の連続範囲を要求できます。
IANA does not generate random values for the requester. IANA allocates requested values without verifying the way in which they have been generated. The name space is essentially unlimited, and any number of individual values and ranges of at most 256 values can be allocated.
IANAはリクエスタのランダムな値を生成しません。 IANAは、生成された方法を確認せずに要求された値を割り当てます。名前空間は基本的に無制限であり、最大256個の値の任意の数の個別の値と範囲を割り当てることができます。
CGA Message Type values for private use MAY be generated with a strong random-number generator without IANA allocation.
私用のCGAメッセージタイプ値は、IANA割り当てなしの強力な乱数ジェネレータで生成される場合があります。
This document does not define any new values in any name space.
このドキュメントでは、名前空間に新しい値を定義していません。
[RFC3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Sommerfeld、B.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279] Bassham、L.、Polk、W.、and R. Housley、 "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile"、RFC 3279、April 2002。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 3280、2002年4月。
[ITU.X690.2002] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
[ITU.X690.2002] International Telecommunications Union、「Information Technology-ASN.1 encoding rules：Specification of Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」、ITU-T勧告X .690、2002年7月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447] Jonsson、J。およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 2.1」、RFC 3447、2003年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[FIPS.180-1.1995] National Institute of Standards and Technology, "Secure Hash Standard", Federal Information Processing Standards Publication FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[FIPS.180-1.1995] National Institute of Standards and Technology、「Secure Hash Standard」、Federal Information Processing Standards Publication FIPS PUB 180-1 April 1995、<http://www.itl.nist.gov/fipspubs/fip180 -1.htm>。
[AAKMNR02] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P., and M. Roe, "Securing IPv6 neighbor discovery and router discovery", ACM Workshop on Wireless Security (WiSe 2002), Atlanta, GA USA , September 2002.
[AAKMNR02] Arkko、J.、Aura、T.、Kempf、J.、Mantyla、V.、Nikander、P。、およびM. Roe、「Secureing IPv6 Neighbor Discovery and Router Discovery」、ACM Workshop on Wireless Security（WiSe 2002）、米国ジョージア州アトランタ、2002年9月。
[Aura03] Aura, T., "Cryptographically Generated Addresses (CGA)", 6th Information Security Conference (ISC'03), Bristol, UK, October 2003.
[Aura03] Aura、T。、「Cryptographically Generated Addresses（CGA）」、第6回情報セキュリティ会議（ISC'03）、英国ブリストル、2003年10月。
[RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Crocker、S。、およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[MOV97] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook of Applied Cryptography", CRC Press , 1997.
[MOV97] Menezes、A.、van Oorschot、P。、およびS. Vanstone、「Handbook of Applied Cryptography」、CRC Press、1997年。
[MC02] Montenegro, G. and C. Castelluccia, "Statistically unique and cryptographically verifiable identifiers and addresses", ISOC Symposium on Network and Distributed System Security (NDSS 2002), San Diego, CA USA , February 2002.
[MC02]モンテネグロ、G。およびC. Castelluccia、「統計的に一意で暗号的に検証可能な識別子およびアドレス」、ネットワークおよび分散システムセキュリティに関するISOCシンポジウム（NDSS 2002）、米国カリフォルニア州サンディエゴ、2002年2月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6におけるステートレスアドレス自動構成のプライバシー拡張」、RFC 3041、2001年1月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[Nik01] Nikander, P., "A scaleable architecture for IPv6 address ownership", draft-nikander-addr-ownership-00 (work in progress), March 2001.
[Nik01] Nikander、P。、「IPv6アドレス所有権のためのスケーラブルなアーキテクチャ」、draft-nikander-addr-ownership-00（進行中の作業）、2001年3月。
[OR01] O'Shea, G. and M. Roe, "Child-proof authentication for MIPv6 (CAM)", ACM Computer Communications Review 31(2), April 2001.
[OR01] O'Shea、G。およびM. Roe、「MIPv6（CAM）のチャイルドプルーフ認証」、ACM Computer Communications Review 31（2）、2001年4月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S.およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
We generate a CGA with Sec=1 from the subnet prefix fe80:: and the following public key:
サブネットプレフィックスfe80 ::と次の公開鍵からSec = 1のCGAを生成します。
305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2ccf23c 5c3c3c3c3c3c3c3c3c3c3c3c3c3c
The modifier is initialized to a random value 89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a. The input to Hash2 is:
修飾子はランダムな値89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9aに初期化されます。 Hash2への入力は次のとおりです。
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a 0000 0000 0000 0000 00 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9a 0000 0000 0000 0000 00 305C 300D 0609 2a86 4886 F70D 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 F10B d973 a368 be368 be23 b023 B5 87265 87165 01b774b73a F10B d973 4b73c a368 c2f1 c2f1 3730 5454 f10b773 4b73 f10b73 d973a368 c2f1 c2f1 3730 5454 f10b3 8716 5b9773a f10b73 d973 a368 44b5。 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
The 112 first bits of the SHA-1 hash value computed from the above input are Hash2=436b 9a70 dbfd dbf1 926e 6e66 29c0. This does not begin with 16*Sec=16 zero bits. Thus, we must increment the modifier by one and recompute the hash. The new input to Hash2 is:
上記の入力から計算されたSHA-1ハッシュ値の最初の112ビットは、Hash2 = 436b 9a70 dbfd dbf1 926e 6e66 29c0です。これは、16 * Sec = 16ゼロビットでは始まりません。したがって、修飾子を1つ増やして、ハッシュを再計算する必要があります。 Hash2への新しい入力は次のとおりです。
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b 0000 0000 0000 0000 00 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b 0000 0000 0000 0000 00 305C 300D 0609 2a86 4886 F70D 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 F10B d973 a368 be368 be23 b023 B5 87265 87165 01b74 F10B d973 4b73 cf38 c2f3 c2f1 3730 5454 f10b73e d973 4b73 CF23 b023a 87165 01b7 97473a。 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
The new hash value is Hash2=0000 01ca 680b 8388 8d09 12df fcce. The 16 leftmost bits of Hash2 are all zero. Thus, we found a suitable modifier. (We were very lucky to find it so soon.)
新しいハッシュ値はHash2 = 0000 01ca 680b 8388 8d09 12df fcceです。 Hash2の左端の16ビットはすべてゼロです。したがって、適切な修飾子を見つけました。 （私たちはそれをすぐに見つけることができてとても幸運でした。）
The input to Hash1 is:
Hash1への入力は次のとおりです。
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 ce9b fe80 0000 0000 0000 00 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4b00 3048 0241 00c2 c2f1 3730 5454 f10b d9ce a368 44b5 30e9 211a 4b26 2b16 467c b7df ba1f 595c 0194 f275 be5a 4d38 6f2c 3c23 8250 8773 c786 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
89a8 a8b2 e858 d8b8 f263 3f44 d2d4 305C 300D 0609 2a86 4886 F70D 0101 0105 0003 3048 0241 4b00 00c2 c2f1 3730 5454 F10B d973 a368 be368 be23 b023 2778 87b2 87165 01b774b73a F10B d973a368 be365 B23 B 0000 0000 0000 00 FE80 ce9b 7f9b 3b9e 63a0 9c7b c48f 7a54 ebef af02 0301 0001
The 64 first bits of the SHA-1 hash value of the above input are Hash1=fd4a 5bf6 ffb4 ca6c. We form an interface identifier from this by writing Sec=1 into the three leftmost bits and by setting bits 6 and 7 (the "u" and "g" bits) to zero. The new interface identifier is 3c4a:5bf6:ffb4:ca6c.
上記の入力のSHA-1ハッシュ値の最初の64ビットは、Hash1 = fd4a 5bf6 ffb4 ca6cです。左端の3つのビットにSec = 1を書き込み、ビット6と7（「u」と「g」ビット）をゼロに設定することにより、これからインターフェース識別子を形成します。新しいインターフェイス識別子は3c4a：5bf6：ffb4：ca6cです。
Finally, we form the IPv6 address fe80::3c4a:5bf6:ffb4:ca6c. This is the new CGA. No address collisions were detected this time. (Collisions are very rare.) The CGA Parameters data structure associated with the address is the same as the input to Hash1 above.
最後に、IPv6アドレスfe80 :: 3c4a：5bf6：ffb4：ca6cを作成します。これは新しいCGAです。今回はアドレスの衝突は検出されませんでした。 （衝突は非常にまれです。）アドレスに関連付けられたCGAパラメーターのデータ構造は、上記のHash1への入力と同じです。
The author gratefully acknowledges the contributions of Jari Arkko, Francis Dupont, Pasi Eronen, Christian Huitema, James Kempf, Pekka Nikander, Michael Roe, Dave Thaler, and other participants of the SEND working group.
著者は、Jari Arkko、Francis Dupont、Pasi Eronen、Christian Huitema、James Kempf、Pekka Nikander、Michael Roe、Dave Thaler、およびSENDワーキンググループの他の参加者の貢献に感謝します。
Author's Address
著者のアドレス
Tuomas Aura Microsoft Research Roger Needham Building 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom
Tuomas Auraマイクロソフトリサーチロジャーニーダムビルディング7 JJトムソンアベニューケンブリッジCB3 0FBイギリス
Phone: +44 1223 479708
EMail: tuomaura@microsoft.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（2005）。
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 currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。