Network Working Group M. Bagnulo
Request for Comments: 5535 UC3M
Category: Standards Track June 2009
Network Working Group M. Bagnulo
Request for Comments: 5535 UC3M
Category: Standards Track June 2009
Hash-Based Addresses (HBA)
基于哈希的地址（HBA）
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as
本备忘录描述了一种机制，用于在多址站点中主机可用的具有不同前缀的多个地址之间提供安全绑定。该机制使用加密生成的地址（CGA）或同一主题的新变体，在地址中使用相同的格式。新变体的主要思想是，有关多个前缀的信息包含在地址本身中。这是通过将主机地址的接口标识符生成为
hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other.
可用前缀和随机数的散列。然后，通过在生成的接口标识符前面加上不同的前缀来生成多个地址。结果是一组地址，称为基于散列的地址（HBA），它们本质上相互绑定。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................4
3.1. Threat Model ...............................................4
3.2. Overview ...................................................4
3.3. Motivations for the HBA Design .............................5
4. Cryptographic Generated Addresses (CGAs) Compatibility
Considerations ..................................................6
5. Multi-Prefix Extension for CGA ..................................8
6. HBA-Set Generation ..............................................9
7. HBA Verification ...............................................11
7.1. Verification That a Particular HBA Address
Corresponds to a Given CGA Parameter Data Structure .......11
7.2. Verification That a Particular HBA Address Belongs to the
HBA Set Associated with a Given CGA Parameter Data
Structure .................................................11
8. Example of HBA Application in a Multihoming Scenario ...........13
8.1. Dynamic Address Set Support ...............................16
9. DNS Considerations .............................................17
10. IANA Considerations ...........................................18
11. Security Considerations .......................................18
11.1. Security Considerations When Using HBAs in the
Shim6 Protocol ...........................................20
11.2. Privacy Considerations ...................................22
11.3. SHA-1 Dependency Considerations ..........................22
11.4. DoS Attack Considerations ................................22
12. Contributors ..................................................23
13. Acknowledgments ...............................................23
14. References ....................................................24
14.1. Normative References .....................................24
14.2. Informative References ...................................24
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview ........................................................4
3.1. Threat Model ...............................................4
3.2. Overview ...................................................4
3.3. Motivations for the HBA Design .............................5
4. Cryptographic Generated Addresses (CGAs) Compatibility
Considerations ..................................................6
5. Multi-Prefix Extension for CGA ..................................8
6. HBA-Set Generation ..............................................9
7. HBA Verification ...............................................11
7.1. Verification That a Particular HBA Address
Corresponds to a Given CGA Parameter Data Structure .......11
7.2. Verification That a Particular HBA Address Belongs to the
HBA Set Associated with a Given CGA Parameter Data
Structure .................................................11
8. Example of HBA Application in a Multihoming Scenario ...........13
8.1. Dynamic Address Set Support ...............................16
9. DNS Considerations .............................................17
10. IANA Considerations ...........................................18
11. Security Considerations .......................................18
11.1. Security Considerations When Using HBAs in the
Shim6 Protocol ...........................................20
11.2. Privacy Considerations ...................................22
11.3. SHA-1 Dependency Considerations ..........................22
11.4. DoS Attack Considerations ................................22
12. Contributors ..................................................23
13. Acknowledgments ...............................................23
14. References ....................................................24
14.1. Normative References .....................................24
14.2. Informative References ...................................24
In order to preserve inter-domain routing system scalability, IPv6 sites obtain addresses from their Internet Service Providers (ISPs). Such an addressing strategy significantly reduces the amount of routes in the global routing tables, since each ISP only announces routes to its own address blocks, rather than announcing one route per customer site. However, this addressing scheme implies that multihomed sites will obtain multiple prefixes, one per ISP. Moreover, since each ISP only announces its own address block, a multihomed site will be reachable through a given ISP if the ISP prefix is contained in the destination address of the packets. This means that, if an established communication needs to be routed through different ISPs during its lifetime, addresses with different prefixes will have to be used. Changing the address used to carry packets of an established communication exposes the communication to numerous attacks, as described in [11], so security mechanisms are required to provide the required protection to the involved parties. This memo describes a tool that can be used to provide protection against some of the potential attacks, in particular against future/ premeditated attacks (aka time shifting attacks in [12]).
为了保持域间路由系统的可伸缩性，IPv6站点从其Internet服务提供商（ISP）获取地址。这种寻址策略大大减少了全局路由表中的路由数量，因为每个ISP只宣布到其自己地址块的路由，而不是每个客户站点宣布一条路由。然而，这种寻址方案意味着多址站点将获得多个前缀，每个ISP一个前缀。此外，由于每个ISP只宣布自己的地址块，如果ISP前缀包含在数据包的目标地址中，则可以通过给定的ISP访问多址站点。这意味着，如果已建立的通信在其生存期内需要通过不同的ISP路由，则必须使用具有不同前缀的地址。如[11]中所述，更改用于承载已建立通信的数据包的地址会使通信遭受多次攻击，因此需要安全机制为相关方提供所需的保护。本备忘录描述了一种工具，可用于针对某些潜在攻击提供保护，特别是针对未来/预谋攻击（在[12]中称为时间转移攻击）。
This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site.
本备忘录描述了一种机制，用于在多址站点中主机可用的具有不同前缀的多个地址之间提供安全绑定。
It should be noted that, as opposed to the mobility case where the addresses that will be used by the mobile node are not known a priori, the multiple addresses available to a host within the multihomed site are pre-defined and known in advance in most of the cases. The mechanism proposed in this memo employs either Cryptographically Generated Addresses (CGAs) [2] or a new variant of the same theme that uses the same format in the addresses. The new variant, Hash-Based Address (HBA), takes advantage of the address set stability. In either case, a secure binding between the addresses of a node in a multihomed site can be provided. CGAs employ public key cryptography and can deal with changing address sets. HBAs employ only symmetric key cryptography, and have smaller computational requirements.
应当注意的是，与移动节点将使用的地址先验未知的移动性情况相反，在大多数情况下，多宿站点内的主机可用的多个地址是预定义的并且预先已知的。本备忘录中提出的机制要么采用加密生成地址（CGA）[2]，要么采用相同主题的新变体，在地址中使用相同的格式。新的变体，基于哈希的地址（HBA），利用了地址集的稳定性。在这两种情况下，都可以在多宿站点中的节点地址之间提供安全绑定。CGA采用公钥加密，可以处理不断变化的地址集。HBA仅采用对称密钥加密，并且具有较小的计算要求。
For the purposes of the Shim6 protocol, the other characteristics of the CGAs and HBAs are similar. Both can be generated by the host itself without any reliance on external infrastructure. Both employ the same format of addresses and same format of data fed to generate the addresses. It is not required that all interface identifiers of a node's addresses be equal, preserving some degree of privacy through changes in the addresses used during the communications.
就Shim6协议而言，CGA和HBA的其他特征相似。两者都可以由主机本身生成，而无需依赖外部基础设施。两者都使用相同格式的地址和相同格式的数据来生成地址。不要求节点地址的所有接口标识符相等，从而通过在通信期间使用的地址的更改来保护一定程度的隐私。
The main idea in HBAs is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are obtained by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses that are inherently bound. A cost-efficient mechanism is available to determine if two addresses belong to the same set, since given the prefix set and the additional parameters used to generate the HBA, a single hash operation is enough to verify if an HBA belongs to a given HBA set.
HBA的主要思想是有关多个前缀的信息包含在地址本身中。这是通过将主机地址的接口标识符生成为可用前缀和随机数的散列来实现的。然后，通过在生成的接口标识符前面加上不同的前缀来获得多个地址。结果是一组固有绑定的地址。一种经济高效的机制可用于确定两个地址是否属于同一组，因为给定前缀集和用于生成HBA的附加参数，一次哈希操作就足以验证HBA是否属于给定的HBA集。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The threat analysis for the multihoming problem is described in [11]. This analysis basically identifies attacks based on redirection of packets by a malicious attacker towards addresses that do not belong to the multihomed node. There are essentially two types of redirection attacks: communication hijacking and flooding attacks. Communication hijacking attacks are about an attacker stealing on-going and/or future communications from a victim. Flooding attacks are about redirecting the traffic generated by a legitimate source towards a third party, flooding it. The HBA solution provides full protection against the communication hijacking attacks. The Shim6 protocol [9] protects against flooding attacks. Residual threats are described in the "Security Considerations" section.
[11]中描述了多宿问题的威胁分析。此分析基本上识别基于恶意攻击者将数据包重定向到不属于多宿节点的地址的攻击。基本上有两种类型的重定向攻击：通信劫持和洪水攻击。通信劫持攻击是指攻击者窃取受害者正在进行和/或未来的通信。洪泛攻击是指将合法来源生成的流量重定向到第三方，使其洪泛。HBA解决方案提供了针对通信劫持攻击的全面保护。Shim6协议[9]可防止洪水攻击。剩余威胁在“安全注意事项”一节中描述。
The basic goal of the HBA mechanism is to securely bind together multiple IPv6 addresses that belong to the same multihomed host. This allows rerouting of traffic without worrying that the communication is being redirected to an attacker. The technique that is used is to include a hash of the permitted prefixes in the low-order bits of the IPv6 address.
HBA机制的基本目标是安全地将属于同一多宿主主机的多个IPv6地址绑定在一起。这允许重新路由通信，而不必担心通信被重定向到攻击者。所使用的技术是在IPv6地址的低位包含允许前缀的哈希。
So, eliding some details, say the available prefixes are A, B, C, and D, the host would generate a prefix list P consisting of (A,B,C,D) and a random number called Modifier M. Then it would generate the new addresses:
因此，省略一些细节，比如可用的前缀是A、B、C和D，主机将生成一个前缀列表P，由（A、B、C、D）和一个称为修饰符M的随机数组成。然后它将生成新地址：
A || H(M || A || P)
A | | H（M | | A | P）
B || H(M || B || P)
B | | H（M | | B | P）
C || H(M || C || P)
C | | H（M | | C | P）
D || H(M || D || P)
D | | H（M | | D | P）
Thus, given one valid address out of the group and the prefix list P and the random Modifier M it is possible to determine whether another address is part of the group by computing the hash and checking against the low-order bits.
因此，给定组中的一个有效地址以及前缀列表P和随机修饰符M，可以通过计算散列并对照低阶位进行检查来确定另一个地址是否是组的一部分。
The design of the HBA technique was driven by the following considerations:
HBA技术的设计是由以下考虑因素驱动的：
First of all, the goal of HBA is to provide a secure binding between the IPv6 address used as an identifier by the upper-layer protocols and the alternative locators available in the multihomed node so that redirection attacks are prevented.
首先，HBA的目标是在上层协议用作标识符的IPv6地址和多宿节点中可用的替代定位器之间提供安全绑定，以防止重定向攻击。
Second, in order to achieve such protection, the selected approach was to include security information in the identifier itself, instead of relying on third trusted parties to secure the binding, such as the ones based on repositories or Public Key Infrastructure. This decision was driven by deployment considerations, i.e., the cost of deploying the trusted third-party infrastructure.
其次，为了实现这种保护，所选择的方法是在标识符本身中包含安全信息，而不是依赖第三方（例如基于存储库或公钥基础设施的第三方）来保护绑定。此决策是由部署考虑因素驱动的，即部署受信任的第三方基础架构的成本。
Third, application support considerations described in [16] resulted in selecting routable IPv6 addresses to be used as identifiers. Hence, security information is stuffed within the interface identifier part of the IPv6 address.
第三，[16]中描述的应用程序支持考虑因素导致选择可路由IPv6地址用作标识符。因此，安全信息填充在IPv6地址的接口标识符部分中。
Fourth, performance considerations as described in [17] motivated the usage of a hash-based approach as opposed to a public-key-based approach based on pure Cryptographic Generated Addresses (CGA), in order to avoid imposing the performance of public key operations for every communication in multihomed environments. The HBA approach presented in this document presents a cheaper alternative that is attractive to many common usage cases. Note that the HBA approach and the CGA approaches are not mutually exclusive and that it is possible to generate addresses that are both valid CGA and HBA addresses providing the benefits of both approaches if needed.
Fourth, performance considerations as described in [17] motivated the usage of a hash-based approach as opposed to a public-key-based approach based on pure Cryptographic Generated Addresses (CGA), in order to avoid imposing the performance of public key operations for every communication in multihomed environments. The HBA approach presented in this document presents a cheaper alternative that is attractive to many common usage cases. Note that the HBA approach and the CGA approaches are not mutually exclusive and that it is possible to generate addresses that are both valid CGA and HBA addresses providing the benefits of both approaches if needed.translate error, please retry
4. Cryptographic Generated Addresses (CGAs) Compatibility Considerations
4. 加密生成地址（CGA）兼容性注意事项
As described in the previous section, the HBA technique uses the interface identifier part of the IPv6 address to encode information about the multiple prefixes available to a multihomed host. However, the interface identifier is also used to carry cryptographic information when Cryptographic Generated Addresses (CGAs) [2] are used. Therefore, conflicting usages of the interface identifier bits may result if this is not taken into account during the HBA design. There are at least two valid reasons to provide CGA-HBA compatibility:
如前一节所述，HBA技术使用IPv6地址的接口标识符部分对多主机可用的多个前缀的信息进行编码。然而，当使用加密生成地址（CGA）[2]时，接口标识符也用于携带加密信息。因此，如果在HBA设计过程中没有考虑到这一点，可能会导致接口标识符位的使用冲突。提供CGA-HBA兼容性至少有两个正当理由：
First, the current Secure Neighbor Discovery (SeND) specification [3] uses the CGAs defined in [2] to prove address ownership. If HBAs are not compatible with CGAs, then nodes using HBAs for multihoming wouldn't be able to do Secure Neighbor Discovery using the same addresses (at least the parts of SeND that require CGAs). This would imply that nodes would have to choose between security (from SeND) and fault tolerance (from IPv6 multihoming support provided by the Shim6 protocol [9]). In addition to SeND, there are other protocols that are considered to benefit from the advantages offered by the CGA scheme, such as mobility support protocols [13]. Those protocols could not be used with HBAs if HBAs are not compatible with CGAs.
首先，当前的安全邻居发现（SeND）规范[3]使用[2]中定义的CGA来证明地址所有权。如果HBA与CGA不兼容，则使用HBA进行多宿的节点将无法使用相同的地址（至少是发送中需要CGA的部分）进行安全邻居发现。这意味着节点必须在安全性（来自发送）和容错性（来自Shim6协议提供的IPv6多宿主支持[9]）之间进行选择。除了发送，还有其他协议被认为受益于CGA方案提供的优势，例如移动支持协议[13]。如果HBA与CGA不兼容，则这些协议不能与HBA一起使用。
Second, CGAs provide additional features that cannot be achieved using only HBAs. In particular, because of its own nature, the HBA technique only supports a predetermined prefix set that is known at the time of the generation of the HBA set. No additions of new prefixes to this original set are supported after the HBA set generation. In most of the cases relevant for site multihoming, this is not a problem because the prefix set available to a multihomed set is not very dynamic. New prefixes may be added in a multihomed site when a new ISP is available, but the timing of those events are rarely in the same time scale as the lifetime of established communications. It is then enough for many situations that the new prefix is not available for established communications and that only new communications benefit from it. However, in the case that such functionality is required, it is possible to use CGAs to provide it. This approach clearly requires that HBA and CGA approaches be compatible. If this is the case, it then would be possible to create HBA/CGA addresses that support CGA and HBA functionality simultaneously. The inputs to the HBA/CGA generation process will be both a prefix set and a public key. In this way, a node that has established a communication using one address of the CGA/HBA set can tell its peer to use the HBA verification when one of the addresses
其次，CGA提供了仅使用HBA无法实现的附加功能。具体地，由于其自身的性质，HBA技术仅支持在生成HBA集时已知的预定前缀集。生成HBA集后，不支持在此原始集中添加新前缀。在大多数与站点多宿主相关的情况下，这不是问题，因为多宿主集可用的前缀集不是非常动态的。当新的ISP可用时，可以在多址站点中添加新的前缀，但这些事件的时间安排很少与已建立的通信的生命周期相同。在许多情况下，新前缀不能用于已建立的通信，并且只有新的通信从中受益，这就足够了。然而，在需要这种功能的情况下，可以使用CGA来提供它。这种方法显然要求HBA和CGA方法兼容。如果是这种情况，则可以创建同时支持CGA和HBA功能的HBA/CGA地址。HBA/CGA生成过程的输入将是前缀集和公钥。通过这种方式，使用CGA/HBA集的一个地址建立通信的节点可以在其中一个地址发生故障时通知其对等方使用HBA验证
of its HBA/CGA set is used as locator in the communication or to use CGA (public-/private-key-based) verification when a new address that does not belong to the HBA/CGA set is used as locator in the communication.
当不属于HBA/CGA集的新地址在通信中用作定位器时，其HBA/CGA集的地址将在通信中用作定位器，或使用CGA（基于公钥/私钥）验证。
So, because of the aforementioned reasons, it is a goal of the HBA design to define HBAs in such a way that they are compatible with CGAs as defined in [2] and their usages described in [3] (consequently, to understand the rest of this note, the reader should be familiar with the CGA specification defined in [2]). This means that it must be possible to generate addresses that are both an HBA and a CGA, i.e., that the interface identifier contains cryptographic information of CGA and the prefix-set information of an HBA. The CGA specification already considers the possibility of including additional information into the CGA generation process through the usage of Extension Fields in the CGA Parameter Data Structure. It is then possible to define a Multi-Prefix extension for CGA so that the prefix set information is included in the interface identifier generation process.
因此，由于上述原因，HBA设计的目标是定义HBA，使其与[2]中定义的CGA以及[3]中描述的用途兼容（因此，为了理解本说明的其余部分，读者应该熟悉[2]中定义的CGA规范）。这意味着必须能够生成既是HBA又是CGA的地址，即接口标识符包含CGA的加密信息和HBA的前缀集信息。CGA规范已经考虑了通过使用CGA参数数据结构中的扩展字段将附加信息包括到CGA生成过程中的可能性。然后可以为CGA定义多前缀扩展，以便在接口标识符生成过程中包括前缀集信息。
Even though a CGA compatible approach is adopted, it should be noted that HBAs and CGAs are different concepts. In particular, the CGA is inherently bound to a public key, while an HBA is inherently bound to a prefix set. This means that a public key is not required to generate an HBA-only address. Because of that, we define three different types of addresses:
尽管采用了CGA兼容的方法，但应注意HBA和CGA是不同的概念。特别是，CGA固有地绑定到公钥，而HBA固有地绑定到前缀集。这意味着生成仅HBA地址不需要公钥。因此，我们定义了三种不同类型的地址：
- CGA-only addresses: These are addresses generated as specified in [2] without including the Multi-Prefix extension. They are bound to a public key and to a single prefix (contained in the basic CGA Parameter Data Structure). These addresses can be used for SeND [3]; if used for multihoming, their application will have to be based on the public key usage.
- 仅CGA地址：这些地址按照[2]中的规定生成，不包括多前缀扩展。它们绑定到公钥和单个前缀（包含在基本CGA参数数据结构中）。这些地址可用于发送[3]；如果用于多主，则其应用程序必须基于公钥使用情况。
- CGA/HBA addresses: These addresses are CGAs that include the Multi-Prefix extension in the CGA Parameter Data Structure used for their generation. These addresses are bound to a public key and a prefix set and they provide both CGA and HBA functionalities. They can be used for SeND as defined in [3] and for any usage defined for HBA (such as a Shim6 protocol).
- CGA/HBA地址：这些地址是CGA，在用于生成它们的CGA参数数据结构中包含多前缀扩展。这些地址绑定到公钥和前缀集，并提供CGA和HBA功能。它们可用于[3]中定义的发送和为HBA定义的任何用途（如Shim6协议）。
- HBA-only addresses: These addresses are bound to a prefix set but they are not bound to a public key. Because HBAs are compatible with CGA, the CGA Parameter Data Structure will be used for their generation, but a random nonce will be included in the Public Key field instead of a public key. These addresses can be used for HBA-based multihoming protocols, but they cannot be used for SeND.
- 仅HBA地址：这些地址绑定到前缀集，但不绑定到公钥。由于HBA与CGA兼容，因此将使用CGA参数数据结构来生成HBA，但公钥字段中将包含随机的nonce，而不是公钥。这些地址可用于基于HBA的多宿主协议，但不能用于发送。
The Multi-Prefix extension has the following TLV format as defined in [8]:
多前缀扩展具有[8]中定义的以下TLV格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type | Extension Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[n] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type | Extension Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[2] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix[n] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext Type: 16-bit type identifier of the Multi-Prefix extension (see the "IANA Considerations" section).
Ext Type：多前缀扩展的16位类型标识符（请参阅“IANA注意事项”部分）。
Ext Len: 16-bit unsigned integer. Length of the Extension in octets, not including the first 4 octets.
Ext Len:16位无符号整数。以八位字节为单位的扩展长度，不包括前4个八位字节。
P flag: Set if a public key is included in the Public Key field of the CGA Parameter Data Structure, reset otherwise.
P标志：设置CGA参数数据结构的公钥字段是否包含公钥，否则重置。
Reserved: 31-bit reserved field. MUST be initialized to zero, and ignored upon receipt.
保留：31位保留字段。必须初始化为零，并在收到时忽略。
Prefix[1...n]: Vector of 64-bit prefixes, numbered 1 to n.
前缀[1…n]：64位前缀的向量，编号为1到n。
The HBA generation process is based on the CGA generation process defined in Section 4 of [2]. The goal is to require the minimum amount of changes to the CGA generation process. It should be noted that the following procedure is only valid for Sec values of 0, 1, and 2. For other Sec values, RFC 4982 [10] has defined a CGA SEC registry that will contain the specifications used to generate CGAs. The generation procedures defined in such specifications must be used for Sec values other than 0, 1, or 2.
HBA生成过程基于[2]第4节中定义的CGA生成过程。目标是要求对CGA生成过程进行最少的更改。应注意，以下程序仅对0、1和2的秒值有效。对于其他Sec值，RFC 4982[10]定义了一个CGA Sec注册表，该注册表将包含用于生成CGA的规范。此类规范中定义的生成程序必须用于0、1或2以外的Sec值。
The CGA generation process has three inputs: a 64-bit subnet prefix, a public key (encoded in DER as an ASN.1 structure of the type SubjectPublicKeyInfo), and the security parameter Sec.
CGA生成过程有三个输入：64位子网前缀、公钥（在DER中编码为SubjectPublicKeyInfo类型的ASN.1结构）和安全参数Sec。
The main difference between the CGA generation and the HBA generation is that while a CGA can be generated independently, all the HBAs of a given HBA set have to be generated using the same parameters, which implies that the generation of the addresses of an HBA set will occur in a coordinated fashion. In this memo, we will describe a mechanism to generate all the addresses of a given HBA set. The generation process of each one of the HBA address of an HBA set will be heavily based in the CGA generation process defined in [2]. More precisely, the HBA set generation process will be defined as a sequence of lightly modified CGA generations.
CGA生成和HBA生成之间的主要区别在于，虽然CGA可以独立生成，但必须使用相同的参数生成给定HBA集的所有HBA，这意味着HBA集地址的生成将以协调的方式进行。在本备忘录中，我们将描述一种生成给定HBA集的所有地址的机制。HBA集的每个HBA地址的生成过程将主要基于[2]中定义的CGA生成过程。更准确地说，HBA集生成过程将定义为一系列稍加修改的CGA生成。
The changes required in the CGA generation process when generating a single HBA are the following: First, the Multi-Prefix extension has to be included in the CGA Parameter Data Structure. Second, in the case that the address being generated is an HBA-only address, a random nonce will have to be used as input instead of a valid public key. For backwards compatibility issues with pure CGAs, the random nonce MUST be encoded as a public key as defined in [2]. In particular, the random nonce MUST be formatted as a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo, defined in the Internet X.509 certificate profile [5]. The algorithm identifier MUST be rsaEncryption, which is 1.2.840.113549.1.1.1, and the random nonce MUST be formatted by using the RSAPublicKey type as specified in Section 2.3.1 of RFC 3279 [4]. The random nonce length is 384 bits.
生成单个HBA时，CGA生成过程中需要进行以下更改：首先，CGA参数数据结构中必须包含多前缀扩展。其次，如果生成的地址是仅HBA地址，则必须使用随机nonce作为输入，而不是有效的公钥。对于纯CGA的向后兼容性问题，必须将随机nonce编码为[2]中定义的公钥。特别是，随机nonce必须格式化为在Internet X.509证书配置文件[5]中定义的SubjectPublicKeyInfo类型的DER编码ASN.1结构。算法标识符必须是RSA加密，即1.2.840.113549.1.1.1，并且必须使用RFC 3279[4]第2.3.1节中规定的RSA公钥类型格式化随机nonce。随机nonce长度为384位。
The resulting HBA-set generation process is the following:
生成HBA集的过程如下所示：
The inputs to the HBA generation process are:
HBA生成过程的输入包括：
o A vector of n 64-bit prefixes,
o n个64位前缀的向量，
o A Sec parameter, and
o Sec参数，以及
o In the case of the generation of a set of HBA/CGA addresses, a public key is also provided as input (not required when generating HBA-only addresses).
o 在生成一组HBA/CGA地址的情况下，还提供公钥作为输入（仅生成HBA地址时不需要公钥）。
The output of the HBA generation process are:
HBA生成过程的输出为：
o An HBA-set
o HBA集
o their respective CGA Parameter Data Structures
o 它们各自的CGA参数数据结构
The steps of the HBA-set generation process are:
HBA集生成过程的步骤包括：
1. Multi-Prefix extension generation. Generate the Multi-Prefix extension with the format defined in Section 5. Include the vector of n 64-bit prefixes in the Prefix[1...n] fields. The Ext Len field value is (n*8 + 4). If a public key is provided, then the P flag is set to one. Otherwise, the P flag is set to zero.
1. 多前缀扩展生成。使用第5节中定义的格式生成多前缀扩展。在前缀[1…n]字段中包含n个64位前缀的向量。Ext Len字段值为（n*8+4）。如果提供了公钥，则P标志设置为1。否则，P标志设置为零。
2. Modifier generation. Generate a Modifier as a random or pseudorandom 128-bit value. If a public key has not been provided as an input, generate the Extended Modifier as a 384-bit random or pseudorandom value. Encode the Extended Modifier value as an RSA key in a DER-encoded ASN.1 structure of the type SubjectPublicKeyInfo defined in the Internet X.509 certificate profile [5].
2. 修改器生成。将修改器生成为随机或伪随机128位值。如果未提供公钥作为输入，则将扩展修饰符生成为384位随机或伪随机值。在Internet X.509证书配置文件[5]中定义的SubjectPublicKeyInfo类型的DER编码ASN.1结构中将扩展修饰符值编码为RSA密钥。
3. Concatenate from left to right the Modifier, 9 zero octets, the encoded public key or the encoded Extended Modifier (if no public key was provided), and the Multi-Prefix extension. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2.
3. 从左到右连接修饰符、9个零八位字节、编码公钥或编码扩展修饰符（如果未提供公钥）以及多前缀扩展。在连接上执行SHA-1算法。取SHA-1散列值最左边的112位。结果是Hash2。
4. Compare the 16*Sec leftmost bits of Hash2 with zero. If they are all zero (or if Sec=0), continue with step (5). Otherwise, increment the Modifier by one and go back to step (3).
4. 将哈希2最左边的16*秒位与零进行比较。如果它们都为零（或如果Sec=0），则继续执行步骤（5）。否则，将修改器增加1，然后返回步骤（3）。
5. Set the 8-bit collision count to zero.
5. 将8位冲突计数设置为零。
6. For i=1 to n (number of prefixes) do:
6. 对于i=1到n（前缀数），请执行以下操作：
6.1. Concatenate from left to right the final Modifier value, Prefix[i], the collision count, the encoded public key or the encoded Extended Modifier (if no public key was provided), and the Multi-Prefix extension. Execute the SHA-1 algorithm on the concatenation. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1[i].
6.1. 从左到右连接最终修饰符值、前缀[i]、冲突计数、编码公钥或编码扩展修饰符（如果未提供公钥）以及多前缀扩展。在连接上执行SHA-1算法。取SHA-1散列值最左边的64位。结果是Hash1[i]。
6.2. Form an interface identifier from Hash1[i] 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) both to zero.
6.2. 通过将Sec的值写入最左边的三个位，并将位6和7（即“u”和“g”位）都设置为零，从Hash1[i]形成接口标识符。
6.3. Generate address HBA[i] by concatenating Prefix[i] 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 [6].
6.3. 通过连接前缀[i]和64位接口标识符来生成地址HBA[i]，以形成一个128位IPv6地址，其左侧为子网前缀，右侧为接口标识符，如标准IPv6地址[6]中所示。
6.4. Perform duplicate address detection if required. If an address collision is detected, increment the collision count by one and go back to step (6). However, after three collisions, stop and report the error.
6.4. 如果需要，执行重复地址检测。如果检测到地址冲突，则将冲突计数增加1，然后返回步骤（6）。但是，在三次碰撞后，停止并报告错误。
6.5. Form the CGA Parameter Data Structure that corresponds to HBA[i] by concatenating from left to right the final Modifier value, Prefix[i], the final collision count value, the encoded public key or the encoded Extended Modifier, and the Multi-Prefix extension.
6.5. 通过从左到右连接最终修饰符值、前缀[i]、最终冲突计数值、编码公钥或编码扩展修饰符以及多前缀扩展，形成与HBA[i]相对应的CGA参数数据结构。
Note: most of the steps of the process are taken from [2].
注：该过程的大部分步骤取自[2]。
The following procedure is only valid for Sec values of 0, 1, and 2. For other Sec values, RFC 4982 [10] has defined a CGA SEC registry that will contain the specifications used to verify CGAs. The verification procedures defined in such specifications must be used for Sec values other than 0,1, or 2.
以下过程仅对0、1和2的秒值有效。对于其他Sec值，RFC 4982[10]定义了一个CGA Sec注册表，该注册表将包含用于验证CGA的规范。此类规范中定义的验证程序必须用于0、1或2以外的Sec值。
7.1. Verification That a Particular HBA Address Corresponds to a Given CGA Parameter Data Structure
7.1. 验证特定HBA地址是否对应于给定的CGA参数数据结构
HBAs are constructed as a CGA Extension, so a properly formatted HBA and its correspondent CGA Parameter Data Structure will successfully finish the verification process described in Section 5 of [2]. Such verification is useful when the goal is the verification of the binding between the public key and the HBA.
HBA被构造为CGA扩展，因此正确格式化的HBA及其相应的CGA参数数据结构将成功完成[2]第5节所述的验证过程。当目标是验证公钥和HBA之间的绑定时，这种验证非常有用。
7.2. Verification That a Particular HBA Address Belongs to the HBA Set Associated with a Given CGA Parameter Data Structure
7.2. 验证特定HBA地址是否属于与给定CGA参数数据结构关联的HBA集
For multihoming applications, it is also relevant that the receiver of the HBA information verifies if a given HBA address belongs to a certain HBA set. An HBA set is identified by a CGA Parameter Data structure that contains a Multi-Prefix extension. So, the receiver needs to verify if a given HBA belongs to the HBA set defined by a CGA Parameter Data Structure. It should be noted that the receiver
对于多主应用程序，HBA信息的接收者验证给定HBA地址是否属于某个HBA集也是相关的。HBA集由包含多前缀扩展的CGA参数数据结构标识。因此，接收器需要验证给定HBA是否属于CGA参数数据结构定义的HBA集。应该注意的是，接收器
may need to verify if an HBA belongs to the HBA set defined by the CGA Parameter Data Structure of another HBA of the set. If this is the case, HBAs will fail to pass the CGA verification process defined in [2], because the prefix included in the Subnet Prefix field of the CGA Parameter Data Structure will not match the prefix of the HBA that is being verified. To verify if an HBA belongs to an HBA set associated with another HBA, verify that the HBA prefix is included in the prefix set defined in the Multi-Prefix extension, and if this is the case, then substitute the prefix included in the Subnet Prefix field by the prefix of the HBA, and then perform the CGA verification process defined in [2].
可能需要验证某个HBA是否属于由该HBA集的另一个HBA的CGA参数数据结构定义的HBA集。在这种情况下，HBA将无法通过[2]中定义的CGA验证过程，因为CGA参数数据结构的子网前缀字段中包含的前缀与正在验证的HBA的前缀不匹配。要验证某个HBA是否属于与另一个HBA关联的HBA集，请验证HBA前缀是否包含在多前缀扩展中定义的前缀集中，如果是这种情况，请用HBA的前缀替换子网前缀字段中包含的前缀，然后执行[2]中定义的CGA验证过程。
So, the process to verify that an HBA belongs to an HBA set determined by a CGA Parameter Data Structure is called HBA verification and it is the following:
因此，验证HBA是否属于由CGA参数数据结构确定的HBA集的过程称为HBA验证，如下所示：
The inputs to the HBA verification process are:
HBA验证过程的输入为：
o An HBA
o HBA
o A CGA Parameter Data Structure
o 一种CGA参数数据结构
The steps of the HBA verification process are the following:
HBA验证过程的步骤如下所示：
1. Verify that the 64-bit HBA prefix is included in the prefix set of the Multi-Prefix extension. If it is not included, the verification fails. If it is included, replace the prefix contained in the Subnet Prefix field of the CGA Parameter Data Structure by the 64-bit HBA prefix.
1. 验证64位HBA前缀是否包含在多前缀扩展的前缀集中。如果未包含，则验证失败。如果包含该前缀，请将CGA参数数据结构的子网前缀字段中包含的前缀替换为64位HBA前缀。
2. Run the verification process described in Section 5 of [2] with the HBA and the new CGA Parameters Data Structure (including the Multi-Prefix extension) as inputs. The steps of the process are included below, extracted from [2]:
2. 以HBA和新的CGA参数数据结构（包括多前缀扩展）作为输入，运行[2]第5节所述的验证过程。该过程的步骤如下所示，摘自[2]：
2.1. Check that the collision count in the CGA Parameter Data Structure is 0, 1, or 2. The CGA verification fails if the collision count is out of the valid range.
2.1. 检查CGA参数数据结构中的冲突计数是否为0、1或2。如果碰撞计数超出有效范围，CGA验证将失败。
2.2. Check that the subnet prefix in the CGA Parameter 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. Note: This step always succeeds because of the action taken in step 1.
2.2. 检查CGA参数数据结构中的子网前缀是否等于地址的子网前缀（即最左边的64位）。如果前缀值不同，CGA验证将失败。注意：由于在步骤1中采取的操作，此步骤始终成功。
2.3. Execute the SHA-1 algorithm on the CGA Parameter Data Structure. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1.
2.3. 在CGA参数数据结构上执行SHA-1算法。取SHA-1散列值最左边的64位。结果是Hash1。
2.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.
2.4. 将Hash1与地址的接口标识符（即最右边的64位）进行比较。忽略最左边的三个位以及位6和7（即“u”和“g”位）中的差异。如果64位值不同（五个忽略位除外），则CGA验证失败。
2.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.)
2.5. 从地址的64位接口标识符最左边的三位读取安全参数Sec。（Sec是一个无符号3位整数。）
2.6. Concatenate from left to right the Modifier, 9 zero octets, the public key, and any extension fields (in this case, the Multi-Prefix extension will be included, at least) that follow the public key in the CGA Parameter 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.
2.6. 在CGA参数数据结构中，从左到右连接修饰符、9个零八位字节、公钥和公钥后的任何扩展字段（在本例中，至少包括多前缀扩展名）。在连接上执行SHA-1算法。取SHA-1散列值最左边的112位。结果是Hash2。
2.7. Compare the 16*Sec leftmost bits of Hash2 with zero. If any one of them is non-zero, the CGA verification fails. Otherwise, the verification succeeds. (If Sec=0, the CGA verification never fails at this step.)
2.7. 将哈希2最左边的16*秒位与零进行比较。如果其中任何一个非零，则CGA验证失败。否则，验证将成功。（如果Sec=0，则CGA验证在此步骤中不会失败。）
In this section, we will describe a possible application of the HBA technique to IPv6 multihoming.
在本节中，我们将描述HBA技术在IPv6多宿主中的可能应用。
We will consider the following scenario: a multihomed site obtains Internet connectivity through two providers: ISPA and ISPB. Each provider has delegated a prefix to the multihomed site (PrefA::/nA and PrefB::/nb, respectively). In order to benefit from multihoming, the hosts within the multihomed site will configure multiple IP addresses, one per available prefix. The resulting configuration is depicted in the next figure.
我们将考虑以下场景：多宿主站点通过两个提供商获得互联网连接：ISPA和ISPB。每个提供程序都已将前缀委派给多址站点（分别为PrefA:：/nA和PrefB:：/nb）。为了从多宿中获益，多宿站点内的主机将配置多个IP地址，每个可用前缀一个。生成的配置如下图所示。
+-------+
| Host2 |
|IPHost2|
+-------+
|
|
(Internet)
/ \
/ \
+------+ +------+
| ISPA | | ISPB |
| | | |
+------+ +------+
| |
\ /
\ /
+---------------------+
| multihomed site |
| PA::/nA |
| PB::/nB +------+ |
| |Host1 | |
| +------+ |
+---------------------+
+-------+
| Host2 |
|IPHost2|
+-------+
|
|
(Internet)
/ \
/ \
+------+ +------+
| ISPA | | ISPB |
| | | |
+------+ +------+
| |
\ /
\ /
+---------------------+
| multihomed site |
| PA::/nA |
| PB::/nB +------+ |
| |Host1 | |
| +------+ |
+---------------------+
We assume that both Host1 and Host2 support the Shim6 protocol.
我们假设Host1和Host2都支持Shim6协议。
Host2 is not located in a multihomed site, so there is no need for it to create HBAs (it must be able to verify them though, in order to support the Shim6 protocol, as we will describe next).
Host2不位于多主机站点中，因此不需要它来创建HBA（但它必须能够验证HBA，以便支持Shim6协议，我们将在下面介绍）。
Host1 is located in the multihomed site, so it will generate its addresses as HBAs. In order to do that, it needs to execute the HBA-set generation process as detailed in Section 6 of this memo. The inputs of the HBA-set generation process will be: a prefix vector containing the two prefixes available in its link, i.e., PA:LA::/64 and PB:LB::/64, a Sec parameter value, and optionally a public key. In this case, we will assume that a public key is provided so that we can also illustrate how a renumbering event can be supported when HBA/CGA addresses are used (see the sub-section referring to dynamic address set support). So, after executing the HBA-set generation process, Host1 will have: an HBA-set consisting in two addresses, i.e., PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter Data Structures, i.e., CGA_PDS_A and CGA_PDS_B. Note that iidA and iidB are different but both contain information about the prefix set available in the multihomed site.
Host1位于多址站点中，因此它将生成其作为HBA的地址。为此，它需要执行本备忘录第6节详述的HBA集生成过程。HBA集生成过程的输入将是：一个前缀向量，包含其链接中可用的两个前缀，即PA:LA:：/64和PB:LB:：/64、一个秒参数值和一个公钥（可选）。在这种情况下，我们将假设提供了公钥，以便我们还可以说明在使用HBA/CGA地址时如何支持重新编号事件（请参阅“动态地址集支持”小节）。因此，在执行HBA集生成过程后，Host1将拥有：一个由两个地址组成的HBA集，即PA:LA:iidA和PB:LB:iidB，以及各自的CGA参数数据结构，即CGA_PDS_A和CGA_PDS_B。请注意，iidA和iidB不同，但都包含有关多址站点中可用前缀集的信息。
We will next consider a communication between Host1 and Host2. Assume that both ISPs of the multihomed site are working properly, so any of the available addresses in Host1 can be used for the communication. Suppose then that the communication is established using PA:LA:iidA and IPHost2 for Host1 and Host2, respectively. So far, no special Shim6 support has been required, and PA:LA:iidA is used as any other global IP address.
接下来我们将考虑在HoST1和HoST2之间进行通信。假设多址站点的两个ISP都正常工作，因此Host1中的任何可用地址都可以用于通信。然后假设通信分别使用主机1和主机2的PA:LA:iidA和IPHost2建立。到目前为止，还不需要特殊的Shim6支持，PA:LA:iidA被用作任何其他全局IP地址。
Suppose that at a certain moment, one of the hosts involved in the communication decides that multihoming support is required in this communication (this basically means that one of the hosts involved in the communication desires enhanced fault-tolerance capabilities for this communication, so that if an outage occurs, the communication can be re-homed to an alternative provider).
假设在某一时刻，参与通信的主机之一决定在该通信中需要多主机支持（这基本上意味着参与通信的主机之一希望增强此通信的容错能力，以便在发生中断时，可以将通信重新定位到备用提供商）。
At this moment, the Shim6 protocol Host-Pair Context establishment exchange will be performed between the two hosts (see [9]). In this exchange, Host1 will send CGA_PDS_A to Host2.
此时，将在两台主机之间执行Shim6协议主机对上下文建立交换（参见[9]）。在此交换中，主机1将向主机2发送CGA_PDS_A。
After the reception of CGA_PDS_A, Host2 will verify that the received CGA Parameter Data Structure corresponds to the address being used in the communication PA:LA:iidA. This means that Host2 will execute the HBA verification process described in Section 7 of this memo with PA: LA:iidA and CGA_PDS_A as inputs. In this case, the verification will succeed since the CGA Parameter Data Structure and the addresses used in the verification match.
在接收到CGA_PDS_A之后，Host2将验证接收到的CGA参数数据结构是否与通信PA:LA:iidA中使用的地址相对应。这意味着Host2将以PA:LA:iidA和CGA_PDS_A作为输入，执行本备忘录第7节所述的HBA验证过程。在这种情况下，验证将成功，因为CGA参数数据结构和验证中使用的地址匹配。
As long as there are no outages affecting the communication path through ISPA, packets will continue flowing. If a failure affects the path through ISPA, Host1 will attempt to re-home the communication to an alternative address, i.e., PB:LB:iidB. In order to accomplish this, after detecting the outage, Host1 will inform Host2 about the alternative address. Host2 will verify that the new address belongs to the HBA set of the initial address. In order to accomplish this, Host2 will execute the HBA verification process with the CGA Parameter Data Structure of the original address (i.e., CGA_PDS_A) and the new address (i.e., PB:LB:iidB) as inputs. The verification process will succeed because PB:LB::/64 has been included in the Multi-Prefix extension during the HBA-set generation process. Additional verifications may be required to prevent flooding attacks (see the comments about flooding attacks prevention in the Security Considerations section of this memo).
只要没有中断影响通过ISPA的通信路径，数据包将继续流动。如果故障影响通过ISPA的路径，Host1将尝试将通信重新定位到备用地址，即PB:LB:iidB。为此，在检测到中断后，Host1将通知Host2备用地址。Host2将验证新地址是否属于初始地址的HBA集。为了实现这一点，Host2将使用原始地址（即CGA_PDS_A）和新地址（即PB:LB:iidB）的CGA参数数据结构作为输入来执行HBA验证过程。验证过程将成功，因为在HBA集生成过程中，多前缀扩展中包含了PB:LB:：/64。可能需要额外的验证来防止洪水攻击（请参阅本备忘录安全注意事项部分中有关洪水攻击预防的评论）。
Once the new address is verified, it can be used as an alternative locator to re-home the communication, while preserving the original address (PA:LA:iidA) as an identifier for the upper layers. This
一旦新地址被验证，它可以被用作替代定位器来重新定位通信，同时保留原始地址（PA:LA:iidA）作为上层的标识符。这
means that following packets will be addressed to/from this new address. Note that no additional HBA verification is required for the following packets, since the new valid address can be stored in Host2.
意味着以下数据包将被发送到/发送到此新地址。请注意，以下数据包不需要额外的HBA验证，因为新的有效地址可以存储在Host2中。
In this example, only the HBA capabilities of the Host1 addresses were used. In other words, neither the public key included in the CGA Parameter Data Structure nor its correspondent private key was used in the protocol. In the following section, we will consider a case where its usage is required.
在此示例中，仅使用了Host1地址的HBA功能。换句话说，协议中既没有使用CGA参数数据结构中包含的公钥，也没有使用相应的私钥。在下面的部分中，我们将考虑需要使用它的情况。
In the previous section, we have presented the mechanisms that allow a host to use different addresses of a predetermined set to exchange packets of a communication. The set of addresses involved was predetermined and known when the communication was initiated. To achieve such functionality, only HBA functionalities of the addresses were needed. In this section, we will explore the case where the goal is to exchange packets using additional addresses that were not known when the communication was established. An example of such a situation is when a new prefix is available in a site after a renumbering event. In this case, the hosts that have the new address available may want to use it in communications that were established before the renumbering event. In this case, HBA functionalities of the addresses are not enough and CGA capabilities are to be used.
在上一节中，我们介绍了允许主机使用预定组的不同地址来交换通信数据包的机制。当通信开始时，所涉及的地址集是预先确定的和已知的。为了实现这种功能，只需要地址的HBA功能。在本节中，我们将探讨这样一种情况，即目标是使用通信建立时未知的其他地址交换数据包。这种情况的一个例子是，在重新编号事件之后，站点中有一个新前缀可用。在这种情况下，具有可用新地址的主机可能希望在重新编号事件之前建立的通信中使用该地址。在这种情况下，地址的HBA功能不够，需要使用CGA功能。
Consider then the previous case of the communication between Host1 and Host2. Suppose that the communication is up and running, as described earlier. Host1 is using PA:LA:iidA and Host2 is using IPHost2 to exchange packets. Now suppose that a new address, PC:LC: addC is available in Host1. Note that this address is just a regular IPv6 address, and it is neither an HBA nor a CGA. Host1 wants to use this new address in the existent communication with Host2. It should be noted that the HBA mechanism described in the previous section cannot be used to verify this new address, since this address does not belong to the HBA set (since the prefix was not available at the moment of the generation of the HBA set). This means that alternative verification mechanisms will be needed.
然后考虑以前的情况下，在HoST1和HoST2之间的通信。假设通信已启动并正在运行，如前所述。Host1使用PA:LA:iidA，Host2使用IPHost2交换数据包。现在假设Host1中有一个新地址PC:LC:addC。请注意，此地址只是一个常规IPv6地址，它既不是HBA也不是CGA。Host1希望在与Host2的现有通信中使用此新地址。应注意，上一节中描述的HBA机制不能用于验证此新地址，因为此地址不属于HBA集（因为在生成HBA集时前缀不可用）。这意味着将需要替代核查机制。
In order to verify this new address, CGA capabilities of PA:LA:iidA are used. Note that the same address is used, only that the verification mechanism is different. So, if Host1 wants to use PC: LC:addC to exchange packets in the established communication, it will use the UPDATE message defined in the Shim6 protocol [9], conveying the new address, PC:LC:addC, and this message will be signed using the private key corresponding to the public key contained in CGA_PDS_A. When Host2 receives the message, it will verify the
为了验证这个新地址，使用了PA:LA:iidA的CGA功能。请注意，使用相同的地址，只是验证机制不同。因此，如果Host1希望使用PC:LC:addC在已建立的通信中交换数据包，它将使用Shim6协议[9]中定义的更新消息，传递新地址PC:LC:addC，并且将使用CGA_PDS_A中包含的公钥对应的私钥对该消息进行签名，它将验证
signature using the public key contained in the CGA Parameter Data Structure associated with the address used for establishing the communication, i.e., CGA_PDS_A and PA:LA:iidA, respectively. Once that the signature is verified, the new address (PC:LC:addC) can be used in the communication.
使用CGA参数数据结构中包含的公钥的签名，该CGA参数数据结构与用于建立通信的地址相关，即CGA_PDS_A和PA:LA:iidA。验证签名后，新地址（PC:LC:addC）可用于通信。
In any case, a renumbering event has an impact on a site that is using the HBA technique. In particular, the new prefix added will not be included in the existing HBA set, so it is only possible to use the new prefix with the existing HBA set if CGA capabilities are used. While this is acceptable for the short term, in the long run, the site will need to renumber its HBA addresses. In order to do that, it will need to re-generate the HBA sets assigned to hosts including the new prefix in the prefix set, which will result in different addresses, not only because we need to add a new address with the new prefix, but also because the addresses with the existing prefixes will also change because of the inclusion of a new prefix in the prefix set. Moreover, since HBA addresses need to be generated locally, once these are generated after the renumbering event, the new address information needs to be conveyed to the DNS manager in case that such address information is to be published in the DNS (see DNS considerations section for more details).
在任何情况下，重新编号事件都会对使用HBA技术的站点产生影响。特别是，添加的新前缀将不包括在现有HBA集中，因此只有在使用CGA功能的情况下，才能将新前缀与现有HBA集一起使用。虽然这在短期内是可以接受的，但从长远来看，站点将需要重新编号其HBA地址。为此，它需要重新生成分配给主机的HBA集，包括前缀集中的新前缀，这将导致不同的地址，这不仅是因为我们需要使用新前缀添加新地址，但另一个原因是，由于前缀集中包含了一个新的前缀，具有现有前缀的地址也将发生变化。此外，由于HBA地址需要在本地生成，一旦在重新编号事件后生成这些地址，则需要将新地址信息传送到DNS管理器，以防在DNS中发布此类地址信息（有关更多详细信息，请参阅DNS注意事项部分）。
HBA sets can be generated using any prefix set. Actually, the only particularity of the HBA is that they contain information about the prefix set in the interface identifier part of the address in the form of a hash, but no assumption about the properties of prefixes used for the HBA generation is made. This basically means that depending on the prefixes used for the HBA set generation, it may or may not be recommended to publish the resulting (HBA) addresses in the DNS. For instance, when Unique Local Address (ULA) prefixes [18] are included in the HBA generation process, specific DNS considerations related to the local nature of the ULA should be taken into account and proper recommendations related to publishing such prefixes in the DNS should followed. Moreover, among its addresses, a given host can have some HBAs and some other IPv6 addresses. The consequence from this is that only HBA addresses will be bound together by the HBA technique, while other addresses would not be bound to the HBA set. This would basically mean that if one of the other addresses is used for initiating a Shim6 communication, it won't be possible to use the HBA technique to bind the address used with the HBA set. Furthermore, since HBA addresses are indistinguishable from other IPv6 addresses in their format, an initiator will not be able to distinguish, by merely looking at the
可以使用任何前缀集生成HBA集。实际上，HBA的唯一特殊性在于，它们以散列的形式包含地址的接口标识符部分中设置的前缀的信息，但没有对用于HBA生成的前缀的属性进行假设。这基本上意味着，根据生成HBA集所使用的前缀，可能建议也可能不建议在DNS中发布生成的（HBA）地址。例如，当HBA生成过程中包含唯一本地地址（ULA）前缀[18]时，应考虑与ULA的本地性质相关的特定DNS注意事项，并应遵循与在DNS中发布此类前缀相关的适当建议。此外，在其地址中，给定主机可以有一些HBA和一些其他IPv6地址。这样做的结果是，HBA技术只会将HBA地址绑定在一起，而其他地址不会绑定到HBA集。这基本上意味着，如果其他地址之一用于启动Shim6通信，则不可能使用HBA技术来绑定与HBA集一起使用的地址。此外，由于HBA地址在格式上与其他IPv6地址无法区分，因此发起方仅通过查看
different addresses, which ones belong to the HBA set and which ones do not, so alternative means would be required the initiator is supposed to use only HBA for establishing communications in the presence of non-HBA addresses in the DNS.
不同的地址，哪些属于HBA集，哪些不属于HBA集，因此需要其他方法。在DNS中存在非HBA地址的情况下，启动器应仅使用HBA建立通信。
In addition, it should be noted that the actual HBA values are a result of the HBA generation procedure, meaning that they cannot be arbitrarily chosen. This has an implication with respect to DNS management, because the party that generates the HBA address set needs to convey the address information to the DNS manager, so that the addresses are published and not the other way around. The situation is similar to regular CGA addresses and even to the case where stateless address autoconfiguration is used. In order to do that, it is possible to use Dynamic DNS updates [19] or other proprietary tools. A similar consideration applies when the host wants to publish reverse-DNS entries. Since the host needs to generate its HBA addresses, it will need to convey the address information to the DNS manager so the proper reverse-DNS entry is populated in case it is needed. It should be noted that neither the Shim6 protocol nor the HBA technique rely on the reverse DNS for its proper functioning and the general reasons for requiring reverse-DNS population apply as for any other regular IPv6 address.
此外，应注意的是，实际HBA值是HBA生成过程的结果，这意味着它们不能任意选择。这与DNS管理有关，因为生成HBA地址集的一方需要将地址信息传递给DNS管理器，以便发布地址，而不是相反。这种情况类似于常规CGA地址，甚至类似于使用无状态地址自动配置的情况。为此，可以使用动态DNS更新[19]或其他专有工具。当主机想要发布反向DNS条目时，也需要考虑类似的问题。由于主机需要生成其HBA地址，因此需要将地址信息传递给DNS管理器，以便在需要时填充正确的反向DNS条目。需要注意的是，无论是Shim6协议还是HBA技术，其正常运行都不依赖反向DNS，并且要求反向DNS填充的一般原因适用于任何其他常规IPv6地址。
This document defines a new CGA Extension, the Multi-Prefix extension. This extension has been assigned the CGA Extension Type value 0x0012.
本文档定义了一个新的CGA扩展，即多前缀扩展。此扩展已分配CGA扩展类型值0x0012。
The goal of HBAs is to create a group of addresses that are securely bound, so that they can be used interchangeably when communicating with a node. If there is no secure binding between the different addresses of a node, a number of attacks are enabled, as described in [11]. In particular, it would be possible for an attacker to redirect the communications of a victim to an address selected by the attacker, hijacking the communication. When using HBAs, only the addresses belonging to an HBA set can be used interchangeably, limiting the addresses that can be used to redirect the communication to a predetermined set that belongs to the original node involved in the communication. So, when using HBAs, a node that is communicating using address A can redirect the communication to a new address B if and only if B belongs to the same HBA set as A.
HBA的目标是创建一组安全绑定的地址，以便在与节点通信时可以互换使用。如果节点的不同地址之间没有安全绑定，则会启用大量攻击，如[11]所述。特别是，攻击者可能会将受害者的通信重定向到攻击者选择的地址，从而劫持通信。当使用HBA时，只有属于HBA集的地址可以互换使用，从而将可用于将通信重定向到属于通信中涉及的原始节点的预定集的地址限制在一起。因此，当使用HBA时，使用地址a进行通信的节点可以将通信重定向到新地址B，前提是B与a属于同一HBA集。
This means that if an attacker wants to redirect communications addressed to address HBA1 to an alternative address IPX, the attacker will need to create a CGA Parameter Data Structure that generates an HBA set that contains both HBA1 and IPX.
这意味着，如果攻击者希望将地址为HBA 1的通信重定向到另一个地址IPX，则攻击者需要创建一个CGA参数数据结构，以生成同时包含HBA 1和IPX的HBA集。
In order to generate the required HBA set, the attacker needs to find a CGA Parameter Data Structure that fulfills the following conditions:
为了生成所需的HBA集，攻击者需要找到满足以下条件的CGA参数数据结构：
o the prefix of HBA1 and the prefix of IPX are included in the Multi-Prefix extension.
o 多前缀扩展中包含HBA1前缀和IPX前缀。
o HBA1 is included in the HBA set generated.
o HBA 1包含在生成的HBA集中。
Note: this assumes that it is acceptable for the attacker to redirect HBA1 to any address of the prefix of IPX.
注意：这假设攻击者可以将HBA1重定向到IPX前缀的任何地址。
The remaining fields that can be changed at will by the attacker in order to meet the above conditions are: the Modifier, other prefixes in the Multi-Prefix extension, and other extensions. In any case, in order to obtain the desired HBA set, the attacker will have to use a brute-force attack, which implies the generation of multiple HBA sets with different parameters (for instance with a different Modifier) until the desired conditions are meet. The expected number of times that the generation process will have to be repeated until the desired HBA set is found is exponentially related with the number of bits containing hash information included in the interface identifier of the HBA. Since 59 of the 64 bits of the interface identifier contain hash bits, then the expected number of generations that will have to be performed by the attacker are O(2^59). Note: We assume brute force is the best attack against HBA/CGAs. Also, note that the assumption that the Sec tool defined in [2] multiplies the attack factor holds for brute-force attacks but may not hold for other attack classes.
攻击者可以随意更改其余字段以满足上述条件：修饰符、多前缀扩展中的其他前缀以及其他扩展。在任何情况下，为了获得所需的HBA集，攻击者必须使用蛮力攻击，这意味着生成具有不同参数（例如，使用不同的修改器）的多个HBA集，直到满足所需条件。在找到所需HBA集之前，必须重复生成过程的预期次数与HBA接口标识符中包含哈希信息的位数呈指数关系。由于接口标识符的64位中有59位包含哈希位，因此攻击者必须执行的预期生成数为O（2^59）。注意：我们假设暴力是针对HBA/CGA的最佳攻击。另外，请注意，假设[2]中定义的Sec工具乘以暴力攻击的攻击因子，但对于其他攻击类别可能不成立。
The protection against brute-force attacks can be improved by increasing the Sec parameter. A non-zero Sec parameter implies that steps 3-4 of the generation process will be repeated O(2^(16*Sec)) times (expected number of times). If we assimilate the cost of repeating the steps 3-4 to the cost of generating the HBA address, we can estimate the number of times that the generation is to be repeated in O(2^(59+16*Sec)), in the case of Sec values of 1 and 2. For other Sec values, Sec protection mechanisms will be defined by the specifications pointed by the CGA SEC registry defined in RFC 4982 [10].
通过增加Sec参数，可以提高对暴力攻击的保护。非零秒参数表示生成过程的步骤3-4将重复O（2^（16*Sec））次（预期次数）。如果我们将重复步骤3-4的成本与生成HBA地址的成本相提并论，那么在秒值为1和2的情况下，我们可以估计在O（2^（59+16*秒））内重复生成的次数。对于其他Sec值，Sec保护机制将由RFC 4982[10]中定义的CGA Sec注册表指定的规范定义。
In this section, we will analyze the security provided by HBAs in the context of a Shim6 protocol as described in Section 8 of this memo.
在本节中，我们将分析HBA在本备忘录第8节所述的Shim6协议环境中提供的安全性。
First of all, it must be noted that HBAs cannot prevent man-in-the-middle (hereafter MITM) attacks. This means that in the scenario described in Section 8, if an attacker is located along the path between Host1 and Host2 during the lifetime of the communication, the attacker will be able to change the addresses used for the communication. This means that he will be able to change the addresses used in the communication, adding or removing prefixes at his will. However, the attacker must make sure that the CGA Parameter Data Structure and the HBA set is changed accordingly. This essentially means that the attacker will have to change the interface identifier part of the addresses involved, since a change in the prefix set will result in different interface identifiers of the addresses of the HBA set, unless the appropriate Modifier value is used (which would require O(2(59+16*Sec)) attempts). So, HBA doesn't provide MITM attacks protection, but a MITM attacker will have to change the address used in the communication in order to change the prefix set valid for the communication.
首先，必须注意，HBA不能防止中间人（以下简称MITM）攻击。这意味着，在第8节所述的场景中，如果攻击者在通信生存期内位于Host1和Host2之间的路径上，则攻击者将能够更改用于通信的地址。这意味着他将能够更改通信中使用的地址，随意添加或删除前缀。但是，攻击者必须确保CGA参数数据结构和HBA集已相应更改。这本质上意味着攻击者必须更改所涉及地址的接口标识符部分，因为前缀集的更改将导致HBA集地址的不同接口标识符，除非使用适当的修饰符值（这将需要O（2（59+16*Sec））次尝试）。因此，HBA不提供MITM攻击保护，但MITM攻击者必须更改通信中使用的地址，才能更改对通信有效的前缀集。
HBAs provide protection against time shifting attacks [11], [12]. In the multihoming context, an attacker would perform a time shifted attack in the following way: an attacker placed along the path of the communication will modify the packets to include an additional address as a valid address for the communication. Then the attacker would leave the on-path location, but the effects of the attack would remain (i.e., the address would still be considered as a valid address for that communication). Next we will present how HBAs can be used to prevent such attacks.
HBA提供针对时移攻击的保护[11]，[12]。在多宿主环境中，攻击者将以以下方式执行时移攻击：沿通信路径放置的攻击者将修改数据包，以包含附加地址作为通信的有效地址。然后，攻击者将离开路径上的位置，但攻击的效果将保持不变（即，该地址仍将被视为该通信的有效地址）。接下来，我们将介绍如何使用HBA来防止此类攻击。
If the attacker is not on-path when the initial CGA Parameter Data Structure is exchanged, his only possibility to launch a redirection attack is to fake the signature of the message for adding new addresses using CGA capabilities of the addresses. This implies discovering the public key used in the CGA Parameter Data Structure and then cracking the key pair, which doesn't seem feasible. So in order to launch a redirection attack, the attacker needs to be on-path when the CGA Parameter Data Structure is exchanged, so he can modify it. Now, in order to launch the redirection attack, the attacker needs to add his own prefix in the prefix set of the CGA Parameter Data Structure. We have seen in the previous section that there are two possible approaches for this:
如果在交换初始CGA参数数据结构时，攻击者不在路径上，则他发起重定向攻击的唯一可能性是伪造消息签名，以便使用地址的CGA功能添加新地址。这意味着发现CGA参数数据结构中使用的公钥，然后破解密钥对，这似乎不可行。因此，为了发起重定向攻击，当交换CGA参数数据结构时，攻击者需要在路径上，以便修改它。现在，为了发起重定向攻击，攻击者需要在CGA参数数据结构的前缀集中添加自己的前缀。我们在上一节中看到，有两种可能的方法：
1. Find the right Modifier value, so that the address initially used in the communication is contained in the new HBA set. The cost of this attack is O(2(59+16*Sec)) iterations of the generation process, so it is deemed unfeasible.
1. 找到正确的修饰符值，以便通信中最初使用的地址包含在新的HBA集中。这种攻击的代价是生成过程的0（2（59+16*秒））次迭代，因此被认为是不可行的。
2. Use any Modifier value, so that the address initially used in the communication is probably not included in the HBA set. In this case, the attacker must remain on-path, since he needs to rewrite the address carried in the packets (if not, the endpoints will notice a change in the address used in the communication). This essentially means that the attacker cannot launch a time shifted attack, but he must be a full-time man-in-the-middle.
2. 使用任何修饰符值，以便最初在通信中使用的地址可能不包括在HBA集中。在这种情况下，攻击者必须保持在路径上，因为他需要重写数据包中携带的地址（否则，端点将注意到通信中使用的地址发生了更改）。这本质上意味着攻击者不能发动时移攻击，但他必须是一名全职的中间人。
So, the conclusion is that HBAs provide protection against time shifted attacks
因此，得出的结论是HBA提供了针对时移攻击的保护
HBAs do not provide complete protection against flooding attacks, and, as a result, the SHIM6 protocol has other means to deal with them. However, HBAs make it very difficult to launch a flooding attack towards a specific address. It is possible though, to launch a flooding attack against a prefix. And of course, the protection that HBA offers applies only to nodes that employ it; HBA provides no solution for general-purpose flooding-attack protection for other nodes.
HBA不能提供针对洪水攻击的完整保护，因此，SHIM6协议有其他方法来应对洪水攻击。然而，HBA使得向特定地址发起洪水攻击变得非常困难。但也有可能对前缀发起洪水攻击。当然，HBA提供的保护只适用于使用它的节点；HBA没有为其他节点提供通用泛洪攻击保护解决方案。
Suppose that an attacker has easy access to a prefix PX::/nX and that he wants to launch a flooding attack on a host located in the address P:iid. The attack would consist of establishing communication with a server S and requesting a heavy flow from it. Then simply redirecting the flow to P:iid, flooding the target. In order to perform this attack, the attacker needs to generate an HBA set including P and PX in the prefix set, and be sure that the resulting HBA set contains P:iid. In order to do this, the attacker needs to find the appropriate Modifier value. The expected number of attempts required to find such Modifier value is O(2(59+16*Sec)), as presented earlier. So, we can conclude that such attack is not feasible.
假设攻击者可以轻松访问前缀PX:：/nX，并希望在地址P:iid中的主机上发起泛洪攻击。攻击包括建立与服务器S的通信，并从服务器请求大量流量。然后简单地将流重定向到P:iid，淹没目标。为了执行此攻击，攻击者需要生成前缀集中包含P和PX的HBA集，并确保生成的HBA集包含P:iid。为此，攻击者需要找到适当的修饰符值。如前所述，查找此类修饰符值所需的预期尝试次数为O（2（59+16*秒））。因此，我们可以得出结论，这种攻击是不可行的。
However, the target of a flooding attack is not limited to specific hosts, but it can also be launched against other elements of the infrastructure, such as router or access links. In order to do that, the attacker can establish a communication with a server S and request a download of a heavy flow. Then, the attacker redirects the communication to any address of the target network. Even if the target address is not assigned to any host, the flow will flood the access link of the target site, and the site access router will also suffer the overload. Such attack cannot be prevented using HBAs,
但是，泛洪攻击的目标不仅限于特定主机，还可以针对基础设施的其他元素（如路由器或访问链路）发起攻击。为了做到这一点，攻击者可以与服务器S建立通信，并请求下载大量流量。然后，攻击者将通信重定向到目标网络的任何地址。即使目标地址没有分配给任何主机，流量也会淹没目标站点的访问链路，站点访问路由器也会过载。使用HBA无法防止此类攻击，
since the attacker can easily generate an HBA set using his own prefix and the target network prefix. In order to prevent such attacks, additional mechanisms are required, such as reachability tests.
因为攻击者可以使用自己的前缀和目标网络前缀轻松生成HBA集。为了防止此类攻击，需要额外的机制，如可达性测试。
HBAs can be used as RFC 4941 [7] addresses. If a node wants to use temporary addresses, it will need to periodically generate new HBA sets. The effort required for this operation depends on the Sec parameter value. If Sec=0, then the cost of generating a new HBA set is similar to the cost of generating a random number, i.e., one iteration of the HBA set generation procedure. However, if Sec>0, then the cost of generating an HBA set is significantly increased, since it required O(2(16*Sec)) iterations of the generation process. In this case, depending on the frequency of address change required, the support for RFC 4941 address may be more expensive.
HBA可用作RFC 4941[7]地址。如果节点希望使用临时地址，则需要定期生成新的HBA集。此操作所需的工作量取决于Sec参数值。如果Sec=0，则生成新HBA集的成本与生成随机数的成本相似，即HBA集生成过程的一次迭代。但是，如果秒>0，则生成HBA集的成本会显著增加，因为它需要对生成过程进行0（2（16*Sec））次迭代。在这种情况下，根据所需地址更改的频率，对RFC 4941地址的支持可能更昂贵。
Recent attacks on currently used hash functions have motivated a considerable amount of concern in the Internet community. The recommended approach [14] [15] 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.
最近对当前使用的哈希函数的攻击引起了互联网社区的极大关注。处理此问题的推荐方法[14][15]首先是分析这些攻击对使用哈希函数的不同互联网协议的影响，其次是确保使用哈希函数的不同互联网协议能够迁移到其他协议（更安全）哈希函数，不会对Internet操作造成重大中断。
The aforementioned analysis for CGAs and their extensions (including HBAs) is performed in RFC 4982 [10]. The conclusion of the analysis is that the security of the protocols using CGAs and their extensions are not affected by the recently available attacks against hash functions. In spite of that, the CGA specification [2] was updated by RFC 4982 [10] to enable the support of alternative hash functions.
RFC 4982[10]中对CGA及其扩展（包括HBA）进行了上述分析。分析的结论是，使用CGA及其扩展的协议的安全性不受最近针对哈希函数的攻击的影响。尽管如此，RFC 4982[10]更新了CGA规范[2]，以支持替代哈希函数。
In order to use the HBA technique, the owner of the HBA set must inform its peer about the CGA Parameter Data Structure in order to allow the peer to verify that the different HBAs belong to the same HBA set. Such information must then be stored by the peer to verify alternative addresses in the future. This can be a vector for DoS attacks, since the peer must commit resources (in this particular case memory) to be able to use the HBA technique for address verification. It is then possible for an attacker to launch a DoS attack by conveying HBA information to a victim, imposing on the victim to use memory for storing HBA related state, and eventually
为了使用HBA技术，HBA集的所有者必须将CGA参数数据结构告知其对等方，以便对等方验证不同HBA是否属于同一HBA集。然后，对等方必须存储此类信息，以在将来验证替代地址。这可能是DoS攻击的一个载体，因为对等方必须提交资源（在这种特殊情况下是内存）才能使用HBA技术进行地址验证。然后，攻击者可以通过将HBA信息传送给受害者，迫使受害者使用内存存储HBA相关状态，并最终将其释放，从而发起DoS攻击
running out of memory for other genuine operations. In order to prevent such an attack, protocols that use the HBA technique should implement proper DoS prevention techniques.
其他正版操作的内存不足。为了防止此类攻击，使用HBA技术的协议应实施适当的DoS预防技术。
For instance, the Shim6 protocol [9] includes a 4-way handshake to establish the Shim6 context and, in particular, to establish the HBA-related state. In this 4-way handshake, the receiver remains stateless during the first 2 messages, while the initiator must keep state throughout the exchange of the 4 messages so that the cost of the context establishment is higher in memory terms for the initiator (i.e., the potential attacker) than for the receiver (i.e., the potential victim). In addition to that, the 4-way handshake prevents the usage of spoofed addresses from off-path attacker, since the initiator must be able to receive information through the address it has used as source address, enabling the tracking of the location from which the attack was launched.
例如，Shim6协议[9]包括4路握手以建立Shim6上下文，尤其是建立HBA相关状态。在这种4向握手中，接收器在前2条消息期间保持无状态，而发起者必须在整个4条消息的交换过程中保持状态，以便在内存方面，发起者（即潜在攻击者）的上下文建立成本高于接收器（即潜在受害者）。除此之外，4路握手还可以防止使用非路径攻击者伪造的地址，因为启动器必须能够通过其用作源地址的地址接收信息，从而能够跟踪发起攻击的位置。
This document was originally produced by a MULTI6 design team consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret Wasserman, and Jukka Ylitalo.
本文件最初由一个多6设计团队编制，该团队由以下人员组成（按字母顺序排列）：贾里·阿尔科、马塞洛·巴格努洛、伊尔吉奇·凡·贝伊纳姆、杰夫·休斯顿、埃里克·诺德马克、玛格丽特·瓦瑟曼和朱卡·伊利塔洛。
The initial discussion about HBA benefited from contributions from Alberto Garcia-Martinez, Tuomas Aura, and Arturo Azcorra.
关于HBA的初步讨论得益于阿尔贝托·加西亚·马丁内斯、托马斯·奥拉和阿图罗·阿兹科拉的贡献。
The HBA-set generation and HBA verification processes described in this document contain several steps extracted from [2].
本文档中描述的HBA集生成和HBA验证过程包含从[2]中提取的几个步骤。
Jari Arkko, Matthew Ford, Francis Dupont, Mohan Parthasarathy, Pekka Savola, Brian Carpenter, Eric Rescorla, Robin Whittle, Matthijs Mekking, Hannes Tschofenig, Spencer Dawkins, Lars Eggert, Tim Polk, Peter Koch, Niclas Comstedt, David Ward, and Sam Hartman have reviewed this document and provided valuable comments.
贾里·阿克科、马修·福特、弗朗西斯·杜邦、莫汉·帕塔萨拉西、佩卡·萨沃拉、布赖恩·卡彭特、埃里克·雷斯科拉、罗宾·惠特尔、马提斯·梅金、汉内斯·茨霍芬尼、斯宾塞·道金斯、拉尔斯·艾格特、蒂姆·波尔克、彼得·科赫、尼古拉斯·康斯特德、大卫·沃德和萨姆·哈特曼已对本文件进行了审查，并提供了宝贵的意见。
The text included in Section 3.2 was provided by Eric Rescorla.
第3.2节包含的文本由Eric Rescorla提供。
The author would also like to thank Francis Dupont for providing the first implementation of HBA.
作者还要感谢Francis Dupont提供了HBA的第一个实现。
[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.，“加密生成地址（CGA）”，RFC 39722005年3月。
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[3] Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[4] 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.
[4] Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[5] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[5] Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[6] Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[7] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[7] Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[8] Bagnulo, M. and J. Arkko, "Cryptographically Generated Addresses (CGA) Extension Field Format", RFC 4581, October 2006.
[8] Bagnulo，M.和J.Arkko，“加密生成地址（CGA）扩展字段格式”，RFC 4581，2006年10月。
[9] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[9] Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 5533，2009年6月。
[10] Bagnulo, M. and J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, July 2007.
[10] Bagnulo，M.和J.Arkko，“在加密生成地址（CGA）中支持多散列算法”，RFC 4982，2007年7月。
[11] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[11] Nordmark，E.和T.Li，“与IPv6多宿主解决方案相关的威胁”，RFC 4218，2005年10月。
[12] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[12] Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42252005年12月。
[13] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[13] Arkko，J.，Vogt，C.，和W.Haddad，“移动IPv6的增强路由优化”，RFC 4866，2007年5月。
[14] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[14] Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[15] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", 2005 September.
[15] Bellovin，S.和E.Rescorla，“部署新的哈希算法”，2005年9月。
[16] Nordmark, E., "Multi6 Application Referral Issues", Work in Progress, October 2004.
[16] Nordmark，E.，“Multi6应用程序转介问题”，正在进行的工作，2004年10月。
[17] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient Security for IPv6 Multihoming", ACM Computer Communications Review Vol 35 n 2, April 2005.
[17] Bagnulo，M.，Garcia Martinez，A.，和A.Azcorra，“IPv6多宿主的有效安全”，ACM计算机通信评论第35卷第2期，2005年4月。
[18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[18] Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC4193，2005年10月。
[19] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[19] Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
Author's Address
作者地址
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
马德里卡洛斯三世大学。西班牙马德里勒加内斯30大学28911
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es