[要約] RFC 6589は、IPv6へのコンテンツの移行に関する考慮事項をまとめたものであり、IPv6への移行を円滑に行うためのガイドラインを提供しています。
Internet Engineering Task Force (IETF) J. Livingood
Request for Comments: 6589 Comcast
Category: Informational April 2012
ISSN: 2070-1721
Considerations for Transitioning Content to IPv6
コンテンツのIPv6への移行に関する考慮事項
Abstract
概要
This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers.
このドキュメントでは、インターネット上のエンドユーザーコンテンツのIPv6への移行に関する考慮事項について説明します。これはエンドユーザーのコンテンツ（通常はWebベース）に対応するように調整されていますが、このドキュメントの多くの側面は、他のアプリケーションやサービスのIPv6への移行にさらに広く適用できます。このドキュメントでは、IPv6への移行に伴う課題、潜在的な移行戦略、可能な移行フェーズ、およびその他の考慮事項について説明します。このドキュメントの対象読者は、一般にインターネットコミュニティ、特に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/rfc6589.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6589で入手できます。
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 ....................................................4
2. Challenges When Transitioning Content to IPv6 ...................4
2.1. IPv6-Related Impairment ....................................5
2.2. Operational Maturity Concerns ..............................5
2.3. Volume-Based Concerns ......................................5
3. IPv6 Adoption Implications ......................................6
4. Potential Migration Tactics .....................................6
4.1. Solving Current End-User IPv6 Impairments ..................7
4.2. Using IPv6-Specific Names ..................................8
4.3. Implementing DNS Resolver Whitelisting .....................8
4.3.1. How DNS Resolver Whitelisting Works ................11
4.3.2. Similarities to Content Delivery Networks
and Global Server Load Balancing ...................15
4.3.3. Similarities to DNS Load Balancing .................15
4.3.4. Similarities to Split DNS ..........................15
4.3.5. Related Considerations .............................16
4.4. Implementing DNS Blacklisting .............................17
4.5. Transitioning Directly to Native Dual Stack ...............18
5. Potential Implementation Phases ................................19
5.1. No Access to IPv6 Content .................................19
5.2. Using IPv6-Specific Names .................................19
5.3. Deploying DNS Resolver Whitelisting Using Manual
Processes .................................................19
5.4. Deploying DNS Resolver Whitelisting Using
Automated Processes .......................................19
5.5. Turning Off DNS Resolver Whitelisting .....................20
5.6. Deploying DNS Blacklisting ................................20
5.7. Fully Dual-Stack Content ..................................20
6. Other Considerations ...........................................20
6.1. Security Considerations ...................................20
6.2. Privacy Considerations ....................................21
6.3. Considerations with Poor IPv4 and Good IPv6 Transport .....22
7. Contributors ...................................................23
8. Acknowledgements ...............................................23
9. References .....................................................24
9.1. Normative References ......................................24
9.2. Informative References ....................................25
This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. The issues explored herein will be of particular interest to major web content sites (sometimes described hereinafter as "high-service-level domains"), which have specific and unique concerns related to maintaining a high-quality user experience for all of their users during their transition to IPv6. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. Some sections of this document also include information about the potential implications of various migration tactics or phased approaches to the transition to IPv6.
このドキュメントでは、インターネット上のエンドユーザーコンテンツのIPv6への移行に関する考慮事項について説明します。これはエンドユーザーのコンテンツ（通常はWebベース）に対応するように調整されていますが、このドキュメントの多くの側面は、他のアプリケーションやサービスのIPv6への移行にさらに広く適用できます。ここで検討される問題は、主要なWebコンテンツサイト（以降、「高サービスレベルドメイン」と記載されることもあります）にとって特に興味深いものです。 IPv6への移行。このドキュメントでは、IPv6への移行に伴う課題、潜在的な移行戦略、可能な移行フェーズ、およびその他の考慮事項について説明します。このドキュメントの一部のセクションには、IPv6への移行に対するさまざまな移行戦術または段階的アプローチの潜在的な影響に関する情報も含まれています。
The goal in transitioning content to IPv6 is to make that content natively dual-stack enabled, which provides native access to all end users via both IPv4 and IPv6. However, there are technical and operational challenges in being able to transition smoothly for all end users, which has led to the development of a variety of migration tactics. A first step in understanding various migration tactics is to first outline the challenges involved in moving content to IPv6.
コンテンツをIPv6に移行する目的は、そのコンテンツをネイティブにデュアルスタック対応にすることです。これにより、IPv4とIPv6の両方を介してすべてのエンドユーザーにネイティブアクセスが提供されます。ただし、すべてのエンドユーザーがスムーズに移行できるようにするためには、技術的および運用上の課題があり、さまざまな移行戦略の開発につながっています。さまざまな移行戦術を理解するための最初のステップは、コンテンツをIPv6に移行することに伴う課題を最初に概説することです。
Implementers of these various migration tactics are attempting to protect users of their services from having a negative experience (poor performance) when they receive DNS responses containing AAAA resource records or when attempting to use IPv6 transport. There are two main concerns that pertain to this practice: one is IPv6-related impairment, and the other is the maturity or stability of IPv6 transport (and associated network operations) for high-service-level domains. Both can negatively affect the experience of end users.
これらのさまざまな移行戦術の実装者は、AAAAリソースレコードを含むDNS応答を受信したとき、またはIPv6トランスポートを使用しようとしたときに、サービスのユーザーが悪い体験（パフォーマンスの低下）から保護することを試みています。このプラクティスに関連する2つの主な懸念事項があります。1つはIPv6関連の障害であり、もう1つは高サービスレベルドメインのIPv6トランスポート（および関連するネットワーク操作）の成熟度または安定性です。どちらもエンドユーザーのエクスペリエンスに悪影響を及ぼす可能性があります。
Not all domains may face the same challenges in transitioning content to IPv6, since the user base of each domain, traffic sources, traffic volumes, and other factors obviously will vary between domains. As a result, while some domains have used an IPv6 migration tactic, others have run brief IPv6 experiments and then decided to simply turn on IPv6 for the domain without further delay and without using any specialized IPv6 migration tactics [Heise]. Each domain should therefore consider its specific situation when formulating a plan to move to IPv6; there is not one approach that will work for every domain.
各ドメインのユーザーベース、トラフィックソース、トラフィック量、およびその他の要因は明らかにドメイン間で異なるため、すべてのドメインがコンテンツをIPv6に移行する際に同じ課題に直面するわけではありません。その結果、一部のドメインはIPv6移行戦術を使用していましたが、IPv6の簡単な実験を行った後、特別なIPv6移行戦術を使用せずに、ドメインに対してIPv6を単にオンにすることを決定しました[Heise]。したがって、各ドメインは、IPv6への移行計画を策定する際に特定の状況を考慮する必要があります。すべてのドメインで機能するアプローチは1つではありません。
Some implementers have observed that when they added AAAA resource records to their authoritative DNS servers in order to support IPv6 access to their content, a small fraction of end users had slow or otherwise impaired access to a given website with both AAAA and A resource records. The fraction of users with such impaired access has been estimated to be as high as 0.078% of total Internet users [IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness].
一部の実装者は、コンテンツへのIPv6アクセスをサポートするために権威あるDNSサーバーにAAAAリソースレコードを追加すると、ほんの一部のエンドユーザーが、AAAAとAの両方のリソースレコードを持つ特定のWebサイトへのアクセスが遅いか、そうでなければ損なわれることを観察しました。このようなアクセス障害を持つユーザーの割合は、インターネットユーザー全体の0.078％と推定されています[IETF-77-DNSOP] [NW-Article-DNSOP] [IPv6-Growth] [IPv6-Brokenness]。
While it is outside the scope of this document to explore the various reasons why a particular user's system (host) may have impaired IPv6 access, and the potential solutions [RFC6555] [RFC6343], for the users who experience this impairment, it has a very real performance impact. It would impact access to all or most dual-stack services to which the user attempts to connect. This negative end-user experience can range from access that is somewhat slower than usual (as compared to native IPv4-based access), to extremely slow access, to no access to the domain's resources whatsoever. In essence, whether the end user even has an IPv6 address or not, merely by receiving a AAAA record response, the user either cannot access a Fully Qualified Domain Name (FQDN, representing a service or resource sought) or it is so slow that the user gives up and assumes the destination is unreachable.
特定のユーザーのシステム（ホスト）がIPv6アクセスを損なった可能性のあるさまざまな理由と、この障害を経験したユーザーのための可能な解決策[RFC6555] [RFC6343]を調査することは、このドキュメントの範囲外ですが、非常に実際のパフォーマンスへの影響。ユーザーが接続しようとするすべてまたはほとんどのデュアルスタックサービスへのアクセスに影響します。この否定的なエンドユーザーエクスペリエンスは、通常の（ネイティブのIPv4ベースのアクセスと比較して）やや遅いアクセスから、非常に遅いアクセス、ドメインのリソースへのアクセスがまったくないものまでさまざまです。本質的に、エンドユーザーがIPv6アドレスを持っているかどうかに関係なく、AAAAレコード応答を受信するだけで、ユーザーは完全修飾ドメイン名（FQDN、必要なサービスまたはリソースを表す）にアクセスできないか、非常に遅いためユーザーはあきらめ、目的地に到達できないと想定します。
Some implementers have discovered that network operations, operations support and business support systems, and other operational processes and procedures are less mature for IPv6 as compared to IPv4, since IPv6 has not heretofore been pervasively deployed. This operational immaturity may be observed not just within the network of a given domain but also in any directly or indirectly interconnected networks. As a result, many domains consider it prudent to undertake any network changes that will cause traffic to shift to IPv6 gradually, in order to provide time and experience for IPv6 operations and network practices to mature.
IPv6はこれまで普及していないため、ネットワーク運用、運用サポート、ビジネスサポートシステム、およびその他の運用プロセスと手順は、IPv4に比べてIPv6では成熟していないことが一部の実装者によって発見されました。この運用上の未成熟は、特定のドメインのネットワーク内だけでなく、直接または間接的に相互接続されたネットワークでも観察される可能性があります。その結果、多くのドメインでは、IPv6の運用とネットワークプラクティスが成熟するための時間と経験を提供するために、トラフィックをIPv6に徐々にシフトさせるネットワーク変更を行うことが賢明であると考えています。
While Section 2.2 pertains to risks due to immaturity in operations, a related concern is that some technical issues may not become apparent until some moderate to high volume of traffic is sent via IPv6 to and from a domain. As above, this may be the case not just within the network of that domain but also for any directly or indirectly interconnected networks. Furthermore, compared to domains with small to moderate traffic volumes, whether by the count of end users or count of bytes transferred, high-traffic domains receive such a level of usage that it is prudent to undertake any network changes gradually and in a manner that minimizes the risk of disruption. One can imagine that for one of the top ten sites globally, for example, the idea of suddenly turning on a significant amount of IPv6 traffic is quite daunting and would carry a relatively high risk of network and/or other disruptions.
セクション2.2は運用の未成熟によるリスクに関係していますが、関連する懸念として、中程度から大量のトラフィックがIPv6を介してドメインとの間で送信されるまで、技術的な問題が明らかにならない場合があります。上記のように、これはそのドメインのネットワーク内だけでなく、直接または間接的に相互接続されたネットワークにも当てはまります。さらに、トラフィック量の少ないドメインから中程度のドメインに比べて、エンドユーザーの数または転送されたバイト数のいずれかによって、トラフィック量の多いドメインは、ネットワークの変更を徐々に、かつ、混乱のリスクを最小限に抑えます。たとえば、世界のトップ10サイトの1つで、大量のIPv6トラフィックを突然オンにするという考えは非常に困難であり、ネットワークやその他の混乱のリスクが比較的高いと考えられます。
It is important that the challenges in transitioning content to IPv6 as noted in Section 2 are addressed, especially for high-service-level domains. Some high-service-level domains may find the prospect of transitioning to IPv6 extremely daunting without having some ability to address these challenges and to incrementally control their transition to IPv6. Lacking such controls, some domains may choose to substantially delay their transition to IPv6. A substantial delay in moving content to IPv6 could certainly mean there are somewhat fewer motivating factors for network operators to deploy IPv6 to end-user hosts (though they have many significant motivating factors that are largely independent of content). At the same time, unless network operators transition to IPv6, there are of course fewer motivations for domain owners to transition content to IPv6. Without progress in each part of the Internet ecosystem, networks and/or content sites may delay, postpone, or cease adoption of IPv6, or to actively seek alternatives to it. Such alternatives may include the use of multi-layer or large-scale network address translation (NAT), which is not preferred relative to native dual stack.
セクション2で説明したように、コンテンツをIPv6に移行する際の課題に対処することは、特に高サービスレベルドメインの場合に重要です。一部の高サービスレベルドメインでは、これらの課題に対処し、IPv6への移行を段階的に制御する能力がなければ、IPv6への移行の見通しが非常に困難になる場合があります。このような制御がないため、一部のドメインはIPv6への移行を大幅に遅らせることを選択する場合があります。コンテンツをIPv6に移行する際の大幅な遅延は、ネットワークオペレーターがIPv6をエンドユーザーホストに展開する動機付け要素が多少少ないことを意味します（コンテンツにはほとんど依存しない多くの重要な動機付け要素があります）。同時に、ネットワークオペレーターがIPv6に移行しない限り、ドメイン所有者がコンテンツをIPv6に移行する動機は当然少なくなります。インターネットエコシステムの各部分で進歩がなければ、ネットワークやコンテンツサイトはIPv6の採用を遅らせたり、延期したり、中止したり、IPv6の代替策を積極的に模索したりする可能性があります。このような代替手段には、ネイティブデュアルスタックに比べて好ましくない、多層または大規模ネットワークアドレス変換（NAT）の使用が含まれる場合があります。
Obviously, transitioning content to IPv6 is important to IPv6 adoption overall. While challenges do exist, such a transition is not an impossible task for a domain to undertake. A range of potential migration tactics, as noted below in Section 4, can help meet these challenges and enable a domain to successfully transition content and other services to IPv6.
明らかに、IPv6へのコンテンツの移行は、IPv6の採用全体にとって重要です。課題は存在しますが、そのような移行は、ドメインが着手する不可能な作業ではありません。以下のセクション4で説明するように、潜在的な移行戦略の範囲は、これらの課題を解決し、ドメインがコンテンツやその他のサービスをIPv6に正常に移行できるようにするのに役立ちます。
Domains have a wide range of potential tactics at their disposal that may be used to facilitate the migration to IPv6. This section includes many of the key tactics that could be used by a domain but by no means provides an exhaustive or exclusive list. Only a specific domain can judge whether or not a given (or any) migration tactic applies to it and meets its needs. A domain may also decide to pursue several of these tactics in parallel. Thus, the usefulness of each tactic and the associated pros and cons will vary from domain to domain.
ドメインには、IPv6への移行を容易にするために使用できる可能性のある幅広い潜在的な戦術があります。このセクションには、ドメインで使用できる主要な戦術の多くが含まれていますが、完全または排他的なリストを提供するものではありません。特定のドメインのみが、特定の（または任意の）移行戦術が適用され、そのニーズを満たしているかどうかを判断できます。ドメインは、これらの戦術のいくつかを並行して追求することを決定する場合もあります。したがって、各戦術の有用性と関連する長所と短所は、ドメインごとに異なります。
Domains can endeavor to fix the underlying technical problems experienced by their end users during the transition to IPv6, as noted in Section 2.1. One challenge with this option is that a domain may have little or no control over the network connectivity, operating system, client software (such as a web browser), and/or other capabilities of the end users of that domain. In most cases, a domain is only in a position to influence and guide its end users. While this is not the same sort of direct control that may exist, for example, in an enterprise network, major domains are likely to be trusted by their end users and may therefore be able to influence and guide these users in solving any IPv6-related impairments.
セクション2.1で述べたように、ドメインはIPv6への移行中にエンドユーザーが経験する根本的な技術的問題を修正するよう努めることができます。このオプションの1つの課題は、ドメインがネットワーク接続、オペレーティングシステム、クライアントソフトウェア（Webブラウザーなど）、および/またはそのドメインのエンドユーザーの他の機能をほとんどまたはまったく制御できない可能性があることです。ほとんどの場合、ドメインはエンドユーザーに影響を与え、導くための立場にあるだけです。これは、たとえばエンタープライズネットワークに存在する可能性のある直接的な制御とは異なりますが、主要なドメインはエンドユーザーから信頼されている可能性が高いため、これらのユーザーに影響を与え、IPv6関連の解決に導くことができます。障害。
Another challenge is that end-user impairments are something that one domain on its own cannot solve. This means that domains may find it more effective to coordinate with many others in the Internet community to solve what is really a collective problem that affects the entire Internet. Of course, it can sometimes be difficult to motivate members of the Internet community to work collectively towards such a goal, sharing the labor, time, and costs related to such an effort. However, World IPv6 Day [W6D] shows that such community efforts are possible, and despite any potential challenges, the Internet community continues to work together in order to solve end-user IPv6 impairments.
もう1つの課題は、エンドユーザーの障害は1つのドメインだけでは解決できない問題です。これは、ドメインがインターネットコミュニティ内の他の多くの人々と連携して、インターネット全体に影響を与える実際に集団的な問題であるものを解決することがより効果的であると感じる場合があることを意味します。もちろん、インターネットコミュニティのメンバーがそのような目標に向けて共同で作業し、そのような作業に関連する労力、時間、およびコストを分かち合うよう動機づけることは困難な場合があります。ただし、World IPv6 Day [W6D]は、そのようなコミュニティの取り組みが可能であることを示しており、潜在的な課題があるにもかかわらず、インターネットコミュニティはエンドユーザーのIPv6障害を解決するために引き続き協力しています。
One potential tactic may be to identify which users have such impairments and then to communicate this information to affected users. Such end-user communication is likely to be most helpful if the end users are not only alerted to a potential problem but are given careful and detailed advice on how to resolve this on their own, or are guided to where they can seek help in doing so. Another potential tactic is for a domain to collect, track over time, and periodically share with the Internet community the rate of impairment observed for that domain. In any such end-user IPv6-related analysis and communication, Section 6.2 is worth taking into account.
潜在的な戦術の1つは、そのような障害のあるユーザーを特定し、この情報を影響を受けるユーザーに伝えることです。このようなエンドユーザーとのコミュニケーションは、エンドユーザーが潜在的な問題を警告されるだけでなく、これを自分で解決する方法について注意深く詳細なアドバイスを受けている場合、またはエンドユーザーが支援を求めることができる場所に案内されている場合に最も役立ちます。そう。もう1つの潜在的な戦術は、ドメインが時間をかけて収集、追跡し、そのドメインで観察された障害率をインターネットコミュニティと定期的に共有することです。このようなエンドユーザーのIPv6関連の分析と通信では、セクション6.2を考慮する価値があります。
However, while these tactics can help reduce IPv6-related impairments (Section 2.1), they do not address either operational maturity concerns (noted in Section 2.2) or volume-based concerns (noted in Section 2.3), which should be considered and addressed separately.
ただし、これらの戦術はIPv6関連の障害（セクション2.1）を減らすのに役立ちますが、運用上の成熟度の懸念（セクション2.2に記載）またはボリュームベースの懸念（セクション2.3に記載）のいずれにも対処しません。 。
Another potential migration tactic is for a domain to gain experience using a special FQDN. This has become typical for domains beginning the transition to IPv6, whereby an address-family-specific name such as ipv6.example.com or www.ipv6.example.com is used. An end user would have to know to use this special IPv6-specific name; it is not the same name used for regular traffic.
別の潜在的な移行戦術は、ドメインが特別なFQDNを使用して経験を積むことです。これは、IPv6への移行を開始するドメインでは一般的になり、ipv6.example.comやwww.ipv6.example.comなどのアドレスファミリ固有の名前が使用されます。エンドユーザーは、この特別なIPv6固有の名前を使用することを知っている必要があります。通常のトラフィックに使用される名前とは異なります。
This special IPv6-specific name directs traffic to a host or hosts that have been enabled for native IPv6 access. In some cases, this name may point to hosts that are separate from those used for IPv4 traffic (via www.example.com), while in other cases it may point to the same hosts used for IPv4 traffic. A subsequent phase, if separate hosts are used to support special IPv6-specific names, is to move to the same hosts used for regular traffic in order to utilize and exercise production infrastructure more fully. Regardless of whether or not dedicated hosts are used, the use of the special name is a way to incrementally control traffic as a tool for a domain to gain IPv6 experience and increase IPv6 use on a relatively controlled basis. Any lessons learned can then inform plans for a full transition to IPv6. This also provides an opportunity for a domain to develop any necessary training for staff, to develop IPv6-related testing procedures for its production network and lab, to deploy IPv6 functionality into its production network, and to develop and deploy IPv6-related network and service monitors. It is also an opportunity to add a relatively small amount of IPv6 traffic to ensure that network gear, network interconnects, and IPv6 routing in general are working as expected.
この特別なIPv6固有の名前は、ネイティブIPv6アクセスが有効になっているホストにトラフィックを転送します。この名前は、（www.example.comを介して）IPv4トラフィックに使用されるホストとは別のホストを指す場合もあれば、IPv4トラフィックに使用される同じホストを指す場合もあります。特別なIPv6固有の名前をサポートするために別のホストが使用されている場合、後続のフェーズは、通常のトラフィックに使用されているのと同じホストに移動して、運用インフラストラクチャをより完全に利用および実行することです。専用ホストを使用するかどうかに関係なく、特別な名前を使用することで、ドメインのツールとしてトラフィックを段階的に制御して、IPv6エクスペリエンスを獲得し、比較的制御された方法でIPv6の使用を増やすことができます。学んだ教訓は、IPv6への完全な移行の計画を伝えることができます。これは、ドメインがスタッフに必要なトレーニングを開発し、本番ネットワークとラボのIPv6関連のテスト手順を開発し、IPv6機能を本番ネットワークに展開し、IPv6関連のネットワークとサービスを開発して展開する機会も提供しますモニター。また、比較的少量のIPv6トラフィックを追加して、ネットワークギア、ネットワーク相互接続、およびIPv6ルーティング全般が期待どおりに機能するようにする機会でもあります。
While using a special IPv6-specific name is a good initial step to functionally test and prepare a domain for IPv6 -- including developing and maturing IPv6 operations, as noted in Section 2.2 -- the utility of the tactic is limited, since users must know the IPv6- specific name, the traffic volume will be low, and the traffic is unlikely to be representative of the general population of end users (they are likely to be self-selecting early adopters and more technically advanced than average), among other reasons. As a result, any concerns and risks related to traffic volume, as noted in Section 2.3, should still be considered and addressed separately.
特別なIPv6固有の名前を使用することは、IPv6のドメインを機能的にテストおよび準備するための良い最初のステップです（セクション2.2で説明したように、IPv6操作の開発と成熟を含む）-ユーザーが知る必要があるため、戦術のユーティリティは制限されますIPv6固有の名前、トラフィック量は少なく、トラフィックはエンドユーザーの一般的な人口を代表する可能性は低いです（それらは、自己選択型アーリーアダプターであり、平均よりも技術的に進んでいる可能性があります）。 。その結果、セクション2.3で述べたように、トラフィック量に関連する懸念やリスクは、引き続き個別に検討して対処する必要があります。
Another potential tactic -- especially when a high-service-level domain is ready to move beyond an IPv6-specific name, as described in Section 4.2 -- is to selectively return AAAA resource records (RRs), which contain IPv6 addresses. This selective response of DNS records is performed by an authoritative DNS server for a domain in response to DNS queries sent by DNS recursive resolvers [RFC1035]. This is commonly referred to in the Internet community as "DNS Resolver Whitelisting", and will be referred to as such hereafter, though in essence it is simply a tactic enabling the selective return of DNS records based upon various technical factors. An end user is seeking a resource by name, and this selective response mechanism enables what is perceived to be the most reliable and best performing IP address family to be used (IPv4 or IPv6). It shares similarities with Content Delivery Networks (CDNs), Global Server Load Balancing (GSLB), DNS Load Balancing, and Split DNS, as described below in Sections 4.3.2, 4.3.3, and 4.3.4. A few high-service-level domains have either implemented DNS Resolver Whitelisting (one of many migration tactics they have used or are using) or are considering doing so [NW-Article-DNS-WL] [WL-Ops].
別の潜在的な戦術-特にセクション4.2で説明されているように、サービスレベルの高いドメインがIPv6固有の名前を超える準備ができている場合-は、IPv6アドレスを含むAAAAリソースレコード（RR）を選択的に返すことです。 DNSレコードのこの選択的な応答は、DNS再帰リゾルバ[RFC1035]によって送信されたDNSクエリに応答して、ドメインの権威あるDNSサーバーによって実行されます。これはインターネットコミュニティでは一般に「DNSリゾルバーホワイトリスト」と呼ばれ、以降、そのように呼ばれますが、本質的には、さまざまな技術的要因に基づいてDNSレコードを選択的に返すことを可能にする戦術です。エンドユーザーは名前でリソースを探しており、この選択的応答メカニズムにより、最も信頼性が高く、最もパフォーマンスの高いIPアドレスファミリ（IPv4またはIPv6）であると認識されているものが認識されます。以下のセクション4.3.2、4.3.3、および4.3.4で説明するように、コンテンツ配信ネットワーク（CDN）、グローバルサーバーロードバランシング（GSLB）、DNSロードバランシング、およびスプリットDNSと類似点があります。いくつかの高サービスレベルドメインは、DNSリゾルバーホワイトリスト（実装または使用している多くの移行戦略の1つ）を実装しているか、実装を検討しています[NW-Article-DNS-WL] [WL-Ops]。
This is a migration tactic used by domains as a method for incrementally transitioning inbound traffic to a domain to IPv6. If an incremental tactic like this is not used, a domain might return AAAA resource records to any relevant DNS query, meaning the domain could go quickly from no IPv6 traffic to a potentially significant amount as soon as the AAAA resource records are published. When DNS Resolver Whitelisting is implemented, a domain's authoritative DNS will selectively return a AAAA resource record to DNS recursive resolvers on a whitelist maintained by the domain, while returning no AAAA resource records to DNS recursive resolvers that are not on that whitelist. This tactic will not have a direct impact on reducing IPv6-related impairments (Section 2.1), though it can help a domain address operational maturity concerns (Section 2.2) as well as concerns and risks related to traffic volume (Section 2.3). While DNS Resolver Whitelisting does not solve IPv6-related impairments, it can help a domain to avoid users that have them. As a result, the tactic removes their impact in all but the few networks that are whitelisted. DNS Resolver Whitelisting also allows website operators to protect non-IPv6 networks (i.e., networks that do not support IPv6 and/or do not have plans to do so in the future) from IPv6-related impairments in their networks. Finally, domains using this tactic should understand that the onus is on them to ensure that the servers being whitelisted represent a network that has proven to their satisfaction that they are IPv6-ready and that this will not create a poor end-user experience for users of the whitelisted server.
これは、ドメインが受信トラフィックをIPv6に段階的に移行する方法としてドメインで使用される移行戦術です。このようなインクリメンタル戦略を使用しない場合、ドメインはAAAAリソースレコードを関連するDNSクエリに返す可能性があります。つまり、AAAAリソースレコードが公開されるとすぐに、ドメインはIPv6トラフィックがない状態からかなりの量になる可能性があります。 DNSリゾルバーホワイトリストが実装されている場合、ドメインの権限のあるDNSは、ドメインによって維持されているホワイトリスト上のDNS再帰リゾルバーにAAAAリソースレコードを選択的に返しますが、そのホワイトリストにないDNS再帰リゾルバーにはAAAAリソースレコードを返しません。この方策は、ドメインが運用上の成熟度の懸念（セクション2.2）やトラフィック量に関連する懸念およびリスク（セクション2.3）に対処するのに役立ちますが、IPv6関連の障害（セクション2.1）の削減には直接影響しません。 DNSリゾルバーホワイトリストはIPv6関連の障害を解決しませんが、ドメインを持つユーザーを回避するのに役立ちます。その結果、この戦術は、ホワイトリストに登録されているいくつかのネットワークを除いて、その影響を取り除きます。 DNSリゾルバーホワイトリストを使用すると、Webサイトオペレーターは非IPv6ネットワーク（つまり、IPv6をサポートしない、または将来的にサポートする予定がないネットワーク）を、ネットワークのIPv6関連の障害から保護できます。最後に、この戦術を使用するドメインは、ホワイトリストに登録されているサーバーが、IPv6対応であり、これによりユーザーのエンドユーザーエクスペリエンスが低下しないことを十分に証明したネットワークであることを保証する責任があることを理解する必要があります。ホワイトリストに登録されたサーバーの。
There are of course challenges and concerns related to DNS Resolver Whitelisting. Some of the concerns with a whitelist of DNS recursive resolvers may be held by parties other than the implementing domain, such as network operators or end users that may not have had their DNS recursive resolvers added to a whitelist. Additionally, the IP address of a DNS recursive resolver is not a precise indicator of the IPv6 preparedness, or lack of IPv6-related impairment, of end-user hosts that query (use) a particular DNS recursive resolver. While the IP addresses of DNS recursive resolvers on networks known to have deployed IPv6 may be an imperfect proxy for judging IPv6 preparedness, or lack of IPv6-related impairment, this method is one of the better available methods at the current time. For example, implementers have found that it is possible to measure the level of IPv6 preparedness of the end users behind any given DNS recursive resolver by conducting ongoing measurement of the IPv6 preparedness of end users querying for one-time-use hostnames and then correlating the domain's authoritative DNS server logs with their web server logs. This can help implementers form a good picture of which DNS recursive resolvers have working IPv6 users behind them and which do not, what the latency impact of turning on IPv6 for any given DNS recursive resolver is, etc. In addition, given the current state of global IPv6 deployment, this migration tactic allows content providers to selectively expose the availability of their IPv6 services. While opinions in the Internet community concerning DNS Resolver Whitelisting are understandably quite varied, there is clear consensus that DNS Resolver Whitelisting can be a useful tactic for use during the transition of a domain to IPv6. In particular, some high-service-level domains view DNS Resolver Whitelisting as one of the few practical and low-risk approaches enabling them to transition to IPv6, without which their transition may not take place for some time. However, there is also consensus that this practice is workable on a manual basis (see below) only in the short term and that it will not scale over the long term. Thus, some domains may find DNS Resolver Whitelisting a beneficial temporary tactic in their transition to IPv6.
もちろん、DNSリゾルバーのホワイトリストに関連する課題と懸念事項があります。 DNS再帰リゾルバーのホワイトリストに関する懸念の一部は、DNS再帰リゾルバーをホワイトリストに追加していない可能性のあるネットワークオペレーターやエンドユーザーなど、実装ドメイン以外の関係者が抱えている可能性があります。さらに、DNS再帰リゾルバーのIPアドレスは、特定のDNS再帰リゾルバーにクエリ（使用）するエンドユーザーホストのIPv6準備またはIPv6関連の障害の欠如の正確な指標ではありません。 IPv6を展開していることがわかっているネットワーク上のDNS再帰リゾルバーのIPアドレスは、IPv6の準備状況またはIPv6関連の障害の欠如を判断するための不完全なプロキシである可能性がありますが、この方法は現時点で利用できる優れた方法の1つです。たとえば、実装者は、1回限りのホスト名を照会するエンドユーザーのIPv6準備の継続的な測定を実行し、次に、それらを関連付けることにより、特定のDNS再帰リゾルバの背後にあるエンドユーザーのIPv6準備のレベルを測定できることを発見しました。ドメインの信頼できるDNSサーバーログとそのWebサーバーログ。これにより、実装者は、どのDNS再帰リゾルバーが背後で動作しているIPv6ユーザーを持っているか、どのDNS再帰リゾルバーが機能していないか、特定のDNS再帰リゾルバーでIPv6をオンにした場合のレイテンシへの影響などを把握するのに役立ちます。グローバルなIPv6展開では、この移行戦術により、コンテンツプロバイダーはIPv6サービスの可用性を選択的に公開できます。 DNSリゾルバーホワイトリストに関するインターネットコミュニティの意見は当然のことながらかなり多様ですが、DNSリゾルバーホワイトリストは、ドメインのIPv6への移行中に使用するのに役立つ戦術である可能性があることは明らかです。特に、一部の高サービスレベルドメインでは、DNSリゾルバーのホワイトリストを、IPv6への移行を可能にする数少ない実用的でリスクの少ないアプローチの1つと見なしています。ただし、この方法は手動でのみ実行でき（以下を参照）、短期的にのみ実行可能であり、長期的には拡大しないというコンセンサスもあります。したがって、一部のドメインでは、IPv6への移行において、DNSリゾルバーホワイトリストが一時的な有益な戦術であることがわかります。
At the current time, generally speaking, a domain that implements DNS Resolver Whitelisting does so manually. This means that a domain manually maintains a list of networks that are permitted to receive IPv6 records (via their DNS resolver IP addresses) and that these networks typically submit applications, or follow some other process established by the domain, in order to be added to the DNS Whitelist. However, implementers foresee that a subsequent phase of DNS Resolver Whitelisting is likely to emerge in the future, possibly in the near future. In this new phase, a domain would return IPv6 and/or IPv4 records dynamically based on automatically detected technical capabilities, location, or other factors. It would then function much like (or indeed as part of) GSLB, a common practice already in use today, as described in Section 4.3.2. Furthermore, in this future phase, networks would be added to and removed from a DNS Whitelist automatically, and possibly on a near-real-time basis. This means, crucially, that networks would no longer need to apply to be added to a whitelist, which may alleviate many of the key concerns that network operators may have with this tactic when it is implemented on a manual basis.
現在のところ、一般的に言えば、DNSリゾルバーのホワイトリストを実装するドメインは手動で実装しています。つまり、ドメインは手動で（DNSリゾルバーIPアドレスを介して）IPv6レコードの受信が許可されているネットワークのリストを維持し、これらのネットワークは通常、アプリケーションを送信するか、ドメインに確立された他のプロセスに従って、 DNSホワイトリスト。ただし、実装者は、DNSリゾルバーホワイトリストの次のフェーズが将来、おそらく近い将来に出現する可能性が高いと予測しています。この新しいフェーズでは、ドメインは、自動的に検出された技術的機能、場所、またはその他の要因に基づいて、IPv6またはIPv4レコードを動的に返します。次に、セクション4.3.2で説明するように、今日すでに使用されている一般的な方法であるGSLBのように（または実際にGSLBの一部として）機能します。さらに、この将来のフェーズでは、ネットワークがDNSホワイトリストに自動的に、場合によってはほぼリアルタイムで追加および削除されます。つまり、ホワイトリストにネットワークを追加するためにネットワークを適用する必要がなくなり、ネットワークオペレーターが手動で実装した場合のこの戦術に関する主な懸念の多くを軽減できる可能性があります。
Using a "whitelist" in a generic sense means that no traffic (or traffic of a certain type) is permitted to the destination host unless the originating host's IP address is contained in the whitelist. In contrast, using a "blacklist" means that all traffic is permitted to the destination host unless the originating host's IP address is contained in the blacklist. In the case of DNS Resolver Whitelisting, the resource that an end user seeks is a name, not an IP address or IP address family. Thus, an end user is seeking a name such as www.example.com, without regard to the underlying IP address family (IPv4 or IPv6) that may be used to access that resource.
一般的な意味での「ホワイトリスト」の使用は、発信元ホストのIPアドレスがホワイトリストに含まれていない限り、宛先ホストへのトラフィック（または特定のタイプのトラフィック）が許可されないことを意味します。対照的に、「ブラックリスト」を使用すると、発信元ホストのIPアドレスがブラックリストに含まれていない限り、すべてのトラフィックが宛先ホストに許可されます。 DNSリゾルバーホワイトリストの場合、エンドユーザーが求めるリソースは名前であり、IPアドレスやIPアドレスファミリーではありません。したがって、エンドユーザーは、そのリソースへのアクセスに使用される可能性のある基本的なIPアドレスファミリ（IPv4またはIPv6）に関係なく、www.example.comなどの名前を求めています。
DNS Resolver Whitelisting is implemented in authoritative DNS servers, not in DNS recursive resolvers. These authoritative DNS servers selectively return AAAA resource records using the IP address of the DNS recursive resolver that has sent them a query. Thus, for a given operator of a website, such as www.example.com, the domain operator implements whitelisting on the authoritative DNS servers for the domain example.com. The whitelist is populated with the IPv4 and/or IPv6 addresses or prefix ranges of DNS recursive resolvers on the Internet, which have been authorized to receive AAAA resource record responses. These DNS recursive resolvers are operated by third parties, such as Internet Service Providers (ISPs), universities, governments, businesses, and individual end users. If a DNS recursive resolver is not matched in the whitelist, then AAAA resource records WILL NOT be sent in response to a query for a hostname in the example.com domain (and an A record would be sent). However, if a DNS recursive resolver is matched in the whitelist, then AAAA resource records WILL be sent. As a result, while Section 2.2 of [RFC4213] notes that a stub resolver can make a choice between whether to use a AAAA record or A record response, with DNS Resolver Whitelisting the authoritative DNS server can also decide whether to return a AAAA record, an A record, or both record types.
DNSリゾルバーホワイトリストは、DNS再帰リゾルバーではなく、信頼できるDNSサーバーに実装されています。これらの信頼できるDNSサーバーは、クエリを送信したDNS再帰リゾルバのIPアドレスを使用して、AAAAリソースレコードを選択的に返します。したがって、www.example.comなどのWebサイトの特定のオペレーターに対して、ドメインオペレーターはドメインexample.comの権限のあるDNSサーバーにホワイトリストを実装します。ホワイトリストには、インターネット上のDNS再帰リゾルバのIPv4アドレスやIPv6アドレス、またはプレフィックス範囲が入力され、AAAAリソースレコード応答の受信が承認されています。これらのDNS再帰リゾルバーは、インターネットサービスプロバイダー（ISP）、大学、政府、企業、および個々のエンドユーザーなどのサードパーティによって運営されています。 DNS再帰リゾルバーがホワイトリストで一致しない場合、example.comドメインのホスト名のクエリへの応答としてAAAAリソースレコードは送信されません（そしてAレコードが送信されます）。ただし、DNS再帰リゾルバがホワイトリストで一致する場合、AAAAリソースレコードが送信されます。その結果、[RFC4213]のセクション2.2では、スタブリゾルバーはAAAAレコードを使用するか、Aレコードレスポンスを使用するかを選択できると述べていますが、権威あるDNSサーバーをホワイトリストに登録するDNSリゾルバーでは、AAAAレコードを返すかどうかも決定できます。 Aレコード、または両方のレコードタイプ。
When implemented on a manual basis, DNS Resolver Whitelisting generally means that a very small fraction of the DNS recursive resolvers on the Internet (those in the whitelist) will receive AAAA responses. The large majority of DNS recursive resolvers on the Internet will therefore receive only A resource records containing IPv4 addresses. Domains may find the practice imposes some incremental operational burdens insofar as it can consume staff time to maintain a whitelist (such as additions and deletions to the list), respond to and review applications to be added to a whitelist, maintain good performance levels on authoritative DNS servers as the whitelist grows, create new network monitors to check the health of a whitelist function, perform new types of troubleshooting related to whitelisting, etc. In addition, manually based whitelisting imposes some incremental burdens on operators of DNS recursive resolvers (such as network operators), since they will need to apply to be whitelisted with any implementing domains, and will subsequently need processes and systems to track the status of whitelisting applications, respond to requests for additional information pertaining to these applications, and track any de-whitelisting actions.
手動で実装した場合、DNSリゾルバーホワイトリストは、一般に、インターネット上のDNS再帰リゾルバーのほんの一部（ホワイトリストにあるもの）がAAAA応答を受信することを意味します。したがって、インターネット上のDNS再帰リゾルバの大多数は、IPv4アドレスを含むAリソースレコードのみを受け取ります。ドメインは、ホワイトリストの維持（リストへの追加や削除など）、ホワイトリストに追加されるアプリケーションへの応答とレビュー、信頼できるレベルでの良好なパフォーマンスレベルの維持にスタッフの時間を費やす可能性がある限り、運用が段階的な運用上の負担を強いることに気付く場合があります。ホワイトリストが拡大するにつれてDNSサーバーは、ホワイトリスト機能の状態をチェックする新しいネットワークモニターを作成し、ホワイトリストに関連する新しいタイプのトラブルシューティングを実行します。さらに、手動ベースのホワイトリストは、DNS再帰リゾルバーのオペレーターにいくつかの増分の負担を課します（ネットワークオペレーター）、それらは実装ドメインでホワイトリストに登録するために適用する必要があり、その後、ホワイトリストアプリケーションのステータスを追跡し、これらのアプリケーションに関する追加情報のリクエストに応答し、ホワイトリストからの削除を追跡するプロセスとシステムが必要になるため行動。
When implemented on an automated basis in the future, DNS recursive resolvers listed in the whitelist could expand and contract dynamically, and possibly in near-real time, based on a wide range of factors. As a result, it is likely that the number of DNS recursive resolvers on the whitelist will be substantially larger than when such a list is maintained manually, and it is also likely that the whitelist will grow at a rapid rate. This automation can eliminate most of the significant incremental operational burdens on implementing domains as well as operators of DNS recursive resolvers, which is clearly a factor that is motivating implementers to work to automate this function.
将来自動的に実装されると、ホワイトリストにリストされているDNS再帰リゾルバーは、さまざまな要因に基づいて、動的に、場合によってはほぼリアルタイムで拡張および縮小できます。その結果、ホワイトリスト上のDNS再帰リゾルバーの数は、そのようなリストを手動で維持する場合よりも大幅に多くなる可能性が高く、ホワイトリストが急速に増加する可能性もあります。この自動化により、DNS再帰リゾルバーのオペレーターだけでなく、ドメインの実装に伴う大幅な運用上の負担のほとんどを排除できます。これは、実装者がこの機能を自動化するように動機づける要因であることが明らかです。
Section 4.3.1.1 and Figure 1 provide more details on DNS Resolver Whitelisting in general. In addition, the potential deployment models of DNS Resolver Whitelisting (manual and automated) are described in Section 5. It is also important to note that DNS Resolver Whitelisting also works independently of whether an authoritative DNS server, DNS recursive resolver, or end-user host uses IPv4 transport, IPv6, or both. So, for example, whitelisting may not result in the return of AAAA responses even in those cases where the DNS recursive resolver has queried the authoritative server over an IPv6 transport. This may also be the case in some situations when the end-user host's original query to its DNS recursive resolver was over IPv6 transport, if that DNS recursive resolver is not on a given whitelist. One important reason for this is that even though the DNS recursive resolver may have no IPv6-related impairments, this is not a reliable predictor of whether the same is true of the end-user host. This also means that a DNS Whitelist can contain both IPv4 and IPv6 addresses.
セクション4.3.1.1と図1は、DNSリゾルバーホワイトリストの一般的な詳細を提供します。また、DNSリゾルバーホワイトリスト（手動および自動）の潜在的な導入モデルについては、セクション5で説明します。DNSリゾルバーホワイトリストは、権威あるDNSサーバー、DNS再帰リゾルバー、またはエンドユーザーのいずれかとは無関係に機能することにも注意してください。ホストはIPv4トランスポート、IPv6、またはその両方を使用します。したがって、たとえば、DNS再帰リゾルバが権限のあるサーバーにIPv6トランスポートを介してクエリを実行した場合でも、ホワイトリストに登録してもAAAA応答が返されないことがあります。これは、DNS再帰リゾルバが特定のホワイトリストにない場合に、DNS再帰リゾルバに対するエンドユーザーホストの元のクエリがIPv6トランスポートを介していた場合にも当てはまります。これの1つの重要な理由は、DNS再帰リゾルバーにIPv6関連の障害がない場合でも、これがエンドユーザーホストに当てはまるかどうかの信頼できる予測子ではないことです。これは、DNSホワイトリストにIPv4アドレスとIPv6アドレスの両方を含めることができることも意味します。
Specific implementations will vary from domain to domain, based on a range of factors such as the technical capabilities of a given domain. As such, any examples listed herein should be considered general examples and are not intended to be exhaustive.
特定の実装は、特定のドメインの技術的能力などのさまざまな要因に基づいて、ドメインごとに異なります。したがって、ここにリストされている例は一般的な例と見なされるべきであり、網羅的であることを意図したものではありません。
The system logic of DNS Resolver Whitelisting is as follows:
DNSリゾルバーホワイトリストのシステムロジックは次のとおりです。
1. The authoritative DNS server for example.com receives DNS queries for the A (IPv4) and/or AAAA (IPv6) address resource records for the FQDN www.example.com, for which AAAA (IPv6) resource records exist.
1. example.comの信頼できるDNSサーバーは、AAQ（IPv6）リソースレコードが存在するFQDN www.example.comのA（IPv4）またはAAAA（IPv6）アドレスリソースレコードのDNSクエリを受信します。
2. The authoritative DNS server checks the IP address (IPv4, IPv6, or both) of the DNS recursive resolver sending the AAAA (IPv6) query against the whitelist (i.e., the DNS Whitelist).
2. 信頼できるDNSサーバーは、AAA（IPv6）クエリを送信するDNS再帰リゾルバーのIPアドレス（IPv4、IPv6、またはその両方）をホワイトリスト（DNSホワイトリスト）と照合してチェックします。
3. If the DNS recursive resolver's IP address IS matched in the whitelist, then the response to that specific DNS recursive resolver can contain AAAA (IPv6) address resource records.
3. DNS再帰リゾルバーのIPアドレスがホワイトリストで一致する場合、その特定のDNS再帰リゾルバーへの応答には、AAAA（IPv6）アドレスリソースレコードを含めることができます。
4. If the DNS recursive resolver's IP address IS NOT matched in the whitelist, then the response to that specific DNS recursive resolver cannot contain AAAA (IPv6) address resource records. In this case, the server will likely return a response with the response code (RCODE) being set to 0 (No Error) with an empty answer section for the AAAA record query.
4. DNS再帰リゾルバーのIPアドレスがホワイトリストで一致しない場合、その特定のDNS再帰リゾルバーへの応答にAAAA（IPv6）アドレスリソースレコードを含めることはできません。この場合、サーバーは、AAAAレコードクエリの空の応答セクションで、応答コード（RCODE）が0（エラーなし）に設定された応答を返す可能性があります。
+--------------------------------------------------------------------+
| Caching Server 1 - IS NOT ON the DNS Whitelist |
| Caching Server 2 - IS ON the DNS Whitelist |
| Note: Transport between each host can be IPv4 or IPv6. |
+--------------------------------------------------------------------+
+----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS |
| Resolver | | Server 1 | | Server |
+----------+ +---------------+ +---------------+
| DNS Query: | |
| example.com A, AAAA | |
|---------------------->| |
| | |
| | DNS Query: |
| | example.com A, AAAA |
| |------------------------>|
| | |
| | | NOT on Whitelist
| | DNS Response: |
| | example.com A |
| |<------------------------|
| | |
| DNS Response: | |
| example.com A | |
|<----------------------| |
+----------+ +---------------+ +---------------+
| Stub | | DNS Caching | | DNS |
| Resolver | | Server 2 | | Server |
+----------+ +---------------+ +---------------+
| DNS Query: | |
| example.com A, AAAA | |
|---------------------->| |
| | |
| | DNS Query: |
| | example.com A, AAAA |
| |------------------------>|
| | |
| | | IS on Whitelist
| | DNS Response: |
| | example.com A, AAAA |
| |<------------------------|
| | |
| DNS Response: | |
| example.com A, AAAA | |
|<----------------------| |
Figure 1: DNS Resolver Whitelisting Diagram
図1：DNSリゾルバーのホワイトリスト図
4.3.2. Similarities to Content Delivery Networks and Global Server Load Balancing
4.3.2. コンテンツ配信ネットワークおよびグローバルサーバーロードバランシングとの類似点
DNS Resolver Whitelisting is functionally similar to CDNs and GSLB. When using a CDN or GSLB, a geographically aware authoritative DNS server function is usually part of that overall system. As a result, the use of a CDN or GSLB with an authoritative DNS server function enables the IP address resource records returned to a resolver in response to a query to vary, based on the estimated geographic location of the resolver [Wild-Resolvers] or a range of other technical factors. This CDN or GSLB DNS function is performed in order to attempt to direct hosts to a) connect either to the nearest host (as measured in round-trip time) or to the host that has the best connectivity to an end user, b) route around failures, c) avoid sites where maintenance work has taken down hosts, and/or d) connect to the host that will otherwise provide the best service experience for an end user at a given point in time. As a result, one can see a direct similarity to DNS Resolver Whitelisting insofar as different IP address resource records are selectively returned to resolvers based on the IP address of each resolver and/or other imputed factors related to that IP address.
DNSリゾルバーのホワイトリストは、CDNおよびGSLBと機能的に類似しています。 CDNまたはGSLBを使用する場合、地理的に認識された信頼できるDNSサーバー機能は通常、そのシステム全体の一部です。その結果、信頼できるDNSサーバー機能でCDNまたはGSLBを使用すると、クエリに応答してリゾルバーに返されるIPアドレスリソースレコードを、リゾルバーの推定地理的位置に基づいて変更できます[Wild-Resolvers]またはその他のさまざまな技術的要因。このCDNまたはGSLB DNS機能は、a）ホストを（a）最も近いホスト（往復時間で測定）またはエンドユーザーへの接続性が最も良いホスト（b）ルートに接続するように試行するために実行されます。障害については、c）メンテナンス作業によってホストがダウンしたサイトを回避するか、d）ホストに接続することで、特定の時点でエンドユーザーに最高のサービスエクスペリエンスを提供します。その結果、各リゾルバーのIPアドレスやそのIPアドレスに関連する他の帰属要因に基づいて、異なるIPアドレスリソースレコードがリゾルバーに選択的に返される限り、DNSリゾルバーのホワイトリストに直接類似していることがわかります。
DNS Resolver Whitelisting has some similarities to DNS Load Balancing. There are of course many ways that DNS Load Balancing can be performed. In one example, multiple IP address resource records (A and/or AAAA) can be added to the DNS for a given FQDN. This approach is referred to as DNS round robin [RFC1794]. DNS round robin may also be employed where SRV resource records are used [RFC2782]. In another example, one or more of the IP address resource records in the DNS will direct traffic to a load balancer. That load balancer, in turn, may be application-aware, and pass the traffic on to one or more hosts that are connected to the load balancer and that have different IP addresses. In cases where private IPv4 addresses are used [RFC1918], as well as when public IP addresses are used, those end hosts may not necessarily be directly reachable without passing through the load balancer first. So, similar to DNS Resolver Whitelisting, a load balancer will control what server host an end-user's host communicates with when using an FQDN.
DNSリゾルバーのホワイトリストには、DNS負荷分散といくつかの類似点があります。もちろん、DNS負荷分散を実行する方法はたくさんあります。一例では、複数のIPアドレスリソースレコード（Aおよび/またはAAAA）を、所定のFQDNのDNSに追加できます。このアプローチは、DNSラウンドロビン[RFC1794]と呼ばれます。 DNSラウンドロビンは、SRVリソースレコードが使用される場合にも使用できます[RFC2782]。別の例では、DNS内の1つ以上のIPアドレスリソースレコードがトラフィックをロードバランサーに転送します。次に、そのロードバランサーはアプリケーション対応であり、ロードバランサーに接続されていて、異なるIPアドレスを持つ1つ以上のホストにトラフィックを渡します。プライベートIPv4アドレスが使用される場合[RFC1918]、およびパブリックIPアドレスが使用される場合、これらのエンドホストは、最初にロードバランサーを通過せずに直接到達できるとは限りません。したがって、DNSリゾルバーのホワイトリストと同様に、ロードバランサーは、FQDNを使用するときにエンドユーザーのホストが通信するサーバーホストを制御します。
DNS Resolver Whitelisting has some similarities to so-called Split DNS, briefly described in Section 3.8 of [RFC2775]. When Split DNS is used, the authoritative DNS server selectively returns different responses, depending upon what host has sent the query. While
DNSリゾルバーのホワイトリストには、いわゆる[分割DNS]といくつかの類似点があり、[RFC2775]のセクション3.8で簡単に説明されています。スプリットDNSを使用する場合、権限のあるDNSサーバーは、クエリを送信したホストに応じて、選択的に異なる応答を返します。ながら
[RFC2775] notes that the typical use of Split DNS is to provide one answer to hosts on an Intranet (internal network) and a different answer to hosts on the Internet (external or public network), the basic idea is that different answers are provided to hosts on different networks. This is similar to the way that DNS Resolver Whitelisting works, whereby hosts on different networks that use different DNS recursive resolvers receive different answers if one DNS recursive resolver is on the whitelist and the other is not. However, Internet transparency and Internet fragmentation concerns regarding Split DNS are detailed in Section 2.1 of [RFC2956]. Section 2.7 of [RFC2956] notes concerns regarding Split DNS, including the concern that the deployment of Split DNS "makes the use of Fully Qualified Domain Names (FQDNs) as endpoint identifiers more complex". Section 3.5 of [RFC2956] further recommends that maintaining a stable approach to DNS operations is key during transitions, such as the one to IPv6 that is underway now, and states that "Operational stability of DNS is paramount, especially during a transition of the network layer, and both IPv6 and some network address translation techniques place a heavier burden on DNS".
[RFC2775]は、スプリットDNSの一般的な使用法は、イントラネット（内部ネットワーク）上のホストに1つの回答を提供し、インターネット（外部またはパブリックネットワーク）上のホストに別の回答を提供することであると述べています。異なるネットワーク上のホストに。これは、DNSリゾルバーホワイトリストが機能する方法に似ています。これにより、一方のDNS再帰リゾルバーがホワイトリストにあり、他方がホワイトリストにない場合、異なるDNS再帰リゾルバーを使用する異なるネットワーク上のホストは異なる回答を受け取ります。ただし、スプリットDNSに関するインターネットの透過性とインターネットの断片化の問題については、[RFC2956]のセクション2.1で詳しく説明しています。 [RFC2956]のセクション2.7は、スプリットDNSの導入により、「エンドポイント識別子としての完全修飾ドメイン名（FQDN）の使用がより複雑になる」という懸念を含む、スプリットDNSに関する懸念に言及しています。 [RFC2956]のセクション3.5は、現在進行中のIPv6への移行など、移行中はDNS運用への安定したアプローチを維持することが重要であることをさらに推奨し、「ネットワークの移行中は特に、DNSの運用の安定性が最も重要です。レイヤー、およびIPv6と一部のネットワークアドレス変換技術の両方がDNSに大きな負担をかけます。」
While techniques such as GSLB and DNS Load Balancing -- which share
much in common with DNS Resolver Whitelisting -- are widespread, some
in the community have raised a range of concerns about all of these
practices. Some concerns are specific to DNS Resolver Whitelisting
[WL-Concerns]. Other concerns are not as specific and pertain to the
general practice of implementing content location or other network
policy controls in the "middle" of the network, in a so-called
"middlebox" function. Whether such DNS-related functions are really
part of a middlebox is debatable. Nevertheless, implementers should
at least be aware of some of the risks of middleboxes, as noted in
[RFC3724]. A related document, [RFC1958], explains that configured
state, policies, and other functions needed in the middle of the
network should be minimized as a design goal. In addition,
Section 2.16 of [RFC3234] makes specific statements concerning
modified DNS servers. Section 1.2 of [RFC3234] also outlines more
general concerns about the introduction of new failure modes when
configuration is no longer limited to two ends of a session, so that
diagnosis of failures and misconfigurations could become more
complex. Two additional sources worth considering are [Tussle] and
[Rethinking], in which the authors note concerns regarding the
introduction of new control points (e.g., in middleboxes or in
the DNS).
However, state, policies, and other functions have always been necessary to enable effective, reliable, and high-quality end-to-end communications on the Internet. In addition, the use of GSLB, CDNs, DNS Load Balancing, and Split DNS are not only widely deployed but are almost uniformly viewed as essential to the functioning of the Internet and highly beneficial to the quality of the end-user experience on the Internet. These techniques have had, and continue to have, a beneficial effect on the experience of a wide range of Internet applications and protocols. So, while there are valid concerns about implementing policy controls in the "middle" of the network, or anywhere away from edge hosts, the definition of what constitutes the middle and edge of the network is debatable in this case. This is particularly so given that GSLBs and CDNs facilitate connections from end hosts and the optimal content hosts, and could therefore be considered a modest and, in many cases, essential network policy extension of a network's edge, especially in the case of high-service-level domains.
ただし、状態、ポリシー、およびその他の機能は、インターネット上で効果的で信頼性のある高品質のエンドツーエンド通信を可能にするために常に必要でした。さらに、GSLB、CDN、DNSロードバランシング、およびスプリットDNSの使用は、広く展開されているだけでなく、インターネットの機能に不可欠であり、インターネット上のエンドユーザーエクスペリエンスの品質に非常に有益であるとほぼ均一に考えられています。 。これらの手法は、さまざまなインターネットアプリケーションおよびプロトコルのエクスペリエンスに有益な影響をもたらしてきました。したがって、ネットワークの「中間」、またはエッジホストから離れた場所にポリシー制御を実装することについては有効な懸念がありますが、この場合、ネットワークの中間およびエッジを構成するものの定義については議論の余地があります。これは特にGSLBとCDNがエンドホストと最適なコンテンツホストからの接続を容易にするため、特に高サービスの場合に、ネットワークエッジの控えめな、そして多くの場合、必須のネットワークポリシー拡張と見なすことができるためです。レベルのドメイン。
There may be additional implications for end users that have configured their hosts to use a third party as their DNS recursive resolver, rather than the one(s) provided by their network operator. In such cases, it will be more challenging for a domain using whitelisting to determine the level of IPv6-related impairment when such third-party DNS recursive resolvers are used, given the wide variety of end-user access networks that may be used and given that this mix may change in unpredictable ways over time.
ネットワークオペレーターが提供するDNSリカーサではなくサードパーティをDNS再帰リゾルバとして使用するようにホストを設定しているエンドユーザーには、追加の影響がある可能性があります。このような場合、使用および提供される可能性のあるさまざまなエンドユーザーアクセスネットワークを考慮して、このようなサードパーティのDNS再帰リゾルバーが使用される場合、ホワイトリストを使用するドメインがIPv6関連の障害のレベルを特定することはより困難になります。このミックスは、時間の経過とともに予測できない方法で変化する可能性があります。
With DNS Resolver Whitelisting, DNS recursive resolvers can receive AAAA resource records only if they are on the whitelist. DNS Blacklisting is by contrast the opposite of that, whereby all DNS recursive resolvers can receive AAAA resource records unless they are on the blacklist. Some implementers of DNS Resolver Whitelisting may choose to subsequently transition to DNS Blacklisting. It is not clear when and if it may be appropriate for a domain to change from whitelisting to blacklisting, nor is it clear how implementers will judge that network conditions have changed sufficiently to justify disabling such controls.
DNSリゾルバーのホワイトリストを使用すると、DNS再帰リゾルバーは、ホワイトリストにある場合にのみAAAAリソースレコードを受信できます。これとは対照的に、DNSブラックリストはその逆であり、ブラックリストにない限り、すべてのDNS再帰リゾルバーはAAAAリソースレコードを受信できます。 DNSリゾルバーホワイトリストの一部の実装者は、その後DNSブラックリストに移行することを選択できます。ドメインがホワイトリストからブラックリストに変更するのが適切かどうか、またそのような制御を無効にすることを正当化するのに十分にネットワーク条件が変化したと実装者がどのように判断するかは明確ではありません。
When a domain uses blacklisting, it is enabling all DNS recursive resolvers to receive AAAA record responses, except for what is presumed to be a relatively small number that are on the blacklist. Over time, it is likely that the blacklist will become smaller as the networks associated with the blacklisted DNS recursive resolvers are able to meaningfully reduce IPv6-related impairments to some acceptable level, though it is possible that some networks may never achieve that. DNS Blacklisting is also likely less labor intensive for a domain than performing DNS Resolver Whitelisting on a manual basis. This is simply because the domain would presumably be focused on a smaller number of DNS recursive resolvers with well-known IPv6-related problems.
ドメインがブラックリストを使用する場合、ブラックリストにある比較的小さな数であると推定されるものを除いて、すべてのDNS再帰リゾルバーがAAAAレコード応答を受信できるようになります。ブラックリストに登録されたDNS再帰リゾルバーに関連付けられたネットワークは、IPv6関連の障害をある程度許容できるレベルまで有意に削減できるため、時間が経つにつれてブラックリストが小さくなる可能性がありますが、一部のネットワークではそれを達成できない可能性があります。 DNSブラックリストは、手動でDNSリゾルバーのホワイトリストを実行するよりも、ドメインの労力が少ない可能性があります。これは単に、ドメインがIPv6関連の既知の問題がある少数のDNS再帰リゾルバーに焦点を当てているためと考えられます。
It is also worth noting that the email industry has a long experience with blacklists and, very generally speaking, blacklists tend to be effective and well received when it is easy to discover if an IP address is on a blacklist, if there is a transparent and easily understood process for requesting removal from a blacklist, and if the decision-making criteria for placing a server on a blacklist are transparently disclosed and perceived as fair. However, in contrast to an email blacklist where a blacklisted host cannot send email to a domain at all, with DNS Resolver Whitelisting, communications will still occur over IPv4 transport.
また、電子メール業界ではブラックリストについて長い経験があり、一般的に言えば、ブラックリストは効果的であり、IPアドレスがブラックリストにあるかどうかがわかりやすく、透過的であり、ブラックリストからの削除をリクエストするための簡単に理解できるプロセス、およびサーバーをブラックリストに配置するための意思決定基準が透過的に開示され、公正であると認識されている場合。ただし、ブラックリストに登録されたホストがドメインにメールをまったく送信できないメールのブラックリストとは対照的に、DNSリゾルバーのホワイトリストでは、IPv4トランスポートを介して通信が行われます。
As an alternative to adopting any of the aforementioned migration tactics, domains can choose to transition to native dual stack directly by adding native IPv6 capabilities to their network and hosts and by publishing AAAA resource records in the DNS for their named resources. Of course, a domain can still control this transition gradually, on a name-by-name basis, by adding native IPv6 to one name at a time, such as mail.example.com first and www.example.com later. So, even a "direct" transition can be performed gradually.
前述の移行戦術のいずれかを採用する代わりに、ドメインは、ネイティブIPv6機能をネットワークとホストに追加し、名前付きリソースのDNSにAAAAリソースレコードを公開することにより、ネイティブデュアルスタックに直接移行することを選択できます。もちろん、ドメインは、最初にmail.example.com、後でwww.example.comのように、一度に1つの名前にネイティブIPv6を追加することにより、名前ごとにこの移行を徐々に制御できます。したがって、「直接」の遷移でさえ、徐々に実行できます。
It is then up to end users with IPv6-related impairments to discover and fix any applicable impairments. However, the concerns and risks related to traffic volume (Section 2.3) should still be considered and managed, since those are not directly related to such impairments. Not all content providers (or other domains) may face the challenges detailed herein or face them to the same degree, since the user base of each domain, traffic sources, traffic volumes, and other factors obviously vary between domains.
該当する障害を発見して修正するのは、IPv6関連の障害を持つエンドユーザー次第です。ただし、交通量に関連する懸念事項とリスク（2.3節）は、そのような障害に直接関係しないため、引き続き検討および管理する必要があります。各ドメインのユーザーベース、トラフィックソース、トラフィック量、およびその他の要因がドメイン間で明らかに異なるため、すべてのコンテンツプロバイダー（または他のドメイン）がここで説明する課題に直面したり、同じ程度に直面したりするわけではありません。
For example, while some content providers have implemented DNS Resolver Whitelisting (one migration tactic), others have run IPv6 experiments whereby they added AAAA resource records and observed and measured errors, and then decided not to implement DNS Resolver Whitelisting [Heise]. A more widespread example of such an experiment was World IPv6 Day [W6D], sponsored by the Internet Society, on June 8, 2011. This was a unique opportunity for hundreds of domains to add AAAA resource records to the DNS without using DNS Resolver Whitelisting, all at the same time. Some of the participating domains chose to leave AAAA resource records in place following the experiment based on their experiences.
たとえば、一部のコンテンツプロバイダーはDNSリゾルバーホワイトリスト（1つの移行戦術）を実装していますが、IPv6実験を実行してAAAAリソースレコードを追加し、エラーを観察および測定してから、DNSリゾルバーホワイトリスト[Heise]を実装しないことにしました。このような実験のより広範な例は、2011年6月8日にInternet Societyが後援するWorld IPv6 Day [W6D]でした。これは、何百ものドメインがDNSリゾルバーのホワイトリストを使用せずにAAAAリソースレコードをDNSに追加するユニークな機会でした、すべて同時に。参加しているドメインの一部は、実験に基づいて、経験に基づいてAAAAリソースレコードを残しておくことを選択しました。
Content providers can run their own independent experiments in the future, adding AAAA resource records for a brief period of time (minutes, hours, or days), and then analyzing any impacts or effects on traffic and the experience of end users. They can also simply turn on IPv6 for their domain, which may be easier when the transition does not involve a high-service-level domain.
コンテンツプロバイダーは、将来的に独自の実験を実行し、AAAAリソースレコードを短時間（分、時間、または日）追加して、トラフィックへの影響または影響とエンドユーザーのエクスペリエンスを分析できます。また、ドメインでIPv6を有効にするだけでもかまいません。これは、サービスレベルの高いドメインが移行に含まれない場合に簡単です。
The usefulness of each tactic in Section 4, and the associated pros and cons associated with each tactic, are relative to each potential implementer and will therefore vary from one implementer to another. As a result, it is not possible to say that the potential phases below make sense for every implementer. This also means that the duration of each phase will vary between implementers, and even that different implementers may skip some of these phases entirely. Finally, the tactics listed in Section 4 are by no means exclusive.
セクション4の各戦術の有用性、および各戦術に関連付けられた長所と短所は、潜在的な実装者ごとに相対的であり、したがって、実装者ごとに異なります。結果として、以下の潜在的なフェーズがすべての実装者にとって理にかなっているとは言えません。これは、各フェーズの期間が実装者によって異なり、実装者によってはこれらのフェーズの一部が完全にスキップされる可能性があることも意味します。最後に、セクション4にリストされている戦術は決して排他的なものではありません。
In this phase, a site is accessible only via IPv4 transport. At the time of this writing, the majority of content on the Internet is in this state and is not accessible natively over IPv6.
このフェーズでは、IPv4トランスポート経由でのみサイトにアクセスできます。この記事の執筆時点では、インターネット上のコンテンツの大部分はこの状態にあり、IPv6を介してネイティブにアクセスすることはできません。
One possible first step for a domain is to gain experience using a specialized new FQDN, such as ipv6.example.com or www.ipv6.example.com, as explained in Section 4.2.
セクション4.2で説明されているように、ドメインの最初のステップとして、ipv6.example.comやwww.ipv6.example.comなどの専用の新しいFQDNを使用して経験を積むことが考えられます。
As noted in Section 4.3, a domain could begin using DNS Resolver Whitelisting as a way to incrementally enable IPv6 access to content. This tactic may be especially interesting to high-service-level domains.
セクション4.3で説明したように、ドメインは、コンテンツへのIPv6アクセスを段階的に有効にする方法として、DNSリゾルバーホワイトリストの使用を開始できます。この戦術は、サービスレベルの高いドメインにとって特に興味深いかもしれません。
For a domain that decides to undertake DNS Resolver Whitelisting on a manual basis, the domain may subsequently move to perform DNS Resolver Whitelisting on an automated basis. This is explained in Section 4.3, and can significantly ease any operational burdens related to a manually maintained whitelist.
手動でDNSリゾルバーホワイトリストを作成することを決定したドメインの場合、ドメインはその後、自動でDNSリゾルバーホワイトリストを実行するために移動する場合があります。これはセクション4.3で説明されており、手動で管理するホワイトリストに関連する運用上の負担を大幅に軽減できます。
Domains that choose to implement DNS Resolver Whitelisting generally consider it to be a temporary measure. Many implementers have announced that they plan to permanently turn off DNS Resolver Whitelisting beginning on the date of the World IPv6 Launch, on June 6, 2012 [World-IPv6-Launch]. For any implementers that do not turn off DNS Resolver Whitelisting at that time, it may be unclear how each and every one will judge the point in time that network conditions have changed sufficiently to justify turning off DNS Resolver Whitelisting. That being said, it is clear that the extent of IPv6 deployment to end users in networks, the state of IPv6- related impairment, and the maturity of IPv6 operations are all important factors. Any such implementers may wish to take into consideration that, as a practical matter, it will be impossible to get to a point where there are no longer any IPv6-related impairments; some reasonably small number of hosts will inevitably be left behind as end users elect not to upgrade them or because some hosts are incapable of being upgraded.
DNSリゾルバーのホワイトリストの実装を選択したドメインは、通常、これを一時的な手段と見なします。多くの実装者は、2012年6月6日のWorld IPv6 Launchの日付から、DNSリゾルバーホワイトリストを永久にオフにする計画を発表しています[World-IPv6-Launch]。 DNSリゾルバーホワイトリストをオフにしない実装者の場合、ネットワーク状態がDNSリゾルバーホワイトリストをオフにする正当な理由で十分に変化した時点を、すべての人がどのように判断するかが不明確になる可能性があります。とはいえ、ネットワークのエンドユーザーへのIPv6展開の範囲、IPv6関連の障害の状態、およびIPv6運用の成熟度がすべて重要な要素であることは明らかです。このような実装者は、実際問題として、IPv6関連の障害がなくなるポイントに到達することは不可能であることを考慮に入れたいと思うかもしれません。エンドユーザーがそれらをアップグレードしないことを選択した場合、または一部のホストがアップグレードできないため、いくつかの合理的に少数のホストは必然的に取り残されます。
Regardless of whether a domain has first implemented DNS Resolver Whitelisting or has never done so, DNS Blacklisting, as described in Section 4.4, may be of interest. This may be at the point in time when domains wish to make their content widely available over IPv6 but still wish to protect end users of a few networks with well-known IPv6 limitations from having a bad end-user experience.
ドメインがDNSリゾルバーのホワイトリストを最初に実装したか、実装したことがないかに関係なく、4.4節で説明したDNSブラックリストは興味深いかもしれません。これは、ドメインがIPv6を介してコンテンツを広く利用できるようにしたいが、IPv6の既知の制限があるいくつかのネットワークのエンドユーザーを、エンドユーザーのエクスペリエンスが悪いことから保護したい場合です。
A domain can arrive at this phase by either following the use of a previous IPv6 migration tactic or going directly to this point, as noted in Section 4.5. In this phase, the site's content has been made natively accessible via both IPv4 and IPv6 for all end users on the Internet, or at least without the use of any other IPv6 migration tactic.
セクション4.5に記載されているように、ドメインは、以前のIPv6移行戦術を使用するか、この時点に直接進むことによって、このフェーズに到達できます。このフェーズでは、インターネット上のすべてのエンドユーザーがIPv4とIPv6の両方を介して、または少なくとも他のIPv6移行戦略を使用せずに、サイトのコンテンツにネイティブにアクセスできるようになります。
If DNS Resolver Whitelisting is adopted, as noted in Section 4.3, then organizations that apply DNS Resolver Whitelisting policies in their authoritative servers should have procedures and systems that do not allow unauthorized parties to modify the whitelist (or blacklist), just as all configuration settings for name servers should be protected by appropriate procedures and systems. Such unauthorized additions or removals from the whitelist (or blacklist) can be damaging, causing content providers and/or network operators to incur support costs resulting from end-user and/or customer contacts, as well as causing potential dramatic and disruptive swings in traffic from IPv6 to IPv4 or vice versa.
セクション4.3に記載されているように、DNSリゾルバーホワイトリストが採用されている場合、権限のあるサーバーにDNSリゾルバーホワイトリストポリシーを適用する組織は、すべての構成設定と同様に、権限のない者がホワイトリスト（またはブラックリスト）を変更できないようにする手順とシステムを備えている必要があります。ネームサーバーは、適切な手順とシステムによって保護する必要があります。ホワイトリスト（またはブラックリスト）からのこのような無許可の追加または削除は損害を与える可能性があり、コンテンツプロバイダーやネットワークオペレーターがエンドユーザーや顧客の連絡先に起因するサポートコストを負担するだけでなく、トラフィックに劇的で破壊的な変動を引き起こす可能性があります。 IPv6からIPv4へ、またはその逆。
DNS Security Extensions (DNSSEC) as defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server that can be used by Security-Aware Resolvers to verify the answers. Since DNS Resolver Whitelisting is implemented on an authoritative DNS server, which provides different answers, depending upon which DNS resolver has sent a query, the DNSSEC chain of trust is not altered. So, even though an authoritative DNS server will selectively return AAAA resource records or a non-existence response, both types of responses will be signed and will validate. In practical terms, this means that two separate views or zones are used, each of which is signed, so that whether or not particular resource records exist, the existence or non-existence of the record can still be validated using DNSSEC. As a result, there should not be any negative impact on DNSSEC for those domains that have implemented DNSSEC on their Security-Aware Authoritative Name Servers and also implemented DNS Resolver Whitelisting. As for any party implementing DNSSEC, such domains should of course ensure that resource records are being appropriately and reliably signed and are consistent with the response being returned.
[RFC4033]、[RFC4034]、および[RFC4035]で定義されているDNS Security Extensions（DNSSEC）は、暗号化デジタル署名を使用して、DNSデータのオリジン認証と整合性保証を提供します。これは、セキュリティ対応リゾルバーが回答を確認するために使用できる、セキュリティ対応権限ネームサーバー上にDNSデータの署名を作成することによって行われます。 DNSリゾルバーホワイトリストは信頼できるDNSサーバーに実装されているため、どのDNSリゾルバーがクエリを送信したかに応じて、さまざまな回答が提供されるため、信頼のDNSSECチェーンは変更されません。したがって、権威あるDNSサーバーがAAAAリソースレコードまたは存在しない応答を選択的に返す場合でも、両方の種類の応答が署名され、検証されます。実際には、これは、2つの別々のビューまたはゾーンが使用され、それぞれが署名されているため、特定のリソースレコードが存在するかどうかにかかわらず、レコードの存在または非存在をDNSSECを使用して検証できることを意味します。その結果、セキュリティ対応の権威ネームサーバーにDNSSECを実装し、DNSリゾルバーのホワイトリストを実装したドメインのDNSSECに悪影響はありません。 DNSSECを実装するすべての関係者に関して、そのようなドメインは、リソースレコードが適切かつ確実に署名され、返される応答と一貫していることを確認する必要があります。
However, network operators that run DNS recursive resolvers should be careful not to modify the responses received from authoritative DNS servers. It is possible that some networks may attempt to do so in order to prevent AAAA record responses from going to end-user hosts, due to some IPv6-related impairment or other lack of IPv6 readiness within that network. But when a network operates a Security-Aware Resolver, modifying or suppressing AAAA resource records for a DNSSEC-signed domain could break the chain of trust established with DNSSEC.
ただし、DNS再帰リゾルバーを実行するネットワークオペレーターは、信頼できるDNSサーバーから受信した応答を変更しないように注意する必要があります。一部のネットワークでは、IPv6関連の障害やその他のネットワーク内のIPv6の準備不足により、AAAAレコードの応答がエンドユーザーホストに送信されないようにする可能性があります。しかし、ネットワークがSecurity-Aware Resolverを操作している場合、DNSSECで署名されたドメインのAAAAリソースレコードを変更または抑制すると、DNSSECで確立された信頼の連鎖が壊れる可能性があります。
As noted in Section 4.1, there is a benefit in sharing IPv6-related impairment statistics within the Internet community over time. Any statistics that are shared or disclosed publicly should be aggregate statistics, such as "the domain example.com has observed an average daily impairment rate of 0.05% in September 2011, down from 0.15% in January 2011". They should not include information that can directly or indirectly identify individuals, such as names or email addresses. Sharing only aggregate data can help protect end-user privacy and any information that may be proprietary to a domain.
セクション4.1で説明したように、IPv6関連の障害の統計をインターネットコミュニティ内で共有することには利点があります。 「ドメインexample.comは、2011年9月に1日の平均減損率が2011年1月の0.15％から0.05％に低下した」などの統計は、集計された統計である必要があります。名前やメールアドレスなど、個人を直接的または間接的に特定できる情報を含めないでください。集計データのみを共有することで、エンドユーザーのプライバシーや、ドメイン固有の情報を保護できます。
In addition, there are often methods to detect IPv6-related impairments for a specific end user, such as running an IPv6 test when an end user visits the website of a particular domain. Should a domain then choose to automatically communicate the facts of an impairment to an affected user, there are likely no direct privacy considerations. However, if the domain then decides to share information concerning that particular end user with that user's network operator or another third party, then the domain may wish to consider advising the end user of this and seeking to obtain the end-user's consent to share such information.
さらに、エンドユーザーが特定のドメインのWebサイトにアクセスしたときにIPv6テストを実行するなど、特定のエンドユーザーのIPv6関連の障害を検出する方法がよくあります。次に、ドメインが障害の事実を影響を受けるユーザーに自動的に通知することを選択した場合、プライバシーに関する直接的な考慮事項はありません。ただし、ドメインがその特定のエンドユーザーに関する情報をそのユーザーのネットワークオペレーターまたは別のサードパーティと共有することを決定した場合、ドメインはこれについてエンドユーザーに助言し、エンドユーザーの同意を得ることを検討することを検討できます。情報。
Appropriate guidelines for any information-sharing likely varies by country and/or legal jurisdiction. Domains should consider any potential privacy issues when considering what information can be shared. If a domain does publish or share detailed impairment statistics, it would be well advised to avoid identifying individual hosts or users.
情報を共有するための適切なガイドラインは、国や法的管轄によって異なります。ドメインは、どの情報を共有できるかを検討する際に、潜在的なプライバシー問題を検討する必要があります。ドメインが詳細な障害統計を公開または共有している場合、個々のホストまたはユーザーを識別しないようにすることをお勧めします。
Finally, if a domain chooses to contact end users directly concerning their IPv6 impairments, that domain should ensure that such communication is permissible under any applicable privacy policies of the domain or its websites.
最後に、ドメインがIPv6障害についてエンドユーザーに直接連絡することを選択した場合、そのドメインは、そのような通信がドメインまたはそのWebサイトの該当するプライバシーポリシーの下で許可されていることを確認する必要があります。
There are situations where the differing quality of the IPv4 and IPv6 connectivity of an end user could cause complications in accessing content when a domain is using an IPv6 migration tactic. While today most end users' IPv4 connectivity is typically superior to IPv6 connectivity (if such connectivity exists at all), there could be implications when the reverse is true and an end user has markedly superior IPv6 connectivity as compared to IPv4. This is not a theoretical situation; it has been observed by at least one major content provider.
ドメインがIPv6移行戦術を使用している場合、エンドユーザーのIPv4およびIPv6接続の品質が異なるとコンテンツへのアクセスが複雑になる状況があります。今日、ほとんどのエンドユーザーのIPv4接続は通常、IPv6接続よりも優れています（そのような接続が存在する場合）、逆が真であり、エンドユーザーがIPv4と比較して著しく優れたIPv6接続を持っている場合に影響がある可能性があります。これは理論的な状況ではありません。少なくとも1つの主要なコンテンツプロバイダーによって確認されています。
For example, in one possible scenario, a user is issued IPv6 addresses by their ISP and has a home network and devices or operating systems that fully support native IPv6. As a result, this theoretical user has very good IPv6 connectivity. However, this end-user's ISP has exhausted their available pool of unique IPv4 addresses, and uses NAT in order to share IPv4 addresses among end users. So, for IPv4 content, the end user must send their IPv4 traffic through some additional network element (e.g., large-scale NAT, proxy server, tunnel server). Use of this additional network element might cause an end user to experience sub-optimal IPv4 connectivity when certain protocols or applications are used. This user then has good IPv6 connectivity but impaired IPv4 connectivity. As a result, the user's poor IPv4 connectivity situation could potentially be exacerbated when accessing a domain that is using a migration tactic that causes this user to only be able to access content over IPv4 transport for whatever reason.
たとえば、考えられる1つのシナリオでは、ユーザーはISPからIPv6アドレスを発行され、ネイティブIPv6を完全にサポートするホームネットワークとデバイスまたはオペレーティングシステムを持っています。その結果、この理論上のユーザーはIPv6接続が非常に良好になります。ただし、このエンドユーザーのISPは一意のIPv4アドレスの利用可能なプールを使い果たし、エンドユーザー間でIPv4アドレスを共有するためにNATを使用します。そのため、IPv4コンテンツの場合、エンドユーザーは追加のネットワーク要素（大規模なNAT、プロキシサーバー、トンネルサーバーなど）を介してIPv4トラフィックを送信する必要があります。この追加のネットワーク要素を使用すると、特定のプロトコルまたはアプリケーションが使用されているときに、エンドユーザーがIPv4接続を最適化できない可能性があります。このユーザーは、IPv6接続は良好ですが、IPv4接続が低下しています。その結果、何らかの理由でこのユーザーがIPv4トランスポートを介してコンテンツにしかアクセスできないようにする移行戦略を使用しているドメインにアクセスすると、ユーザーのIPv4接続状況が悪化する可能性があります。
Should this sort of situation become widespread in the future, a domain may wish to take it into account when deciding how and when to transition content to IPv6.
この種の状況が将来的に広まる場合、ドメインは、コンテンツをIPv6に移行する方法と時期を決定するときにそれを考慮に入れたい場合があります。
The following people made significant textual contributions to this document and/or played an important role in the development and evolution of this document:
次の人々は、このドキュメントに重要なテキストの貢献をしたか、このドキュメントの開発と進化において重要な役割を果たしました。
- John Brzozowski - Chris Griffiths - Tom Klieber - Yiu Lee - Rich Woundy
- John Brzozowski-Chris Griffiths-Tom Klieber-Yiu Lee-Rich Woundy
The author and contributors also wish to acknowledge the assistance of the following individuals or groups. Some of these people provided helpful and important guidance in the development of this document and/or in the development of the concepts covered in this document. Other people assisted by performing a detailed review of this document and then providing feedback and constructive criticism for revisions to this document, or engaged in a healthy debate over the subject of the document. All of this was helpful, and therefore the following individuals merit acknowledgement:
著者と寄稿者は、以下の個人またはグループの支援にも感謝します。これらの人々の何人かは、このドキュメントの開発および/またはこのドキュメントでカバーされている概念の開発に役立つ重要なガイダンスを提供しました。他の人々は、このドキュメントの詳細なレビューを実行し、このドキュメントの改訂に対するフィードバックと建設的な批判を提供したり、ドキュメントの主題について健全な議論を行ったりすることで支援しました。これはすべて役に立ちました。そのため、以下の個人は承認に値します：
- Bernard Aboba - Mark Andrews - Jari Arkko - Fred Baker - Ron Bonica - Frank Bulk - Brian Carpenter - Lorenzo Colitti - Alissa Cooper - Dave Crocker - Ralph Droms - Wesley Eddy
- バーナードアボバ-マークアンドリュース-ジャリアルコ-フレッドベイカー-ロンボニカ-フランクバルク-ブライアンカーペンター-ロレンゾコリッティ-アリッサクーパー-デイブクロッカー-ラルフドロムス-ウェスリーエディ
- J.D. Falk - Adrian Farrel - Stephen Farrell - Tony Finch - Karsten Fleischhauer - Igor Gashinsky - Wesley George - Philip Homburg - Jerry Huang - Ray Hunter - Joel Jaeggli - Erik Kline - Suresh Krishnan - Victor Kuarsingh - Marc Lampo - Donn Lee - John Leslie - John Mann - Danny McPherson - Milo Medin - Martin Millnert - Russ Mundy - Thomas Narten - Pekka Savola - Robert Sparks - Barbara Stark - Joe Touch - Hannes Tschofenig - Tina Tsou - Members of the Broadband Internet Technical Advisory Group (BITAG)
- JDフォーク-エイドリアンファレル-スティーブンファレル-トニーフィンチ-カルステンフライシュハウアー-イゴールガシンスキー-ウェスリージョージ-フィリップホンブルク-ジェリーフアン-レイハンター-ジョエルジャグリ-エリッククライン-スレシュクリシュナン-ビクタークアルシン-マークランポ-ドンリー-ジョンレスリー-John Mann-Danny McPherson-Milo Medin-Martin Millnert-Russ Mundy-Thomas Narten-Pekka Savola-Robert Sparks-Barbara Stark-Joe Touch-Hannes Tschofenig-Tina Tsou-Broadband Internet Technical Advisory Group（BITAG）のメンバー
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995.
[RFC1794] Brisco、T。、「DNS Support for Load Balancing」、RFC 1794、1995年4月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、編、「インターネットのアーキテクチャ原則」、RFC 1958、1996年6月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775] Carpenter、B。、「Internet Transparency」、RFC 2775、2000年2月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC2956] Kaat, M., "Overview of 1999 IAB Network Layer Workshop", RFC 2956, October 2000.
[RFC2956] Kaat、M。、「Overview of 1999 IAB Network Layer Workshop」、RFC 2956、2000年10月。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002.
[RFC3234]カーペンター、B。およびS.ブリム、「ミドルボックス：分類と問題」、RFC 3234、2002年2月。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[RFC3724] Kempf、J.、Ed。、Austein、R.、Ed。、およびIAB、「中間の台頭とエンドツーエンドの未来：インターネットアーキテクチャの進化に関する考察」、RFC 3724 、2004年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、2005年10月。
[Heise] Heise.de, "The Big IPv6 Experiment", Heise.de Website http://www.h-online.com, January 2011, <http://www.h-online.com/features/ The-big-IPv6-experiment-1165042.html>.
[Heise] Heise.de、「The Big IPv6 Experiment」、Heise.de Website http：//www.h-online.com、2011年1月、<http://www.h-online.com/features/ The- big-IPv6-experiment-1165042.html>。
[IETF-77-DNSOP] Gashinsky, I., "IPv6 & recursive resolvers: How do we make the transition less painful?", IETF 77 DNS Operations Working Group, March 2010, <http://www.ietf.org/proceedings/77/slides/dnsop-7.pdf>.
[IETF-77-DNSOP] Gashinsky、I。、「IPv6と再帰リゾルバ：どうすれば移行を簡単にすることができるのか？」、IETF 77 DNS Operations Working Group、2010年3月、<http://www.ietf.org/議事録/77/slides/dnsop-7.pdf>。
[IPv6-Brokenness] Anderson, T., "Measuring and Combating IPv6 Brokenness", Reseaux IP Europeens (RIPE) 61st Meeting, November 2010, <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[IPv6-Brokenness] Anderson、T.、 "Measuring and Combating IPv6 Brokenness"、Reseaux IP Europeens（RIPE）61st Meeting、November 2010、<http://ripe61.ripe.net/presentations/162-ripe61.pdf>。
[IPv6-Growth] Colitti, L., Gunderson, S., Kline, E., and T. Refice, "Evaluating IPv6 adoption in the Internet", Proceedings of the 11th International Conference on Passive and Active Measurement (PAM 2010), Springer, Lecture Notes in Computer Science, 2010, Volume 6032, Passive and Active Measurement, Pages 141-150.
[IPv6-Growth] Colitti、L.、Gunderson、S.、Kline、E。、およびT. Refice、「インターネットでのIPv6導入の評価」、第11回パッシブおよびアクティブ測定に関する国際会議の議事録（PAM 2010）、 Springer、コンピュータサイエンスの講義ノート、2010年、第6032巻、パッシブおよびアクティブ測定、ページ141-150。
[NW-Article-DNS-WL] Marsan, C., "Google, Microsoft, Netflix in talks to create shared list of IPv6 users", Network World, March 2010, <http://www.networkworld.com/news/2010/ 032610-dns-ipv6-whitelist.html>.
[NW-Article-DNS-WL] Marsan、C。、「IPv6ユーザーの共有リストを作成するためのGoogle、Microsoft、Netflixの協議」、Network World、2010年3月、<http://www.networkworld.com/news/ 2010 / 032610-dns-ipv6-whitelist.html>。
[NW-Article-DNSOP] Marsan, C., "Yahoo proposes 'really ugly hack' to DNS", Network World, March 2010, <http://www.networkworld.com/ news/2010/032610-yahoo-dns.html>.
[NW-Article-DNSOP] Marsan、C。、「YahooがDNSに「本当に醜いハック」を提案する」、ネットワークワールド、2010年3月、<http://www.networkworld.com/news/2010/032610-yahoo-dns .html>。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]カーペンター、B。、「6to4展開に関する勧告ガイドライン」、RFC 6343、2011年8月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555] Wing、D。、およびA. Yourtchenko、「Happy Eyeballs：Success with Dual-Stack Hosts」、RFC 6555、2012年4月。
[Rethinking] Blumenthal, M. and D. Clark, "Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave New World", ACM Transactions on Internet Technology, Volume 1, Number 1, Pages 70-109, August 2001, <http://groups.csail.mit.edu/ana/Publications/PubPDFs/ Rethinking the design of the internet2001.pdf>.
[再考] Blumenthal、M。、およびD.クラーク、「インターネットの設計を再考する：エンドツーエンドの議論と大胆な新世界」、インターネットテクノロジーに関するACMトランザクション、ボリューム1、ナンバー1、ページ70- 109、2001年8月、<http://groups.csail.mit.edu/ana/Publications/PubPDFs/インターネット2001.pdfのデザインを再考する>。
[Tussle] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", Proceedings of ACM Sigcomm 2002, August 2002, <http://groups.csail.mit.edu/ana/Publications/PubPDFs/ Tussle2002.pdf>.
[タスル]クラークD.、ブロツラフJ.、ソリンズK.、およびR.ブレーデン、「サイバースペースの闘い：明日のインターネットの定義」、ACM Sigcomm 2002の議事録、2002年8月、<http：//groups.csail .mit.edu / ana / Publications / PubPDFs / Tussle2002.pdf>。
[W6D] The Internet Society, "World IPv6 Day - June 8, 2011", Internet Society Website http://www.isoc.org, January 2011, <http://isoc.org/wp/worldipv6day/>.
[W6D] The Internet Society、「World IPv6 Day-June 8、2011」、Internet Society Website http：//www.isoc.org、2011年1月、<http://isoc.org/wp/worldipv6day/>。
[WL-Concerns] Brzozowski, J., Griffiths, C., Klieber, T., Lee, Y., Livingood, J., and R. Woundy, "IPv6 DNS Whitelisting - Could It Hinder IPv6 Adoption?", ISOC (Internet Society) IPv6 Deployment Workshop, April 2010, <http://www.comcast6.net/ IPv6_DNS_Whitelisting_Concerns_20100416.pdf>.
[WLの懸念] Brzozowski、J.、Griffiths、C.、Klieber、T.、Lee、Y.、Livingood、J。、およびR. Woundy、「IPv6 DNSホワイトリスト-IPv6の採用を妨げる可能性があるか？」、ISOC（ Internet Society）IPv6 Deployment Workshop、April 2010、<http://www.comcast6.net/ IPv6_DNS_Whitelisting_Concerns_20100416.pdf>。
[WL-Ops] Kline, E., "IPv6 Whitelist Operations", Google IPv6 Implementors Conference, June 2010, <http://sites.google.com/site/ipv6implementors/2010/ agenda/IPv6_Whitelist_Operations.pdf>.
[WL-Ops] Kline、E。、「IPv6 Whitelist Operations」、Google IPv6 Implementors Conference、2010年6月、<http://sites.google.com/site/ipv6implementors/2010/ agenda / IPv6_Whitelist_Operations.pdf>。
[Wild-Resolvers] Ager, B., Smaragdakis, G., Muhlbauer, W., and S. Uhlig, "Comparing DNS Resolvers in the Wild", ACM Sigcomm Internet Measurement Conference 2010, November 2010, <http://conferences.sigcomm.org/imc/2010/papers/p15.pdf>.
[Wild-Resolvers] Ager、B.、Smaragdakis、G.、Muhlbauer、W.、and S. Uhlig、 "Comparing DNS Resolvers in the Wild"、ACM Sigcomm Internet Measurement Conference 2010、November 2010、<http：// conferences .sigcomm.org / imc / 2010 / papers / p15.pdf>。
[World-IPv6-Launch] The Internet Society, "World IPv6 Launch Website", June 2012, <http://www.worldipv6launch.org/>.
[World-IPv6-Launch] The Internet Society、「World IPv6 Launch Website」、2012年6月、<http://www.worldipv6launch.org/>。
Author's Address
著者のアドレス
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 US
Jason Livingood Comcast Cable Communications One Comcast Center 1701 John F. Kennedy Boulevard Philadelphia、PA 19103 US
EMail: jason_livingood@cable.comcast.com
URI: http://www.comcast.com