[要約] RFC 4982は、Cryptographically Generated Addresses（CGAs）で複数のハッシュアルゴリズムをサポートするための仕様です。目的は、CGAsのセキュリティと柔軟性を向上させることです。
Network Working Group M. Bagnulo
Request for Comments: 4982 UC3M
Updates: 3972 J. Arkko
Category: Standards Track Ericsson
July 2007
Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)
暗号で生成されたアドレス（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 IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
Abstract
概要
This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms.
このドキュメントでは、暗号生成アドレス（CGA）で一般的に使用されるハッシュ関数に対する最近の攻撃の影響を分析し、複数のハッシュアルゴリズムをサポートするようにCGA仕様を更新します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Impact of Collision Attacks in CGAs . . . . . . . . . . . . . . 2
4. Options for Multiple Hash Algorithm Support in CGAs . . . . . . 3
4.1. Where to Encode the Hash Function? . . . . . . . . . . . . 4
5. CGA Generation Procedure . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Recent attacks to currently used hash functions have motivated a considerable amount of concern in the Internet community. The recommended approach [6] [10] to deal with this issue is first to analyze the impact of these attacks on the different Internet protocols that use hash functions and second to make sure that the different Internet protocols that use hash functions are capable of migrating to an alternative (more secure) hash function without a major disruption in the Internet operation.
現在使用されているハッシュ関数に対する最近の攻撃は、インターネットコミュニティでかなりの懸念を引き起こしています。この問題に対処するための推奨アプローチ[6] [10]は、最初にハッシュ関数を使用するさまざまなインターネットプロトコルに対するこれらの攻撃の影響を分析し、次にハッシュ関数を使用するさまざまなインターネットプロトコルが移行できることを確認することですインターネットの操作を大幅に中断することなく、代替（より安全な）ハッシュ関数に変換します。
This document performs such analysis for the Cryptographically Generated Addresses (CGAs) defined in [2]. The first conclusion of the analysis is that the security of the protocols using CGAs is not affected by the recently available attacks against hash functions. The second conclusion of the analysis is that the hash function used is hard coded in the CGA specification. This document updates the CGA specification [2] to enable the support of alternative hash functions. In order to do so, this document creates a new registry managed by IANA to register the different hash algorithms used in CGAs.
このドキュメントは、[2]で定義された暗号化生成アドレス（CGA）に対してこのような分析を実行します。分析の最初の結論は、CGAを使用するプロトコルのセキュリティは、ハッシュ関数に対する最近利用可能な攻撃の影響を受けないということです。分析の2番目の結論は、使用されるハッシュ関数がCGA仕様でハードコーディングされていることです。このドキュメントは、CGA仕様[2]を更新して、代替ハッシュ関数のサポートを有効にします。そのために、このドキュメントでは、IANAによって管理される新しいレジストリを作成して、CGAで使用されるさまざまなハッシュアルゴリズムを登録します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [1]で説明されているように解釈されます。
Recent advances in cryptography have resulted in simplified attacks against the collision-free property of certain commonly used hash functions [6] [10], including SHA-1 that is the hash function used by CGAs [2]. The result is that it is possible to obtain two messages, M1 and M2, that have the same hash value with much less than 2^(L/2) attempts. We will next analyze the impact of such attacks in the currently proposed usages of CGAs.
暗号化の最近の進歩により、CGAが使用するハッシュ関数であるSHA-1 [2]を含む、一般的に使用される特定のハッシュ関数[6] [10]の衝突のない特性に対する攻撃が単純化されました。その結果、同じハッシュ値を持つ2つのメッセージM1とM2を取得でき、試行回数は2 ^（L / 2）よりはるかに少なくなります。次に、現在提案されているCGAの使用法におけるこのような攻撃の影響を分析します。
As we understand it, the attacks against the collision-free property of a hash function mostly challenge the application of such hash functions, for the provision of non-repudiation capabilities. This is because an attacker would be capable to create two different messages that result in the same hash value and it can then present any of the messages interchangeably (for example after one of them has been signed by the other party involved in the transaction). However, it must be noted that both messages must be generated by the same party.
私たちが理解しているように、ハッシュ関数の衝突のないプロパティに対する攻撃は、ほとんどの場合、そのようなハッシュ関数のアプリケーションに挑戦し、否認防止機能を提供します。これは、攻撃者が2つの異なるメッセージを作成して同じハッシュ値を生成する可能性があり、任意のメッセージを交換可能に提示できるためです（たとえば、トランザクションに関与する他のパーティによってメッセージの1つが署名された後など）。ただし、両方のメッセージが同じ当事者によって生成される必要があることに注意する必要があります。
As far as we understand, current usages of CGAs does not include the provision of non-repudiation capabilities, so attacks against the collision-free property of the hash function do not enable any useful attack against CGA-based protocols.
私たちが理解している限り、CGAの現在の使用には否認防止機能のプロビジョニングが含まれていないため、ハッシュ関数の衝突のないプロパティに対する攻撃は、CGAベースのプロトコルに対する有用な攻撃を有効にしません。
Current usages of the CGAs are basically oriented to prove the ownership of a CGA and then bind it to alternative addresses that can be used to reach the original CGA. This type of application of the CGA include:
CGAの現在の使用法は、基本的にCGAの所有権を証明し、それを元のCGAに到達するために使用できる代替アドレスにバインドすることを目的としています。 CGAのこのタイプのアプリケーションは次のとおりです。
o The application of CGAs to protect the shim6 protocol [7]. In this case, CGAs are used as identifiers for the established communications. CGA features are used to prove that the owner of the identifier is the one that is providing the alternative addresses that can be used to reach the initial identifier. This is achieved by signing the list of alternative addresses available in the multihomed host with the private key of the CGA.
o shim6プロトコルを保護するためのCGAの適用[7]。この場合、CGAは確立された通信の識別子として使用されます。 CGA機能は、識別子の所有者が、初期識別子に到達するために使用できる代替アドレスを提供していることを証明するために使用されます。これは、マルチホームホストで使用可能な代替アドレスのリストにCGAの秘密鍵で署名することによって実現されます。
o The application of CGAs to secure the IPv6 mobility support protocol [8] as proposed in [9]. In this case, the CGAs are used as Home Addresses and they are used to prove that the owner of the Home Address is the one creating the binding with the new Care-off Address. Similarly to the previous case, this is achieved by signing the Binding Update message carrying the Care-off Address with the private key of the CGA.
o [9]で提案されているIPv6モビリティサポートプロトコル[8]を保護するためのCGAの適用。この場合、CGAはホームアドレスとして使用され、ホームアドレスの所有者が新しい気付けアドレスとのバインディングを作成した所有者であることを証明するために使用されます。前のケースと同様に、これは、CGAの秘密鍵で気付アドレスを運ぶバインディング更新メッセージに署名することによって達成されます。
o The application of CGA to Secure Neighbour Discovery [4]. In this case, the CGA features are used to prove the address ownership, so that it is possible to verify that the owner of the IP address is the one that is providing the layer 2 address information. This is achieved by signing the layer 2 address information with the private key of the CGA.
o 安全な近隣探索へのCGAの適用[4]。この場合、CGA機能を使用してアドレスの所有権が証明されるため、IPアドレスの所有者がレイヤー2アドレス情報を提供している所有者であることを確認できます。これは、CGAの秘密鍵を使用してレイヤー2アドレス情報に署名することで実現されます。
Essentially, all the current applications of CGAs rely on CGAs to protect a communication between two peers from third party attacks and not to provide protection from the peer itself. Attacks against the collision-free property of the hash functions suppose that one of the parties is generating two messages with the same hash value in order to launch an attack against its communicating peer. Since CGAs are not currently used to providing this type of protection, it is then natural that no additional attacks are enabled by a weaker collision resistance of the hash function.
基本的に、CGAの現在のすべてのアプリケーションは、CGAに依存して、2つのピア間の通信をサードパーティの攻撃から保護し、ピア自体からの保護を提供していません。ハッシュ関数の衝突のないプロパティに対する攻撃は、通信相手への攻撃を開始するために、一方の当事者が同じハッシュ値を持つ2つのメッセージを生成していると想定しています。 CGAは現在このタイプの保護を提供するために使用されていないため、ハッシュ関数の衝突抵抗が弱いために追加の攻撃が有効にならないのは当然です。
CGAs, as currently defined in [2], are intrinsically bound to the SHA-1 hash algorithm and no other hash function is supported.
現在[2]で定義されているCGAは、本質的にSHA-1ハッシュアルゴリズムにバインドされており、他のハッシュ関数はサポートされていません。
Even though the attacks against the collision-free property of the hash functions do not result in new vulnerabilities in the current applications of CGAs, it seems wise to enable multiple hash function support in CGAs. This is mainly for two reasons: first, potential future applications of the CGA technology may be susceptible to attacks against the collision-free property of SHA-1. Supporting alternative hash functions would allow applications that have stricter requirements on the collision-free property to use CGAs. Second, one lesson learned from the recent attacks against hash functions is that it is possible that one day we need to start using alternative hash functions because of successful attacks against other properties of the commonly used hash functions. Therefore, it seems wise to modify protocols in general and the CGAs in particular to support this transition to alternative hash functions as easy as possible.
ハッシュ関数の衝突のないプロパティに対する攻撃の結果、CGAの現在のアプリケーションに新しい脆弱性は生じませんが、CGAで複数のハッシュ関数のサポートを有効にすることは賢明なようです。これには主に2つの理由があります。1つ目は、CGAテクノロジーの将来の潜在的なアプリケーションは、SHA-1の衝突のない特性に対する攻撃を受けやすい可能性があることです。代替ハッシュ関数をサポートすることで、衝突のないプロパティに対してより厳しい要件を持つアプリケーションがCGAを使用できるようになります。第2に、最近のハッシュ関数に対する攻撃から学んだ教訓の1つは、一般的に使用されるハッシュ関数の他のプロパティに対する攻撃が成功したため、ある日、代替ハッシュ関数の使用を開始する必要がある可能性があるということです。したがって、一般的なプロトコル、特にCGAを変更して、代替ハッシュ関数へのこの移行をできるだけ簡単にサポートすることは賢明なようです。
The next question we need to answer is where to encode the hash function that is being used. There are several options that can be considered:
次に答える必要がある質問は、使用されているハッシュ関数をどこにエンコードするかです。考慮できるいくつかのオプションがあります。
One option would be to include the hash function used as an input to the hash function. This basically means to create an extension to the CGA Parameter Data Structure, as defined in [3], that codifies the hash function used. The problem is that this approach is vulnerable to bidding down attacks or downgrading attacks as defined in [10]. This means that even if a strong hash function is used, an attacker could find a CGA Parameter Data Structure that uses a weaker function but results in an equal hash value. This happens when the original hash function H1 and CGA Parameters Data Structure indicating H1 result in value X, and another hash function H2 and CGA Parameters Data Structure indicating H2 also result in the same value X.
1つのオプションは、ハッシュ関数への入力として使用されるハッシュ関数を含めることです。これは基本的に、[3]で定義されているように、使用するハッシュ関数をコード化するCGAパラメータデータ構造の拡張を作成することを意味します。問題は、このアプローチが[10]で定義されているように、ビッドダウン攻撃またはダウングレード攻撃に対して脆弱であることです。これは、強力なハッシュ関数が使用されている場合でも、攻撃者はより弱い関数を使用するCGAパラメータデータ構造を見つける可能性がありますが、ハッシュ値は同じであることを意味します。これは、H1を示す元のハッシュ関数H1およびCGAパラメータデータ構造が値Xになり、H2を示す別のハッシュ関数H2およびCGAパラメータデータ構造も同じ値Xになる場合に発生します。
In other words, the downgrading attack would work as follows: suppose that Alice generates a CGA CGA_A using the strong hash function HashStrong and using a CGA Parameter Data Structure CGA_PDS_A. The selected hash function HashStrong is encoded as an extension field in the CGA_PDS_A. Suppose that by using a brute force attack, an attacker X finds an alternative CGA Parameter Data Structure CGA_PDS_X whose hash value, by using a weaker hash function, is CGA_A. At this point, the attacker can pretend to be the owner of CGA_A and the stronger hash function has not provided additional protection.
つまり、ダウングレード攻撃は次のように機能します。アリスが強力なハッシュ関数HashStrongとCGAパラメータデータ構造CGA_PDS_Aを使用してCGA CGA_Aを生成するとします。選択したハッシュ関数HashStrongは、CGA_PDS_Aの拡張フィールドとしてエンコードされます。総当たり攻撃を使用することにより、攻撃者Xが代替のCGAパラメータデータ構造CGA_PDS_Xを見つけ、そのハッシュ値がより弱いハッシュ関数を使用してCGA_Aであるとします。この時点で、攻撃者はCGA_Aの所有者を装うことができ、より強力なハッシュ関数は追加の保護を提供していません。
The conclusion from the previous analysis is that the hash function used in the CGA generation must be encoded in the address itself.
以前の分析からの結論は、CGA生成で使用されるハッシュ関数はアドレス自体にエンコードする必要があるということです。
Since we want to support several hash functions, we will likely need at least 2 or 3 bits for this.
いくつかのハッシュ関数をサポートする必要があるため、これには少なくとも2ビットまたは3ビットが必要になる可能性があります。
One option would be to use more bits from the hash bits of the interface identifier. However, the problem with this approach is that the resulting CGA is weaker because less hash information is encoded in the address. In addition, since those bits are currently used as hash bits, it is impossible to make this approach backward compatible with existent implementations.
1つのオプションは、インターフェイス識別子のハッシュビットからより多くのビットを使用することです。ただし、この方法の問題は、アドレスにエンコードされるハッシュ情報が少なくなるため、結果のCGAが弱くなることです。さらに、これらのビットは現在ハッシュビットとして使用されているため、このアプローチを既存の実装と下位互換にすることはできません。
Another option would be to use the "u" and the "g" bits to encode this information, but this is probably not such a good idea since those bits have been honoured so far in all interface identifier generation mechanisms, which allow them to be used for the original purpose (for instance we can still create a global registry for unique interface identifiers). Finally, another option is to encode the hash value used in the Sec bits. The Sec bits are used to artificially introduce additional difficulty in the CGA generation process in order to provide additional protection against brute force attacks. The Sec bits have been designed in a way that the lifetime of CGAs are extended, when it is feasible to attack 59-bits long hash values. However, this is not the case today, so in general CGA will have a Sec value of 000. The proposal is to encode in the Sec bits, not only information about brute force attack protection but also to encode the hash function used to generate the hash. So for instance, the Sec value 000 would mean that the hash function used is SHA-1 and the 0 bits of hash2 (as defined in RFC 3972) must be 0. Sec value of 001 could be that the hash function used is SHA-1 and the 16 bits of hash2 (as defined in RFC 3972) must be zero. However, the other values of Sec could mean that an alternative hash function needs to be used and that a certain amount of bits of hash2 must be zero. The proposal is not to define any concrete hash function to be used for other Sec values, since it is not yet clear that we need to do so nor is it clear which hash function should be selected.
別のオプションは、「u」および「g」ビットを使用してこの情報をエンコードすることですが、これらのビットはすべてのインターフェイス識別子生成メカニズムでこれまで尊重されてきたため、これはおそらく良いアイデアではありません。元の目的で使用されます（たとえば、一意のインターフェイス識別子のグローバルレジストリを作成できます）。最後に、別のオプションは、Secビットで使用されるハッシュ値をエンコードすることです。 Secビットは、ブルートフォース攻撃に対する追加の保護を提供するために、CGA生成プロセスに人工的に追加の困難を導入するために使用されます。 Secビットは、59ビットの長いハッシュ値を攻撃することが可能である場合に、CGAの寿命が延びるように設計されています。ただし、これは今日のケースではないため、一般的にCGAのSec値は000になります。提案は、ブルートフォース攻撃保護に関する情報だけでなく、ハッシュ。たとえば、Sec値000は、使用されるハッシュ関数がSHA-1であり、hash2（RFC 3972で定義）の0ビットが0でなければならないことを意味します。Sec値001は、使用されるハッシュ関数がSHA- 1およびhash2の16ビット（RFC 3972で定義）はゼロでなければなりません。ただし、Secの他の値は、代替ハッシュ関数を使用する必要があり、hash2のビットの特定の量をゼロにする必要があることを意味する場合があります。他のSec値に使用する具体的なハッシュ関数を定義することは提案されていません。定義する必要があることや、どのハッシュ関数を選択する必要があるかがまだ明確ではないためです。
Note that since there are only 8 Sec values, it may be necessary to reuse Sec values when we run out of unused Sec values. The scenario where such an approach makes sense is where there are some Sec values that are no longer being used because the resulting security has become weak. In this case, where the usage of the Sec value has long been abandoned, it would be possible to reassign the Sec values. However, this must be a last resource option, since it may affect interoperability. This is because two implementations using different meanings of a given Sec value would not be able to interoperate properly (i.e., if an old implementation receives a CGA generated with the new meaning of the Sec value, it will fail and the same for a new implementation receiving a CGA generated with the old meaning of the Sec value). In case the approach of reassigning a Sec value is followed, a long time is required between the deprecation of the old value and the reassignment in order to prevent misinterpretation of the value by old implementations.
Sec値は8つしかないため、未使用のSec値がなくなると、Sec値を再利用する必要がある場合があります。このようなアプローチが理にかなっているシナリオは、結果のセキュリティが弱くなったために使用されなくなったSec値がある場合です。この場合、Sec値の使用がずっと放棄されているため、Sec値を再割り当てすることができます。ただし、相互運用性に影響する可能性があるため、これは最後のリソースオプションである必要があります。これは、特定のSec値の異なる意味を使用する2つの実装が適切に相互運用できないためです（つまり、古い実装がSec値の新しい意味で生成されたCGAを受信すると、失敗し、新しい実装でも同じになります。 Sec値の古い意味で生成されたCGAを受け取ります）。 Sec値を再割り当てするアプローチに従う場合、古い実装による値の誤った解釈を防ぐために、古い値の非推奨と再割り当ての間には長い時間が必要です。
An erroneous interpretation of a reused Sec value, both on the CGA owner's side and the CGA verifier's side, would have the following result, CGA verification would fail in the worst case and both nodes would have to revert to unprotected IPv6 addresses. This can happen only with obsolete CGA parameter sets, which would be considered insecure anyway. In any case, an implementation must not simultaneously support two different meanings of a Sec value.
CGA所有者側とCGA検証者側の両方で再利用されたSec値を誤って解釈すると、次のような結果になります。最悪の場合、CGA検証が失敗し、両方のノードが保護されていないIPv6アドレスに戻る必要があります。これは、いずれにしても安全でないと見なされる、廃止されたCGAパラメータセットでのみ発生する可能性があります。いずれの場合も、実装は、Sec値の2つの異なる意味を同時にサポートしてはなりません。
The SEC registry defined in the IANA considerations section of this document contains entries for the different Sec values. Each of these entries points to an RFC that defines the CGA generation procedure that MUST be used when generating CGAs with the associated Sec value.
このドキュメントのIANAの考慮事項セクションで定義されているSECレジストリには、さまざまなSec値のエントリが含まれています。これらの各エントリは、関連するSec値を持つCGAを生成するときに使用する必要があるCGA生成手順を定義するRFCを指します。
It should be noted that the CGA generation procedure may be changed by the new procedure not only in terms of the hash function used but also in other aspects, e.g., longer Modifier values may be required if the number of 0s required in hash2 exceed the currently defined bound of 112 bits. The new procedure (which potentially involves a longer Modifier value) would be described in the RFC pointed to by the corresponding Sec registry entry.
CGA生成手順は、使用されるハッシュ関数に関してだけでなく、他の側面でも新しい手順によって変更される場合があることに注意してください。たとえば、hash2で必要な0の数が現在の112ビットの定義済み境界。新しい手順（より長いModifier値が含まれる可能性があります）は、対応するSecレジストリエントリが指すRFCに記述されています。
In addition, the RFC that defines the CGA generation procedure for a Sec value MUST explicitly define the minimum key length acceptable for CGAs with that Sec value. This is to provide a coherent protection both in the hash and the public key techniques.
さらに、Sec値のCGA生成手順を定義するRFCは、そのSec値を持つCGAに受け入れられる最小のキー長を明示的に定義する必要があります。これは、ハッシュ技術と公開鍵技術の両方で一貫した保護を提供するためです。
This document defines a new registry entitled "CGA SEC" for the Sec field defined in RFC 3972 [2] that has been created and is maintained by IANA. The values in this name space are 3-bit unsigned integers.
このドキュメントでは、RFC 3972 [2]で定義されているSecフィールドに「CGA SEC」というタイトルの新しいレジストリを定義し、IANAによって作成および保守されています。この名前空間の値は、3ビットの符号なし整数です。
Initial values for the CGA Extension Type field are given below; future assignments are to be made through Standards Action [5]. Assignments consist of a name, the value, and the RFC number where the CGA generation procedure is defined.
CGA拡張タイプフィールドの初期値を以下に示します。今後の割り当ては、標準アクション[5]を通じて行われます。割り当ては、名前、値、およびCGA生成手順が定義されているRFC番号で構成されています。
The following initial values are assigned in this document:
このドキュメントでは、次の初期値が割り当てられています。
Name | Value | RFCs
-------------------+-------+------------
SHA-1_0hash2bits | 000 | 3972, 4982
SHA-1_16hash2bits | 001 | 3972, 4982
SHA-1_32hash2bits | 010 | 3972, 4982
This document is about security issues and, in particular, about protection against potential attacks against hash functions.
このドキュメントは、セキュリティの問題、特にハッシュ関数に対する潜在的な攻撃からの保護に関するものです。
Russ Housley, James Kempf, Christian Vogt, Pekka Nikander, and Henrik Levkowetz reviewed and provided comments about this document.
Russ Housley、James Kempf、Christian Vogt、Pekka Nikander、およびHenrik Levkowetzは、このドキュメントについてレビューし、コメントを提供しました。
Marcelo Bagnulo worked on this document while visiting Ericsson Research Laboratory Nomadiclab.
Marcelo Bagnuloは、Ericsson Research Laboratory Nomadiclabを訪れている間にこの文書に取り組みました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[2] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年3月。
[3] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.
[3] Bagnulo、M。およびJ. Arkko、「Cryptographically Generated Addresses（CGA）Extension Field Format」、RFC 4581、2006年10月。
[4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[4] Arkko、J.、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[6] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[6] Hoffman、P.およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
[7] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", Work in Progress, July 2005.
[7] Nordmark、E.およびM. Bagnulo、「マルチホーミングL3シムアプローチ」、進行中の作業、2005年7月。
[8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[8] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 3775、2004年6月。
[9] Arkko, J., "Applying Cryptographically Generated Addresses and Credit-Based Authorization to Mobile IPv6", Work in Progress, June 2006.
[9] Arkko、J.、「モバイルIPv6への暗号で生成されたアドレスとクレジットベースの承認の適用」、2006年6月、進行中。
[10] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", NDSS '06, February 2006.
[10] Bellovin、S.およびE. Rescorla、「Deploying a New Hash Algorithm」、NDSS '06、2006年2月。
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 IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
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から提供されています。