[要約] RFC 6629は、IPv6のレベル3マルチホーミングシムプロトコル（Shim6）の適用に関する考慮事項をまとめたものです。このRFCの目的は、Shim6の実装と展開に関するガイダンスを提供することです。
Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 6629 ICANN
Category: Informational M. Bagnulo
ISSN: 2070-1721 A. Garcia-Martinez
UC3M
June 2012
Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)
レベル3マルチホーミングShimプロトコルのIPv6への適用に関する考慮事項（Shim6）
Abstract
概要
This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6.
このドキュメントでは、IPv6のレベル3マルチホーミングShimプロトコル（Shim6）の適用性に関するいくつかの考慮事項と、IPv6でサイトマルチホーミング機能を提供するための関連するサポートプロトコルおよびメカニズムについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6629.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6629で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Deployment Scenarios ............................................4
3. Addresses and Shim6 .............................................6
3.1. Protocol Version (IPv4 vs. IPv6) ...........................6
3.2. Prefix Lengths .............................................7
3.3. Address Generation and Configuration .......................7
3.4. Use of CGA vs. HBA .........................................7
4. Shim6 in Multihomed Nodes .......................................8
5. Shim6 Capabilities .............................................10
5.1. Fault Tolerance ...........................................10
5.1.1. Establishing Communications After an Outage ........10
5.1.2. Short-Lived and Long-Lived Communications ..........11
5.2. Load Balancing ............................................11
5.3. Traffic Engineering .......................................12
6. Application Considerations .....................................12
7. Interaction with Other Protocols and Mechanisms ................13
7.1. Shim6 and Mobile IPv6 .....................................13
7.1.1. Multihomed Home Network ............................14
7.1.2. Shim6 Between the HA and the MN ....................16
7.2. Shim6 and SEND ............................................16
7.3. Shim6, SCTP and MPTCP .....................................17
7.4. Shim6 and NEMO ............................................18
7.5. Shim6 and HIP .............................................18
7.6. Shim6 and Firewalls .......................................19
7.7. Shim6 and NPTv6 ...........................................20
8. Security Considerations ........................................23
8.1. Privacy Considerations ....................................24
9. Contributors ...................................................24
10. Acknowledgements ..............................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
Site multihoming is an arrangement by which a site may use multiple paths to the rest of the Internet to provide better reliability for traffic passing in and out of the site than would be possible with a single path. Some of the motivations for operators to multihome their network are described in [RFC3582].
サイトマルチホーミングは、サイトが残りのインターネットへの複数のパスを使用して、単一のパスで可能であるよりもサイトに出入りするトラフィックの信頼性を向上させるための配置です。事業者がネットワークをマルチホーム化する動機のいくつかは、[RFC3582]で説明されています。
In IPv4, site multihoming is achieved by injecting the additional state required to allow session resilience over re-homing events [RFC4116] into the global Internet routing system (sometimes referred to as the Default-Free Zone, or DFZ). There is concern that this approach will not scale [RFC3221] [RFC4984].
IPv4では、サイトのマルチホーミングは、セッションの復元を可能にするために必要な追加の状態をリホーミングイベント[RFC4116]からグローバルインターネットルーティングシステム（デフォルトフリーゾーン、またはDFZと呼ばれることもあります）に注入することで実現されます。このアプローチがスケーリングしない[RFC3221] [RFC4984]という懸念があります。
Site multihoming in IPv6 can be achieved as in IPv4, thus facing similar scalability concerns. However, IPv6's large address space enables a different solution for site multihoming in IPv6: to assign multiple addresses to each host, one or more from each provider. Deploying site multihoming in this way does not impact the routing system. So such a site multihoming strategy may be extended to a large number of sites, and may be applied to small sites that would not be eligible for site multihoming based on the injection of routes to Provider Independent (PI) prefixes. A drawback of this multihoming approach is that it does not provide transport-layer stability across re-homing events.
IPv6のサイトマルチホーミングはIPv4の場合と同様に実現できるため、同様のスケーラビリティの問題に直面しています。ただし、IPv6の大きなアドレス空間により、IPv6でのサイトマルチホーミングの異なるソリューションが可能になります。つまり、各プロバイダーに1つ以上の複数のアドレスを各ホストに割り当てることです。この方法でサイトマルチホーミングを展開しても、ルーティングシステムには影響しません。そのため、このようなサイトマルチホーミング戦略は多数のサイトに拡張でき、プロバイダー独立（PI）プレフィックスへのルートの注入に基づくサイトマルチホーミングに適さない小さなサイトに適用できます。このマルチホーミングアプローチの欠点は、リホーミングイベント全体でトランスポート層の安定性を提供しないことです。
Shim6 provides layer-3 support for making re-homing events transparent to the transport layer by means of a shim approach. Once a Shim6 session has been established, the failure detection mechanism defined for Shim6 allows finding new, valid locator combinations in case of failure and using these locators to continue the communication. However, Shim6 does not provide failure protection to the communication establishment, so if a host within a multihomed site attempts to establish a communication with a remote host and selects an address that corresponds to a failed transit path, the communication will fail. State information relating to the multihoming of two endpoints exchanging unicast traffic is retained on the endpoints themselves, rather than in the network. Communications between Shim6-capable hosts and Shim6-incapable hosts proceed as normal, but without the benefit of transport-layer stability. The Shim6 approach is thought to have better scaling properties with respect to the state held in the DFZ than the PI approach. In order to successfully deploy Shim6 in a multihomed site, additional mechanisms may be required to solve issues, such as selecting the source address appropriate to the destination and to the outgoing provider, or to allow the network manager to perform traffic engineering. Such problems are not specific to Shim6, but are relevant to the hosts of any site that is connected to multiple transit providers, and that receives an IPv6 prefix from each of the providers [RFC5220]. Some of these mechanisms are not defined today. However, note that once a Shim6 session has been established, Shim6 reduces the impact of these problems, because if a working path exists, Shim6 will find it.
Shim6は、shimアプローチを使用して、リホーミングイベントをトランスポート層に対して透過的にするためのレイヤー3サポートを提供します。 Shim6セッションが確立されると、Shim6に定義された障害検出メカニズムにより、障害発生時に新しい有効なロケーターの組み合わせを見つけ、これらのロケーターを使用して通信を継続できます。ただし、Shim6は通信の確立に障害保護を提供しないため、マルチホームサイト内のホストがリモートホストとの通信を確立しようとして、失敗したトランジットパスに対応するアドレスを選択すると、通信は失敗します。ユニキャストトラフィックを交換する2つのエンドポイントのマルチホーミングに関する状態情報は、ネットワーク内ではなく、エンドポイント自体に保持されます。 Shim6対応ホストとShim6非対応ホスト間の通信は通常どおりに進行しますが、トランスポート層の安定性の利点はありません。 Shim6アプローチは、PIアプローチよりもDFZに保持されている状態に関して、より優れたスケーリング特性を持っていると考えられています。マルチホームサイトにShim6を正常に展開するには、問題を解決するために、宛先と送信プロバイダーに適切な送信元アドレスを選択したり、ネットワーク管理者がトラフィックエンジニアリングを実行できるようにするための追加のメカニズムが必要になる場合があります。このような問題はShim6に固有のものではありませんが、複数のトランジットプロバイダーに接続され、各プロバイダーからIPv6プレフィックスを受信するすべてのサイトのホストに関連しています[RFC5220]。これらのメカニズムのいくつかは今日定義されていません。ただし、Shim6セッションが確立されると、Shim6はこれらの問題の影響を軽減します。これは、作業パスが存在する場合、Shim6がそれを見つけるためです。
This note describes the applicability of the Level 3 multihoming (hereafter Shim6) protocol defined in [RFC5533] and the failure detection mechanisms defined in [RFC5534].
このノートでは、[RFC5533]で定義されているレベル3マルチホーミング（以下、Shim6）プロトコルの適用性と、[RFC5534]で定義されている障害検出メカニズムについて説明します。
The terminology used in this document, including terms like locator and Upper-Layer Identifier (ULID), is defined in [RFC5533].
このドキュメントで使用されている用語は、ロケーターや上位層識別子（ULID）などの用語を含み、[RFC5533]で定義されています。
The goal of the Shim6 protocol is to support locator agility in established communications; different layer-3 endpoint addresses may be used to exchange packets belonging to the same transport-layer session, all the time presenting a consistent identifier pair to upper-layer protocols.
Shim6プロトコルの目標は、確立された通信でロケーターの俊敏性をサポートすることです。同じトランスポート層セッションに属するパケットを交換するために、異なるレイヤー3エンドポイントアドレスを使用できます。常に、上位層プロトコルに一貫した識別子のペアを提示します。
In order to be useful, the Shim6 protocol requires that at least one of the peers have more than one address that could be used on the wire (as locators). In the event of communications failure between an active pair of addresses, the Shim6 protocol attempts to reestablish communication by trying different combinations of locators.
役立つために、Shim6プロトコルでは、ピアの少なくとも1つが（ロケーターとして）ワイヤーで使用できる複数のアドレスを持っている必要があります。アクティブなアドレスのペア間で通信障害が発生した場合、Shim6プロトコルは、ロケーターのさまざまな組み合わせを試行して、通信の再確立を試みます。
While other multi-addressing scenarios are not precluded, the scenario in which the Shim6 protocol is expected to operate is that of a multihomed site that is connected to multiple transit providers, and that receives an IPv6 prefix from each of them. This configuration is intended to provide protection for the end-site in the event of a failure in some subset of the available transit providers, without requiring the end-site to acquire PI address space or requiring any particular cooperation between the transit providers.
他のマルチアドレッシングシナリオは除外されませんが、Shim6プロトコルが動作すると予想されるシナリオは、複数のトランジットプロバイダーに接続され、それぞれからIPv6プレフィックスを受信するマルチホームサイトのシナリオです。この構成は、エンドサイトがPIアドレス空間を取得したり、トランジットプロバイダー間の特定の連携を要求したりすることなく、利用可能なトランジットプロバイダーのサブセットに障害が発生した場合にエンドサイトを保護することを目的としています。
,------------------------------------. ,----------------.
| Rest of the Internet +-------+ Remote Host R |
`--+-----------+------------------+--' `----------------'
| | | LR[1] ... LR[m]
,---+----. ,---+----. ,----+---.
| ISP[1] | | ISP[2] | ...... | ISP[n] |
`---+----' `---+----' `----+---'
| | |
,---+-----------+------------------+---.
| Multi-Homed Site S assigned |
| prefixes P[1], P[2], ..., P[n] |
| |
| ,--------. L[1] = P[1]:iid[1], |
| | Host H | L[2] = P[2]:iid[2], ... |
| `--------' L[n] = P[n]:iid[n] |
`--------------------------------------'
Figure 1
図1
In the scenario illustrated in Figure 1, host H communicates with some remote host R. Each of the addresses L[i] configured on host H in the multihomed site S can be reached through provider ISP[i] only, since ISP[i] is solely responsible for advertising a covering prefix for P[i] to the rest of the Internet.
図1に示すシナリオでは、ホストHがリモートホストRと通信します。マルチホームサイトSのホストHに構成されている各アドレスL [i]には、プロバイダーISP [i]を介してのみ到達できます。 P [i]のカバープレフィックスをインターネットの残りの部分にアドバタイズする責任は単独であります。
The use of locator L[i] on H hence causes inbound traffic towards H to be routed through ISP[i]. Changing the locator from L[i] to L[j] will have the effect of re-routing inbound traffic to H from ISP[i] to ISP[j]. This is the central mechanism by which the Shim6 protocol aims to provide multihoming functionality: by changing locators, host H can change the upstream ISP used to route inbound packets towards itself. Regarding the outbound traffic to H, the path taken in this case depends on both the actual locator LR[j] used for R, and the administrative exit selection policy of site S. As discussed in Section 4, the site should deliver outgoing packets that have a source address derived from the prefix of ISP[i] to that particular provider, in order to prevent those packets from being filtered due to ingress filtering [RFC2827] being applied by the providers. It is worth noting that in a scenario such as the one depicted in Figure 1, the paths followed by inbound and outbound traffic are determined, to a large extent, by the locators in use for the communication. This is not a particular issue of Shim6, but it is common to any deployment in which hosts are configured with addresses received from different providers. Traffic Engineering in such sites will likely involve proper configuration of address selection policies in the hosts, by means of mechanisms such as the ones discussed in Section 4.
したがって、HでロケーターL [i]を使用すると、HへのインバウンドトラフィックがISP [i]経由でルーティングされます。ロケーターをL [i]からL [j]に変更すると、着信トラフィックをHにISP [i]からISP [j]に再ルーティングする効果があります。これは、Shim6プロトコルがマルチホーミング機能を提供することを目的とする中心的なメカニズムです。ロケーターを変更することにより、ホストHは、受信パケットを自身にルーティングするために使用されるアップストリームISPを変更できます。 Hへのアウトバウンドトラフィックに関して、この場合に取られるパスは、Rに使用される実際のロケーターLR [j]とサイトSの管理出口選択ポリシーの両方に依存します。セクション4で説明したように、サイトはプロバイダーによって適用されるイングレスフィルタリング[RFC2827]によってこれらのパケットがフィルタリングされないようにするために、ISP [i]のプレフィックスからその特定のプロバイダーへのソースアドレスを取得します。図1に示すようなシナリオでは、インバウンドとアウトバウンドのトラフィックがたどるパスは、通信に使用されているロケーターによって大部分が決定されることに注意してください。これはShim6の特定の問題ではありませんが、ホストがさまざまなプロバイダーから受信したアドレスで構成されているすべての展開に共通です。このようなサイトのトラフィックエンジニアリングでは、セクション4で説明したようなメカニズムを使用して、ホストでのアドレス選択ポリシーの適切な構成が必要になる可能性があります。
The Shim6 protocol has other potential applications beyond site multihoming. For example, since Shim6 is a host-based protocol, it can also be used to support host multihoming. In this case, a failure in communication between a multihomed host and some other remote host might be repaired by selecting a locator associated with a different interface.
Shim6プロトコルには、サイトマルチホーミング以外の潜在的なアプリケーションがあります。たとえば、Shim6はホストベースのプロトコルであるため、ホストマルチホーミングのサポートにも使用できます。この場合、別のインターフェースに関連付けられているロケーターを選択することにより、マルチホームホストと他のリモートホスト間の通信の失敗を修復できます。
To allow nodes to benefit from the capabilities provided by Shim6, (discussed in Section 5) such as fault tolerance, nodes should be configured to initiate a Shim6 session with any peer node if they have multiple locators to use. Note that this configuration can be performed transparently to the applications, in the sense that applications do not need to be aware of the Shim6 functionality provided by the node; in particular, nodes are not forced to use the Shim6 API [RFC6316] to benefit from Shim6. The Shim6 session should be created after the two nodes have been communicating for some time, i.e., using the deferred context establishment facility provided by Shim6. Otherwise, the cost of the Shim6 4-way handshake used for establishing the session may exceed the benefits provided for short-lived communications (see Section 5.1.2). More advanced node configuration may involve configuring different delays for initiating the session for different applications, for example, based on a per-port configuration. Nodes being able to use a single locator for the communication should not initiate the creation of a Shim6 context, but should participate if another node initiates it. Note that Shim6-aware applications can override this behavior by means of the Shim6 API [RFC6316].
フォールトトレランスなど、ノードがShim6で提供される機能（セクション5で説明）を利用できるようにするには、複数のロケーターを使用するピアノードとのShim6セッションを開始するようにノードを構成する必要があります。この構成は、アプリケーションがノードによって提供されるShim6機能を認識する必要がないという意味で、アプリケーションに対して透過的に実行できることに注意してください。特に、ノードはShim6 API [RFC6316]を使用せずにShim6を利用できます。 Shim6セッションは、2つのノードがしばらくの間、つまりShim6によって提供される遅延コンテキスト確立機能を使用して通信した後に作成する必要があります。それ以外の場合、セッションの確立に使用されるShim6 4ウェイハンドシェイクのコストは、短期間の通信で提供される利点を超える可能性があります（セクション5.1.2を参照）。より高度なノード構成では、たとえば、ポートごとの構成に基づいて、さまざまなアプリケーションのセッションを開始するためにさまざまな遅延を構成する必要があります。通信に単一のロケーターを使用できるノードは、Shim6コンテキストの作成を開始するべきではありませんが、別のノードが開始する場合は参加する必要があります。 Shim6対応のアプリケーションは、Shim6 API [RFC6316]を使用してこの動作をオーバーライドできることに注意してください。
The Shim6 protocol is defined only for IPv6. While some Shim6-like approaches have been suggested to support IPv4 addresses as a locator [SHIM6-ESD], it is not clear if such extensions are feasible.
Shim6プロトコルはIPv6に対してのみ定義されています。ロケーターとしてIPv4アドレスをサポートするためにいくつかのShim6に似たアプローチが提案されていますが[SHIM6-ESD]、そのような拡張が実現可能かどうかは明確ではありません。
The Shim6 protocol, as specified for IPv6, incorporates cryptographic elements in the construction of locators (see [RFC3972] and [RFC5535]). Since IPv4 addresses are insufficiently large to contain addresses constructed in this fashion, direct use of Shim6 with IPv4 addresses is not possible.
IPv6で指定されているShim6プロトコルは、ロケーターの構築に暗号化要素を組み込んでいます（[RFC3972]および[RFC5535]を参照）。 IPv4アドレスは、この方法で構築されたアドレスを含めるには不十分な大きさであるため、IPv4アドレスでShim6を直接使用することはできません。
In addition, there are other factors to take into account when considering the support of IPv4 addresses, in particular, IPv4 locators. Using multiple IPv4 addresses in a single host in order to support the Shim6 style of multihoming would result in an increased IPv4 address consumption, which would be problematic considering that the IPv4 address space has been exhausted. Besides, Shim6 may experience additional problems if locators become translated on the wire. Address translation is more likely to involve IPv4 addresses. IPv4 addresses can be translated to other IPv4 addresses (for example, a private IPv4 address into a public IPv4 address and vice versa) or to/from IPv6 addresses (for example, as defined by NAT64 [RFC6146]). When address translation occurs, a locator exchanged by Shim6 could be different from the address needed to reach the corresponding host, either because the translated version of the locator exchanged by Shim6 is not known or because the translation state no longer exists in the translator device. Besides, the translated locators will not be verifiable with the current Cryptographically Generated Address (CGA) and Hash-Based Address (HBA) verification mechanisms, which protect the locators as seen by the node for which they are configured.
さらに、IPv4アドレスのサポートを検討するときに考慮すべき他の要因、特にIPv4ロケーターがあります。 Shim6スタイルのマルチホーミングをサポートするために単一のホストで複数のIPv4アドレスを使用すると、IPv4アドレスの消費量が増加し、IPv4アドレス空間が使い果たされていることを考えると問題になります。さらに、ロケーターがネットワーク上で変換されると、Shim6で追加の問題が発生する可能性があります。アドレス変換には、IPv4アドレスが含まれる可能性が高くなります。 IPv4アドレスは、他のIPv4アドレス（たとえば、プライベートIPv4アドレスからパブリックIPv4アドレスに、またはその逆）に変換したり、IPv6アドレス（たとえば、NAT64 [RFC6146]で定義）との間で変換できます。アドレス変換が発生すると、Shim6によって交換されたロケーターの変換されたバージョンが不明であるか、変換状態がトランスレーターデバイスに存在しないため、Shim6によって交換されたロケーターは、対応するホストに到達するために必要なアドレスと異なる場合があります。その上、変換されたロケーターは、構成されているノードから見たロケーターを保護する現在の暗号生成アドレス（CGA）およびハッシュベースアドレス（HBA）検証メカニズムでは検証できません。
The Shim6 protocol does not assume that all the prefixes assigned to the multihomed site have the same prefix length.
Shim6プロトコルは、マルチホームサイトに割り当てられたすべてのプレフィックスが同じプレフィックス長であるとは想定していません。
However, the use of CGA [RFC3972] and HBA [RFC5535] involves encoding information in the lower 64 bits of the locators. This imposes the requirement that all interface addresses should be able to accommodate 64-bit interface identifiers on Shim6-capable hosts. Note that this is imposed by RFC 4291 [RFC4291].
ただし、CGA [RFC3972]とHBA [RFC5535]を使用するには、ロケーターの下位64ビットで情報をエンコードする必要があります。これは、すべてのインターフェイスアドレスがShim6対応ホストの64ビットインターフェイス識別子に対応できる必要があるという要件を課します。これはRFC 4291 [RFC4291]によって課されていることに注意してください。
The security of the Shim6 protocol is based on the use of CGA and HBA addresses.
Shim6プロトコルのセキュリティは、CGAおよびHBAアドレスの使用に基づいています。
The CGA and HBA generation process can use the information provided by the stateless auto-configuration mechanism defined in [RFC4862] with the additional considerations presented in [RFC3972] and [RFC5535].
CGAとHBAの生成プロセスは、[RFC4862]で定義されているステートレス自動構成メカニズムによって提供される情報を使用でき、[RFC3972]と[RFC5535]で提示されている追加の考慮事項があります。
Stateful address auto-configuration using DHCP [RFC3315] is not currently supported, because there is no defined mechanism to convey the CGA Parameter Data Structure and other relevant information from the DHCP server to the host. An analysis of the possible interactions between DHCPv6 and CGA can be found in [DHCPv6-CGA].
DHCP [RFC3315]を使用したステートフルアドレス自動構成は現在サポートされていません。これは、CGAパラメータデータ構造とその他の関連情報をDHCPサーバーからホストに伝達するメカニズムが定義されていないためです。 DHCPv6とCGA間の可能な相互作用の分析は、[DHCPv6-CGA]にあります。
The choice between CGA and HBA is a trade-off between flexibility and performance.
CGAとHBAのどちらを選択するかは、柔軟性とパフォーマンスのトレードオフです。
The use of HBA is more efficient in the sense that addresses require less computation than CGA, involving only hash operations for both the generation and the verification of locator sets. However, the locators of an HBA set are determined during the generation process and cannot be subsequently changed; the addition of new locators to that initial set is not supported. Therefore, a node using an HBA as a ULID for a Shim6 session can only use the locators associated to that HBA for the considered Shim6 session. If the node wants to use a new set of locators, it has to generate a new HBA including the prefixes of the new locators (which will result with very high probability in different addresses to those of the previous set). New sessions initiated with a ULID belonging to the new HBA address set could use the new locators.
ロケータセットの生成と検証の両方にハッシュ演算のみが含まれるため、アドレスに必要な計算はCGAよりも少ないという意味で、HBAの使用はより効率的です。ただし、HBAセットのロケーターは生成プロセス中に決定されるため、後で変更することはできません。その初期セットへの新しいロケーターの追加はサポートされていません。したがって、HBAをShim6セッションのULIDとして使用しているノードは、そのHBAに関連付けられているロケーターのみを、対象のShim6セッションに使用できます。ノードが新しいロケーターのセットを使用する場合は、新しいロケーターのプレフィックスを含む新しいHBAを生成する必要があります（これにより、前のセットとは異なるアドレスで非常に高い確率が発生します）。新しいHBAアドレスセットに属するULIDで開始された新しいセッションは、新しいロケーターを使用できます。
The use of CGA is more computationally expensive, involving public-key cryptography in the verification of locator sets. However, CGAs are more flexible in the sense that they support the dynamic modification of locator sets.
CGAを使用すると、計算コストが高くなり、ロケーターセットの検証に公開キー暗号化が含まれます。ただし、CGAはロケーターセットの動的な変更をサポートするという意味で、より柔軟です。
Therefore, CGAs are well suited to support dynamic environments such as mobile hosts, where the locator set must be changed frequently. HBAs are better suited for sites where the prefix set remains relatively stable.
したがって、CGAは、ロケーターセットを頻繁に変更する必要があるモバイルホストなどの動的環境をサポートするのに適しています。 HBAは、プレフィックスセットが比較的安定しているサイトに適しています。
It should be noted that since HBAs are defined as a CGA extension, it is possible to generate an address that incorporates the strengths of both HBA and CGA, i.e., that a single address can be used as an HBA, enabling computationally-cheap validation amongst a fixed set of addresses, and also as a CGA, enabling dynamic manipulation of the locator set. For additional details, see [RFC5535].
HBAはCGA拡張として定義されているため、HBAとCGAの両方の長所を組み込んだアドレスを生成することができます。つまり、単一のアドレスをHBAとして使用できるため、アドレスの固定セット、およびCGAとして、ロケーターセットの動的操作を可能にします。詳細については、[RFC5535]を参照してください。
Shim6 multihomed nodes are likely to experience problems related to the attachment to different provision domains. Note that these problems are not specific to Shim6. [RFC6418] discusses the problems associated with nodes with multiple interfaces, which may involve difficulties in
Shim6マルチホームノードでは、異なるプロビジョニングドメインへの接続に関連する問題が発生する可能性があります。これらの問題はShim6に固有のものではないことに注意してください。 [RFC6418]では、複数のインターフェイスを持つノードに関連する問題について説明しています。
o managing the configuration associated with different providers.
o さまざまなプロバイダーに関連付けられた構成の管理。
o finding the appropriate DNS server to resolve a query and to match DNS answers to providers.
o クエリを解決し、プロバイダーへのDNS回答を照合するための適切なDNSサーバーを見つける。
o routing the packets to the right provider.
o パケットを適切なプロバイダーにルーティングする。
o selecting the source address appropriate to the destination and to the outgoing provider.
o 宛先と発信プロバイダーに適切な発信元アドレスを選択します。
o performing session management appropriately.
o セッション管理を適切に実行する。
Some of these problems may also arise in single-interface hosts connected to multiple networks, for example, in configurations in which a customer network receives multiple Provider Aggregatable prefixes. These problems are relevant to other solutions supporting multihoming, such as Stream Control Transmission Protocol (SCTP) [RFC4960], Multipath TCP (MPTCP) [RFC6182], or Host Identity Protocol (HIP) [RFC4423]. Note also that single-homed nodes implementing Shim6 to improve communications with other nodes having multiple addresses will not experience these problems.
これらの問題の一部は、たとえば、顧客ネットワークが複数のプロバイダー集約可能プレフィックスを受信する構成など、複数のネットワークに接続されている単一インターフェースホストでも発生する可能性があります。これらの問題は、Stream Control Transmission Protocol（SCTP）[RFC4960]、Multipath TCP（MPTCP）[RFC6182]、Host Identity Protocol（HIP）[RFC4423]など、マルチホーミングをサポートする他のソリューションに関連しています。また、複数のアドレスを持つ他のノードとの通信を改善するためにShim6を実装するシングルホームノードでは、これらの問題は発生しません。
The compatibility of Shim6 with configurations or mechanisms developed to solve any multihoming problem has to be carefully considered on a case-by-case basis. However, the interaction of Shim6 with some of the solutions discussed in [IPv6NAT] is commented on in the next paragraphs.
Shim6とマルチホーミング問題を解決するために開発された構成またはメカニズムとの互換性は、ケースバイケースで慎重に検討する必要があります。ただし、[IPv6NAT]で説明されているソリューションの一部とShim6の相互作用については、次の段落でコメントされています。
In order to configure source and destination address selection, tools such as DHCPv6 can be used to disseminate an [RFC3484] policy table to a host [6MAN]. The impact to Shim6 using this solution, which disseminates the policy table to the hosts, is the following: Shim6 selects the ULID pair to use in communication according to the mechanism described in [RFC3484]. In case different locator pairs need to be explored, nodes also use the rules defined by [RFC3484] to identify valid pairs, and to establish an order among them, as described in [RFC5534].
送信元および宛先アドレスの選択を構成するために、DHCPv6などのツールを使用して、[RFC3484]ポリシーテーブルをホスト[6MAN]に配布できます。ホストにポリシーテーブルを配布するこのソリューションを使用したShim6への影響は次のとおりです。Shim6は、[RFC3484]で説明されているメカニズムに従って、通信で使用するULIDペアを選択します。 [RFC5534]で説明されているように、異なるロケーターペアを探索する必要がある場合、ノードは[RFC3484]で定義されたルールを使用して有効なペアを識別し、ペア間の順序を確立します。
When a locator has been selected by a host to be used as the source address for a Shim6 session, Shim6 has no means to enforce an appropriate path for that source address in either the host or the network. For IPv6 nodes, the next-hop router to use for a given set of destinations can be configured through Extensions to Router Advertisements, through Default Router Preference and More-Specific Routes [RFC4191], the use of a DHCPv6 option, or the use of a routing protocol. It is also possible to rely on routers that consider source addresses in their forwarding decisions in addition to the usual destination-based forwarding. All these solutions are compatible with Shim6 operation. Note that an improper matching of source address and egress provider may result in packets being dropped if the provider performs ingress filtering [RFC2827], i.e., dropping packets that come from customer networks with source addresses not belonging to the prefix assigned to them to prevent address spoofing.
ホストによってロケーターがShim6セッションの送信元アドレスとして使用されるように選択されている場合、Shim6はホストまたはネットワークのいずれかでその送信元アドレスに適切なパスを強制する手段がありません。 IPv6ノードの場合、特定の宛先セットに使用するネクストホップルーターは、ルーターアドバタイズの拡張、デフォルトルーター設定とより具体的なルート[RFC4191]、DHCPv6オプションの使用、またはルーティングプロトコル。通常の宛先ベースの転送に加えて、転送の決定において送信元アドレスを考慮するルーターに依存することも可能です。これらのソリューションはすべて、Shim6の動作と互換性があります。ソースアドレスと出力プロバイダーの不適切なマッチングにより、プロバイダーが入力フィルタリング[RFC2827]を実行すると、パケットがドロップされる可能性があることに注意してください。つまり、アドレスを防ぐために割り当てられたプレフィックスに属さないソースアドレスを持つカスタマーネットワークからのパケットをドロップします。なりすまし。
For some particular configurations, i.e., for a walled-garden or closed service, the node may need to identify the most appropriate DNS server to resolve a particular query. For an analysis of this problem, the reader is referred to [IPv6NAT].
一部の特定の構成、つまりウォールドガーデンまたはクローズドサービスの場合、ノードは特定のクエリを解決するために最も適切なDNSサーバーを識別する必要がある場合があります。この問題の分析については、[IPv6NAT]を参照してください。
Finally, note that Shim6 is built to handle communication problems, so it may recover from the misconfiguration (or lack) of some of the mechanisms used to handle the aforementioned problems. For example, if any notification is received from the router dropping the packets with legitimate source addresses as a result of ingress filtering, the affected locator could be associated with a low preference (or not be used at all). But even if such a notification is not received, or not processed by the Shim6 layer, the defective source address or next-hop selection will be treated as a communication failure. Therefore, Shim6 re-homing could finally select a working path in which packets are not filtered, if this path exists. This behavior results from the powerful end-to-end resilience properties exhibited by the REAchability Protocol (REAP) [RFC5534].
最後に、Shim6は通信の問題を処理するために構築されているため、前述の問題を処理するために使用されるメカニズムの一部の構成ミス（または欠落）から回復する場合があることに注意してください。たとえば、入力フィルタリングの結果として、正当な送信元アドレスを持つパケットをドロップする通知がルーターから受信された場合、影響を受けるロケーターは優先度が低い（またはまったく使用されていない）可能性があります。ただし、そのような通知が受信されない場合や、Shim6レイヤーで処理されない場合でも、欠陥のある送信元アドレスまたはネクストホップの選択は通信障害として扱われます。したがって、Shim6リホーミングは、このパスが存在する場合、パケットがフィルタリングされない実際のパスを最終的に選択できます。この動作は、REAchability Protocol（REAP）[RFC5534]によって示される強力なエンドツーエンドの復元力プロパティに起因します。
If a host within a multihomed site attempts to establish a communication with a remote host and selects a locator that corresponds to a failed transit path, bidirectional communication between the two hosts will not succeed. In order to establish a new communication, the initiating host must try different combinations of (source, destination) locator pairs until it finds a pair that works. The mechanism for this default address selection is described in [RFC3484]. As a result of the use of this mechanism, some failures may not be recovered, even if a valid alternative path exists between two communicating hosts. For example, assuming a failure in ISP[1] (see Figure 1), and host H initiating a communication with host R, the source address selection algorithm described in [RFC3484] may result in the selection of the source address corresponding to ISP[1] for every destination address being tried by the application. However, note that if R is the node initiating the communication, it will find a valid path provided that the application at R tries every available address for H.
マルチホームサイト内のホストがリモートホストとの通信を確立しようとして、障害が発生したトランジットパスに対応するロケーターを選択した場合、2つのホスト間の双方向通信は成功しません。新しい通信を確立するために、開始ホストは、機能するペアが見つかるまで、（ソース、宛先）ロケーターペアのさまざまな組み合わせを試行する必要があります。このデフォルトのアドレス選択のメカニズムは、[RFC3484]で説明されています。このメカニズムを使用した結果、通信している2つのホスト間に有効な代替パスが存在する場合でも、一部の障害が回復されないことがあります。たとえば、ISP [1]（図1を参照）で障害が発生し、ホストHがホストRとの通信を開始すると、[RFC3484]で説明されているソースアドレス選択アルゴリズムにより、ISP [に対応するソースアドレスが選択される可能性があります。 1]アプリケーションによって試行されているすべての宛先アドレス。ただし、Rが通信を開始するノードである場合、RのアプリケーションがHの使用可能なすべてのアドレスを試行する場合、有効なパスを見つけることに注意してください。
Since a Shim6 context is normally established between two hosts only after initial communication has been set up, there is no opportunity for Shim6 to participate in the discovery of a suitable, initial (source, destination) locator pair. The same consideration holds for referrals, as described in Section 6.
Shim6コンテキストは通常、最初の通信がセットアップされた後にのみ2つのホスト間で確立されるため、Shim6が適切な初期（ソース、宛先）ロケーターペアの検出に参加する機会はありません。セクション6で説明されているように、同じ考慮事項が紹介にも当てはまります。
The Shim6 context establishment operation requires a 4-way packet exchange, and involves some overhead on the participating hosts in memory and CPU.
Shim6コンテキストの確立操作には、4方向のパケット交換が必要であり、メモリとCPUで参加しているホストにオーバーヘッドがかかります。
For short-lived communications between two hosts, the benefit of establishing a Shim6 context might not exceed the cost, perhaps because the protocols concerned are fault tolerant and can arrange their own recovery (e.g., DNS) or because the frequency of re-homing events is sufficiently low that the probability of such a failure occurring during a short-lived exchange is not considered significant.
2つのホスト間の短期間の通信の場合、おそらく関連するプロトコルがフォールトトレラントであり、独自の回復（DNSなど）を調整できるため、またはリホーミングイベントの頻度が原因で、Shim6コンテキストを確立するメリットがコストを超えない場合があります。短期間の交換中に発生するこのような障害の確率が重要であると見なされないほど十分に低い。
It is anticipated that the exchange of Shim6 context will provide the most benefit for exchanges between hosts that are long-lived. For this reason, the default behavior of Shim6-capable hosts is expected to employ deferred context-establishment. Deferred context setup ensures that session-establishment time will not be increased by the use of Shim6. This default behavior can be overridden by applications that prefer immediate context establishment, regardless of transaction longevity, by using [RFC6316].
Shim6コンテキストの交換は、長寿命のホスト間の交換に最大の利点を提供すると予想されます。このため、Shim6対応ホストのデフォルトの動作では、遅延コンテキスト確立が使用されると予想されます。遅延コンテキストセットアップにより、Shim6を使用してもセッション確立時間が長くならないことが保証されます。このデフォルトの動作は、[RFC6316]を使用することにより、トランザクションの寿命に関係なく、即時のコンテキスト確立を優先するアプリケーションによってオーバーライドできます。
Note that all the above considerations refer to the lifetime of the interaction between the peers, and not the lifetime of a particular connection (e.g., TCP connection). In other words, the Shim6 context is established between ULID pairs and it affects all the communication between these ULIDs. So, two nodes with multiple short-lived communications using the same ULID pair would benefit as much from the Shim6 features as two nodes having a single long-lived communication. One example of such a scenario would be a web-client software downloading web content from a server over multiple TCP connections. Each TCP connection is short-lived, but the communication/contact between the two ULID could be long-lived.
上記のすべての考慮事項は、ピア間の相互作用の存続期間を指し、特定の接続（TCP接続など）の存続期間ではないことに注意してください。つまり、Shim6コンテキストはULIDペア間で確立され、これらのULID間のすべての通信に影響します。したがって、同じULIDペアを使用して複数の短命の通信を行う2つのノードは、2つのノードが長命の通信を1つ持つのと同じくらい、Shim6機能の恩恵を受けます。そのようなシナリオの1つの例は、複数のTCP接続を介してサーバーからWebコンテンツをダウンロードするWebクライアントソフトウェアです。各TCP接続は短命ですが、2つのULID間の通信/連絡は長持ちする可能性があります。
The Shim6 protocol does not support load balancing within a single context: all packets associated with a particular context are exchanged using a single locator pair per direction, with the exception of forked contexts, which are created upon explicit requests from the upper-layer protocol.
Shim6プロトコルは、単一のコンテキスト内でのロードバランシングをサポートしていません。特定のコンテキストに関連付けられたすべてのパケットは、上位層プロトコルからの明示的な要求に基づいて作成されるフォークされたコンテキストを除き、方向ごとに単一のロケーターペアを使用して交換されます。
It may be possible to extend the Shim6 protocol to use multiple locator pairs in a single context, but the impact of such an extension on upper-layer protocols (e.g., on TCP congestion control) should be considered carefully.
Shim6プロトコルを拡張して、単一のコンテキストで複数のロケーターペアを使用することは可能ですが、そのような拡張が上位層プロトコル（TCP輻輳制御など）に与える影響は慎重に検討する必要があります。
When many contexts are considered together in aggregation, e.g., on a single host that participates in many simultaneous contexts or in a site full of hosts, some degree of load sharing should occur naturally due to the selection of different locator pairs in each context. However, there is no mechanism defined to ensure that this natural load sharing is arranged to provide a statistical balance between transit providers.
たとえば、多くの同時コンテキストに参加する単一のホストや、ホストでいっぱいのサイトなど、多くのコンテキストがまとめて考慮される場合、各コンテキストで異なるロケーターペアを選択するため、ある程度の負荷分散が自然に発生するはずです。ただし、この自然な負荷分散がトランジットプロバイダー間の統計的なバランスを提供するように調整されていることを保証するメカニズムは定義されていません。
Note that the use of transport-layer solutions enhanced with mechanisms to allow the use of multiple paths for a transport session are more amenable for achieving load-balancing. One such solution is MPTCP [RFC6182].
トランスポートセッションで複数のパスを使用できるようにするメカニズムで強化されたトランスポートレイヤーソリューションの使用は、ロードバランシングを実現するのに適しています。そのような解決策の1つはMPTCP [RFC6182]です。
For sites with prefixes obtained from different providers, the paths followed by inbound and outbound traffic are determined to a large extent by the locators selected for each communication. This is not a particular issue of Shim6, but it is common to any deployment in which hosts are configured with addresses received from different providers. Traffic engineering in such sites will likely involve proper configuration of the address selection policies defined by [RFC3484].
異なるプロバイダーから取得したプレフィックスを持つサイトの場合、インバウンドおよびアウトバウンドトラフィックがたどるパスは、各通信用に選択されたロケーターによって大幅に決定されます。これはShim6の特定の問題ではありませんが、ホストがさまざまなプロバイダーから受信したアドレスで構成されているすべての展開に共通です。このようなサイトのトラフィックエンジニアリングには、[RFC3484]で定義されているアドレス選択ポリシーの適切な構成が含まれる可能性があります。
The Shim6 protocol provides some lightweight traffic engineering capabilities in the form of the Locator Preferences option, which allows a host to inform a remote host of local preferences for locator selection. In this way, the host can influence the incoming path for the communication. This mechanism is only available after a Shim6 context has been established, and it is a host-based capability rather than a site-based capability. There is no defined mechanism that would allow use of the Locator Preferences option amongst a site full of hosts to be managed centrally by the administrator of the site.
Shim6プロトコルは、ロケーター設定オプションの形式で軽量のトラフィックエンジニアリング機能を提供します。これにより、ホストはロケーター選択のローカル設定をリモートホストに通知できます。このようにして、ホストは通信の着信パスに影響を与えることができます。このメカニズムは、Shim6コンテキストが確立された後でのみ使用でき、サイトベースの機能ではなく、ホストベースの機能です。ホストで一杯のサイト間でLocator Preferencesオプションを使用して、サイトの管理者が集中管理できるようにするメカニズムは定義されていません。
Shim6 provides multihoming support without forcing changes in the applications running on the host. The fact that an address has been generated according to the CGA or HBA specification does not require any specific action from the application, e.g., it can obtain remote CGA or HBA addresses as a result of a getaddrinfo() call to trigger a DNS Request. The storage of CGA or HBA addresses in DNS does not require any modification to this protocol, since they are recorded using AAAA records. Moreover, neither the ULID/locator management [RFC5533] nor the failure detection and recovery [RFC5534] functions require application awareness.
Shim6は、ホストで実行されているアプリケーションを強制的に変更せずにマルチホーミングをサポートします。アドレスがCGAまたはHBA仕様に従って生成されているという事実は、アプリケーションからの特定のアクションを必要としません。たとえば、getaddrinfo()呼び出しの結果としてリモートCGAまたはHBAアドレスを取得して、DNS要求をトリガーできます。 DNSでのCGAまたはHBAアドレスの格納は、AAAAレコードを使用して記録されるため、このプロトコルを変更する必要はありません。さらに、ULID /ロケーター管理[RFC5533]も障害検出および回復[RFC5534]機能も、アプリケーションの認識を必要としません。
However, a specific API [RFC6316] has been developed for those applications that might require additional capabilities in ULID/ locator management, such as the locator pair in use for a given context, or the set of local or remote locators available for it. This API can also be used to disable Shim6 operation when required.
ただし、特定のAPI [RFC6316]は、特定のコンテキストで使用されているロケーターペアや、それに使用できるローカルまたはリモートロケーターのセットなど、ULID /ロケーター管理で追加機能を必要とする可能性があるアプリケーション用に開発されました。このAPIは、必要に応じてShim6操作を無効にするためにも使用できます。
It is worth noting that callbacks can benefit naturally from Shim6 support. In a callback, an application in B retrieves IP_A, the IP address of a peer A, and B uses IP_A to establish a new communication with A. As long as the address exchanged, IP_A, is the ULID for the initial communication between A and B, and B uses the same address as in the initial communication, and this initial communication is alive (or the context has not been deleted), the new communication could use the locators exchanged by Shim6 for the first communication. In this case, communication could proceed even if the ULID of A is not reachable.
コールバックがShim6サポートから自然に恩恵を受けることができることは注目に値します。コールバックでは、BのアプリケーションがピアAのIPアドレスであるIP_Aを取得し、BはIP_Aを使用してAとの新しい通信を確立します。交換されたアドレスIP_AがAとAの間の初期通信のULIDである限りB、およびBは最初の通信と同じアドレスを使用し、この最初の通信は有効である（またはコンテキストが削除されていない）場合、新しい通信はShim6によって交換されたロケーターを最初の通信に使用できます。この場合、AのULIDに到達できない場合でも、通信は続行できます。
However, Shim6 does not provide specific protection to current applications when they use referrals. A referral is the exchange of the IP address IP_A of a party A by party B to party C, so that party C could use IP_A to communicate with party A. In a normal case, the ULID IP_A would be the only information sent by B to C as a referral. But if IP_A is no longer valid as the locator in A, C could have trouble establishing a communication with A. Increased failure protection for referrals could be obtained if B exchanged the whole list of alternative locators of A; although, in this case the application protocol should be modified. Note that B could send to C the current locator of A, instead of the ULID of A, as a way of using the most recent reachability information about A. While in this case no modification of the application protocol is required, some concerns arise: host A may not accept one of its locators as ULID for initiating a communication, and if a CGA are used, the locator may not be a CGA so a Shim6 context among A and C could not be created.
ただし、Shim6は、現在のアプリケーションが紹介を使用する場合、特定の保護を提供しません。紹介とは、パーティーAのIPアドレスIP_AをパーティーBからパーティーCに交換することです。これにより、パーティーCはIP_Aを使用してパーティーAと通信できます。通常の場合、ULID IP_AがBから送信される唯一の情報になります。紹介としてCに。ただし、IP_AがAのロケーターとして有効でなくなった場合、CはAとの通信を確立するときに問題が発生する可能性があります。ただし、この場合、アプリケーションプロトコルを変更する必要があります。 BがAの最新の到達可能性情報を使用する方法として、AのULIDではなく、Aの現在のロケーターをCに送信できることに注意してください。この場合、アプリケーションプロトコルの変更は必要ありませんが、いくつかの懸念が生じます。ホストAは、ロケーターの1つを通信を開始するためのULIDとして受け入れない場合があり、CGAが使用されている場合、ロケーターがCGAでない可能性があるため、AとCの間のShim6コンテキストを作成できませんでした。
In this section we discuss the interaction between Shim6 and other protocols and mechanisms. Before starting the discussion, it is worth noting that at the time of this writing, there is a lack of experience with the combination of Shim6 and these protocols and mechanisms. Therefore, the conclusions stated should be reviewed as real experience is gained in the use of Shim6.
このセクションでは、Shim6と他のプロトコルおよびメカニズムとの相互作用について説明します。議論を始める前に、この記事の執筆時点では、Shim6とこれらのプロトコルおよびメカニズムの組み合わせに関する経験が不足していることに注意してください。したがって、Shim6の使用で実際の経験が得られるので、述べられた結論を確認する必要があります。
Here, we consider some scenarios in which the Shim6 protocol and the Mobile IPv6 (MIPv6) protocol [RFC6275] might be used simultaneously.
ここでは、Shim6プロトコルとモバイルIPv6（MIPv6）プロトコル[RFC6275]が同時に使用される可能性があるいくつかのシナリオを検討します。
In this case, the Home Network of the Mobile Node (MN) is multihomed. This implies the availability of multiple Home Network prefixes, resulting in multiple Home Addresses (HoAs) for each MN. Since the MN is a node within a multihomed site, it seems reasonable to expect that the MN should be able to benefit from the multihoming capabilities provided by the Shim6 protocol. Moreover, the MN needs to be able to obtain the multihoming benefits, even when it is roaming away from the Home Network: if the MN is away from the Home Network while the Home Network suffers a failure in a transit path, the MN should be able to continue communicating using alternate paths to reach the Home Network.
この場合、モバイルノード（MN）のホームネットワークはマルチホームです。これは、複数のホームネットワークプレフィックスが利用できることを意味し、各MNに複数のホームアドレス（HoA）が生成されます。 MNはマルチホームサイト内のノードであるため、MNがShim6プロトコルによって提供されるマルチホーミング機能の恩恵を受けることができると期待するのは理にかなっているようです。さらに、MNがホームネットワークから離れてローミングしている場合でも、MNはマルチホーミングのメリットを得ることができる必要があります。MNがホームネットワークから離れている場合、MNはトランジットパスで障害が発生すると、MNはホームネットワークに到達するための代替パスを使用して通信を継続できます。
The resulting scenario is the following:
結果のシナリオは次のとおりです。
+------------------------------------+
| Internet |
+------------------------------------+
| |
+----+ +----+
|ISP1| |ISP2|
+----+ +----+
| |
+------------------------------------+
| Multihomed Home Network |
| Prefixes: P1 and P2 |
| |
| Home Agent |
| // |
+------------------//----------------+
//
//
+-----+
| MN | HoA1, HoA2
+-----+
Figure 2
図2
So, in this configuration, the Shim6 protocol is used to provide multiple communication paths to all the nodes within the multihomed sites (including the mobile nodes), and the MIPv6 protocol is used to support mobility of the multihomed site's mobile nodes.
したがって、この構成では、Shim6プロトコルを使用してマルチホームサイト（モバイルノードを含む）内のすべてのノードに複数の通信パスを提供し、MIPv6プロトコルを使用してマルチホームサイトのモバイルノードのモビリティをサポートします。
The proposed protocol architecture would be the following:
提案されるプロトコルアーキテクチャは次のようになります。
+--------------+
| Application |
+--------------+
| Transport |
+--------------+
| IP |
| +----------+ |
| | IPSec | |
| +----------+<--ULIDs
| | Shim6 | |
| +----------+<--HoAs
| | MIPv6 | |
| +----------+<--CoAs
| |
+--------------+
Figure 3
In this architecture, the upper-layer protocols and IPSec would use ULIDs of the Shim6 protocol (see Section 16.1 in [RFC5533] for more detail on the interaction between Shim6 and IPsec). Only the HoAs will be presented by the upper layers to the Shim6 layer as potential ULIDs. Two Shim6 entities will exchange their own available HoAs as locators. Therefore, Shim6 provides failover between different HoAs and allows preservation of established communications when an outage affects the path through the ISP that has delegated the HoA used for initiating the communication (similar to the case of a host within a multihomed site). The Care-of Addresses (CoAs) are not presented to the Shim6 layer and are not included in the local locator set in this case. The CoAs are managed by the MIPv6 layer, which binds each HoA to a CoA. For example, if a single CoA, CoA1, is available for the MN in the foreign link to which it is attached, every HoA should have a bind to CoA1.
このアーキテクチャでは、上位層プロトコルとIPSecはShim6プロトコルのULIDを使用します（Shim6とIPsec間の相互作用の詳細については、[RFC5533]のセクション16.1を参照してください）。上位層からShim6層に、ULAの候補としてHoAのみが提示されます。 2つのShim6エンティティが、使用可能な独自のHoAをロケーターとして交換します。したがって、Shim6は異なるHoA間のフェイルオーバーを提供し、停止が通信の開始に使用されるHoAを委任したISPを介したパスに影響する場合に確立された通信を維持できるようにします（マルチホームサイト内のホストの場合と同様）。気付アドレス（CoA）はShim6レイヤーに提示されず、この場合、ローカルロケーターセットには含まれません。 CoAは、各HoAをCoAにバインドするMIPv6レイヤーによって管理されます。たとえば、接続されている外部リンクのMNで単一のCoA、CoA1が使用可能な場合、すべてのHoAにCoA1へのバインドが必要です。
So, in this case, the upper-layer protocols select a ULID pair for the communication. The Shim6 protocol translates the ULID pair to an alternative locator in case that is needed. Both the ULIDs and the alternative locators are HoAs. Next, the MIPv6 layer maps the selected HoA to the corresponding CoA, which is the actual address included in the wire.
したがって、この場合、上位層プロトコルは通信用にULIDペアを選択します。 Shim6プロトコルは、必要に応じてULIDペアを代替ロケーターに変換します。 ULIDと代替ロケーターはどちらもHoAです。次に、MIPv6レイヤーは、選択されたHoAを対応するCoAにマップします。これは、ワイヤーに含まれる実際のアドレスです。
The Shim6 context is established between the MN and the Correspondent Node (CN), and it would allow the communication to use all the available HoAs to provide fault tolerance. The MIPv6 protocol is used between the MN and the Home Agent (HA) in the case of the bidirectional tunnel mode, and between the MN and the CN in case of the Route Optimization (RO) mode.
Shim6コンテキストはMNとコレスポンデントノード（CN）の間に確立され、通信はすべての利用可能なHoAを使用してフォールトトレランスを提供できます。 MIPv6プロトコルは、双方向トンネルモードの場合はMNとホームエージェント（HA）の間で使用され、ルート最適化（RO）モードの場合はMNとCNの間で使用されます。
Another scenario where a Shim6-MIPv6 interaction may be useful is the case where a Shim6 context is established between the MN and the HA in order to provide fault tolerance capabilities to the bidirectional tunnel between them.
Shim6-MIPv6相互作用が役立つ別のシナリオとして、MNとHAの間の双方向トンネルにフォールトトレランス機能を提供するために、MNとHAの間にShim6コンテキストが確立される場合があります。
Consider the case where the HA has multiple addresses (whether because the Home Network is multihomed or because the HA has multiple interfaces) and/or the MN has multiple addresses (whether because the visited network is multihomed or because the MN has multiple interfaces). In this case, if a failure affects the address pair that is being used to run the tunnel between the MN and HA, additional mechanisms need to be used to preserve the communication.
HAに複数のアドレスがある場合（ホームネットワークがマルチホームであるか、HAに複数のインターフェイスがあるため）および/またはMNに複数のアドレスがある場合（訪問したネットワークがマルチホームであるか、MNに複数のインターフェイスがあるため）。この場合、障害がMNとHA間のトンネルを実行するために使用されているアドレスペアに影響を与える場合、通信を維持するために追加のメカニズムを使用する必要があります。
One possibility would be to use MIPv6 capabilities, by simply changing the CoA used as the tunnel endpoint. However, MIPv6 lacks the failure detection mechanisms that would allow the MN and/or the HA to detect the failure and trigger the usage of an alternative address. Shim6 provides such a failure detection protocol, so one possibility would be re-using the failure detection function from the Shim6 failure detection protocol in MIPv6. In this case, the Shim6 protocol wouldn't be used to create Shim6 context and provide fault tolerance, but just its failure detection functionality would be re-used.
1つの可能性は、トンネルエンドポイントとして使用されるCoAを変更するだけで、MIPv6機能を使用することです。ただし、MIPv6には、MNおよび/またはHAが障害を検出して代替アドレスの使用をトリガーできる障害検出メカニズムがありません。 Shim6はこのような障害検出プロトコルを提供しているため、MIPv6のShim6障害検出プロトコルの障害検出機能を再利用する可能性があります。この場合、Shim6プロトコルを使用してShim6コンテキストを作成し、フォールトトレランスを提供するのではなく、障害検出機能だけを再利用します。
The other possibility would be to use the Shim6 protocol to create a Shim6 context between the HA and the MN, so that the Shim6 detects any failure and re-homes the communication in a transparent fashion to MIPv6. In this case, the Shim6 protocol would be associated with the tunnel interface.
他の可能性としては、Shim6プロトコルを使用してHAとMNの間にShim6コンテキストを作成し、Shim6が障害を検出して、MIPv6に対して透過的な方法で通信のホームを変更する方法があります。この場合、Shim6プロトコルはトンネルインターフェイスに関連付けられます。
Secure Neighbor Discovery (SEND) [RFC3971] uses CGAs to prove address ownership for Neighbor Discovery [RFC4861]. The Shim6 protocol can use either CGAs or HBAs to protect locator sets included in Shim6 contexts. It is expected that some hosts will need to participate in both SEND and Shim6 simultaneously.
Secure Neighbor Discovery（SEND）[RFC3971]は、CGAを使用してNeighbor Discovery [RFC4861]のアドレス所有権を証明します。 Shim6プロトコルは、CGAまたはHBAのいずれかを使用して、Shim6コンテキストに含まれるロケーターセットを保護できます。一部のホストは、SENDとShim6の両方に同時に参加する必要があると予想されます。
In the case that both the SEND and Shim6 protocols are using the CGA technique to generate addresses, there is no conflict; the host will generate addresses for both purposes as CGAs, and since it will be in control of the associated private key, the same CGA can be used for the different protocols.
SENDプロトコルとShim6プロトコルの両方がCGA手法を使用してアドレスを生成している場合、競合はありません。ホストはCGAとして両方の目的でアドレスを生成し、関連付けられた秘密鍵を制御するため、異なるプロトコルに同じCGAを使用できます。
In the case that a Shim6-capable host is using HBAs to protect its locator sets, the host will need to generate an address that is both a valid CGA and a valid HBA, as defined in [RFC5535]. In this case, the CGA Parameter Data Structure containing a valid public key and the Multi-Prefix extension are included as inputs to the hash function.
Shim6対応ホストがロケーターセットを保護するためにHBAを使用している場合、[RFC5535]で定義されているように、ホストは有効なCGAと有効なHBAの両方であるアドレスを生成する必要があります。この場合、有効な公開鍵とマルチプレフィックス拡張を含むCGAパラメータデータ構造は、ハッシュ関数への入力として含まれます。
Both the SCTP [RFC4960] and MPTCP [RFC6182] protocols provide a reliable, stream-based communications channel between two hosts that provides a superset of the capabilities of TCP. One notable feature of these two protocols is that they allow the exchange of endpoint addresses between hosts in order to recover from the failure of a particular endpoint pair, or to benefit from multipath communication in the MPTCP case, in a manner that is conceptually similar to locator selection in Shim6.
SCTP [RFC4960]とMPTCP [RFC6182]の両方のプロトコルは、TCPの機能のスーパーセットを提供する2つのホスト間に信頼性の高い、ストリームベースの通信チャネルを提供します。これらの2つのプロトコルの注目すべき機能の1つは、特定のエンドポイントペアの障害から回復するため、またはMPTCPの場合のマルチパス通信から利益を得るために、ホスト間でエンドポイントアドレスを交換できることです。 Shim6でのロケーターの選択。
SCTP and MPTCP are transport-layer protocols, higher in the protocol stack than Shim6; hence, there is no fundamental incompatibility that would prevent a Shim6-capable host from communicating using SCTP or MPTCP.
SCTPとMPTCPはトランスポート層プロトコルであり、Shim6よりもプロトコルスタックの上位にあります。したがって、Shim6対応ホストがSCTPまたはMPTCPを使用して通信することを妨げる基本的な非互換性はありません。
However, since either SCTP or MPTCP, and Shim6 aim to exchange addressing information between hosts in order to meet the same generic goal, it is possible that their simultaneous use might result in unexpected behavior, e.g., lead to race conditions.
ただし、SCTPまたはMPTCPのいずれか、およびShim6は同じ一般的な目標を達成するためにホスト間でアドレス情報を交換することを目的としているため、それらを同時に使用すると予期しない動作が発生する可能性があります。
The capabilities of these transport protocols with respect to path maintenance of a reliable, connection-oriented stream protocol are more extensive than the more general layer-3 locator agility provided by Shim6. Therefore, it is recommended that Shim6 not be used for SCTP or MPTCP sessions, and that path maintenance be provided solely by SCTP or MPTCP. There are at least two ways to enforce this behavior. One option is to make the stack, and in particular the Shim6 sublayer, aware of the use of SCTP or MPTCP, and in this case refrain from creating a Shim6 context. The other option is that the upper transport layer indicates, using a Shim6-capable API like the one proposed in [RFC6316], that no Shim6 context must be created for this particular communication.
信頼性の高い接続指向のストリームプロトコルのパスメンテナンスに関するこれらのトランスポートプロトコルの機能は、Shim6が提供するより一般的なレイヤー3ロケーターの俊敏性よりも広範囲です。したがって、Shim6をSCTPまたはMPTCPセッションに使用しないこと、およびパスのメンテナンスをSCTPまたはMPTCPのみで提供することをお勧めします。この動作を強制するには、少なくとも2つの方法があります。 1つのオプションは、スタック、特にShim6サブレイヤーにSCTPまたはMPTCPの使用を認識させることです。この場合、Shim6コンテキストの作成を控えます。もう1つのオプションは、[RFC6316]で提案されているようなShim6対応APIを使用して、この特定の通信用にShim6コンテキストを作成する必要がないことを上位トランスポート層が示すことです。
In general, the issues described here may also arise for protocols that handle different addresses for two communicating nodes at a higher level than the network layer to improve reliability, performance, congestion control, etc.
一般に、ここで説明する問題は、信頼性、パフォーマンス、輻輳制御などを改善するために、ネットワーク層よりも高いレベルで2つの通信ノードの異なるアドレスを処理するプロトコルでも発生する可能性があります。
The Network Mobility (NEMO) [RFC3963] protocol extensions to MIPv6 allow a Mobile Network to communicate through a bidirectional tunnel via a Mobile Router (MR) to a NEMO-compliant HA located in a Home Network.
MIPv6のネットワークモビリティ（NEMO）[RFC3963]プロトコル拡張により、モバイルネットワークは、モバイルルーター（MR）を介した双方向トンネルを通じて、ホームネットワークにあるNEMO準拠のHAと通信できます。
If either or both the MR or HA are multihomed, then an established Shim6 context preserves the integrity of the bidirectional tunnel between them in the event that a transit failure occurs in the connecting path.
MRまたはHAのいずれかまたは両方がマルチホームである場合、確立されたShim6コンテキストは、接続パスで転送エラーが発生した場合に、それらの間の双方向トンネルの整合性を維持します。
Once the tunnel between MR and HA is established, hosts within the Mobile Network that are Shim6-capable can establish contexts with remote hosts in order to receive the same multihoming benefits as any host located within the Home Network.
MRとHAの間のトンネルが確立されると、Shim6対応のモバイルネットワーク内のホストは、リモートホストとのコンテキストを確立して、ホームネットワーク内にあるホストと同じマルチホーミングのメリットを享受できます。
Shim6 and HIP [RFC4423] are architecturally similar in the sense that both solutions allow two hosts to use different locators to support communications between stable ULIDs. The signaling exchange to establish the demultiplexing context on the hosts is very similar for both protocols. However, there are a few key differences. First, Shim6 avoids defining a new namespace for ULIDs, preferring instead to use a routable locator as a ULID, while HIP uses public keys and hashes thereof as ULIDs. The use of a routable locator as the ULID better supports deferred context establishment, application callbacks, and application referrals, and avoids management and resolution costs of a new namespace, but requires additional security mechanisms to securely bind the ULID with the locators. Second, Shim6 uses an explicit context header on data packets for which the ULIDs differ from the locators in use (this header is only needed after a failure/re-homing event occurs), while HIP may compress this context-tag function into the Encapsulating Security Payload (ESP) Security Parameter Index (SPI) field [RFC5201]. Third, HIP as presently defined requires the use of public-key operations in its signaling exchange and ESP encryption in the data plane, while the use of Shim6 requires neither (if only HBA addresses are used). By default, HIP provides data protection, while this is a non-goal for Shim6.
Shim6とHIP [RFC4423]は、両方のソリューションで2つのホストが異なるロケーターを使用して安定したULID間の通信をサポートできるという意味で、アーキテクチャが似ています。ホスト上で逆多重化コンテキストを確立するためのシグナリング交換は、両方のプロトコルで非常によく似ています。ただし、いくつかの重要な違いがあります。まず、Shim6はULIDの新しい名前空間の定義を回避し、代わりにルーティング可能なロケーターをULIDとして使用することを好む一方、HIPは公開キーとそのハッシュをULIDとして使用します。 ULIDとしてルーティング可能なロケーターを使用すると、遅延コンテキストの確立、アプリケーションのコールバック、アプリケーションの参照をより適切にサポートし、新しい名前空間の管理と解決のコストを回避できますが、ULIDをロケーターに安全にバインドするには、追加のセキュリティメカニズムが必要です。 2つ目は、Himがこのコンテキストタグ機能をカプセル化に圧縮する一方で、Shim6は、ULIDが使用中のロケーターとは異なるデータパケットで明示的なコンテキストヘッダーを使用します（このヘッダーは、障害/リホーミングイベントが発生した後にのみ必要です）。セキュリティペイロード（ESP）セキュリティパラメータインデックス（SPI）フィールド[RFC5201]。 3番目に、現在定義されているHIPでは、シグナリング交換での公開鍵操作とデータプレーンでのESP暗号化の使用が必要ですが、Shim6の使用ではどちらも必要ありません（HBAアドレスのみが使用されている場合）。デフォルトでは、HIPはデータ保護を提供しますが、これはShim6の目標ではありません。
Shim6 aimed to provide a solution to a specific problem, multihoming, which minimizes deployment disruption, while HIP is considered more of an experimental approach intended to solve several more general problems (mobility, multihoming, and loss of end-to-end addressing transparency) through an explicit identifier/locator split.
Shim6は、特定の問題の解決策を提供することを目的としており、展開の中断を最小限に抑えるマルチホーミングですが、HIPは、いくつかのより一般的な問題（モビリティ、マルチホーミング、およびエンドツーエンドのアドレッシングの透過性の損失）を解決するための実験的アプローチと見なされています。明示的な識別子/ロケーター分割を介して。
Communicating hosts that are willing to run HIP (perhaps extended with Shim6's failure detection protocol) likely have no reason to also run Shim6. In this sense, HIP may be viewed as a possible long-term evolution or extension of the Shim6 architecture, or one possible implementation of the Extended Shim6 Design (ESD) [SHIM6-ESD].
HIP（Shim6の障害検出プロトコルで拡張されている可能性があります）を実行する意思がある通信ホストは、Shim6も実行する理由がありません。この意味で、HIPは、Shim6アーキテクチャの長期的な進化または拡張の可能性、または拡張Shim6設計（ESD）[SHIM6-ESD]の可能な実装の1つと見なすことができます。
The ability of Shim6 to divert the communication to different paths may be affected by certain firewall configurations. For example, consider a deployment in which one of the peers of a Shim6 session is protected by a firewall (i.e., all the paths to the locators of that peer traverse the firewall). The firewall implements the Simple Security model [RFC4864], in which incoming packets are checked against a state resulting from outgoing traffic, either associated with the locator of the internal node ('endpoint independent filtering') or to both the locators of the internal and external nodes ('address dependent filtering' or 'address and port dependent filtering'). If the external node changes the locator associated with the internal node, the packet will be discarded by the firewall. In addition, if the firewall implements 'address dependent filtering' or 'address and port dependent filtering', any change by the external node in the locator used to identify itself will also result in the packet being discarded by the firewall.
通信を別のパスに迂回させるShim6の機能は、特定のファイアウォール構成によって影響を受ける場合があります。たとえば、Shim6セッションのピアの1つがファイアウォールで保護されている配置を考えてください（つまり、そのピアのロケーターへのすべてのパスがファイアウォールを通過します）。ファイアウォールは、Simple Securityモデル[RFC4864]を実装しています。このモデルでは、内部ノードのロケーター（「エンドポイントに依存しないフィルタリング」）に関連付けられているか、内部および外部ノード（「アドレス依存フィルタリング」または「アドレスおよびポート依存フィルタリング」）。外部ノードが内部ノードに関連付けられているロケーターを変更すると、パケットはファイアウォールによって破棄されます。さらに、ファイアウォールが「アドレス依存フィルタリング」または「アドレスおよびポート依存フィルタリング」を実装している場合、自身を識別するために使用されるロケーター内の外部ノードによる変更も、パケットがファイアウォールによって破棄される結果になります。
This issue could be mitigated by making the firewalls aware of the different locators that could be associated with a given communication. If the firewall is implemented in the communication node itself, the firewall could inspect the Shim6 control packet exchange to obtain this information, or the Shim6 software module could explicitly inform the firewall software module. For firewalls located outside the node, the Shim6 control packet exchange can be used to associate the alternate locators to the communication state, although it may not work for topologies in which both directions for the communication do not traverse the firewall, or in which the firewall is not traversed after a locator change. The detail of any of such mechanisms is out of the scope of this document.
この問題は、特定の通信に関連付けられている可能性のあるさまざまなロケーターをファイアウォールに認識させることで軽減できます。ファイアウォールが通信ノード自体に実装されている場合、ファイアウォールはShim6制御パケット交換を検査してこの情報を取得するか、Shim6ソフトウェアモジュールがファイアウォールソフトウェアモジュールに明示的に通知できます。ノードの外側にあるファイアウォールの場合、Shim6制御パケット交換を使用して代替ロケーターを通信状態に関連付けることができますが、通信の両方向がファイアウォールを通過しない、またはファイアウォールが通過するトポロジでは機能しない場合がありますロケーターの変更後はトラバースされません。このようなメカニズムの詳細は、このドキュメントの範囲外です。
However, note that a failure in using the alternative locators does not impact the communication between the nodes as long as the path between them defined by the initial locator pair remains available. In this case, data packets flow between the communicating nodes as for any non-Shim6 communication.
ただし、初期ロケーターペアによって定義されたノード間のパスが利用可能である限り、代替ロケーターの使用に失敗してもノード間の通信に影響を与えないことに注意してください。この場合、Shim6以外の通信と同様に、通信ノード間でデータパケットが流れます。
Address translation techniques such as Network Prefix Translation (NPTv6) [RFC6296] may be used until workable solutions to avoid renumbering or facilitate multihoming are developed [RFC5902]. We now consider the impact of NPTv6 in Shim6 operation. Some of the considerations stated in this section may also be applicable to other types of IPv6 NAT.
ネットワークプレフィックス変換（NPTv6）[RFC6296]などのアドレス変換手法は、番号の付け直しを回避したり、マルチホーミングを容易にする実用的なソリューションが開発されるまで使用できます[RFC5902]。次に、Shim6運用におけるNPTv6の影響について検討します。このセクションで説明する考慮事項の一部は、他のタイプのIPv6 NATにも適用できる場合があります。
The main purpose of Shim6 is to provide locator agility below transport protocols. To prevent the risk of redirection attacks by abusing the locator exchange facilities provided by Shim6, the protocol is built upon the cryptographic properties of CGA and HBA addresses. When the CGA address of a node is used as the local ULID, the locators configured in the node can be signed with the private key associated with the CGA. A peer receiving a Shim6 message performs a hash of the CGA Parameter Data Structure information received, including a public key, to assure that this key is bound to the CGA address, and then checks the signature protecting the locators. When an HBA address of a node is used as the local ULID, the HBA address securely chains the ULID and other locators of the node by means of a hash. For both the CGA and the HBA, the locators can be exchanged at the four-way handshake used to establish the Shim6 context, or once the context has been established by means of an Update Request message.
Shim6の主な目的は、トランスポートプロトコルの下でロケーターの俊敏性を提供することです。 Shim6が提供するロケーター交換機能を悪用することでリダイレクト攻撃のリスクを防ぐために、プロトコルはCGAおよびHBAアドレスの暗号化プロパティに基づいて構築されています。ノードのCGAアドレスがローカルULIDとして使用される場合、ノードで構成されたロケーターは、CGAに関連付けられた秘密鍵で署名できます。 Shim6メッセージを受信するピアは、公開鍵を含む受信したCGAパラメータデータ構造情報のハッシュを実行して、この鍵がCGAアドレスにバインドされていることを確認し、ロケーターを保護する署名を確認します。ノードのHBAアドレスがローカルULIDとして使用される場合、HBAアドレスはハッシュを使用して、ノードのULIDと他のロケーターを安全にチェーンします。 CGAとHBAの両方で、ロケーターは、Shim6コンテキストを確立するために使用される4ウェイハンドシェイクで、またはコンテキストが更新要求メッセージによって確立された後で交換できます。
When a node behind an NPTv6 communicates, the NAT device translates the address assigned to this internal node to an address of its address pool. This operation results in a mismatch between the address seen by external hosts and the address configured in the internal node, which is the locator that would be conveyed in a Shim6 locator exchange and is also the address for which the security defined in the CGA and HBA specifications are provided. Then, the validation processes performed by an external node may prevent the creation of the Shim6 context, or may allow the context to be created but render the alternative locator of the internal host unusable.
NPTv6の背後にあるノードが通信するとき、NATデバイスはこの内部ノードに割り当てられたアドレスをそのアドレスプールのアドレスに変換します。この操作の結果、外部ホストから見たアドレスと内部ノードで構成されたアドレスが一致しなくなります。これは、Shim6ロケーター交換で伝達されるロケーターであり、CGAおよびHBAでセキュリティが定義されているアドレスでもあります。仕様が提供されます。次に、外部ノードによって実行される検証プロセスにより、Shim6コンテキストの作成が妨げられるか、またはコンテキストの作成が許可されても内部ホストの代替ロケーターが使用できなくなる場合があります。
However, note that the failure in creating a Shim6 context, or in using the alternative locators, does not impact the communication between the nodes as long as the path between them defined by the initial locator pair remains available. Data packets flow between the communicating nodes as for any non-Shim6 communication. Not creating the Shim6 context, or not being able to convey the local locators to the peer node, affect the added value provided by Shim6, i.e., the ability to preserve the communication in case any of the locators fail. Therefore, using Shim6 with NPTv6 does not provide less functionality than using IPv6 in the same scenario.
ただし、Shim6コンテキストの作成または代替ロケーターの使用の失敗は、初期ロケーターペアによって定義されたノード間のパスが利用可能なままである限り、ノード間の通信に影響を与えないことに注意してください。データパケットは、Shim6以外の通信と同様に、通信ノード間を流れます。 Shim6コンテキストを作成しない、またはローカルロケーターをピアノードに伝達できない場合、Shim6によって提供される付加価値、つまり、いずれかのロケーターが失敗した場合に通信を維持する機能に影響を与えます。したがって、NPTv6でShim6を使用しても、同じシナリオでIPv6を使用するよりも機能が少なくなることはありません。
We now illustrate some cases that may occur when combining Shim6 and NPTv6. The following discussion does not aim to be exhaustive in the cases that may arise, but just aims to provide some examples of possible situations. We assume a scenario in which host A is located behind a NPTv6 device for its locator IP_A1, but it is connected to the public IPv6 Internet for its locator IP_A2. Once translated, locator IP_A1 appears to external nodes as IP_T. Node A communicates with node B, with public addresses IP_B1 and IP_B2.
次に、Shim6とNPTv6を組み合わせるときに発生する可能性があるいくつかのケースを示します。以下の説明は、発生する可能性のあるケースを網羅することを目的としたものではなく、可能な状況のいくつかの例を提供することを目的としています。ホストAがロケーターIP_A1のNPTv6デバイスの背後にあるが、ロケーターIP_A2のパブリックIPv6インターネットに接続されているシナリオを想定しています。変換後、ロケーターIP_A1はIP_Tとして外部ノードに表示されます。ノードAはノードBと通信し、パブリックアドレスはIP_B1およびIP_B2です。
+-----+
| A |
+-----+
IP_A1 | | IP_A2
| |
| +-----+
| |
+--------+ |
| NPTv6 | |
+--------+ |
IP_T | |
| |
+--------------------------+
| Internet |
+--------------------------+
| |
IP_B1 | | IP_B2
+-----+
| B |
+-----+
Figure 4
図4
We first discuss some issues related with the four-way handshake used to establish the Shim6 context. When the locator information is included in the Shim6 exchange, either in the I2 or R2 messages, the receiver is required to validate the ULID of the peer node by performing the CGA or HBA address validation procedure. In case the validation fails, the message containing the information is silently discarded. In the scenario depicted in Figure 4, some of the cases that may occur are:
最初に、Shim6コンテキストの確立に使用される4ウェイハンドシェイクに関連するいくつかの問題について説明します。ロケーター情報がShim6交換のI2またはR2メッセージに含まれている場合、受信者はCGAまたはHBAアドレス検証手順を実行して、ピアノードのULIDを検証する必要があります。検証が失敗した場合、情報を含むメッセージは通知なく破棄されます。図4に示すシナリオでは、次のようなケースが発生する可能性があります。
o Node A initiates the exchange, with IP_B1 as the destination address and IP_A1 as the source address, which is a CGA. Node A includes IP_A2 as an alternative locator in the I2 message. Node B sees IP_T as the ULID for A, so when it validates the CGA with the information contained in I2, the validation fails because the CGA Parameter Data Structure contains information bound to IP_A1. Therefore, B silently discards the received I2 message. Without receiving a valid I2 message, B does not create the Shim6 context. Without receiving the R2 message, A also does not create the Shim6 context. However, data communication can proceed as long as the path between IP_A1 and IP_B1 is valid. A similar case occurs if IP_A1 and IP_A2 form an HBA, instead of using CGAs for securing the communication.
oノードAが交換を開始し、IP_B1を宛先アドレス、IP_A1をソースアドレスとして使用します。これはCGAです。ノードAは、代替ロケーターとしてIP_A2をI2メッセージに含めます。ノードBはIP_TをAのULIDとして認識しているため、I2に含まれる情報でCGAを検証すると、CGAパラメータデータ構造にIP_A1にバインドされた情報が含まれているため、検証は失敗します。したがって、Bは受信したI2メッセージをサイレントに破棄します。有効なI2メッセージを受信しないと、BはShim6コンテキストを作成しません。 R2メッセージを受信しない場合、AはShim6コンテキストも作成しません。ただし、IP_A1とIP_B1の間のパスが有効である限り、データ通信は続行できます。通信を保護するためにCGAを使用する代わりに、IP_A1とIP_A2がHBAを形成する場合も、同様のケースが発生します。
o Node A initiates the exchange with IP_B1 as the destination address and IP_A2 (its public address) as the source address, which is a CGA. Node A includes IP_A1 as an alternative locator in the I2 message. In this case, B can successfully validate IP_A2 as a CGA. Regarding the validation of IP_A1 as an alternative locator for A, the Shim6 specification [RFC5533] indicates that it should perform this check when the I2 message is received, but it may perform it later on, provided that the check is performed before using it as a locator. In case the validation is performed when I2 is received, the I2 message would be silently discarded, with the same result as for the previous case. In case the validation is performed later, the Shim6 context would be established in both nodes A and B, but B could not send to IP_A1, and packets sent by A from IP_A1 will not be received by B. Note that in this case both IP_B1 and IP_B2 could be used by A and B, as long as the locator for A is IP_A2, so limited locator agility may be achieved.
o ノードAは、IP_B1を宛先アドレスとして、IP_A2（そのパブリックアドレス）をソースアドレス（CGA）として交換を開始します。ノードAは、代替ロケーターとしてIP_A1をI2メッセージに含めます。この場合、BはIP_A2をCGAとして正常に検証できます。 Aの代替ロケーターとしてのIP_A1の検証に関して、Shim6仕様[RFC5533]は、I2メッセージが受信されたときにこのチェックを実行する必要があることを示していますが、それを使用する前にチェックが実行されればロケーター。 I2の受信時に検証が実行される場合、I2メッセージは通知なしで破棄され、前のケースと同じ結果になります。検証が後で実行される場合、Shim6コンテキストはノードAとBの両方で確立されますが、BはIP_A1に送信できず、IP_A1からAが送信したパケットはBで受信されません。この場合、両方のIP_B1に注意してください。また、AのロケーターがIP_A2である限り、IP_B2をAとBで使用できるため、ロケーターの俊敏性が制限される可能性があります。
o Node B initiates the exchange with IP_B1 as the source address, and IP_A2 as the destination address, which is a CGA. This case is similar to the previous one, although it is the R2 message sent by A that cannot be validated. While A can create a context with B, B cannot do the same for A. Data communication using IP_B1 and IP_A2 can proceed. However, A may try to use IP_B2 as an alternative locator, but the data packets sent carrying the Shim6 Extension Header will not be associated by B to any established context, so they will be discarded. The same occurs for packets sent by A with IP_A1 as the source address.
o ノードBは、IP_B1をソースアドレスとして、IP_A2を宛先アドレス（CGA）として交換を開始します。このケースは前のケースと似ていますが、検証できないのはAから送信されたR2メッセージです。 AはBとのコンテキストを作成できますが、BはAに対して同じことを行うことはできません。IP_B1とIP_A2を使用したデータ通信は続行できます。ただし、AはIP_B2を代替ロケーターとして使用しようとする場合がありますが、Shim6拡張ヘッダーを伝送して送信されたデータパケットはBによって確立されたコンテキストに関連付けられないため、破棄されます。送信元アドレスとしてIP_A1を使用してAが送信したパケットについても同じことが発生します。
We can also consider the case in which node A does not exchange its own locators in the Shim6 establishment exchange. For example, a Shim6 context can be established between CGA IP_A2 and IP_B1. B can convey locator IP_B2 in the four-way handshake, and validation will be correctly done by A. Later on, A may send an Update Request message to inform B about its locator IP_A1. Validation for this message will fail in B, and B will send a Shim6 Error message to A. Neither A nor B will use IP_A1 as a locator. However, IP_A2, IP_B1, and IP_B2 can still be used as valid locators for the communication.
ノードAがShim6確立交換で自身のロケーターを交換しない場合も考慮することができます。たとえば、CGA IP_A2とIP_B1の間にShim6コンテキストを確立できます。 Bは4ウェイハンドシェイクでロケーターIP_B2を伝達でき、検証はAによって正しく行われます。後で、Aは更新要求メッセージを送信して、ロケーターIP_A1についてBに通知します。このメッセージの検証はBで失敗し、BはShim6エラーメッセージをAに送信します。AもBもIP_A1をロケーターとして使用しません。ただし、IP_A2、IP_B1、およびIP_B2は、通信の有効なロケーターとして引き続き使用できます。
Finally, note that modification of the Shim6 control packets by the NPTv6 would not be able to generate a valid signature when a CGA is being used or a Parameter Data Structure binding the translated locator to the other locators of a node when an HBA is being used. Therefore, the same failure cases described before would remain.
最後に、NPTv6によるShim6制御パケットの変更は、CGAが使用されている場合、またはHBAが使用されている場合、変換されたロケーターをノードの他のロケーターにバインドするパラメーターデータ構造を生成できないことに注意してください。 。したがって、前に説明したのと同じ失敗のケースが残ります。
This section considers the applicability of the Shim6 protocol from a security perspective, i.e., which security features can be expected by applications and users of the Shim6 protocol.
このセクションでは、Shim6プロトコルの適用性をセキュリティの観点から検討します。つまり、Shim6プロトコルのアプリケーションやユーザーが期待できるセキュリティ機能はどれですか。
First of all, it should be noted that the Shim6 protocol is not a security protocol, unlike HIP, for instance. This means that, as opposed to HIP, it is an explicit non-goal of the Shim6 protocol to provide enhanced security for the communications that use the Shim6 protocol. The goal of the Shim6 protocol design, in terms of security, is not to introduce new vulnerabilities that were not present in the current non-Shim6 enabled communications. In particular, it is an explicit non-goal of Shim6 protocol security to provide protection from on-path attackers. On-path attackers are able to sniff and spoof packets in the current Internet, and they are able to do the same in Shim6 communications (as long as the communication flows through the path on which they are located). Summarizing, the Shim6 protocol does not provide data packet protection from on-path attackers.
まず第一に、Shim6プロトコルは、たとえばHIPとは異なり、セキュリティプロトコルではないことに注意してください。これは、HIPとは対照的に、Shim6プロトコルを使用する通信のセキュリティを強化することは、Shim6プロトコルの明確な目的ではないことを意味します。セキュリティの観点から、Shim6プロトコル設計の目標は、現在の非Shim6対応通信に存在しなかった新しい脆弱性を導入することではありません。特に、パス上の攻撃者からの保護を提供することは、Shim6プロトコルセキュリティの明確な目的ではありません。パス上の攻撃者は、現在のインターネットでパケットの傍受やなりすましを行うことができ、Shim6通信でも同じことができます（通信がそれらが配置されているパスを通過する限り）。要約すると、Shim6プロトコルは、パス上の攻撃者からのデータパケット保護を提供しません。
However, the Shim6 protocol does use several security techniques. The goal of these security measures is to protect the Shim6 signaling protocol from new attacks resulting from the adoption of the Shim6 protocol. In particular, the use of HBA/CGA prevents on-path and off-path attackers from injecting new locators into the locator set of a Shim6 context, thus preventing redirection attacks [RFC4218]. Moreover, the usage of probes before re-homing to a different locator as a destination address prevents flooding attacks from off-path attackers. Note that for nodes using CGA addresses, security depends on the secure handling of the private key associated with the signature and validation of locators. In particular, any address configuration method must assure that the private key remains secret, as discussed in Section 3.3.
ただし、Shim6プロトコルはいくつかのセキュリティ技術を使用します。これらのセキュリティ対策の目的は、Shim6プロトコルの採用による新しい攻撃からShim6シグナリングプロトコルを保護することです。特に、HBA / CGAを使用すると、オンパスとオフパスの攻撃者が新しいロケーターをShim6コンテキストのロケーターセットに挿入できなくなり、リダイレクト攻撃を防ぐことができます[RFC4218]。さらに、別のロケーターに宛先アドレスとしてリホーミングする前にプローブを使用することで、オフパス攻撃者によるフラッディング攻撃を防ぐことができます。 CGAアドレスを使用するノードの場合、セキュリティはロケーターの署名と検証に関連付けられた秘密鍵の安全な処理に依存することに注意してください。特に、セクション3.3で説明されているように、アドレス構成方法では、秘密鍵が秘密のままであることを保証する必要があります。
In addition, the usage of a 4-way handshake for establishing the Shim6 context protects against DoS attacks, so hosts implementing the Shim6 protocol should not be more vulnerable to DoS attacks than regular IPv6 hosts.
さらに、Shim6コンテキストの確立に4ウェイハンドシェイクを使用すると、DoS攻撃から保護されるため、Shim6プロトコルを実装するホストは、通常のIPv6ホストよりもDoS攻撃に対して脆弱ではありません。
Finally, many Shim6 signaling messages contain a Context Tag, meaning that only attackers that know the Context Tag can forge them. As a consequence, only on-path attackers can generate false Shim6 signaling packets for an established context. The impact of these attacks would be limited since they would not be able to add additional locators to the locator set (because of the HBA/CGA protection). In general, the possible attacks have similar effects to the ones that an on-path attacker can launch on any regular IPv6 communication. The residual threats are described in the Security Considerations of the Shim6 protocol specification [RFC5533].
最後に、多くのShim6シグナリングメッセージにはコンテキストタグが含まれています。つまり、コンテキストタグを知っている攻撃者のみが偽造できるということです。その結果、パス上の攻撃者のみが、確立されたコンテキストに対して偽のShim6シグナリングパケットを生成できます。 （HBA / CGA保護のため）ロケーターセットにロケーターを追加できないため、これらの攻撃の影響は限定的です。一般に、可能な攻撃は、パス上の攻撃者が通常のIPv6通信で起動できる攻撃と同じような影響を与えます。残りの脅威は、Shim6プロトコル仕様のセキュリティに関する考慮事項[RFC5533]で説明されています。
The Shim6 protocol is designed to provide some basic privacy features. In particular, HBAs are generated in such a way that the different addresses assigned to a host cannot be trivially linked together as belonging to the same host, since there is nothing in common in the addresses themselves. Similar features are provided when the CGA protection is used. This means that it is not trivial to determine that a set of addresses is assigned to a single Shim6 host.
Shim6プロトコルは、いくつかの基本的なプライバシー機能を提供するように設計されています。特に、HBAは、ホスト自体に共通するものがないため、ホストに割り当てられた異なるアドレスを同じホストに属するものとして簡単にリンクできないように生成されます。 CGA保護を使用すると、同様の機能が提供されます。これは、アドレスのセットが単一のShim6ホストに割り当てられていると判断することは簡単ではないことを意味します。
However, the Shim6 protocol does exchange the locator set in clear text, and it also uses a fixed Context Tag when using different locators in a given context. This implies that an attacker observing the Shim6 context establishment exchange or seeing different payload packets exchanged through different locators, but with the same Context Tag, can determine the set of addresses assigned to a host. However, this requires that the attacker be located along the path and can capture the Shim6 signaling packets.
ただし、Shim6プロトコルはクリアテキストで設定されたロケーターを交換します。また、特定のコンテキストで異なるロケーターを使用する場合は、固定のコンテキストタグも使用します。これは、Shim6コンテキスト確立交換を観察するか、異なるロケーターを介して交換される異なるペイロードパケットを確認する攻撃者が、同じコンテキストタグを使用して、ホストに割り当てられたアドレスのセットを特定できることを意味します。ただし、これには、攻撃者がパスに沿って位置し、Shim6シグナリングパケットをキャプチャできることが必要です。
The analysis on the interaction between the Shim6 protocol and the other protocols presented in this note benefited from the advice of various people including Tom Henderson, Erik Nordmark, Hesham Soliman, Vijay Devarpalli, John Loughney, and Dave Thaler.
このメモに記載されているShim6プロトコルと他のプロトコルの間の相互作用に関する分析は、トムヘンダーソン、エリックノードマーク、ヘシャムソリマン、ビジェイデヴァルパリ、ジョンラフニー、デイブターラーなどのさまざまな人々の助言から利益を得ました。
Joe Abley's work was supported, in part, by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC.
Joe Ableyの仕事は、一部は全米科学財団（研究助成金SCI-0427144）とDNS-OARCによってサポートされていました。
Marcelo Bagnulo worked on this document while visiting Ericsson Research Laboratory Nomadiclab.
Marcelo Bagnuloは、Ericsson Research Laboratory Nomadiclabを訪れている間にこの文書に取り組みました。
Alberto Garcia-Martinez was supported, in part, by the eeCONTET project (TEC2011-29688-C02-02, granted by the Spanish Science and Innovation Ministry).
Alberto Garcia-Martinezは、eeCONTETプロジェクト（TEC2011-29688-C02-02、スペイン科学革新省から供与）によって部分的にサポートされました。
Shinta Sugimoto reviewed this document and provided comments and text.
杉本新太がこのドキュメントをレビューし、コメントとテキストを提供しました。
Brian Carpenter, Jari Arkko, Joel Halpern, Iljitsch van Beijnum, Sam Xia, Carsten Bormann, Dan Wing, Stephen Farrell, and Stewart Bryant reviewed this document and provided comments.
ブライアン・カーペンター、ヤリ・アルコ、ジョエル・ハルパーン、イルジット・ファン・ベイナム、サム・シア、カーステン・ボルマン、ダン・ウィング、スティーブン・ファレル、スチュワート・ブライアントがこのドキュメントをレビューし、コメントを提供した。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを採用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、2000年5月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[Raffsey] Devarapalli、W。、脇川、R.、Petresque、A。、およびp。 Tubert、「Network Mobility（Nemo）Basic Support Protocol」、RFAC1、2009年1月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972] Aura、T。、「Cryptographically Generated Addresses（CGA）」、RFC 3972、2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「Host Identity Protocol（HIP）Architecture」、RFC 4423、2006年5月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmark、E。およびM. Bagnulo、「Shim6：Level 3 Multihoming Shim Protocol for IPv6」、RFC 5533、2009年6月。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[RFC5534] Arkko、J。およびI. van Beijnum、「IPv6マルチホーミング用の障害検出およびロケータペア探索プロトコル」、RFC 5534、2009年6月。
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[RFC5535] Bagnulo、M。、「ハッシュベースのアドレス（HBA）」、RFC 5535、2009年6月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[RFC6182] Ford、A.、Raiciu、C.、Handley、M.、Barre、S。、およびJ. Iyengar、「Multipath TCP Development Architectural Guidelines」、RFC 6182、2011年3月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed., "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[RFC6316] Komu、M.、Bagnulo、M.、Slavov、K.、and S. Sugimoto、Ed。、 "Sockets Application Program Interface（API）for Multihoming Shim"、RFC 6316、July 2011。
[6MAN] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, February 2012.
[6MAN]松本明朗、藤崎武、加藤純、Chown、「DHCPv6を使用したアドレス選択ポリシーの配布」、作業中、2012年2月。
[DHCPv6-CGA] Jiang, S. and S. Shen, "Analysis of Possible DHCPv6 and CGA Interactions", Work in Progress, March 2012.
[DHCPv6-CGA] Jiang、S。およびS. Shen、「可能なDHCPv6とCGAの相互作用の分析」、進行中の作業、2012年3月。
[IPv6NAT] Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. Wing, "IPv6 Multihoming without Network Address Translation", Work in Progress, February 2012.
[IPv6NAT]松島誠、沖本哲也、Troan、O.、Miles、D。、およびD. Wing、「ネットワークアドレス変換なしのIPv6マルチホーミング」、作業中、2012年2月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221] Huston、G.、「インターネットにおけるドメイン間ルーティングに関する解説」、RFC 3221、2001年12月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582] Abley、J.、Black、B。、およびV. Gill、「Goals for IPv6 Site-Multihoming Architectures」、RFC 3582、2003年8月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116] Abley、J.、Lindqvist、K.、Davies、E.、Black、B。、およびV. Gill、「IPv4 Multihoming Practices and Limitations」、RFC 4116、2005年7月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、2005年11月。
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[RFC4218] Nordmark、E。およびT. Li、「IPv6マルチホーミングソリューションに関連する脅威」、RFC 4218、2005年10月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] Van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984] Meyer、D。、編、Zhang、L。、編、およびK. Fall、編、「ルーティングとアドレッシングに関するIABワークショップからの報告」、RFC 4984、2007年9月。
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008.
[RFC5220]マツモトA.、藤崎T.、ヒロミR.、およびカナヤマK.「マルチプレフィックス環境におけるデフォルトアドレス選択の問題ステートメント：RFC 3484デフォルトルールの運用上の問題」、RFC 5220、2008年7月。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902] Thaler、D.、Zhang、L。、およびG. Lebovitz、「IAB Thoughts on IPv6 Network Address Translation」、RFC 5902、2010年7月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、2011年6月。
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418] Blanchet、M。およびP. Seite、「Multiple Interfaces and Provisioning Domains Problem Statement」、RFC 6418、2011年11月。
[SHIM6-ESD] Nordmark, E., "Extended Shim6 Design for ID/loc split and Traffic Engineering", Work in Progress, February 2008.
[SHIM6-ESD] Nordmark、E。、「ID / loc split and Traffic Engineering向けの拡張Shim6設計」、Work in Progress、2008年2月。
Authors' Addresses
著者のアドレス
Joe Abley ICANN 12025 Waterfront Drive Suite 300 Los Angeles, CA 90094 USA
Joe Abley ICANN 12025 Waterfront Drive Suite 300 Los Angeles、CA 90094 USA
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
Marcelo Bagnulo U. Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
Marcelo Bagnulo U. Carlos III of Madrid Av。Universidad 30 Leganes、Madrid 28911 Spain
Phone: +34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/
Alberto Garcia-Martinez U. Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
マドリードのアルベルトガルシアマルティネスU.カルロス3世大学Universidad 30 Leganes、Madrid 28911 Spain
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/