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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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ホワイトリストを使用して、ユーザーの利便性を高めることができる（例えば、[WHITELIST]）。しかし、これは（世界的な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のトラフィックが倍増し、ホストのアドレスの好みでは傷つかないネットワークおよびサーバは（例えば、[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専用デュアルスタックから遷移しながらのIPv4の負荷を軽減するために、そして、最も重要なIPv4ネットワークから負荷を除去するために依然としてのIPv6を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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The basis of the IPv6/IPv4 selection problem was first described in 1994 in [RFC1671]:
IPv6 / IPv4の選択問題の基本は、最初の[RFC1671]で1994年に記載されました。
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ホストBへのIPngホストAからの途中で時々（予測できない）の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）に直接適用可能です。アプリケーションは、要求/応答セマンティクスを有する場合、コネクションレスのトランスポートプロトコル（例えば、UDP）のために、同様のメカニズムを使用することができる（例えば、作業のIPv6またはIPv4メディア経路[RFC6157]を選択するインタラクティブ接続確立（ICE）によって行われるように）。
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.example.com」）、特定のクライアント技術（例えば、IPv6クライアント）との依存関係（例えば、作業のIPv6パス）でのみアクセス可能であるが、名前空間の断片化を引き起こし、ユーザーのための能力を減少させ、別の名前空間を使用しますホスト名を共有することができます。また、ホスト名が含まれて印刷物を複雑にします。
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.
クライアントは、サーバ（1-4）のIPv4とIPv6のレコードを取得します。クライアントは、時間の数秒を消費する、（6-8）のサーバーにIPv6を使用して接続しようとしますが、IPv6のパスが壊れています。最終的に、クライアントは成功した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:
「ハッピー眼球」アルゴリズムは、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上に同時に2つのTCPのSYNを送信する（7）。図では、IPv6のパスが壊れているが、IPv4を使用前には長い遅延がないので、ユーザにほとんど影響を与えません。アプリケーションは、（10）を放棄するまでのIPv6経路が再試行されます。
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：ハッピー眼球フロー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インフラ上の不要なトラフィックの急増を生じさせないことが重要です。その目標を達成するには、対応のハッピー眼球アルゴリズムは、このセクションの要件を遵守しなければなりません。
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.
IPv4専用であるホスト、IPv6-のみ（例えば、センサ）は、ホスト、およびデュアルスタックホスト - 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: 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アドレスを共有される可能性があります。デュアルスタックホストが優位性を持っている：彼らは、この文書に記載された技術を利用することができます意味のIPv6またはIPv4を利用することができます。 IPv4のみのホストは欠点を持っている：彼らはIPv4のみを利用することができます。すべてのホスト（デュアルスタックとIPv4のみ）はIPv4を使用している場合は、共有IPv4アドレスのための追加の競合があります。 （彼らはIPv4のみを使用することができるよう）デュアルスタックホストがIPv6を使用してそれを避けることができますしながら、IPv4のみのホストは、その競合を回避することはできません。
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トラフィックがあるでしょう。これらのデュアルスタックホストは（彼らがIPv4を使用しようとする前に、数十秒でタイムアウトして）IPv6を使用するには非常に強い好みを持っているので、これは、特にハッピー眼球を実装していないデュアルスタックホストにも当てはまります。
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機器への投資を削減したいと思うでしょう - ロードバランサ、ピアリングのリンク、およびアドレス共有デバイス。ハッピー眼球の実装がどのアドレスファミリに接続することによっても同様にIPv6とIPv4を扱う場合は最速で、それは、IPv4にロードするために貢献していきます。 （IPv4アドレスの共有の競合を増加し、IPv4ロードバランサの負荷を増加させることによって）、この荷重の影響IPv4専用デバイス。このため、ISPやコンテンツプロバイダは、それが不可能IPv4機器への投資を削減することができます。これは、IPv4への投資を減少させることができないため、IPv6へ移行するためのコストが増加していることを意味します。また、接続速度を測定するのみのメトリックを使用して、IPv4アドレスのような改善されたジオロケーション[RFC6269]として共有、大翻訳を横断による運命共有の欠如と比較した場合、IPv6がもたらす利点を無視します。
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.
セクション4.2で説明ステートフルなアルゴリズムを実装しない限り、このように、IPv4のみのホストを害する避けるために、実装は、ホストのアドレス優先ポリシーによって返される最初のIPアドレスファミリを優先しなければなりません。これは、通常、その嗜好は、ユーザ設定によって、またはネットワーク構成[ADDR-SELECT]で上書きすることができるが、IPv4の上のIPv6に優先を与えることを意味します。ホストのポリシーが不明または達成可能でない場合、実装は、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.
いくつかの幸せな眼球アルゴリズムは、ステートフルです - つまり、アルゴリズムはように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.
（5.5節を参照）は、好ましいアドレスファミリー（例えば、IPv6）の上の接続試行を行うと、一定時間内に接続を確立するために失敗した後、ハッピー眼球の実装では、同じアドレスファミリを使用して、第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の両方の接続試行の簡単な倍増を回避することができます。実装上の注意：これはハッピー眼球の状態をフラッシュすることによって達成することができます大幅にアプリケーションの後続の接続のセットアップ時間に悪影響を及ぼすことはありません10分ごと、。優先アドレスファミリを使用して接続が再び成功した場合、優先アドレスファミリは、後続の接続のために使用されるべきです。この実装はステートフルであるため、それが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接続を破壊）、ハッピー眼球アルゴリズムを再初期化する必要があります。インターフェイスは、種々の機構によって、ネットワーク（再）初期化を決定することができる（例えば、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 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).
HTTP：いくつかのサイトの設計が原因で、クライアントのIPアドレスを組み込み、すべての接続が同じIPアドレスからも必要とHTTPクッキーを破ることができます。同じクライアントからのいくつかの接続は、異なる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.
アプリケーションは、（AAAAクエリを介して学習）ネイティブのIPv6アドレス及び（クエリを介して学習）ネイティブのIPv4アドレスを認識するために、このようなデュアルスタックホストとして、いくつかの過渡的な技術のために、それは簡単です。 IPv6の/ IPv4の変換が難しいことになりますが、デュアルスタッククライアントは、ネイティブIPアドレスファミリを使用することができますので、IPv6の/のIPv4トランスレータは、デュアルスタッククライアントとネットワーク上に展開する必要はありません。
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インタフェース：デュアルスタックホストは、通常、二つの論理インタフェースを有しています。しかし、デュアルスタックホストが、なぜならなぜならなぜなら、有線および無線イーサネット（登録商標）などの複数の物理インタフェースで、（第3のインタフェースは、多くの場合、遠隔企業ネットワークによって割り当てられたトンネルアドレスである）VPNつ以上の論理的なインタフェースを有するかもしれませんホストが複数のVLAN、またはその他の理由に属します。二つ以上の論理インタフェースで満足して眼球の相互作用は、今後の検討課題です。
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 address. If that fails after a certain time (see Section 5.5), the next address SHOULD be the IPv4 address.
AまたはAAAAリソースレコードのDNSクエリが複数のAまたはAAAAアドレスを返すことも可能です。これが発生すると、幸せな眼球の実装のため、ホストのアドレス優先の方針を以下のと応答が最初のアドレスを試すことが推奨されます。それは（セクション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を参照）一定時間後に接続に失敗した場合、ハッピー眼球の実装では、返された他のアドレスを試してみてください。これらの接続試行の順序は重要ではありません。
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レコードに有用であろう。複数のAAAAレコードがハッピー眼球及びその壊れているIPv6接続を使用していないクライアントに返される場合は、それがさらに戻ったIPv4にフォール遅延が増加します。このように、ネイティブIPv6接続でWebサイト運営者は、複数のAAAAレコードを申し出てはなりません。ハッピー眼球が広く将来的に展開されている場合は、この勧告は再訪される可能性があります。
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を越えて、オペレーティング・システムからの特定のサポートを必要としないでしょう。また、トランスポート・サービス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.
ホストのアドレス優先ポリシーによってソートされたIPアドレスのリストを返します。1.通話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の）に属する第1のアドレスとの接続の試行を開始します。
4. The first connection that is established is used. The other connection is discarded.
前記確立された最初の接続が使用されます。他の接続が破棄されます。
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].
他の例示的なアルゴリズムは、[アンドリュース] [ペロー]含み、。
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総会でスチュアートチェシャーの議論に触発された、SRVレコード、ICE [RFC5245]、SMTPメール転送エージェントの現在のIPv4 / IPv6の行動、および実装とSafariの操作の著者の理解GoogleのChromeとMozilla Firefoxの中の幸せな眼球。
Thanks to Fred Baker, Jeff Kinzli, Christian Kuhtz, and Iljitsch van Beijnum for fostering the creation of this document.
このドキュメントの作成を育むためのフレッド・ベイカー、ジェフKinzli、クリスチャンKuhtz、およびIljitschバンBeijnumに感謝します。
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.
彼らのフィードバックのためのスコット・ブリム、リック・ジョーンズ、スティグVenaas、エリック・クライン、ビョルンゼエブ、マット・ミラー、デーブターラー、ドミトリーAnipko、ブライアン・カーペンター、そしてデビッド・クロッカーに感謝します。
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.
アクティブフィードバックと、彼らが作成した独立した実用的な実装上の実験研究のためのハビエルUbillos、サイモンペロー、そしてマーク・アンドリュースに感謝します。
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.
Mohacsiヤーノシュ、ペッカSavola、テッド・レモン、カルロス・マルティネス・Cagnazzo、サイモン・ペロー、ジャック・ベイツ、イェルーンMassar、フレッド・ベイカー、ハビエルUbillos、テーム：また、著者は、このトピックに関するさまざまな電子メールの議論に参加した以下の個人に感謝したいと思いますSavolainenの、スコット・ブリム、エリック・クライン、キャメロン・バーン、ダニエルRoesen、ギョームルクランシェ、マーク・スミス、ゲルトDoering、マーティンMillnert、ティム・デュラック、そしてマシュー・パーマー。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、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]松本、A.、藤崎、T.、加藤、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>.
[アンドリュース]アンドリュース、M.、「どのようにTCP上でマルチホームサーバーに接続する」、2011年1月、<http://www.isc.org/community/ブログ/ 201101 /ハウツーコネクト・ツー・マルチホーム・サーバー・オーバー-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.モース、 "壊れたIPv6ネットワーク内のホスト挙動の経験"、2011年3月、<HTTP：//www.ietf .ORG /手続き/ 80 /スライド/ v6ops-12.pdf>。
[Perreault] Perreault, S., "Happy Eyeballs in Erlang", February 2011, <http://www.viagenie.ca/news/ index.html#happy_eyeballs_erlang>.
[ペロー]ペロー、S.、 "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]大工、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.、カールソン、J.、およびS.チェシャー、 "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]ローゼンバーグ、J.、 "インタラクティブ接続確立（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]クリシュナン、S.およびG.デイリー、 "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]キャマリロ、G.、エルMalki、K.、およびV. Gurbani、 "セッション開始プロトコルにおけるIPv6移行（SIP）"、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]フォード、M.、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、RFC 6269、2011年6月、 "IPアドレスの共有に関する問題"。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]バース、A.、 "ウェブ起源コンセプト"、RFC 6454、2011年12月。
[WHITELIST] Google, "Google over IPv6", <http://www.google.com/intl/en/ipv6>.
[WHITELIST]グーグル、 "IPv6を介しグーグル"、<http://www.google.com/intl/en/ipv6>。
Authors' Addresses
著者のアドレス
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
ダン・ウィングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA
EMail: dwing@cisco.com
メールアドレス：dwing@cisco.com
Andrew Yourtchenko Cisco Systems, Inc. De Kleetlaan, 7 Diegem B-1831 Belgium
アンドリューYourtchenkoシスコシステムズ、株式会社デKleetlaan、7ディーゲムB-1831ベルギー
EMail: ayourtch@cisco.com
メールアドレス：ayourtch@cisco.com