[要約] RFC 6555は、デュアルスタックホストでの成功を目指すための「ハッピーアイボールズ」の手法を提案しています。このRFCの目的は、IPv4とIPv6の両方をサポートするホストでの接続の遅延を最小化し、ユーザーエクスペリエンスを向上させることです。
Internet Engineering Task Force (IETF) D. Wing
Request for Comments: 6555 A. Yourtchenko
Category: Standards Track Cisco
ISSN: 2070-1721 April 2012
Happy Eyeballs: Success with Dual-Stack Hosts
ハッピーアイボール：デュアルスタックホストでの成功
Abstract
概要
When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual-stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm.
サーバーのIPv4パスとプロトコルが機能しているが、サーバーのIPv6パスとプロトコルが機能していない場合、デュアルスタッククライアントアプリケーションは、IPv4のみのクライアントと比較して大きな接続遅延を経験します。これは、デュアルスタックのクライアントがより悪いユーザーエクスペリエンスを持たせるため、望ましくありません。このドキュメントは、このユーザー可視遅延を減らし、アルゴリズムを提供するアルゴリズムの要件を指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc6555.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6555で取得できます。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Additional Network and Host Traffic . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Hostnames . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Delay When IPv6 Is Not Accessible . . . . . . . . . . . . 5
4. Algorithm Requirements . . . . . . . . . . . . . . . . . . . . 6
4.1. Delay IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Stateful Behavior When IPv6 Fails . . . . . . . . . . . . 8
4.3. Reset on Network (Re-)Initialization . . . . . . . . . . . 9
4.4. Abandon Non-Winning Connections . . . . . . . . . . . . . 9
5. Additional Considerations . . . . . . . . . . . . . . . . . . 10
5.1. Determining Address Type . . . . . . . . . . . . . . . . . 10
5.2. Debugging and Troubleshooting . . . . . . . . . . . . . . 10
5.3. Three or More Interfaces . . . . . . . . . . . . . . . . . 10
5.4. A and AAAA Resource Records . . . . . . . . . . . . . . . 10
5.5. Connection Timeout . . . . . . . . . . . . . . . . . . . . 11
5.6. Interaction with Same-Origin Policy . . . . . . . . . . . 11
5.7. Implementation Strategies . . . . . . . . . . . . . . . . 12
6. Example Algorithm . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
In order to use applications over IPv6, it is necessary that users enjoy nearly identical performance as compared to IPv4. A combination of today's applications, IPv6 tunneling, IPv6 service providers, and some of today's content providers all cause the user experience to suffer (Section 3). For IPv6, a content provider may ensure a positive user experience by using a DNS white list of IPv6 service providers who peer directly with them (e.g., [WHITELIST]). However, this does not scale well (to the number of DNS servers worldwide or the number of content providers worldwide) and does react to intermittent network path outages.
IPv6を介してアプリケーションを使用するには、ユーザーがIPv4と比較してほぼ同じパフォーマンスを享受する必要があります。今日のアプリケーション、IPv6トンネル、IPv6サービスプロバイダー、および今日のコンテンツプロバイダーの一部の組み合わせはすべて、ユーザーエクスペリエンスを引き起こします（セクション3）。IPv6の場合、コンテンツプロバイダーは、IPv6サービスプロバイダーのDNSホワイトリストを使用することにより、ポジティブなユーザーエクスペリエンスを確保できます（例：[ホワイトリスト]）。ただし、これは（世界中のDNSサーバーの数または世界中のコンテンツプロバイダーの数に適したものではなく、断続的なネットワークパスの停止に反応します。
Instead, applications reduce connection setup delays themselves, by more aggressively making connections on IPv6 and IPv4. There are a variety of algorithms that can be envisioned. This document specifies requirements for any such algorithm, with the goals that the network and servers not be inordinately harmed with a simple doubling of traffic on IPv6 and IPv4 and the host's address preference be honored (e.g., [RFC3484]).
代わりに、アプリケーションは、IPv6とIPv4でより積極的に接続を行うことにより、接続セットアップの遅延を減らします。想定できるさまざまなアルゴリズムがあります。このドキュメントは、そのようなアルゴリズムの要件を指定し、ネットワークとサーバーがIPv6とIPv4のトラフィックの単純な倍増とホストの住所選好を単純に2倍にしないという目標を備えています（例：[RFC3484]）。
Additional network traffic and additional server load is created due to the recommendations in this document, especially when connections to the preferred address family (usually IPv6) are not completing quickly.
特に優先アドレスファミリ（通常はIPv6）への接続が迅速に完了していない場合、このドキュメントの推奨事項により、追加のネットワークトラフィックと追加のサーバーロードが作成されます。
The procedures described in this document retain a quality user experience while transitioning from IPv4-only to dual stack, while still giving IPv6 a slight preference over IPv4 (in order to remove load from IPv4 networks and, most importantly, to reduce the load on IPv4 network address translators). The user experience is improved to the slight detriment of the network, DNS server, and server that are serving the user.
このドキュメントに記載されている手順は、IPv4のみからデュアルスタックに移行しながら質の高いユーザーエクスペリエンスを保持しますが、IPv6をIPv4よりもわずかに好みます（IPv4ネットワークから負荷を削除し、最も重要なことには、IPv4の負荷を減らすためにネットワークアドレス翻訳者）。ユーザーエクスペリエンスは、ユーザーにサービスを提供しているネットワーク、DNSサーバー、およびサーバーをわずかに損なうように改善されます。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The basis of the IPv6/IPv4 selection problem was first described in 1994 in [RFC1671]:
IPv6/IPv4選択問題の基礎は、1994年に[RFC1671]で最初に説明されました。
The dual-stack code may get two addresses back from DNS; which does it use? During the many years of transition the Internet will contain black holes. For example, somewhere on the way from IPng host A to IPng host B there will sometimes (unpredictably) be IPv4-only routers which discard IPng packets. Also, the state of the DNS does not necessarily correspond to reality. A host for which DNS claims to know an IPng address may in fact not be running IPng at a particular moment; thus an IPng packet to that host will be discarded on delivery. Knowing that a host has both IPv4 and IPng addresses gives no information about black holes. A solution to this must be proposed and it must not depend on manually maintained information. (If this is not solved, the dual-stack approach is no better than the packet translation approach.)
デュアルスタックコードは、DNSから2つのアドレスを取り戻す場合があります。どちらを使用しますか？長年の移行中に、インターネットにはブラックホールが含まれます。たとえば、IPNGホストAからIPNGホストBへの途中のどこかで、IPNGパケットを破棄するIPv4のみのルーターが（予測不可能に）時々（予測不可能に）あります。また、DNSの状態は必ずしも現実に対応するものではありません。DNSがIPNGアドレスを知っていると主張するホストは、実際には特定の瞬間にIPNGを実行していない可能性があります。したがって、そのホストへのIPNGパケットは配信時に破棄されます。ホストがIPv4アドレスとIPNGアドレスの両方を持っていることを知っていると、ブラックホールに関する情報はありません。これに対する解決策を提案する必要があり、手動で維持された情報に依存してはなりません。（これが解決されない場合、デュアルスタックアプローチはパケット翻訳アプローチよりも優れていません。）
As discussed in more detail in Section 3.1, it is important that the same hostname be used for IPv4 and IPv6.
セクション3.1で詳しく説明しているように、同じホスト名をIPv4とIPv6に使用することが重要です。
As discussed in more detail in Section 3.2, IPv6 connectivity is broken to specific prefixes or specific hosts or is slower than native IPv4 connectivity.
セクション3.2で詳細に説明したように、IPv6接続は特定のプレフィックスまたは特定のホストに壊れているか、ネイティブIPv4接続よりも遅いです。
The mechanism described in this document is directly applicable to connection-oriented transports (e.g., TCP, SCTP), which is the scope of this document. For connectionless transport protocols (e.g., UDP), a similar mechanism can be used if the application has request/ response semantics (e.g., as done by Interactive Connectivity Establishment (ICE) to select a working IPv6 or IPv4 media path [RFC6157]).
このドキュメントで説明されているメカニズムは、このドキュメントの範囲である接続指向のトランスポート（TCP、SCTPなど）に直接適用できます。Connectionless Transport Protocols（例：UDP）の場合、アプリケーションにリクエスト/応答セマンティクスがある場合（たとえば、インタラクティブ接続確立（ICE）が行うように、作業IPv6またはIPv4メディアパス[RFC6157]）の場合、同様のメカニズムを使用できます。
Hostnames are often used between users to exchange pointers to content -- such as on social networks, email, instant messaging, or other systems. Using separate namespaces (e.g., "ipv6.example.com"), which are only accessible with certain client technology (e.g., an IPv6 client) and dependencies (e.g., a working IPv6 path), causes namespace fragmentation and reduces the ability for users to share hostnames. It also complicates printed material that includes the hostname.
ホスト名は、ソーシャルネットワーク、電子メール、インスタントメッセージング、その他のシステムなど、ポインターをコンテンツに交換するためにユーザー間でよく使用されます。特定のクライアントテクノロジー（IPv6クライアントなど）と依存関係（作業IPv6パスなど）でのみアクセスできる個別の名前空間（ "ipv6.example.com"）を使用すると、名前空間の断片化を引き起こし、ユーザーの能力が低下します。ホスト名を共有します。また、ホスト名を含む印刷物を複雑にします。
The algorithm described in this document allows production hostnames to avoid these problematic references to IPv4 or IPv6.
このドキュメントで説明されているアルゴリズムにより、生産ホスト名はIPv4またはIPv6へのこれらの問題のある参照を回避できます。
When IPv6 connectivity is impaired, today's IPv6-capable applications (e.g., web browsers, email clients, instant messaging clients) incur many seconds of delay before falling back to IPv4. This delays overall application operation, including harming the user's experience with IPv6, which will slow the acceptance of IPv6, because IPv6 is frequently disabled in its entirety on the end systems to improve the user experience.
IPv6接続が損なわれると、今日のIPv6対応アプリケーション（たとえば、Webブラウザー、電子メールクライアント、インスタントメッセージングクライアントなど）は、IPv4に戻る前に何秒の遅延が発生します。これにより、IPv6でのユーザーのエクスペリエンスの害が含まれるなど、全体的なアプリケーション操作が遅れます。これにより、IPv6の受け入れが遅くなります。これは、IPv6が最終システムで完全に無効になっているため、ユーザーエクスペリエンスを改善するためです。
Reasons for such failure include no connection to the IPv6 Internet, broken 6to4 or Teredo tunnels, and broken IPv6 peering. The following diagram shows this behavior.
このような障害の理由には、IPv6インターネットとの接続、壊れた6to4またはTeredoトンネル、IPv6の壊れたピアリングが含まれます。次の図は、この動作を示しています。
The algorithm described in this document allows clients to connect to servers without significant delay, even if a path or the server is slow or down.
このドキュメントで説明されているアルゴリズムにより、クライアントはパスやサーバーが遅いかダウンしていても、それほど遅滞なくサーバーに接続できます。
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6===>X |
7. | |==TCP SYN, IPv6===>X |
8. | |==TCP SYN, IPv6===>X |
9. | | |
10. | |--TCP SYN, IPv4------->|
11. | |<-TCP SYN+ACK, IPv4----|
12. | |--TCP ACK, IPv4------->|
Figure 1: Existing Behavior Message Flow
図1：既存の動作メッセージフロー
The client obtains the IPv4 and IPv6 records for the server (1-4). The client attempts to connect using IPv6 to the server, but the IPv6 path is broken (6-8), which consumes several seconds of time. Eventually, the client attempts to connect using IPv4 (10), which succeeds.
クライアントは、サーバーのIPv4およびIPv6レコードを取得します（1-4）。クライアントはIPv6を使用してサーバーに接続しようとしますが、IPv6パスは壊れており（6-8）、数秒かかります。最終的に、クライアントは、成功するIPv4（10）を使用して接続しようとします。
Delays experienced by users of various browser and operating system combinations have been studied [Experiences].
さまざまなブラウザとオペレーティングシステムの組み合わせのユーザーが経験した遅延が研究されています[経験]。
A "Happy Eyeballs" algorithm has two primary goals:
「Happy Eyeballs」アルゴリズムには2つの主要な目標があります。
1. Provides fast connection for users, by quickly attempting to connect using IPv6 and (if that connection attempt is not quickly successful) to connect using IPv4.
1. IPv6を使用して迅速に接続しようとすることにより、（その接続の試みが迅速に成功しない場合）IPv4を使用して接続することにより、ユーザーに高速接続を提供します。
2. Avoids thrashing the network, by not (always) making simultaneous connection attempts on both IPv6 and IPv4.
2. （常に）IPv6とIPv4の両方で同時接続試行を行うことではなく、ネットワークを叩き回避します。
The basic idea is depicted in the following diagram:
基本的なアイデアは、次の図に描かれています。
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6===>X |
7. | |--TCP SYN, IPv4------->|
8. | |<-TCP SYN+ACK, IPv4----|
9. | |--TCP ACK, IPv4------->|
10. | |==TCP SYN, IPv6===>X |
Figure 2: Happy Eyeballs Flow 1, IPv6 Broken
図2：ハッピーアイボールフロー1、IPv6が壊れている
In the diagram above, the client sends two TCP SYNs at the same time over IPv6 (6) and IPv4 (7). In the diagram, the IPv6 path is broken but has little impact to the user because there is no long delay before using IPv4. The IPv6 path is retried until the application gives up (10).
上記の図では、クライアントはIPv6（6）とIPv4（7）を介して2つのTCP Synを同時に送信します。図では、IPv6パスは壊れていますが、IPv4を使用する前に長い遅延がないため、ユーザーにはほとんど影響しません。IPv6パスは、アプリケーションが放棄されるまで再試行されます（10）。
After performing the above procedure, the client learns whether connections to the host's IPv6 or IPv4 address were successful. The client MUST cache information regarding the outcome of each connection attempt, and it uses that information to avoid thrashing the network with subsequent attempts. In the example above, the cache indicates that the IPv6 connection attempt failed, and therefore the system will prefer IPv4 instead. Cache entries should be flushed when their age exceeds a system-defined maximum on the order of 10 minutes.
上記の手順を実行した後、クライアントはホストのIPv6またはIPv4アドレスへの接続が成功したかどうかを学びます。クライアントは、各接続試行の結果に関する情報をキャッシュする必要があり、その情報を使用して、その後の試みでネットワークを叩かないようにします。上記の例では、キャッシュはIPv6接続の試行が失敗したことを示しているため、システムは代わりにIPv4を好みます。キャッシュエントリは、年齢が10分程度のシステム定義の最大値を超えたときにフラッシュする必要があります。
DNS Server Client Server
| | |
1. |<--www.example.com A?-----| |
2. |<--www.example.com AAAA?--| |
3. |---192.0.2.1------------->| |
4. |---2001:db8::1----------->| |
5. | | |
6. | |==TCP SYN, IPv6=======>|
7. | |--TCP SYN, IPv4------->|
8. | |<=TCP SYN+ACK, IPv6====|
9. | |<-TCP SYN+ACK, IPv4----|
10. | |==TCP ACK, IPv6=======>|
11. | |--TCP ACK, IPv4------->|
12. | |--TCP RST, IPv4------->|
Figure 3: Happy Eyeballs Flow 2, IPv6 Working
図3：Happy Eyeballs Flow 2、IPv6が動作する
The diagram above shows a case where both IPv6 and IPv4 are working, and IPv4 is abandoned (12).
上の図は、IPv6とIPv4の両方が機能し、IPv4が放棄されている場合を示しています（12）。
Any Happy Eyeballs algorithm will persist in products for as long as the client host is dual-stacked, which will persist as long as there are IPv4-only servers on the Internet -- the so-called "long tail". Over time, as most content is available via IPv6, the amount of IPv4 traffic will decrease. This means that the IPv4 infrastructure will, over time, be sized to accommodate that decreased (and decreasing) amount of traffic. It is critical that a Happy Eyeballs algorithm not cause a surge of unnecessary traffic on that IPv4 infrastructure. To meet that goal, compliant Happy Eyeballs algorithms must adhere to the requirements in this section.
ハッピーアイボールアルゴリズムは、クライアントホストがデュアルスタックされている限り、製品に持続します。これは、インターネット上にIPv4のみのサーバーがある限り持続します。時間が経つにつれて、ほとんどのコンテンツはIPv6を介して利用可能であるため、IPv4トラフィックの量は減少します。これは、IPv4インフラストラクチャが、時間の経過とともに、トラフィックの減少（および減少）に対応するためにサイズが大きくなることを意味します。幸せな眼球アルゴリズムがそのIPv4インフラストラクチャに不必要なトラフィックの急増を引き起こさないことが重要です。その目標を達成するために、準拠したHappy Eyeballsアルゴリズムは、このセクションの要件を順守する必要があります。
The transition to IPv6 is likely to produce a mix of different hosts within a subnetwork -- hosts that are IPv4-only, hosts that are IPv6- only (e.g., sensors), and dual-stack hosts. This mix of hosts will exist both within an administrative domain (a single home, enterprise, hotel, or coffee shop) and between administrative domains. For example, a single home might have an IPv4-only television in one room and a dual-stack television in another room. As another example, another subscriber might have hosts that are all capable of dual-stack operation.
IPv6への移行は、サブネットワーク内の異なるホストのミックスを生成する可能性があります - IPv4のみのホスト、IPv6-のみ（センサーなど）、およびデュアルスタックホストのホスト。このホストの組み合わせは、管理ドメイン（単一の家、企業、ホテル、またはコーヒーショップ）と管理ドメインの間に存在します。たとえば、1つの家には、ある部屋にIPv4のみのテレビがあり、別の部屋にデュアルスタックテレビがある場合があります。別の例として、別のサブスクライバーがすべてデュアルスタック操作が可能なホストを持っている可能性があります。
Due to IPv4 exhaustion, it is likely that a subscriber's hosts (both IPv4-only hosts and dual-stack hosts) will be sharing an IPv4 address with other subscribers. The dual-stack hosts have an advantage: they can utilize IPv6 or IPv4, which means they can utilize the technique described in this document. The IPv4-only hosts have a disadvantage:
IPv4の疲労により、サブスクライバーのホスト（IPv4のみのホストとデュアルスタックホストの両方）が他のサブスクライバーとIPv4アドレスを共有する可能性があります。デュアルスタックのホストには利点があります。IPv6またはIPv4を利用できます。つまり、このドキュメントで説明されている手法を利用できます。IPv4のみのホストには不利な点があります。
they can only utilize IPv4. If all hosts (dual-stack and IPv4-only) are using IPv4, there is additional contention for the shared IPv4 address. The IPv4-only hosts cannot avoid that contention (as they can only use IPv4), while the dual-stack hosts can avoid it by using IPv6.
IPv4のみを利用できます。すべてのホスト（デュアルスタックとIPv4のみ）がIPv4を使用している場合、共有IPv4アドレスに追加の競合があります。IPv4のみのホストは、その競合を回避できません（IPv4のみを使用できるため）。一方、デュアルスタックホストはIPv6を使用して回避できます。
As dual-stack hosts proliferate and content becomes available over IPv6, there will be proportionally less IPv4 traffic. This is true especially for dual-stack hosts that do not implement Happy Eyeballs, because those dual-stack hosts have a very strong preference to use IPv6 (with timeouts in the tens of seconds before they will attempt to use IPv4).
デュアルスタックホストが増殖し、IPv6でコンテンツが利用可能になると、IPv4トラフィックが比例して少なくなります。これは、特にハッピーアイボールを実装していないデュアルスタックホストに当てはまります。これらのデュアルスタックホストは、IPv6を使用することを非常に強く好むためです（IPv4を使用しようとする前にタイムアウトが数十秒で）。
When deploying IPv6, both content providers and Internet Service Providers (who supply mechanisms for IPv4 address sharing such as Carrier-Grade NAT (CGN)) will want to reduce their investment in IPv4 equipment -- load-balancers, peering links, and address sharing devices. If a Happy Eyeballs implementation treats IPv6 and IPv4 equally by connecting to whichever address family is fastest, it will contribute to load on IPv4. This load impacts IPv4-only devices (by increasing contention of IPv4 address sharing and increasing load on IPv4 load-balancers). Because of this, ISPs and content providers will find it impossible to reduce their investment in IPv4 equipment. This means that costs to migrate to IPv6 are increased because the investment in IPv4 cannot be reduced. Furthermore, using only a metric that measures the connection speed ignores the benefits that IPv6 brings when compared with IPv4 address sharing, such as improved geo-location [RFC6269] and the lack of fate-sharing due to traversing a large translator.
IPv6を展開する場合、コンテンツプロバイダーとインターネットサービスプロバイダー（キャリアグレードNAT（CGN）などのIPv4アドレス共有のメカニズムを提供する人）は、IPv4機器、つまり荷物バランサー、ピアリングリンク、アドレス共有への投資を削減したいと考えています。デバイス。 Happy Eyeballsの実装が、住所ファミリが最も速いどの住所に接続してIPv6とIPv4を均等に扱う場合、IPv4の負荷に貢献します。この負荷は、IPv4のみのデバイスに影響を与えます（IPv4アドレス共有の競合を増やし、IPv4ロードバランサーの負荷を増加させることにより）。このため、ISPとコンテンツプロバイダーは、IPv4機器への投資を減らすことは不可能だと感じるでしょう。これは、IPv4への投資を減らすことができないため、IPv6に移行するためのコストが増加することを意味します。さらに、接続速度を測定するメトリックのみを使用すると、IPv6がもたらす場合の利点は無視されます。IPv4アドレス共有と比較して、地理ロケーションの改善[RFC6269]や大規模な翻訳者の移動による運命共有の欠如などです。
Thus, to avoid harming IPv4-only hosts, implementations MUST prefer the first IP address family returned by the host's address preference policy, unless implementing a stateful algorithm described in Section 4.2. This usually means giving preference to IPv6 over IPv4, although that preference can be overridden by user configuration or by network configuration [ADDR-SELECT]. If the host's policy is unknown or not attainable, implementations MUST prefer IPv6 over IPv4.
したがって、IPv4のみのホストを傷つけることを避けるために、実装は、セクション4.2で説明されているステートフルアルゴリズムを実装しない限り、ホストのアドレス選好ポリシーによって返される最初のIPアドレスファミリを優先する必要があります。これは通常、IPv4よりもIPv6を優先することを意味しますが、その好みはユーザー構成またはネットワーク構成[ADDR-Select]によってオーバーライドできます。ホストのポリシーが不明であるか、達成できない場合、実装はIPv4よりもIPv6を好む必要があります。
Some Happy Eyeballs algorithms are stateful -- that is, the algorithm will remember that IPv6 always fails, or that IPv6 to certain prefixes always fails, and so on. This section describes such algorithms. Stateless algorithms, which do not remember the success/ failure of previous connections, are not discussed in this section.
いくつかのHappy Eyeballs Algorithmsはステートフルです。つまり、アルゴリズムはIPv6が常に故障していること、または特定のプレフィックスへのIPv6が常に故障することなどを覚えています。このセクションでは、そのようなアルゴリズムについて説明します。このセクションでは、以前の接続の成功/失敗を覚えていないステートレスアルゴリズムについては説明していません。
After making a connection attempt on the preferred address family (e.g., IPv6) and failing to establish a connection within a certain time period (see Section 5.5), a Happy Eyeballs implementation will decide to initiate a second connection attempt using the same address family or the other address family.
優先アドレスファミリ（IPv6など）で接続を試み、特定の期間内に接続を確立できなかった後（セクション5.5を参照）、Happy Eyeballsの実装は、同じアドレスファミリまたは同じアドレスファミリを使用して2番目の接続試行を開始することを決定します。他の住所ファミリー。
Such an implementation MAY make subsequent connection attempts (to the same host or to other hosts) on the successful address family (e.g., IPv4). So long as new connections are being attempted by the host, such an implementation MUST occasionally make connection attempts using the host's preferred address family, as it may have become functional again, and it SHOULD do so every 10 minutes. The 10-minute delay before retrying a failed address family avoids the simple doubling of connection attempts on both IPv6 and IPv4. Implementation note: this can be achieved by flushing Happy Eyeballs state every 10 minutes, which does not significantly harm the application's subsequent connection setup time. If connections using the preferred address family are again successful, the preferred address family SHOULD be used for subsequent connections. Because this implementation is stateful, it MAY track connection success (or failure) based on IPv6 or IPv4 prefix (e.g., connections to the same prefix assigned to the interface are successful whereas connections to other prefixes are failing).
このような実装は、成功したアドレスファミリ（例えば、IPv4）に対して（同じホストまたは他のホストに対する）後続の接続試行を行う場合があります。ホストが新しい接続が試みられている限り、そのような実装は、再び機能的になった可能性があるため、ホストの優先アドレスファミリを使用して接続の試みを行う必要があり、10分ごとにそうする必要があります。障害のあるアドレスファミリを再試行する前の10分間の遅延は、IPv6とIPv4の両方での接続試行の単純な2倍を回避します。実装注：これは、10分ごとにHappy Eyeballs状態をフラッシュすることで実現できます。優先アドレスファミリを使用した接続が再び成功した場合、優先アドレスファミリを後続の接続に使用する必要があります。この実装はステートフルであるため、IPv6またはIPv4プレフィックスに基づいて接続の成功（または障害）を追跡する可能性があります（たとえば、インターフェイスに割り当てられた同じプレフィックスへの接続は成功し、他のプレフィックスへの接続は失敗します）。
Because every network has different characteristics (e.g., working or broken IPv6 or IPv4 connectivity), a Happy Eyeballs algorithm SHOULD re-initialize when the interface is connected to a new network. Interfaces can determine network (re-)initialization by a variety of mechanisms (e.g., Detecting Network Attachment in IPv4 (DNAv4) [RFC4436], DNAv6 [RFC6059]).
すべてのネットワークには異なる特性があるため（たとえば、動作または壊れたIPv6またはIPv4接続）、インターフェイスが新しいネットワークに接続されている場合、Happy Eyeballsアルゴリズムは再発明する必要があります。インターフェイスは、さまざまなメカニズムによるネットワーク（RE）初期化を決定できます（例：IPv4（DNAV4）[RFC4436]、DNAV6 [RFC6059]のネットワークアタッチメントの検出）。
If the client application is a web browser, see also Section 5.6.
クライアントアプリケーションがWebブラウザの場合は、セクション5.6も参照してください。
It is RECOMMENDED that the non-winning connections be abandoned, even though they could -- in some cases -- be put to reasonable use.
有利な接続は、場合によっては合理的に使用できる場合でも、有利でない接続を放棄することをお勧めします。
Justification: This reduces the load on the server (file descriptors, TCP control blocks) and stateful middleboxes (NAT and firewalls). Also, if the abandoned connection is IPv4, this reduces IPv4 address sharing contention.
正当化：これにより、サーバー（ファイル記述子、TCP制御ブロック）とステートフルミドルボックス（NATおよびファイアウォール）の負荷が削減されます。また、放棄された接続がIPv4の場合、これによりIPv4アドレス共有の競合が減少します。
HTTP: The design of some sites can break because of HTTP cookies that incorporate the client's IP address and require all connections be from the same IP address. If some connections from
HTTP：一部のサイトの設計は、クライアントのIPアドレスを組み込んだHTTP Cookieのために破損する可能性があり、同じIPアドレスからすべての接続を必要とします。からの接続がある場合
the same client are arriving from different IP addresses (or worse, different IP address families), such applications will break. Additionally, for HTTP, using the non-winning connection can interfere with the browser's same-origin policy (see Section 5.6).
同じクライアントが異なるIPアドレス（またはさらに悪い、異なるIPアドレスファミリ）から到着しているため、そのようなアプリケーションは壊れます。さらに、HTTPの場合、受賞していない接続を使用すると、ブラウザの同性ポリシーを妨げる可能性があります（セクション5.6を参照）。
This section discusses considerations related to Happy Eyeballs.
このセクションでは、幸せな眼球に関連する考慮事項について説明します。
For some transitional technologies such as a dual-stack host, it is easy for the application to recognize the native IPv6 address (learned via a AAAA query) and the native IPv4 address (learned via an A query). While IPv6/IPv4 translation makes that difficult, IPv6/ IPv4 translators do not need to be deployed on networks with dual-stack clients because dual-stack clients can use their native IP address family.
デュアルスタックホストなどの一部の移行技術の場合、アプリケーションがネイティブIPv6アドレス（AAAAクエリを介して学習）とネイティブIPv4アドレス（Aクエリで学習）を簡単に認識できます。IPv6/ IPv4の翻訳は難しくなりますが、IPv6/ IPv4翻訳者は、デュアルスタッククライアントがネイティブIPアドレスファミリを使用できるため、デュアルスタッククライアントとネットワークに展開する必要はありません。
This mechanism is aimed at ensuring a reliable user experience regardless of connectivity problems affecting any single transport. However, this naturally means that applications employing these techniques are by default less useful for diagnosing issues with a particular address family. To assist in that regard, the implementations MAY also provide a mechanism to disable their Happy Eyeballs behavior via a user setting, and to provide data useful for debugging (e.g., a log or way to review current preferences).
このメカニズムは、単一の輸送に影響を与える接続性の問題に関係なく、信頼できるユーザーエクスペリエンスを確保することを目的としています。ただし、これは当然のことながら、これらの手法を採用するアプリケーションが、特定のアドレスファミリとの問題の診断にデフォルトではあまり役に立たないことを意味します。その点で支援するために、実装は、ユーザー設定を介して幸せな眼球の動作を無効にするメカニズムを提供し、デバッグに役立つデータを提供することもできます（例：ログや現在の設定を確認する方法）。
A dual-stack host normally has two logical interfaces: an IPv6 interface and an IPv4 interface. However, a dual-stack host might have more than two logical interfaces because of a VPN (where a third interface is the tunnel address, often assigned by the remote corporate network), because of multiple physical interfaces such as wired and wireless Ethernet, because the host belongs to multiple VLANs, or other reasons. The interaction of Happy Eyeballs with more than two logical interfaces is for further study.
デュアルスタックホストには、通常、IPv6インターフェイスとIPv4インターフェイスの2つの論理インターフェイスがあります。ただし、デュアルスタックのホストは、VPN（3番目のインターフェイスがトンネルアドレスであり、多くの場合リモートコーポレートネットワークによって割り当てられているトンネルアドレスである）のために、2つ以上の論理インターフェイスを持っている可能性があります。ホストは、複数のVLAN、またはその他の理由に属します。幸せな眼球と2つ以上の論理インターフェイスとの相互作用は、さらなる研究のためのものです。
It is possible that a DNS query for an A or AAAA resource record will return more than one A or AAAA address. When this occurs, it is RECOMMENDED that a Happy Eyeballs implementation order the responses following the host's address preference policy and then try the first
AまたはAAAAリソースレコードのDNSクエリが複数のAまたはAAAAアドレスを返す可能性があります。これが発生した場合、Happy Eyeballsの実装は、ホストのアドレス選好ポリシーに従って応答を注文し、最初のものを試すことをお勧めします
address. If that fails after a certain time (see Section 5.5), the next address SHOULD be the IPv4 address.
住所。特定の時間の後に失敗した場合（セクション5.5を参照）、次のアドレスはIPv4アドレスである必要があります。
If that fails to connect after a certain time (see Section 5.5), a Happy Eyeballs implementation SHOULD try the other addresses returned; the order of these connection attempts is not important.
特定の時間の後に接続できない場合（セクション5.5を参照）、Happy Eyeballsの実装は、返される他のアドレスを試してみてください。これらの接続試行の順序は重要ではありません。
On the Internet today, servers commonly have multiple A records to provide load-balancing across their servers. This same technique would be useful for AAAA records, as well. However, if multiple AAAA records are returned to a client that is not using Happy Eyeballs and that has broken IPv6 connectivity, it will further increase the delay to fall back to IPv4. Thus, web site operators with native IPv6 connectivity SHOULD NOT offer multiple AAAA records. If Happy Eyeballs is widely deployed in the future, this recommendation might be revisited.
今日のインターネットでは、サーバーには一般に、サーバー全体でロードバランスを提供するための複数のAレコードがあります。この同じ手法は、AAAAレコードにも役立ちます。ただし、Happy Eyeballsを使用していないクライアントに複数のAAAAレコードが返され、IPv6接続が破損している場合、遅延がさらに増加してIPv4に戻ります。したがって、ネイティブIPv6接続を備えたWebサイトオペレーターは、複数のAAAAレコードを提供してはなりません。Happy Eyeballsが将来広く展開されている場合、この推奨事項が再検討される可能性があります。
The primary purpose of Happy Eyeballs is to reduce the wait time for a dual-stack connection to complete, especially when the IPv6 path is broken and IPv6 is preferred. Aggressive timeouts (on the order of tens of milliseconds) achieve this goal, but at the cost of network traffic. This network traffic may be billable on certain networks, will create state on some middleboxes (e.g., firewalls, intrusion detection systems, NATs), and will consume ports if IPv4 addresses are shared. For these reasons, it is RECOMMENDED that connection attempts be paced to give connections a chance to complete. It is RECOMMENDED that connection attempts be paced 150-250 ms apart to balance human factors against network load. Stateful algorithms are expected to be more aggressive (that is, make connection attempts closer together), as stateful algorithms maintain an estimate of the expected connection completion time.
ハッピーアイボールの主な目的は、特にIPv6パスが壊れてIPv6が好まれる場合、デュアルスタック接続が完了するまでの待ち時間を短縮することです。積極的なタイムアウト（数十ミリ秒の順序で）は、この目標を達成しますが、ネットワークトラフィックを犠牲にします。このネットワークトラフィックは、特定のネットワークで請求可能であり、一部のミドルボックス（ファイアウォール、侵入検知システム、NATなど）で状態を作成し、IPv4アドレスが共有されている場合はポートを消費します。これらの理由により、接続の試行をペースにして、接続が完了する機会を与えることをお勧めします。ネットワークの負荷とヒューマンファクターのバランスをとるために、接続の試行を150〜250ミリ秒間隔でペースすることをお勧めします。ステートフルアルゴリズムは、予想される接続完了時間の推定値を維持するため、ステートフルアルゴリズムはより積極的になると予想されます（つまり、接続の試みをより近づけます）。
Web browsers implement a same-origin policy [RFC6454] that causes subsequent connections to the same hostname to go to the same IPv4 (or IPv6) address as the previous successful connection. This is done to prevent certain types of attacks.
Webブラウザは、同じホスト名への後続の接続を、以前の成功した接続と同じIPv4（またはIPv6）アドレスに移動するように、同性愛者ポリシー[RFC6454]を実装します。これは、特定の種類の攻撃を防ぐために行われます。
The same-origin policy harms user-visible responsiveness if a new connection fails (e.g., due to a transient event such as router failure or load-balancer failure). While it is tempting to use Happy Eyeballs to maintain responsiveness, web browsers MUST NOT change their same-origin policy because of Happy Eyeballs, as that would create an additional security exposure.
同性のポリシーは、新しい接続が失敗した場合にユーザー可視の応答性に害を及ぼします（たとえば、ルーター障害や負荷バランサーの故障などの一時的なイベントのため）。ハッピーアイボールを使用して応答性を維持することは魅力的ですが、Webブラウザーは、ハッピーアイボールのために同じオリジンポリシーを変更してはなりません。
The simplest venue for the implementation of Happy Eyeballs is within the application itself. The algorithm specified in this document is relatively simple to implement and would require no specific support from the operating system beyond the commonly available APIs that provide transport service. It could also be added to applications by way of a specific Happy Eyeballs API, replacing or augmenting the transport service APIs.
幸せな眼球の実装のための最も簡単な会場は、アプリケーション自体にあります。このドキュメントで指定されているアルゴリズムは、実装が比較的簡単であり、輸送サービスを提供する一般的に利用可能なAPIを超えたオペレーティングシステムからの特定のサポートを必要としません。また、特定のHappy Eyeballs APIを介してアプリケーションに追加し、輸送サービスAPIを交換または増強することもできます。
To improve the IPv6 connectivity experience for legacy applications (e.g., applications that simply rely on the operating system's address preference order), operating systems may consider more sophisticated approaches. These can include changing default address selection sorting [RFC3484] based on configuration received from the network, or observing connection failures to IPv6 and IPV4 destinations.
レガシーアプリケーションのIPv6接続エクスペリエンスを改善するため（たとえば、オペレーティングシステムのアドレス選好順序に依存するアプリケーションなど）、オペレーティングシステムはより洗練されたアプローチを検討する場合があります。これらには、ネットワークから受信した構成に基づいて、デフォルトのアドレス選択ソート[RFC3484]の変更、またはIPv6およびIPv4の宛先への接続障害の観察が含まれます。
What follows is the algorithm implemented in Google Chrome and Mozilla Firefox.
以下は、Google ChromeとMozilla Firefoxに実装されているアルゴリズムです。
1. Call getaddinfo(), which returns a list of IP addresses sorted by the host's address preference policy.
1. ホストのアドレス選好ポリシーでソートされたIPアドレスのリストを返すgetaddinfo（）を呼び出します。
2. Initiate a connection attempt with the first address in that list (e.g., IPv6).
2. そのリストの最初のアドレスとの接続試行を開始します（例：IPv6）。
3. If that connection does not complete within a short period of time (Firefox and Chrome use 300 ms), initiate a connection attempt with the first address belonging to the other address family (e.g., IPv4).
3. その接続が短期間（FirefoxとChromeが300ミリ秒を使用する）以内に完了しない場合は、他のアドレスファミリ（例：IPv4）に属する最初のアドレスとの接続試行を開始します。
4. The first connection that is established is used. The other connection is discarded.
4. 確立された最初の接続が使用されます。他の接続は破棄されます。
If an algorithm were to cache connection success/failure, the caching would occur after step 4 determined which connection was successful.
アルゴリズムが接続の成功/失敗をキャッシュする場合、ステップ4がどの接続が成功したかを決定した後、キャッシュが発生します。
Other example algorithms include [Perreault] and [Andrews].
他の例アルゴリズムには、[Perreault]と[Andrews]が含まれます。
See Sections 4.4 and 5.6.
セクション4.4および5.6を参照してください。
The mechanism described in this paper was inspired by Stuart Cheshire's discussion at the IAB Plenary at IETF 72, the author's understanding of Safari's operation with SRV records, ICE [RFC5245], the current IPv4/IPv6 behavior of SMTP mail transfer agents, and the implementation of Happy Eyeballs in Google Chrome and Mozilla Firefox.
この論文で説明されているメカニズムは、IETF 72のIABプレナリーでのStuart Cheshireの議論に触発されました。著者のSRVレコード、ICE [RFC5245]、SMTPメール転送担当の現在のIPv4/IPv6挙動、および実装の著者の理解に触発されました。Google ChromeとMozilla Firefoxの幸せな眼球の。
Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van Beijnum for fostering the creation of this document.
この文書の作成を促進してくれたフレッド・ベイカー、ジェフ・キンズリ、クリスチャン・クーツ、イルジッチ・ヴァン・ベイナムに感謝します。
Thanks to Scott Brim, Rick Jones, Stig Venaas, Erik Kline, Bjoern Zeeb, Matt Miller, Dave Thaler, Dmitry Anipko, Brian Carpenter, and David Crocker for their feedback.
スコット・ブリム、リック・ジョーンズ、スティグ・ヴェナス、エリック・クライン、Bジョーン・ジーブ、マット・ミラー、デイブ・ターラー、ドミトリー・アニプコ、ブライアン・カーペンター、デビッド・クロッカーのフィードバックに感謝します。
Thanks to Javier Ubillos, Simon Perreault, and Mark Andrews for the active feedback and the experimental work on the independent practical implementations that they created.
Javier Ubillos、Simon Perreault、およびMark Andrewsに、アクティブなフィードバックと、作成した独立した実用的な実装に関する実験的作業に感謝します。
Also the authors would like to thank the following individuals who participated in various email discussions on this topic: Mohacsi Janos, Pekka Savola, Ted Lemon, Carlos Martinez-Cagnazzo, Simon Perreault, Jack Bates, Jeroen Massar, Fred Baker, Javier Ubillos, Teemu Savolainen, Scott Brim, Erik Kline, Cameron Byrne, Daniel Roesen, Guillaume Leclanche, Mark Smith, Gert Doering, Martin Millnert, Tim Durack, and Matthew Palmer.
また、著者は、このトピックに関するさまざまなメールディスカッションに参加した以下の個人に感謝したいと思います。MohacsiJanos、Pekka Savola、Ted Lemon、Carlos Martinez-Cagnazzo、Simon Perreault、Jack Bates、Jeroen Massar、Fred Baker、Javier Ubillos、Teemuサボレーン、スコット・ブリム、エリック・クライン、キャメロン・バーン、ダニエル・ローゼン、ギヨーム・レクランチ、マーク・スミス、ゲルト・ドーリング、マーティン・ミルナート、ティム・デュラック、マシュー・パーマー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[ADDR-SELECT] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, February 2012.
[Addr-Select] Matsumoto、A.、Fujisaki、T.、Kato、J。、およびT. Chown、「DHCPV6を使用した住所選択ポリシーの分散」、2012年2月の作業。
[Andrews] Andrews, M., "How to connect to a multi-homed server over TCP", January 2011, <http://www.isc.org/community/ blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp>.
[Andrews] Andrews、M。、「TCPを介したマルチホームサーバーに接続する方法」、2011年1月、<http://www.isc.org/community/ blog/201101/how-to-connect-to--a-multi-homed-server-over-tcp>。
[Experiences] Savolainen, T., Miettinen, N., Veikkolainen, S., Chown, T., and J. Morse, "Experiences of host behavior in broken IPv6 networks", March 2011, <http://www.ietf.org/proceedings/80/slides/ v6ops-12.pdf>.
[経験] Savolainen、T.、Miettinen、N.、Veikkolainen、S.、Chown、T。、およびJ. Morse、「壊れたIPv6ネットワークの宿主行動の経験」、2011年3月、<http：//www.ietf.org/proceedings/80/slides/v6ops-12.pdf>。
[Perreault] Perreault, S., "Happy Eyeballs in Erlang", February 2011, <http://www.viagenie.ca/news/ index.html#happy_eyeballs_erlang>.
[Perreault] Perreault、S。、「Happy Eyeballs in Erlang」、2011年2月、<http://www.viagenie.ca/news/ index.html＃happy_eyeballs_erlang>。
[RFC1671] Carpenter, B., "IPng White Paper on Transition and Other Considerations", RFC 1671, August 1994.
[RFC1671] Carpenter、B。、「移行およびその他の考慮事項に関するIPNGホワイトペーパー」、RFC 1671、1994年8月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、Carlson、J。、およびS. Cheshire、「IPv4（DNAV4）のネットワークアタッチメントの検出」、RFC 4436、2006年3月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、RFC 5245、2010年4月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
[RFC6059] Krishnan、S。およびG. Daley、「IPv6でのネットワークアタッチメントを検出するための簡単な手順」、RFC 6059、2010年11月。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157] Camarillo、G.、El Malki、K。、およびV. Gurbani、「セッション開始プロトコル（SIP）におけるIPv6遷移」、RFC 6157、2011年4月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269] Ford、M.、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「IPアドレス共有の問題」、RFC 6269、2011年6月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454] Barth、A。、「Web Origin Concept」、RFC 6454、2011年12月。
[WHITELIST] Google, "Google over IPv6", <http://www.google.com/intl/en/ipv6>.
[Whitelist] Google、「Google Over IPv6」、<http://www.google.com/intl/en/ipv6>。
Authors' Addresses
著者のアドレス
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
Dan Wing Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USA
EMail: dwing@cisco.com
Andrew Yourtchenko Cisco Systems, Inc. De Kleetlaan, 7 Diegem B-1831 Belgium
Andrew Yourtchenko Cisco Systems、Inc。de Kleetlaan、7 Diegem B-1831ベルギー
EMail: ayourtch@cisco.com