Network Working Group M. Bagnulo
Request for Comments: 5535 UC3M
Category: Standards Track June 2009
Hash-Based Addresses (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と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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 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.
このメモは、マルチホームサイト内のホストで使用可能な異なるプレフィックスを使って複数のアドレス間での安全な結合を提供するためのメカニズムについて説明します。このメカニズムは、暗号的に生成されたアドレス（CGAs）またはアドレスで同じフォーマットを使用して同じテーマの新しい亜種のいずれかを採用しています。新しい変種での主なアイデアは、複数のプレフィックスに関する情報はアドレスそのものに含まれていることです。これは、利用可能なプレフィックスおよび乱数のハッシュとしてホストのアドレスのインタフェース識別子を生成することによって達成されます。その後、複数のアドレスが生成されたインタフェース識別子とは異なるプレフィックスを付加することによって生成されます。結果は、本質的に互いに結合されたアドレスのセットと呼ばれるハッシュベースアドレス（の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
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サイトは、彼らのインターネットサービスプロバイダ（ISP）からアドレスを取得します。各ISPだけではなく、顧客のサイトごとに1つのルートを発表するよりも、独自のアドレスブロックへのルートを発表しましたので、そのようなアドレス指定の戦略は大きく、グローバルルーティングテーブル内のルートの量を減少させます。しかし、このアドレス指定方式は、マルチホームのサイトは、ISPごとに1つずつ、複数のプレフィックスを取得することを意味します。各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.
モバイルノードによって使用されるアドレスが先験的に知られていないモビリティ場合とは対照的に、マルチホームサイト内のホストに利用可能な複数のアドレスが事前定義された最もに予め知られている、ことに留意すべきです例。このメモで提案されたメカニズムは、いずれかの暗号化生成アドレス（CGAs）を用いる[2]またはアドレスで同じフォーマットを使用して、同じテーマの新しい変異体。新しい変種、ハッシュベースアドレス（HBA）は、アドレス設定の安定性を利用しています。いずれの場合においても、マルチホームサイト内のノードのアドレスとの間の安全な結合を提供することができます。 CGAsは、公開鍵暗号方式を採用して変化するアドレスセットを扱うことができます。 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プロトコルの目的のために、CGAsおよび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セットに属しているかどうかを確認するのに十分であるので、コスト効率的な機構は、2つのアドレスが同じ集合に属しているかどうかを決定するために利用可能です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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]に記載されています。この分析は、基本的には、マルチホームノードに属さないアドレスに向けて、悪意のある攻撃者によって、パケットのリダイレクションに基づく攻撃を識別します。通信の乗っ取りやフラッディング攻撃：リダイレクション攻撃の2種類が基本的にあります。通信ハイジャック攻撃は、攻撃者が、継続被害者からおよび/または将来の通信を盗むについてです。フラッディング攻撃は、それを洪水、第三者への合法的なソースによって生成されたトラフィックをリダイレクトについてです。 HBAソリューションは、通信ハイジャック攻撃に対する完全な保護を提供します。 [9] SHIM6プロトコルは、フラッディング攻撃から保護します。残留脅威は、「セキュリティの考慮事項」セクションに記載されています。
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:
だから、いくつかの詳細をeliding、利用可能なプレフィックスは、B、C、及びDであると言う、ホストが（A、B、C、D）からなるプレフィクスリストPと修飾M.呼ばれる乱数を生成する次に希望新しいアドレスを生成します。
A || H(M || A || P)
|| 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.
公開鍵操作のパフォーマンスを課すことを回避するために、純粋な暗号化生成アドレス（CGA）に基づいて公開鍵ベースのアプローチとは対照的に、第四の、[17]に記載されているように、パフォーマンスの考慮事項は、ハッシュベースのアプローチの使用を動機付けマルチホーム環境内のすべての通信のために。この文書のHBAのアプローチは、多くの一般的な使用例に魅力的である安価な代替を提供します。 HBAのアプローチとCGAのアプローチは相互に排他的ではなく、必要な場合は、両方のアプローチの利点を提供する両方の有効なCGAおよびHBAアドレスであるアドレスを生成することが可能であることに注意してください。
4. Cryptographic Generated Addresses (CGAs) Compatibility Considerations
4.暗号化生成アドレス（CGAs）の互換性に関する注意事項
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アドレスのインタフェース識別子の部分を使用します。暗号化は、アドレス（CGAs）を生成したときただし、インタフェース識別子はまた、[2]が使用されている暗号化情報を搬送するために使用されます。これはHBAの設計中に考慮されていない場合したがって、インターフェース識別子ビットの競合用途をもたらすことができます。 CGA-HBAの互換性を提供するために、少なくとも2つの有効な理由があります。
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]で定義されたCGAsを使用します。 HBAがCGAsと互換性がない場合には、マルチホーミングのためのHBAを使用してノードが同じアドレス（CGAsを必要と送信の少なくとも一部）を使用してセキュア近隣探索を実行することができないだろう。これは、ノードが（送信から）セキュリティおよびフォールトトレランスの間で選択しなければならないことを暗示する（SHIM6プロトコルによって提供されるのIPv6マルチホーミング支援から[9]）。送信に加えて、このようなモビリティサポートプロトコルとしてCGAスキームによって提供される利点から利益を得ると考えられる他のプロトコル、[13]があります。 HBAがCGAsとの互換性がない場合、これらのプロトコルは、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 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.
第二に、CGAsは唯一のHBAを使用して達成することができない追加の機能を提供します。特に、理由はそれ自身の性質上、HBA技術は唯一のHBAセットの生成時に知られている所定のプレフィックスセットをサポートしています。この元のセットに新しいプレフィックスのいかなる追加はHBAセット生成後にサポートされていません。マルチホームセットで利用可能なプレフィックスセットが非常に動的ではありませんので、サイトマルチホーミングに関連するほとんどの場合、これは問題ではありません。新しいISPが利用可能になったときに新しいプレフィックスは、マルチホームサイトに追加することができるが、これらのイベントのタイミングは、確立された通信の有効期間と同じ時間スケールではめったにありません。新しいプレフィックスが確立された通信のために利用可能ではなく、唯一の新しいコミュニケーションがそれの恩恵を受けることこと、その後、多くの状況のために十分です。しかし、そのような機能が必要とされている場合には、それを提供するために、CGAsを使用することが可能です。このアプローチは、明らかHBAおよびCGAは互換性が近づいていることが必要です。このような場合は、その後、同時にCGAおよびHBA機能をサポートHBA / CGAアドレスを作成することも可能です。 HBA / CGA生成プロセスへの入力は、プレフィックスセットと公開鍵の両方になります。このように、CGA / HBAセットの一つのアドレスを用いて通信を確立しているノードは、そのHBA / CGAセットのアドレスのいずれかが通信してロケータとして使用されるか、または使用する場合、HBA検証を使用するピアを伝えることができCGA（公的/私的キー・ベース）HBA / 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.
そう、なぜなら前述の理由により、それはで定義されるようにCGAsと互換性があるような方法で、HBAを定義するHBA設計の目標である[2]、[3]（従って、残りを理解するために記載され、それらの用途この注目すべきことに、読者は、[2]）で定義されたCGA仕様に精通しなければなりません。これは、インタフェース識別子がCGAの暗号情報とHBAのプレフィックス設定情報が含まれていることが、すなわち、両方のHBAおよびCGAを、あるアドレスを生成することが可能でなければならないことを意味します。 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とCGAsは異なる概念であることに留意すべきです。 HBAは、本質的に接頭辞セットにバインドされている間、特に、CGAは、本質的に、公開鍵にバインドされています。これは、公開鍵がHBA専用のアドレスを生成するために必要とされていないことを意味します。そのため、我々は、アドレスの3つのタイプを定義します。
- 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パラメータのデータ構造でマルチプレフィックスの拡張子を含めるCGAsあります。これらのアドレスは、公開鍵とプレフィックスセットにバインドされていると、彼らは両方CGAおよびHBA機能を提供します。 [3]及び（例えばSHIM6プロトコルとして）HBAに定義された使用のために定義され、それらは送信のために使用することができます。
- 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ベースのマルチホーミングプロトコルのために使用することができますが、彼らが送るために使用することはできません。
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] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext Type: 16-bit type identifier of the Multi-Prefix extension (see the "IANA Considerations" section).
EXTタイプ：マルチプレフィックス拡張の16ビットタイプ識別子（「IANAの考慮事項」の項を参照）。
Ext Len: 16-bit unsigned integer. Length of the Extension in octets, not including the first 4 octets.
EXTレン：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ビットのプレフィックスのベクトルは、nに1の番号を付け。
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生成プロセスへの変更の最小量を必要とすることです。 CGAsを生成するために使用される仕様を含むであろうCGA SECレジストリを定義しているRFC 4982 [10]、次の手順では、0、1、および他の秒の値について2のSEC値に対してのみ有効であることに留意すべきです。そのような仕様で定義された生成手順は、0,1、又は2秒以外の値を使用しなければなりません。
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.
64ビットのサブネットプレフィックス（タイプSubjectPublicKeyInfoでのASN.1構造としてDERで符号化された）、公開鍵、およびセキュリティパラメータ秒：CGA生成プロセスは3つの入力を有しています。
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.
CGAの生成プロセスに必要な変更単一のHBAを生成する以下の通りである：第一に、マルチプレフィックス拡張はCGAパラメータデータ構造に含まれなければなりません。第二に、生成されたアドレスは、HBA-アドレスのみである場合には、ランダムなナンスではなく、有効な公開鍵の入力として使用する必要があります。純粋CGAsとの後方互換性の問題のために、ランダムなノンス[2]で定義されるように公開鍵として符号化されなければなりません。具体的には、ランダムなノンスは、インターネットX.509証明書プロファイルに定義され、式SubjectPublicKeyInfoでのDER符号化されたASN.1構造としてフォーマットされなければならない[5]。アルゴリズム識別子は1.2.840.113549.1.1.1あるrsaEncryptionでなければならず、およびRFC 3279のセクション2.3.1で指定されるように、ランダムなノンスはのRSAPublicKeyタイプを使用してフォーマットされなければならない[4]。ランダムなノンスの長さは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 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).
秒パラメータ、およびHBA / CGAアドレスのセットを生成する場合には、O、O、公開鍵はまた、（HBAのみのアドレスを生成する場合は不要）入力として提供されます。
The output of the HBA generation process are:
HBA生成プロセスの出力は、次のとおりです。
o An HBA-set
HBA-セットO
o their respective CGA Parameter Data Structures
それぞれのCGAパラメータデータ構造O
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ビットのプレフィックスのベクターを含みます。拡張LENフィールド値は（N + 4 * 8）。公開鍵が提供されている場合は、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ビットのランダム又は擬似ランダム値などの拡張修飾を生成します。インターネットX.509証明書プロファイルで定義されたタイプSubjectPublicKeyInfoでのDER符号化されたASN.1構造におけるRSAキーとして拡張修飾値を符号化する[5]。
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.ゼロでHASH2の16 *秒左端のビットを比較してください。それらは全てゼロ（またはsec- = 0の場合）である場合、ステップ（5）に進みます。それ以外の場合は、いずれかによって修飾子をインクリメントし、ステップ（3）に戻ります。
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. HASH1からインタフェース識別子を形成する[I] 3左端のビットに秒の値を書き込むことによってゼロにビット6および7（すなわち、「U」と「G」ビット）の両方を設定することによって。
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]プレフィックスを連結することによって、[i]はアドレスHBAを生成し、標準のIPv6アドレス[6]のように左から右に、インターフェイス識別子にサブネットプレフィックスと、128ビットのIPv6アドレスを形成するために64ビットのインタフェース識別子。
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）に戻ってください。しかし、3つの衝突した後、停止し、エラーを報告します。
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に対応するCGAパラメータデータ構造を形成し、接頭辞[i]は、最終的な衝突カウント値、符号化された公開鍵またはコード拡張修飾、およびマルチプレフィクス拡張。
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、RFC 4982 [10] CGAsを検証するために使用される仕様を含むであろうCGA SECレジストリを定義しています。そのような仕様で定義された検証手順は、0,1、又は2秒以外の値に使用されなければなりません。
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パラメータデータ構造は正常のセクション5で説明検証処理を終了します[2]。目標は、公開鍵と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 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情報の受信を検証することにも関連しています。 HBAのセットは、マルチプレフィックスの拡張が含まれているCGAパラメータデータ構造によって識別されます。だから、受信機は、与えられたHBAがCGAパラメータデータ構造によって定義されたHBAのセットに属しているかどうかを確認する必要があります。受信機はHBAがセットの他のHBAのCGAパラメータデータ構造によって定義されたHBAのセットに属するかどうかを確認する必要があるかもしれないことに留意すべきです。この場合、プレフィックスはCGAパラメータデータ構造のサブネットプレフィックスフィールドに含まれるため、HBAは、[2]で定義された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
HBA O
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プレフィックスは、マルチプレフィックス拡張のプレフィックスセットに含まれていることを確認します。それが含まれていない場合、検証は失敗します。それが含まれている場合は、64ビットのHBAのプレフィックスによってCGAパラメータデータ構造のサブネットプレフィックスフィールドに含まれるプレフィックスを交換してください。
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パラメータデータ構造に衝突回数が衝突カウントが有効範囲外の場合CGA検証が失敗した0、1、または2であることを確認してください。
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. アドレスのインタフェース識別子（すなわち、右端の64ビット）とHASH1を比較します。 3つの左端のビット数とビット6および7（すなわち、「U」と「G」ビット）の違いは無視されます。 64ビット値は、（5無視ビット以外の）異なる場合、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は、符号なしの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. ゼロオクテット、公開鍵、および任意の拡張フィールド修飾、9を左から右へ連結（この場合には、マルチプレフィックス拡張は、少なくとも、含まれる）CGAパラメータデータ構造内の公開鍵に従うこと。連結上の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. ゼロでHASH2の16 *秒左端のビットを比較してください。それらのいずれかがゼロでない場合、CGA検証は失敗します。それ以外の場合は、検証が成功しました。 （秒= 0の場合、CGA検証は、この段階で失敗することはありません。）
In this section, we will describe a possible application of the HBA technique to IPv6 multihoming.
このセクションでは、我々は、IPv6マルチホーミングにHBA技術の適用可能性を説明します。
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：マルチホームのサイトは、2つのプロバイダ経由でインターネット接続を取得します。各プロバイダは、マルチホームサイトにプレフィックスを委任した（PREFA :: / NAおよびPrefB :: / NB、それぞれ）。マルチホーミングの恩恵を受けるためには、マルチホームサイト内のホストは、1つのごとに使用可能なプレフィックスを複数のIPアドレスを設定します。得られた構成は、次の図に示されています。
+-------+
| Host2 |
|IPHost2|
+-------+
|
|
(Internet)
/ \
/ \
+------+ +------+
| ISPA | | ISPB |
| | | |
+------+ +------+
| |
\ /
\ /
+---------------------+
| multihomed site |
| PA::/nA |
| PB::/nB +------+ |
| |Host1 | |
| +------+ |
+---------------------+
We assume that both Host1 and Host2 support the Shim6 protocol.
私たちは、ホスト1とホスト2の両方が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がマルチホームサイトに配置されていないので、それは（私たちは次について説明しますと、SHIM6プロトコルをサポートするために、しかしそれらを確認することができなければならない）HBAを作成するための必要はありません。
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.
それはHBAのようにそのアドレスを生成しますので、ホスト1は、マルチホームサイトにあります。これを行うためには、このメモのセクション6で詳述したようHBA-設定生成処理を実行する必要があります。 HBA設定生成処理の入力は、次のようになります。すなわち、そのリンクで利用可能な2つのプレフィックスを含むプレフィックスベクター、PA：LA :: / 64とPB：LB :: / 64、秒パラメータ値、および必要に応じて公開鍵。この場合、我々はまた、（動的アドレスを参照のサブセクションでは、サポートを設定する参照）HBA / CGAアドレスが使用されるときにリナンバリングイベントをサポートすることができる方法を示すことができるように、公開鍵が提供されると仮定する。だから、HBA集合生成処理を実行した後、host1があります：二つのアドレスで構成されるHBA-セットを、すなわち、PA：LA：飯田とPB：LB：それぞれのCGAパラメータデータ構造、すなわち、CGA_PDS_AとCGA_PDS_BとiidB 。飯田と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.
私たちは、次のホスト1とホスト2の間の通信を検討します。マルチホームサイトの両方のISPが正常に動作していると仮定し、そのホスト1で使用可能なアドレスのいずれかが通信に使用することができます。 LA：ホスト1とホスト2のための飯田とIPHost2、それぞれ通信がPAを使用して確立されることその後仮定する。これまでのところ、特別なSHIM6のサポートが必要とされていない、とPA：LA：飯田は、他のグローバル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).
ある瞬間に、通信に関わるホストの1つが（マルチホーミングサポートをこの通信に必要であると判断し、これは基本的に通信欲望に関わるホストの1つが、この通信のためのフォールトトレランス機能を強化することを意味するとし、もしそのよう停止）は、通信が別のプロバイダに再ホーミングすることができ、発生します。
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プロトコルホスト対コンテキスト確立交換は、2つのホスト（[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.
LA：飯田CGA_PDS_Aの受信後、ホスト2は、受信されたCGAパラメータデータ構造は、通信PAに使用されているアドレスに対応することを検証します。 LA：飯田とCGA_PDS_A入力としてこれは、ホスト2は、PAと、このメモのセクション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を通じての通信経路に影響を与える何の停止がないよう、パケットが流れていきます。 LB：iidB障害がISPAを通じてパスに影響を与える場合、host1がすなわち、PB、代替アドレスへの通信の再家にしようとします。これを実現するためには、停電を検出した後、host1が代替アドレスについてホスト2に通知します。ホスト2は、新しいアドレスが初期アドレスのHBAセットに属していることを確認します。入力としてこれを達成するために、ホスト2は、元のアドレス（すなわち、CGA_PDS_A）及び新しいアドレス（iidB：LB即ち、PB）のCGAパラメータデータ構造とHBAの検証処理を実行します。 PBので、検証プロセスが成功します：LB :: / 64 HBA集合生成プロセス中にマルチプレフィックス拡張に含まれています。追加の検証は、（このメモのSecurity Considerations部でフラッディング攻撃の防止に関するコメントを参照してください）フラッディング攻撃を防ぐために必要な場合があります。
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 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.
上層の識別子として（飯田：LA PA）新しいアドレスが確認されると元のアドレスを保持しながら、通信家を直す別のロケータとして使用することができます。これは、次のパケットは、この新しいアドレスから/宛されることを意味します。新しい有効なアドレスがホスト2に格納することができますので、追加のHBAの検証は、次のパケットのために必要とされないことに注意してください。
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.
この例では、ホスト1のアドレスの唯一の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.
その後、ホスト1とホスト2の間の通信の前のケースを考えます。前述したように、通信は、稼働していると仮定する。 host1がPAを使用している：LA：飯田とhost2がパケットを交換するためにIPHost2を使用しています。今と仮定し、その新しいアドレス、PC：LC：ADDCはホスト1で利用可能です。このアドレスは普通のIPv6アドレスです、そしてそれはHBAでもCGAでもないことに注意してください。 host1がホスト2との既存の通信では、この新しいアドレスを使用したいです。前のセクションで説明した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 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.
この新しいアドレスを確認するために、PAのCGA能力：LA：飯田が使用されています。検証メカニズムが異なるだけで、同じアドレスが使用されていることに注意してください。ホスト1は、PCを使用したいのであれば、：LC：LC：ADDCは確立された通信でパケットを交換するために、それは新しいアドレス、PC運搬、[9] SHIM6プロトコルで定義されたUPDATEメッセージを使用しますADDCを、このメッセージは、意志CGA_PDS_Aに含まれる公開鍵に対応する秘密鍵を使用して署名すること。 LA：それぞれ飯田、ホスト2は、メッセージを受信すると、通信を確立するために使用されるアドレス、すなわち、CGA_PDS_A及びPAに関連付けられたCGAパラメータデータ構造に含まれる公開鍵を用いて署名を検証します。署名が検証されたら、新しいアドレス（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 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の唯一の特殊性は、それらが、ハッシュの形でアドレスのインタフェース識別子部分に設定プレフィックスの情報を含むが、HBAの生成に使用されるプレフィックスの特性についての仮定がなされていないことです。これは基本的HBAセット生成のために使用プレフィックスに依存し、またはDNSをもたらす（HBA）アドレスを公開することを推奨してもしなくてもよいことを意味します。ユニークローカルアドレス（ULA）の接頭辞[18] HBA生成プロセスに含まれている場合、例えば、ULAの局所的性質に関連する特定のDNS考慮事項が考慮され、DNSにそのようなプレフィックスべき公開に関する適切な推奨されるべきです続きます。また、そのアドレスのうち、特定のホストは、いくつかのHBAおよびいくつかの他のIPv6アドレスを持つことができます。これからの結果は、他のアドレスは、HBAセットにバインドされない間だけHBAアドレスは、HBA技術によって互いに結合されるということです。これは基本的に他のアドレスのいずれかがSHIM6の通信を開始するために使用されている場合、HBAのセットで使用するアドレスをバインドするHBAの技術を使用できないことがありますことを意味します。 HBAのアドレスはその形式で他のIPv6アドレスと区別がつかないので、イニシエータは、単にものが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の生成手順の結果であることに留意すべきです。 HBAアドレスセットを生成し、当事者が他の方法で回避したアドレスが公開されるように、DNSマネージャにアドレス情報を伝達する必要はないので、これは、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.
これにより、攻撃者は、通信が代替アドレスIPXにHBA1に対処するための対処リダイレクトしたい場合、攻撃者はHBA1とIPXの両方が含まれているHBAのセットを生成CGAパラメータデータ構造を作成する必要がありますことを意味します。
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.
HBA1のプレフィックスとIPXの接頭辞oをマルチプレフィクス拡張に含まれています。
o HBA1 is included in the HBA set generated.
O HBA1が生成HBAセットに含まれます。
Note: this assumes that it is acceptable for the attacker to redirect HBA1 to any address of the prefix of IPX.
注：これは、攻撃者がIPXの接頭辞の任意のアドレスにHBA1をリダイレクトすることが許容可能であることを前提としています。
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 / CGAsに対する最善の攻撃であると仮定します。また、で定義された秒ツールは、[2]の攻撃係数を乗じという仮定がブルートフォース攻撃のために保持しているが、他の攻撃クラスに保持しないかもしれないことに注意してください。
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 *秒））×（倍の期待数）繰り返される工程を意味します。私たちは、HBAのアドレスを生成するコストに3-4の手順を繰り返すのコストを同化した場合、我々は世代がOで繰り返される回数（2 ^（59 + 16 *秒））、中を推定することができます他の秒値1と2秒の値の場合は、秒の保護メカニズムは、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.
このメモのセクション8で説明したように、このセクションでは、我々はSHIM6プロトコルの文脈でのHBAによって提供されるセキュリティを分析します。
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がman-in-the-middle攻撃（MITMを以後）を防止することができないことに注意しなければなりません。これにより、攻撃者は、通信の存続期間中にホスト1とホスト2の間の経路に沿って配置されている場合、セクション8に記載されたシナリオでは、攻撃者が通信のために使用されるアドレスを変更することができるであろうことを意味します。これは彼が彼の意志で接頭辞を追加または削除、通信に使用されるアドレスを変更することができるようになることを意味します。しかし、攻撃者はCGAパラメータデータ構造とHBAのセットがそれに応じて変更されたことを確認する必要があります。これは本質的にどのだろう（適切な修飾値が使用されていない限りプレフィックスセットの変化は、HBAセットのアドレスの異なるインタフェース識別子をもたらすため、攻撃者は、関係するアドレスのインタフェース識別子部分を変更しなければならないことを意味しますO（2（59 + 16 *秒））の試み）を必要とします。だから、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パラメータデータ構造の接頭辞セットで彼自身のプレフィックスを追加する必要があります。我々は、このための2つの可能なアプローチがあることを前節で見てきました：
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.
当初は通信に使用されるアドレスは、新しいHBAセットに含まれるように、右のモディファイ値を見つけます。この攻撃のコストはO（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.
当初は通信に使用されるアドレスは、おそらくHBAセットに含まれないように2、任意の修飾子値を使用します。彼は（ない場合は、エンドポイントが通信に使用するアドレスの変化に気づくでしょう）パケットで運ばれたアドレスを書き換える必要があるため、この場合、攻撃者は、上のパスでなければなりません。これは本質的に時間を起動することはできません、攻撃者が攻撃をシフトすることを意味するが、彼はフルタイムのman-in-the-middleでなければなりません。
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.
IID：攻撃者は接頭辞PXに簡単にアクセス:: / nXをを持っており、彼はアドレスPにあるホスト上でフラッディング攻撃を開始したいことをしたと。攻撃は、サーバSとの通信を確立し、それからの重い流れを要求することからなります。 、IIDターゲット洪水：次に、単にPへの流れをリダイレクトします。 IID：この攻撃を実行するためには、攻撃者は、接頭辞セットでPとPXを含むHBAのセットを生成し、そして得られたHBAのセットはPが含まれていることを確認する必要があります。これを行うためには、攻撃者は、適切な修飾子値を見つける必要があります。先に提示したような修飾値を見つけるために必要な試行数の期待値は、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, 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.
しかし、フラッディング攻撃のターゲットは、特定のホストに限定されるものではないが、それはまた、このようなルータまたはアクセスリンクとして、インフラの他の要素に対して実行することができます。そのためには、攻撃者は、サーバSとの通信を確立し、重い流れのダウンロードを要求することができます。その後、攻撃者は、ターゲット・ネットワークの任意のアドレスへの通信をリダイレクトします。ターゲットアドレスは任意のホストに割り当てられていない場合であっても、流れは、標的部位のアクセスリンクをフラッディングします、サイトアクセスルータはまた、過負荷を被るだろう。攻撃者は簡単に自分のプレフィックスとターゲットネットワークプレフィックスを使用してHBAのセットを生成することができますので、このような攻撃は、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のパラメータの値に依存します。秒= 0の場合は、新しいHBAのセットを生成するコストは、乱数を発生するコストと同様であり、すなわち、HBA集合生成手順の1回の繰り返し。それはO（2（16 *秒））生成プロセスの反復を要するので、秒> 0の場合、HBAのセットを生成するコストが大幅に増加します。この場合、必要なアドレス変更の頻度に応じて、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]この問題に対処するためであるハッシュ関数を使用する別のインターネットプロトコルが可能であることを確認するために、ハッシュ関数を使用する別のインターネット・プロトコル上のこれらの攻撃の影響、および秒を分析する最初のインターネット操作における主要な中断することなく別の（より安全な）ハッシュ関数に移行します。
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.
CGAs及び（HBAを含む）、それらの拡張のための前述の分析は、RFC 4982 [10]で行われます。分析の結論はCGAsを使用してプロトコルとその拡張子のセキュリティは、ハッシュ関数に対する最近利用可能な攻撃に影響されないということです。それにもかかわらず、[2] CGA仕様は別のハッシュ関数のサポートを可能にするために、RFC 4982 [10]により更新されました。
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 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の技術を使用するためには、HBA・セットの所有者は、ピアが異なるHBAが同じHBAのセットに属していることを確認することを可能にするためにCGAパラメータデータ構造についてそのピアに通知しなければなりません。そのような情報は、将来的には別のアドレスを確認するために、ピアにより記憶されなければなりません。ピアがアドレス検証のためのHBA技術を使用できるようにする（この特定の場合メモリに）リソースをコミットしなければならないので、これは、DoS攻撃のためのベクターであってもよいです。攻撃者はHBA関連の状態を保存し、最終的には他の本物の操作のためにメモリ不足のためにメモリを使用するように被害者に課し、被害者へのHBA情報を伝えることでDoS攻撃を起動することがことが可能です。このような攻撃を防ぐために、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] HBAに関連する状態を確立するために、特に、SHIM6コンテキストを確立し、4ウェイハンドシェイクを含みます。コンテキストの確立のコストを開始するためのメモリ点で高くなるように開始剤が、すなわち（4つのメッセージの交換を通して状態を維持しなければならないが、この4ウェイハンドシェイクでは、受信機は、第2のメッセージ中ステートレスのままで受信機（すなわち、潜在的な被害者）のためのより潜在的な攻撃者）。イニシエータは、元の場所の追跡を可能にする、それが送信元アドレスとして使用しているアドレスを介して情報を受信することができなければならないので、それに加えて、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.
ヤリArkko、マルセロBagnulo、IljitschバンBeijnum、ジェフ・ヒューストン、エリックNordmarkと、マーガレットワッサーマン、およびユッカYlitalo：この文書は、もともと（アルファベット順）からなるMULTI6のデザインチームによって作成されました。
The initial discussion about HBA benefited from contributions from Alberto Garcia-Martinez, Tuomas Aura, and Arturo Azcorra.
HBAに関する初期の議論は、アルベルト・ガルシア・マルティネス、のTuomasオーラ、そしてアルトゥーロ・アズコーッラからの貢献の恩恵を受けました。
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.
ヤリArkko、マシュー・フォード、フランシスデュポン、モハンパルタサラティ、ペッカSavola、ブライアン・カーペンター、エリックレスコラ、ロビン・ホイットル、Matthijs Mekking、ハンネスTschofenig、スペンサードーキンスラースEggertの、ティムポーク、ピーター・コッホ、ニクラスComstedt、デビッド・ウォード、そしてサムハートマンは、この文書を検討し、貴重なコメントを提供してきました。
The text included in Section 3.2 was provided by Eric Rescorla.
3.2節に含まれるテキストは、エリックレスコラによって提供されました。
The author would also like to thank Francis Dupont for providing the first implementation of HBA.
著者はまた、HBAの最初の実装を提供するためのフランシス・デュポンに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[2]オーラ、T.、 "暗号化生成アドレス（CGA）"、RFC 3972、2005年3月。
[3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[3] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikanderを、 "セキュア近隣探索（SEND）"、RFC 3971、2005年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.、ポーク、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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[6] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[6] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年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、 "暗号化生成アドレス（CGAs）の複数のハッシュアルゴリズムのサポート"、RFC 4982、2007年7月。
[11] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[11] Nordmarkと、E.およびT.李、 "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.、オーラ、T.、モンテネグロ、G.、およびE. Nordmarkと、 "モバイルIPバージョン6経路最適化セキュリティデザインの背景"、RFC 4225、2005年12月。
[13] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007.
[13] Arkko、J.、フォークト、C.、およびW.ハダッド、 "モバイルIPv6のための強化されたルート最適化"、RFC 4866、2007年5月。
[14] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[14]ホフマン、P.とB.シュナイアー、 "インターネットプロトコルで暗号化ハッシュに対する攻撃"、RFC 4270、2005年11月。
[15] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", 2005 September.
[15] Bellovin氏、S.およびE.レスコラ、 "新しいハッシュアルゴリズムの展開" を、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.、ガルシア・マルティネス、A.、およびA. Azcorra、 "IPv6のマルチホーミングのための効率的なセキュリティ"、ACMコンピュータコミュニケーションレビュー集35 N 2、2005年4月。
[18] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[18] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、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] RFC 2136 "ドメインネームシステム（DNS更新）における動的更新" いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、1997年4月。
Author's Address
著者のアドレス
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
マドリードのマルセロBagnuloチャールズIII大学のAv。大学30レガネス、マドリード28911スペイン
Phone: 34 91 6249500 EMail: marcelo@it.uc3m.es URI: http://www.it.uc3m.es
電話：34 91 6249500 Eメール：marcelo@it.uc3m.es URI：http://www.it.uc3m.es