Network Working Group T. Aura
Request for Comments: 3972 Microsoft Research
Category: Standards Track March 2005
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).
版权所有（C）互联网协会（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.
本文档描述了在安全邻居发现（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
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].
本文档指定了一种将加密公钥与安全邻居发现（SEND）协议[RFC3971]中的IPv6地址安全关联的方法。基本思想是通过计算公钥的加密散列来生成IPv6地址的接口标识符（即，最右边的64位）。生成的IPv6地址称为加密生成地址（CGA）。然后，可以使用相应的私钥对从该地址发送的消息进行签名。有关CGA及其发送应用程序的介绍，请参见[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.
第2节和第3节定义了地址格式和CGA参数格式。第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.
当谈到地址时，本文档指的是IPv6地址，其中128位地址中最左边的64位构成子网前缀，最右边的64位构成接口标识符[RFC3513]。我们从左边的零位开始对接口标识符的位进行编号。
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），该参数决定其抵御暴力攻击的强度。安全参数是一个三位无符号整数，它编码在接口标识符最左边的三位（即0-2位）中。这可以写如下：
Sec = (interface identifier & 0xe000000000000000) >> 61
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与一组由公钥和辅助参数组成的参数相关联。根据参数计算两个哈希值Hash1（64位）和Hash2（112位）。公钥和辅助参数的格式以及散列值的计算方法在第3节中定义。
A cryptographically generated address is defined as an IPv6 address that satisfies the following two conditions:
加密生成的地址定义为满足以下两个条件的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 第二个哈希值Hash2的16*秒最左端位为零。
The above definition can be stated in terms of the following two bit masks:
上述定义可以用以下两位掩码表示：
Mask1 (64 bits) = 0x1cffffffffffffff
Mask1（64位）=0x1CFFFFFFFFFFFF
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位）=0x0000000000000000000000如果秒=0，0xFFFF000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
A cryptographically generated address is an IPv6 address for which the following two equations hold:
加密生成的地址是IPv6地址，以下两个等式适用：
Hash1 & Mask1 == interface identifier & Mask1
Hash2 & Mask2 == 0x0000000000000000000000000000
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) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
这是一个8位无符号整数，必须为0、1或2。在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.
这是一个可变长度字段，包含地址所有者的公钥。公钥必须格式化为DER编码的[ITU.X690.2002]ASN.1结构，其类型为SubjectPublicKeyInfo，在Internet X.509证书配置文件[RFC3280]中定义。SEND应使用RSA公钥/私钥对。使用RSA时，算法标识符必须是RSAConyption，即1.2.840.113549.1.1.1，并且必须使用RFC 3279[RFC3279]第2.3.1节中规定的RSACublicKey类型格式化RSA公钥。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.
这两个散列值必须按如下方式计算。对CGA参数应用SHA-1哈希算法[FIPS.180-1.1995]。当计算Hash1时，SHA-1算法的输入是CGA参数数据结构。64位哈希1是通过获取160位SHA-1哈希值中最左边的64位获得的。计算Hash2时，输入与CGA参数数据结构相同，只是子网前缀和冲突计数设置为零。通过获取160位SHA-1散列值中最左边的112位来获得112位散列2。请注意，哈希值是在整个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位子网前缀、地址所有者的公钥作为DER编码的ASN.1结构（SubjectPublicKeyInfo类型）和安全参数Sec（无符号三位整数）。生成新CGA的成本以指数形式取决于安全参数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. 将哈希2最左边的16*秒位与零进行比较。如果它们都为零（或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的值写入最左边的三个位，并将位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. 连接64位子网前缀和64位接口标识符，形成一个128位IPv6地址，子网前缀在左侧，接口标识符在右侧，如标准IPv6地址[RFC3513]。
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。但是，在三次碰撞后，停止并报告错误。
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
应随机选择步骤1中修饰符的初始值，以使同一公钥生成的地址不可链接，从而增强隐私性（参见第7.3节）。随机数生成器的质量不会影响两者之间的绑定强度
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.
地址和公钥。没有强随机数可用的实现可以使用用当前时间初始化的非加密伪随机数生成器。
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。但是，任何修改版本的输出必须满足以下两个要求。首先，生成的CGA和CGA参数数据结构必须按照第2-3节的规定进行格式化。第二，当在CGA生成算法的输出上调用时，第5节中定义的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.
其中一个优化尤为重要。如果地址的子网前缀更改，但地址所有者的公钥没有更改，则可以重新使用旧的修饰符值。如果重复使用，则应从步骤4开始执行算法。这种优化避免了重复昂贵的搜索可接受的修饰符值，但在某些情况下，可能会使观察者更容易将两个地址相互链接。
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位）进行比较。忽略最左边的三个位以及位6和7（即“u”和“g”位）中的差异。如果64位值不同（五个忽略位除外），则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位接口标识符最左边的三位读取安全参数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. 在CGA参数数据结构中，从左到右连接修饰符、9个零八位字节、公钥和公钥后面的任何扩展字段。在连接上执行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. 将哈希2最左边的16*秒位与零进行比较。如果其中任何一个不为零，则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
如果验证在任何步骤失败，必须立即停止算法的执行。另一方面，如果验证成功，则验证方知道CGA参数中的公钥是地址所有者的真实公钥。这个
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.
验证器可以通过从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位）的值被忽略。在发送协议中，验证成功后，验证器应以相同的方式处理所有CGA，而不考虑秒、修饰符和冲突计数值。特别是，发送协议中的验证器不应具有任何基于Sec值区分地址的安全策略。这样，地址生成器就可以自由选择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。验证过程相对较快，通常最多需要两次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验证的节点应该能够处理算法标识符为RSA加密的RSA公钥，密钥长度在384到2048位之间。实现可能支持更长的键。本规范的未来版本可能建议支持更长的密钥。
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.
发送协议规范[RFC3971]定义了几个在签名选项中包含签名的消息。发送协议规范还定义了CGA消息类型名称空间中的类型标记。同一类型标记用于所有具有签名选项的发送消息。此类型标记是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参数数据结构、消息和签名发送给验证器。发送协议规范定义了如何在发送协议消息中发送这些数据项。请注意，128位类型标记不包括在发送协议消息中，因为验证器从发送消息中的ICMP消息类型字段隐式知道其值。有关SEND如何处理类型标记的确切信息，请参阅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位类型标记和消息与左侧的类型标记和右侧的消息连接起来。串联是下一步要验证其签名的消息。
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 使用RSASSA-PKCS1-v1_5[RFC3447]算法和SHA-1哈希算法验证RSA签名。验证操作的输入是公钥（即，作为CGA参数数据结构一部分的SubjectPublicKeyInfo结构中的RSPublicKey结构）、上面创建的连接和签名。
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地址的窃取和欺骗。地址所有者的公钥以加密方式绑定到地址。地址所有者可以使用相应的私钥来声明其所有权，并对从该地址发送的消息进行签名和发送。
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的冲突。（此处所需的散列函数的属性称为第二预映像电阻[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*（秒+1）个不同的CGA与该值匹配。这是因为减少接口标识符最左边三位中的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的另一个限制是没有任何机制来证明地址不是CGA。因此，攻击者可以获取其他人的CGA并将其显示为非加密生成的地址（例如，RFC 3041地址[RFC3041]）。攻击者无法从中获益，因为尽管发送节点接受来自每个地址的已签名和未签名消息，但它们会优先处理已签名消息中的信息。
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.
发送所需的最小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的影响取决于使用它们的应用程序。在SEND中，这不是一个主要问题。如果私有签名密钥因发送节点本身已受损而受损，则攻击者无需欺骗该节点发送的消息。当发现某个节点已被破坏时，应生成新的签名密钥和新的CGA。
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.
为了实现哈希长度的有效扩展，对第二个哈希函数Hash2的输入进行修改（通过更改修饰符值），直到哈希值的最左边16*秒位为零。这将使地址生成的成本增加约2^（16*秒）。同样，它也会增加暴力攻击的成本。也就是说，创建将攻击者的公钥与其他人的地址绑定的CGA参数数据结构的成本从O（2^59）增加到O（2^（59+16*秒））。地址生成器可以根据其自身的计算能力、感知到的攻击风险和地址的预期寿命来选择安全参数Sec。目前，对于大多数IPv6节点，0到2之间的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-
理论上，如果未使用散列扩展（即Sec=0），并且典型的攻击者能够同时攻击N个本地网络，则针对链路本地地址的攻击的效率是针对特定网络地址的攻击的N倍。这种影响可以通过对链接使用稍高的Sec值来抵消-
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.
本地地址。当对所有地址使用更高的秒值（例如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).
为了使子网前缀经常更改的移动节点能够使用大于零的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.
在大多数网络中，安全邻居发现和CGA签名的目标是防止拒绝服务攻击。因此，通常明智的做法是首先使用较低的秒值，只有在基于蛮力搜索的拒绝服务攻击成为一个重大问题时，才使用较高的秒值替换地址。如果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.
如果存在地址冲突，则冲突计数值用于修改哈希1的输入。重要的是不允许碰撞计数值大于2。首先，极不可能发生三次冲突，原因肯定是配置或实现错误或拒绝服务攻击。（使用发送协议时，会检测到并忽略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]所示。当需要隐私保护时，地址生成中使用的（伪）随机数生成器应足够强大，以生成不可预测和不可链接的值。有关生成随机数的建议，请参见[RFC1750]。
There are two apparent limitations to this privacy protection. However, as will be explained below, neither is very serious.
这种隐私保护有两个明显的限制。然而，正如下文将解释的那样，两者都不是非常严重的。
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.
首先，地址生成的高成本可能会阻止使用高秒值的主机频繁更改其地址。这一问题得到缓解，因为地址生成的昂贵部分可以提前或离线完成，如前一节所述。还应注意，从高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.
其次，地址所有者的公钥将在签名的发送消息中显示。这意味着，如果地址所有者希望对其访问的本地链路中的节点使用假名，那么它不仅应该生成新地址，还应该生成新公钥。然而，对于典型的本地链路技术，节点的链路层地址是节点的唯一标识符。只要节点继续使用相同的链路层地址，出于隐私原因更改公钥就没有什么意义。
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.
尽管本文档仅为安全邻居发现的目的定义了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.
为了防止相关的协议攻击，在对每条消息进行签名之前，都会在其前面添加一个类型标记。类型标记是128位随机选择的值，这可以防止与不使用任何类型标记的设计糟糕的协议发生意外类型冲突。此外，发送协议在所有签名的消息中包括发送方的CGA地址。这使得攻击者从其他上下文中获取签名消息并将其作为发送消息进行重播变得更加困难。
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.
最后，关于将CGA签名用于发送以外的目的，必须提出强烈的警告。首先，其他协议必须以与SEND相同的方式在所有签名消息中包含类型标记和发送方地址。每个协议必须定义自己的类型标签值，如第8节所述。此外，由于存在相关协议攻击的可能性，公钥只能用于签名，不能用于加密。其次，384位的最小RSA密钥长度对于许多应用程序来说可能太短，必须评估密钥泄露对特定协议的影响。第三，基于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.
请求者应使用强随机数生成器生成新值。如果使用强随机数生成器生成了值的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.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[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.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[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，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年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]国际电信联盟，“信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（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，“公钥密码标准（PKCS）#1:RSA密码规范版本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，“在RFCs中编写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]国家标准与技术研究所，“安全哈希标准”，联邦信息处理标准出版物FIPS PUB 180-1，1995年4月<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，“保护IPv6邻居发现和路由器发现”，ACM无线安全研讨会（WiSe 2002），美国佐治亚州亚特兰大，2002年9月。
[Aura03] Aura, T., "Cryptographically Generated Addresses (CGA)", 6th Information Security Conference (ISC'03), Bristol, UK, October 2003.
[Aura03]Aura，T.，“加密生成地址（CGA）”，第六届信息安全会议（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，“安全性的随机性建议”，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，“应用密码学手册”，CRC出版社，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，“IP版本6（IPv6）的邻居发现”，RFC2461，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计算机通信评论31（2），2001年4月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，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 3730 544 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 EBEF02 0301 0001
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 00000 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4B0 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 7B7B 3b9e 63a0 9c7b c48f 7a54 EBF 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 00000 305c 300d 0609 2a86 4886 f70d 0101 0105 0003 4B0 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 7B7B 7B 3b9e 63a0 9c7b c48f 7a54 EBF 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 ce9b fe80 0000 0000 0000 00000 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 7C7B c48f 3b9e 63a0 9C7B7F AF0301 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。通过将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和工作组其他参与者的贡献。
Author's Address
作者地址
Tuomas Aura Microsoft Research Roger Needham Building 7 JJ Thomson Avenue Cambridge CB3 0FB United Kingdom
Tuomas Aura微软研究公司Roger Needham大厦7号JJ汤姆逊大道剑桥CB3 0FB英国
Phone: +44 1223 479708
EMail: tuomaura@microsoft.com
Phone: +44 1223 479708
EMail: tuomaura@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。