[要約] RFC 7094は、IP Anycastのアーキテクチャに関する考慮事項を提供する。その目的は、IP Anycastの設計と展開に関するガイダンスを提供し、インターネットのパフォーマンスと信頼性を向上させることである。
Internet Architecture Board (IAB) D. McPherson
Request for Comments: 7094 Verisign, Inc.
Category: Informational D. Oran
ISSN: 2070-1721 Cisco Systems
D. Thaler
Microsoft Corporation
E. Osterweil
Verisign, Inc.
January 2014
Architectural Considerations of IP Anycast
IPエニーキャストのアーキテクチャに関する考慮事項
Abstract
概要
This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols.
このメモは、IPエニーキャストのアーキテクチャ上の影響について説明し、さまざまなIETFプロトコルによるエニーキャストの使用に関するいくつかの履歴分析を提供します。
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 Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7094.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7094で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Overview ........................................................2
2. Background ......................................................3
2.1. Anycast History ............................................3
2.2. Anycast in IPv6 ............................................6
2.3. DNS Anycast ................................................6
2.4. BCP 126 on Operation of Anycast Services ...................8
3. Principles ......................................................8
3.1. Layering and Resiliency ....................................8
3.2. Anycast Addresses as Destinations ..........................9
3.3. Anycast Addresses as Sources ..............................10
3.4. Service Discovery .........................................10
4. Analysis .......................................................11
4.1. Regarding Widespread Anycast Use ..........................11
4.2. Transport Implications ....................................11
4.3. Stateful Firewalls, Middleboxes, and Anycast ..............12
4.4. Security Considerations ...................................12
4.5. Deployment Considerations .................................15
5. Conclusions ....................................................16
6. Acknowledgements ...............................................16
7. Informative References .........................................16
Appendix A. IAB Members at the Time of Approval ...................21
IP anycast is a technique with a long legacy and interesting engineering challenges. However, at its core, it is a relatively simple concept. As described in BCP 126 [RFC4786], the general form of IP anycast is the practice of making a particular Service Address available in multiple, discrete, autonomous locations, such that datagrams sent are routed to one of several available locations.
IPエニーキャストは、長い間レガシーで興味深いエンジニアリング上の課題がある技術です。ただし、その中心は比較的単純な概念です。 BCP 126 [RFC4786]で説明されているように、IPエニーキャストの一般的な形式は、送信されるデータグラムがいくつかの利用可能な場所の1つにルーティングされるように、特定のサービスアドレスを複数の個別の自律的な場所で利用できるようにする方法です。
IP anycast is used for at least one critical Internet service: that of the Domain Name System [RFC1035] root servers. By late 2007, at least 10 of the 13 root name servers were already using IP anycast [RSSAC29]. Use of IP anycast is growing for other applications as well. It has been deployed for over a decade for DNS resolution services and is currently used by several DNS Top Level Domain (TLD) operators. IP anycast is also used for other services in operational environments, including Network Time Protocol (NTP) [RFC5905] services.
IPエニーキャストは、少なくとも1つの重要なインターネットサービス（ドメインネームシステム[RFC1035]ルートサーバーのサービス）に使用されます。 2007年後半までに、13台のルートネームサーバーのうち少なくとも10台がすでにIPエニーキャスト[RSSAC29]を使用していた。 IPエニーキャストの使用は、他のアプリケーションでも成長しています。 DNS解決サービスのために10年以上にわたって導入されており、現在、いくつかのDNSトップレベルドメイン（TLD）オペレーターによって使用されています。 IPエニーキャストは、ネットワークタイムプロトコル（NTP）[RFC5905]サービスなど、運用環境の他のサービスにも使用されます。
Anycast addresses are syntactically indistinguishable from unicast addresses. Anycast addressing is equivalent to that of unicast in multiple locations. Destination-based routing does best-effort delivery of a packet to one interface among the set of interfaces asserting reachability for the address. The expectation of delivery is to the "closest" instance as determined by unicast routing topology metric(s), and there is also a possibility that various load-balancing techniques (e.g., per-packet, per-microflow) may be used among multiple equal-cost routes to distribute load for an anycasted prefix.
エニーキャストアドレスは、構文的にはユニキャストアドレスと区別できません。エニーキャストのアドレス指定は、複数の場所でのユニキャストのアドレス指定と同等です。宛先ベースのルーティングは、アドレスの到達可能性をアサートする一連のインターフェイスのうち、1つのインターフェイスにパケットをベストエフォートで配信します。配信の期待は、ユニキャストルーティングトポロジメトリックによって決定される「最も近い」インスタンスであり、さまざまなロードバランシング技術（たとえば、パケットごと、マイクロフローごと）が複数の間で使用される可能性もあります。エニーキャストプレフィックスの負荷を分散するための等コストルート。
Unlike IP unicast, it is not considered an error to assert the same anycast address on multiple interfaces within the same or multiple systems.
IPユニキャストとは異なり、同じまたは複数のシステム内の複数のインターフェイスで同じエニーキャストアドレスをアサートしても、エラーとは見なされません。
When IP anycast is employed, many pitfalls and subtleties exist with applications and transports as well as for routing configuration and operation. In this document, we aim to capture many of the architectural implications of IP anycast.
IPエニーキャストを使用する場合、アプリケーションとトランスポート、およびルーティングの構成と操作に関して、多くの落とし穴と機微が存在します。このドキュメントでは、IPエニーキャストのアーキテクチャ上の影響の多くを捉えることを目指しています。
BCP 126 [RFC4786] discusses several different deployment models with IP anycast. Two additional distinctions beyond that document involve "off-link anycast" and "on-link anycast". "Off-link anycast" takes advantage of routing protocol preferences and the IP hop-by-hop destination-based forwarding paradigm in order to direct packets to the "closest" destination. This is the traditional method of anycast largely considered in BCP 126 [RFC4786] and can be used for IPv4 and IPv6. "On-link anycast" is the formal support of anycast in the address resolution (duplicate address detection) protocol and is only standardized for IPv6, with the introduction of designated anycast addresses on the anycasted hosts, and the Override flag in Neighbor Discovery (ND) Neighbor Advertisements (NAs) [RFC4861]. There is no standardized mechanism for this in IPv4.
BCP 126 [RFC4786]では、IPエニーキャストを使用したいくつかの異なる展開モデルについて説明しています。このドキュメント以外に、「オフリンクエニーキャスト」と「オンリンクエニーキャスト」の2つの違いがあります。 「オフリンクエニーキャスト」は、ルーティングプロトコルプリファレンスとIPホップバイホップ宛先ベースの転送パラダイムを利用して、「最も近い」宛先にパケットを転送します。これは主にBCP 126 [RFC4786]で検討されているエニーキャストの伝統的な方法であり、IPv4およびIPv6に使用できます。 「オンリンクエニーキャスト」は、アドレス解決（重複アドレス検出）プロトコルでのエニーキャストの正式なサポートであり、エニーキャストホストに指定されたエニーキャストアドレスが導入され、ネイバー探索（ND ）ネイバーアドバタイズメント（NA）[RFC4861]。 IPv4には、このための標準化されたメカニズムはありません。
As of this writing, the term "anycast" appears in 176 RFCs and 144 active Internet-Drafts. The following sections capture some of the key appearances and discussion of anycasting within the IETF over the years.
この記事の執筆時点で、「エニーキャスト」という用語は、176のRFCと144のアクティブなインターネットドラフトに登場しています。次のセクションでは、長年にわたるIETF内のエニーキャスティングの主要な外観とディスカッションの一部をキャプチャします。
The first formal specification of anycast was provided in "Host Anycasting Service" [RFC1546]. The authors of this document did a good job of capturing most of the issues that exist with IP anycast today.
エニーキャストの最初の正式な仕様は、「Host Anycasting Service」[RFC1546]で提供されました。このドキュメントの作成者は、今日のIPエニーキャストに存在する問題のほとんどを把握するのに役立ちました。
One of the first documented uses of anycast was in 1994 for a "Video Registry" experiment [IMR9401]. In the experiment, a UDP query was transmitted to an anycasted address to locate the topologically closest "supposedly equivalent network resource":
エニーキャストの最初の文書化された使用法の1つは、1994年に「Video Registry」実験[IMR9401]であった。実験では、UDPクエリがエニーキャストアドレスに送信され、トポロジ的に最も近い「想定される同等のネットワークリソース」を見つけました。
A video resource (for example, a catalog server that lists available video clips) sends an anycast UDP datagram to locate the nearest video registry. At most one registry responds with a unicast UDP datagram containing the registry's IP address. Said resource then opens a TCP connection to that [the received registry address] address and sends a request to register itself. Every 5 minutes or so, each registry multicasts to all other registries all of the resources it knows from local registration requests. It also immediately announces newly registered resources. Remotely registered resources not heard about for 20 minutes are dropped.
ビデオリソース（たとえば、利用可能なビデオクリップをリストするカタログサーバー）は、エニーキャストUDPデータグラムを送信して、最も近いビデオレジストリを見つけます。最大で1つのレジストリが、レジストリのIPアドレスを含むユニキャストUDPデータグラムで応答します。次に、そのリソースはその[受信したレジストリアドレス]アドレスへのTCP接続を開き、自分自身を登録する要求を送信します。 5分程度ごとに、各レジストリは、ローカルの登録要求から知っているすべてのリソースを他のすべてのレジストリにマルチキャストします。また、新しく登録されたリソースをすぐに発表します。 20分間聞こえなかったリモート登録リソースはドロップされます。
There is also discussion that ISPs began using anycast for DNS resolution services around the same time, although no public references to support this are available.
ISPがDNS解決サービスにエニーキャストをほぼ同時に使用し始めたとの議論もありますが、これをサポートするパブリックリファレンスはありません。
In 1997, the IAB clarified that IPv4 anycast addresses were pure "locators" and could never serve as "identifiers" of hosts or interfaces [RFC2101].
1997年に、IABはIPv4エニーキャストアドレスが純粋な「ロケーター」であり、ホストまたはインターフェースの「識別子」として機能することができないことを明らかにしました[RFC2101]。
In 1998, the IAB conducted a routing workshop [RFC2902]. Of the conclusions and output action items from the report, an Anycast section is contained in Section 2.10.3. Specifically called out is the need to describe the advantages and disadvantages of anycast and the belief that local-scoped well-known anycast addresses will be useful to some applications. In the subsequent section, an action item was outlined that suggested a BOF should be held to plan work on anycast, and if a working group forms, a paper on the advantages and the disadvantages of anycast should be included as part of the charter.
1998年、IABはルーティングワークショップ[RFC2902]を実施しました。レポートの結論と出力アクションアイテムのうち、エニーキャストセクションはセクション2.10.3に含まれています。特に呼び出されるのは、エニーキャストの長所と短所、およびローカルスコープの既知のエニーキャストアドレスが一部のアプリケーションに役立つという信念を説明する必要性です。次のセクションでは、エニキャストに関する作業を計画するためにBOFを開催することを提案するアクションアイテムの概要を説明し、ワーキンググループが形成される場合は、エニーキャストの長所と短所に関するペーパーを憲章の一部として含める必要があります。
As a result of the recommendation in [RFC2902], an Anycast BOF [ANYCASTBOF] was held at IETF 46 in November of 1999. A number of uses for anycast were discussed. No firm conclusion was reached regarding use of TCP with anycasted services. However, it was observed that anycasting was useful for DNS, although it did introduce some new complexities. The use of global anycast was not expected to scale (see Section 4.1 below for more discussion) and, hence, was expected to be limited to a small number of key uses.
[RFC2902]の勧告の結果、エニーキャストBOF [ANYCASTBOF]が1999年11月にIETF 46で開催されました。エニーキャストの多くの使用法が議論されました。エニーキャストサービスでのTCPの使用に関して、確固たる結論には至りませんでした。ただし、エニーキャスティングはいくつかの新しい複雑さをもたらしましたが、DNSに役立つことが観察されました。グローバルエニーキャストの使用は、拡張が予想されておらず（詳細については、以下のセクション4.1を参照）、したがって、少数の主要な用途に限定されると予想されていました。
In 2001, the Multicast and Anycast Group Membership [MAGMA] WG was chartered to address host-to-router signaling, including initial authentication and access control issues for multicast and anycast group membership, but other aspects of anycast, including architecture and routing, were outside the group's scope.
2001年に、マルチキャストおよびエニーキャストグループメンバーシップ[MAGMA] WGは、マルチキャストおよびエニーキャストグループメンバーシップの初期認証およびアクセス制御の問題を含む、ホストからルーターへのシグナリングに対処するために設立されましたが、アーキテクチャやルーティングを含むエニーキャストの他の側面は、グループの範囲外。
Simple Network Time Protocol (SNTP) Version 4 [RFC2030] defined how to use SNTP anycast for server discovery. This was extended in [RFC4330] as an NTP-specific "manycast" service, in which anycast was used for the discovery part.
Simple Network Time Protocol（SNTP）バージョン4 [RFC2030]は、サーバー検出にSNTPエニーキャストを使用する方法を定義しました。これは、[RFC4330]でNTP固有の「マニーキャスト」サービスとして拡張されました。このサービスでは、検出部分にエニーキャストが使用されました。
IPv6 defined some reserved subnet anycast addresses [RFC2526] and assigned one to "Mobile IPv6 Home-Agents" [RFC3775] (obsoleted by [RFC6275]).
IPv6はいくつかの予約済みサブネットエニーキャストアドレス[RFC2526]を定義し、「モバイルIPv6ホームエージェント」[RFC3775]に1つ割り当てました（[RFC6275]により廃止）。
The original IPv6 transition mechanism [RFC2893] made use of IPv4 anycast addresses as tunnel endpoints for IPv6 encapsulated in IPv4, but this was later removed [RFC4213]. The 6to4 tunneling protocol [RFC3056] was augmented by a 6to4 relay anycast prefix [RFC3068] in a move aimed at simplifying the configuration of 6to4 routers. Incidentally, 6to4 deployment has shown a fair number of operational and security issues [RFC3964] that result from using anycast as a discovery mechanism. Specifically, one inference is that operational consideration is needed to ensure that anycast addresses get advertised and/or filtered in a way that produces the intended scope (e.g., only advertise a route for your 6to4 relay to Autonomous Systems (ASes) that conform to your own acceptable usage policy), an attribute that can easily become quite operationally expensive.
オリジナルのIPv6移行メカニズム[RFC2893]は、IPv4にカプセル化されたIPv6のトンネルエンドポイントとしてIPv4エニーキャストアドレスを使用しましたが、これは後で削除されました[RFC4213]。 6to4トンネリングプロトコル[RFC3056]は、6to4ルーターの構成を簡略化することを目的とした6to4リレーエニーキャストプレフィックス[RFC3068]によって拡張されました。ちなみに、6to4の配置では、エニーキャストを検出メカニズムとして使用することから生じる、運用上およびセキュリティ上の問題[RFC3964]が多数示されています。具体的には、1つの推論は、エニーキャストアドレスが意図したスコープを生成する方法（たとえば、6to4リレーのルートを自律システム（AS）にアドバタイズするルートのみをアドバタイズする方法でアドバタイズする独自の許容される使用ポリシー）、これは簡単に非常に運用コストが高くなる可能性がある属性です。
In 2002, DNS' use of anycast was first specified in "Distributing Authoritative Name Servers via Shared Unicast Addresses" [RFC3258]. It is notable that it used the term "shared unicast address" rather than "anycast address" for the service. This distinction was made due to the IPv6 differentiation in the on-link model. "Shared unicast" addresses are unicast (not multicast) in the IPv6 model and, therefore, support the off-link anycast model (described earlier) but not the on-link anycast model. At the same time, site-local-scoped well-known addresses began being used for recursive resolvers [DNS-DISC], but this use was never standardized (see below in Section 3.4 for more discussion).
2002年、DNSによるエニーキャストの使用は、「共有ユニキャストアドレスを介した権威ネームサーバーの配布」[RFC3258]で最初に規定されました。サービスの「エニーキャストアドレス」ではなく「共有ユニキャストアドレス」という用語を使用したことは注目に値します。この区別は、オンリンクモデルにおけるIPv6の差別化のために行われました。 「共有ユニキャスト」アドレスは、IPv6モデルではユニキャスト（マルチキャストではない）であるため、オフリンクエニーキャストモデル（前述）をサポートしていますが、オンリンクエニーキャストモデルはサポートしていません。同時に、サイトローカルスコープの既知のアドレスが再帰リゾルバー[DNS-DISC]に使用され始めましたが、この使用は標準化されていませんでした（詳細については、セクション3.4を参照）。
Anycast was used for routing to rendezvous points (RPs) for PIM [RFC4610].
エニーキャストは、PIM [RFC4610]のランデブーポイント（RP）へのルーティングに使用されました。
"Operation of Anycast Services" BCP 126 [RFC4786] deals with how the routing system interacts with anycast services and the operation of anycast services.
「エニーキャストサービスの操作」BCP 126 [RFC4786]は、ルーティングシステムがエニーキャストサービスとやり取りする方法とエニーキャストサービスの操作を扱います。
"Requirements for a Mechanism Identifying a Name Server Instance" [RFC4892] cites the use of anycast with DNS as a motivation to identify individual name server instances, and the Name Server ID (NSID) option was defined for this purpose [RFC5001]. One could view the addition of NSID as an incarnation of locator and identifier separation (where the anycast address is a locator and the NSID is an identifier).
「ネームサーバーインスタンスを識別するメカニズムの要件」[RFC4892]は、DNSでのエニーキャストの使用を個々のネームサーバーインスタンスを識別する動機として引用しており、この目的のためにネームサーバーID（NSID）オプションが定義されています[RFC5001]。 NSIDの追加は、ロケーターと識別子の分離（エニーキャストアドレスはロケーターであり、NSIDは識別子です）の具体化と見なすことができます。
The IAB's "Reflections on Internet Transparency" [RFC4924] briefly mentions how violating transparency can also damage global services that use anycast.
IABの「Reflections on Internet Transparency」[RFC4924]は、透明性の違反がエニーキャストを使用するグローバルサービスにどのように影響を与えるかについて簡単に述べています。
Originally, the IPv6 addressing architecture [RFC1884] [RFC2373] [RFC3513] severely restricted the use of anycast addresses. In particular, the architecture provided that anycast addresses must not be used as source addresses and must not be assigned to IPv6 hosts (i.e., only routers). These restrictions were later lifted in 2006 [RFC4291].
もともと、IPv6アドレス指定アーキテクチャ[RFC1884] [RFC2373] [RFC3513]は、エニーキャストアドレスの使用を厳しく制限していました。特に、エニーキャストアドレスを送信元アドレスとして使用したり、IPv6ホスト（ルーターのみ）に割り当てたりしてはならないというアーキテクチャを採用しています。これらの制限は、2006年に解除されました[RFC4291]。
In fact, the more recent "IPv6 Transition/Co-existence Security Considerations" [RFC4942] overview now recommends:
実際、最近の「IPv6移行/共存セキュリティに関する考慮事項」[RFC4942]の概要では、次のことを推奨しています。
To avoid exposing knowledge about the internal structure of the network, it is recommended that anycast servers now take advantage of the ability to return responses with the anycast address as the source address if possible.
ネットワークの内部構造に関する知識が公開されないようにするには、エニーキャストサーバーが、可能であればエニーキャストアドレスをソースアドレスとして応答を返す機能を利用することをお勧めします。
As discussed in the Overview, "on-link anycast" is employed expressly in IPv6 via ND NAs; see Section 7.2.7 of [RFC4861] for additional information.
概要で説明したように、「オンリンクエニーキャスト」は、ND NAを介してIPv6で明示的に使用されます。詳細については、[RFC4861]のセクション7.2.7を参照してください。
"Distributed Authoritative Name Servers via Shared Unicast Addresses" [RFC3258] described how to reach authoritative name servers using multiple unicast addresses, each one configured on a different set of servers. It stated in Section 2.3:
「共有ユニキャストアドレスを介した権威ネームサーバーの分散」[RFC3258]は、複数のユニキャストアドレスを使用して権威ネームサーバーに到達する方法を説明し、それぞれが異なるサーバーセットで構成されています。それはセクション2.3で述べた：
This document presumes that the usual DNS failover methods are the only ones used to ensure reachability of the data for clients. It does not advise that the routes be withdrawn in the case of failure; it advises instead that the DNS process shutdown so that servers on other addresses are queried. This recommendation reflects a choice between performance and operational complexity. While it would be possible to have some process withdraw the route for a specific server instance when it is not available, there is considerable operational complexity involved in ensuring that this occurs reliably. Given the existing DNS failover methods, the marginal improvement in performance will not be sufficient to justify the additional complexity for most uses.
このドキュメントでは、通常のDNSフェイルオーバー方法が、クライアントのデータの到達可能性を確保するために使用される唯一の方法であると想定しています。障害が発生した場合にルートを撤回することはお勧めしません。代わりに、他のアドレスのサーバーが照会されるようにDNSプロセスをシャットダウンすることをお勧めします。この推奨事項は、パフォーマンスと運用の複雑さの間の選択を反映しています。特定のサーバーインスタンスのルートが利用できない場合に、そのプロセスでルートを取り消すことは可能ですが、これが確実に行われるようにするには、操作がかなり複雑になります。既存のDNSフェイルオーバー方法を考えると、パフォーマンスのわずかな改善だけでは、ほとんどの用途で追加の複雑さを正当化するのに十分ではありません。
In anycast more generally, most anycast benefits cannot be realized without route withdrawals, since traffic will continue to be directed to the link with the failed server. When multiple unicast addresses are used with different sets of servers, a client can still fail over to using a different server address and, hence, a different set of servers. There can still be reliability problems, however, when each set contains a failed server. If all servers in the same set are on the same subnet, such problems could be minimized where address resolution within the subnet will cause traffic to go to an available server.
より一般的にエニーキャストでは、トラフィックは障害が発生したサーバーとのリンクに引き続き送信されるため、ルートの撤回なしではほとんどのエニーキャストの利点を実現できません。異なるサーバーのセットで複数のユニキャストアドレスが使用されている場合でも、クライアントは、異なるサーバーアドレス、つまり異なるサーバーのセットを使用するようにフェイルオーバーできます。ただし、各セットに障害が発生したサーバーが含まれている場合は、信頼性の問題が発生する可能性があります。同じセット内のすべてのサーバーが同じサブネット上にある場合は、サブネット内のアドレス解決によってトラフィックが使用可能なサーバーに送られるような問題を最小限に抑えることができます。
Other assertions included:
その他のアサーションが含まれています：
o It asserted (as an advantage) that no routing changes were needed.
o それは（利点として）ルーティングの変更が必要ないことを主張しました。
o It recommended stopping DNS processes rather than withdrawing routes to deal with failures, data synchronization issues, and failover, as provided in the quoted text above. The spirit of this advice was that DNS resolvers may (indeed) reach out and query unavailable DNS name servers, but as their queries time out, they will elect to pin themselves to other server addresses and, hence, different servers.
o 上記の引用テキストにあるように、障害、データ同期の問題、フェイルオーバーに対処するためにルートを撤回するのではなく、DNSプロセスを停止することを推奨しました。このアドバイスの精神は、DNSリゾルバーが（実際に）使用できないDNSネームサーバーに到達してクエリを実行する可能性があることですが、クエリがタイムアウトすると、他のサーバーアドレス、つまり別のサーバーにピン留めすることを選択します。
o It argued that failure modes involving state were not serious, because:
o それは状態を含む故障モードが深刻ではなかったと主張した：
* the vast majority of DNS queries are UDP
* DNSクエリの大部分はUDPです
* large routing metric disparity among authoritative server instances would localize queries to a single instance for most clients
* 信頼できるサーバーインスタンス間のルーティングメトリックの大きな差異は、ほとんどのクライアントのクエリを単一のインスタンスにローカライズします
* when the resolver tries TCP and it breaks, the resolver will try to move to a different server address. In order to ensure that this is possible, it is important that the DNS zone be configured with multiple server addresses for different sets of name servers. The advice given in Section 3.3 of [DNS-DISC] describes, in more detail, why using multiple addresses is important.
* リゾルバーがTCPを試行して中断すると、リゾルバーは別のサーバーアドレスに移動しようとします。これが可能であることを確認するには、ネームサーバーの異なるセットに対して複数のサーバーアドレスでDNSゾーンを構成することが重要です。 [DNS-DISC]のセクション3.3に記載されているアドバイスは、複数のアドレスを使用することが重要である理由をより詳細に説明しています。
"Unique Per-Node Origin ASNs for Globally Anycasted Services" [RFC6382] makes recommendations regarding the use of per-node unique origin Autonomous System Numbers (ASNs) for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. The object was to allow network management and monitoring techniques, or other operational mechanisms to employ this new origin AS as a discriminator in whatever manner fits their operating environment, either for detection or policy associated with a given anycasted node.
「グローバルエニーキャストサービスの一意のノードごとの発信元ASN」[RFC6382]は、指定されたエニーキャストプレフィックスにルーティングシステム識別子を提供するために、グローバルエニーキャストの重要インフラストラクチャサービスに対するノードごとの固有の発信元自律システム番号（ASN）の使用に関する推奨事項を作成します。その目的は、ネットワーク管理および監視技術、またはその他の運用メカニズムが、特定のエニーキャストノードに関連付けられた検出またはポリシーのために、運用環境に適した方法でこの新しいオリジンASを弁別器として使用できるようにすることでした。
"Operation of Anycast Services" BCP 126 [RFC4786] was a product of the IETF's GROW working group. The primary design constraint considered was that routing "be stable" for significantly longer than a "transaction time", where "transaction time" is loosely defined as "a single interaction between a single client and a single server". It takes no position on what applications are suitable candidates for anycast usage.
「エニーキャストサービスの運用」BCP 126 [RFC4786]は、IETFのGROWワーキンググループの製品でした。検討された主な設計上の制約は、ルーティングが「トランザクション時間」よりも大幅に「安定」していることです。どのアプリケーションがエニーキャストの使用に適した候補であるかということには関係ありません。
Furthermore, it views anycast service disruptions as an operational problem: "Operators should be aware that, especially for long running flows, there are potential failure modes using anycast that are more complex than a simple 'destination unreachable' failure using unicast".
さらに、エニーキャストサービスの中断を運用上の問題と見なします。「オペレーターは、特に長時間実行されるフローでは、ユニキャストを使用した単純な「宛先到達不能」障害よりも複雑な、エニーキャストを使用した潜在的な障害モードがあることに注意してください。」
The document primarily deals with global Internet-wide services provided by anycast. Where internal topology issues are discussed, they're mostly regarding routing implications rather than application design implications. BCP 126 also views networks employing per-packet load balancing on equal cost paths as "pathological". This was also discussed in [RFC2991].
このドキュメントは主に、エニーキャストが提供するグローバルなインターネット全体のサービスを扱います。内部トポロジの問題について説明する場合、それらは主に、アプリケーション設計の影響ではなく、ルーティングの影響に関するものです。また、BCP 126は、等コストパスでパケットごとのロードバランシングを使用するネットワークを「病理学的」と見なします。これは[RFC2991]でも議論されました。
Preserving the integrity of a modular layered design for IP protocols on the Internet is critical to its continued success and flexibility. One such consideration is that of whether an application should have to adapt to changes in the routing system.
インターネット上のIPプロトコルのモジュラーレイヤードデザインの整合性を維持することは、その継続的な成功と柔軟性にとって重要です。そのような考慮事項の1つは、アプリケーションがルーティングシステムの変更に適応する必要があるかどうかです。
Applications should make minimal assumptions about routing stability, just as they should make minimal assumptions about congestion and packet loss. When designing applications, it would perhaps be safe to assume that the routing system may deliver each anycast packet to a different service instance, in any pattern, with temporal reordering being a not-so-rare phenomenon.
アプリケーションは、輻輳とパケット損失について最小限の仮定を行う必要があるのと同様に、ルーティングの安定性について最小限の仮定を行う必要があります。アプリケーションを設計するとき、ルーティングシステムが各エニーキャストパケットをさまざまなサービスインスタンスに任意のパターンで配信し、時間的な並べ替えはそれほど珍しい現象ではないことを前提とするとおそらく安全です。
Most stateful transport protocols (e.g., TCP), without modification, do not understand the properties of anycast; hence, they will fail probabilistically, but possibly catastrophically, when using anycast addresses in the presence of "normal" routing dynamics. Specifically, if datagrams associated with a given active transaction are routed to a new anycasted end system and that end system lacks state data associated with the active transaction, the session will be reset; hence, it will need to be reinitiated. As another example, different networks have different routing properties and therefore will experience problems under different conditions. This can lead to a protocol working fine in, say, a test lab but not in the global Internet.
ほとんどのステートフルトランスポートプロトコル（TCPなど）は、変更なしではエニーキャストのプロパティを理解しません。したがって、「通常の」ルーティングダイナミクスが存在する状態でエニーキャストアドレスを使用すると、確率的には失敗しますが、破局的になる可能性があります。具体的には、特定のアクティブトランザクションに関連付けられたデータグラムが新しいエニーキャストエンドシステムにルーティングされ、そのエンドシステムにアクティブトランザクションに関連付けられた状態データがない場合、セッションはリセットされます。したがって、再起動する必要があります。別の例として、ネットワークごとにルーティングプロパティが異なるため、さまざまな条件下で問題が発生します。これにより、たとえばテストラボではプロトコルが正常に機能しますが、グローバルインターネットでは機能しません。
When an anycast address is used as a destination address, different packets with the same destination IP address may reach different destination hosts, even if the packets are generated by the same source host. Anycast addresses are thus "safe" to use as destination addresses for an application if the following design points are all met:
エニーキャストアドレスを宛先アドレスとして使用すると、同じ送信元ホストによって生成されたパケットであっても、同じ宛先IPアドレスを持つ異なるパケットが異なる宛先ホストに到達する可能性があります。したがって、エニーキャストアドレスは、次の設計ポイントがすべて満たされている場合、アプリケーションの宛先アドレスとして使用するのに「安全」です。
o A request message or "one shot" message is self-contained in a single transport packet.
o 要求メッセージまたは「ワンショット」メッセージは、単一のトランスポートパケットに自己完結型です。
o A stateless transport (e.g., UDP) is used for the above.
o 上記には、ステートレストランスポート（UDPなど）が使用されます。
o Replies are always sent to a unicast address; these can be multipacket since the unicast destination is presumed to be associated with a single "stable" end system and not an anycasted source address. Note that this constrains the use of anycast as source addresses in request messages, since reply messages sent back to that address may reach a device that was not the source that initially triggered it.
o 返信は常にユニキャストアドレスに送信されます。ユニキャスト宛先は、エニーキャストされたソースアドレスではなく、単一の「安定した」エンドシステムに関連付けられていると想定されるため、これらはマルチパケットになる可能性があります。そのアドレスに送り返された応答メッセージは、最初にそれをトリガーしたソースではなかったデバイスに到達する可能性があるため、これは要求メッセージのソースアドレスとしてエニーキャストの使用を制限することに注意してください。
o The server side of the application keeps no hard state across requests.
o アプリケーションのサーバー側は、要求間でハード状態を維持しません。
o Retries are idempotent; in addition to not assuming server state, they do not encode any assumptions about loss of requests versus loss of replies.
o 再試行はべき等です。サーバーの状態を想定しないことに加えて、要求の損失と応答の損失のどちらについても想定をエンコードしません。
It is noteworthy, though, that even under the above circumstances ICMP messages against packets with anycast source addresses may be routed to servers other than those expected. In addition, Path Maximum Transmission Unit Discovery (PMTUD) can encounter complications when employed against anycast addresses, since iterations in the PMTU discovery process may have packets routed to different anycast service instances.
ただし、上記の状況下でも、エニーキャストソースアドレスを持つパケットに対するICMPメッセージが、予期されたもの以外のサーバーにルーティングされる可能性があることは注目に値します。さらに、PMTU検出プロセスの反復では、パケットが異なるエニーキャストサービスインスタンスにルーティングされる可能性があるため、エニーキャストアドレスに対してパス最大伝送ユニット検出（PMTUD）を使用すると、問題が発生する可能性があります。
When an anycast address is used as a source address, the source address does not uniquely identify the source host; hence, replies might be sent to a different host. As noted earlier, this concept is sometimes referred to (e.g., in [RFC3258]) as a "shared unicast address". Anycast addresses are "safe" to use as source addresses for an application if all of the following design points are met:
エニーキャストアドレスが送信元アドレスとして使用される場合、送信元アドレスは送信元ホストを一意に識別しません。したがって、応答が別のホストに送信される可能性があります。前に述べたように、この概念は時々（例えば、[RFC3258]で）「共有ユニキャストアドレス」と呼ばれます。エニーキャストアドレスは、次の設計ポイントがすべて満たされている場合、アプリケーションの送信元アドレスとして使用しても安全です。
o No response message is generated by the receiver with the anycast source used as a destination unless the application has some private state synchronization that allows for the response message arriving at a different instance.
o 別のインスタンスに到達する応答メッセージを可能にするプライベート状態同期がアプリケーションにない限り、エニーキャストソースを宛先として使用して、受信者は応答メッセージを生成しません。
o The source anycast address is reachable via the interface address if unicast reverse path forwarding (RPF) [RFC4778] checking is on, or the service address is explicitly provisioned to bypass RPF checks. In addition to the application defined in [RFC4778], Section 4.4.5 of BCP 126 [RFC4786] gives explicit consideration to RPF checks in anycasting operations.
o ユニキャストReverse Path Forwarding（RPF）[RFC4778]チェックがオンの場合、またはRPFチェックをバイパスするようにサービスアドレスが明示的にプロビジョニングされている場合、ソースエニーキャストアドレスはインターフェイスアドレスを介して到達可能です。 [RFC4778]で定義されているアプリケーションに加えて、BCP 126 [RFC4786]のセクション4.4.5は、エニーキャスティング操作でのRPFチェックを明示的に考慮しています。
Applications able to tolerate an extra round-trip time (RTT) to learn a unicast destination address for multipacket exchanges might safely use anycast destination addresses for service instance discovery. For example, "instance discovery" messages are sent to an anycast destination address, and a reply is subsequently sent from the unique unicast source address of the interface that received the discovery message, or a reply is sent from the anycast source address of the interface that received the message, containing the unicast address to be used to invoke the service. Only the latter of these will avoid potential NAT binding and stateful firewall issues.
マルチパケット交換のユニキャスト宛先アドレスを学習するために追加のラウンドトリップ時間（RTT）を許容できるアプリケーションは、サービスインスタンスの検出にエニーキャスト宛先アドレスを安全に使用できます。たとえば、「インスタンスディスカバリ」メッセージはエニーキャスト宛先アドレスに送信され、その後、ディスカバリメッセージを受信したインターフェイスの一意のユニキャストソースアドレスから応答が送信されます。または、インターフェイスのエニーキャストソースアドレスから応答が送信されます。メッセージの受信者。サービスの呼び出しに使用されるユニキャストアドレスが含まれています。これらの後者のみが、潜在的なNATバインディングおよびステートフルファイアウォールの問題を回避します。
[DNS-DISC] discussed several options to address the need to configure DNS servers, including the use of a "Well-known Anycast Address" for recursive DNS service configuration in clients to ease configuration and allow those systems to ship with these well-known addresses configured "from the beginning, as, say, factory default". The proposal was later dropped, but the analysis was used in publishing [RFC4339].
[DNS-DISC]は、クライアントでの再帰DNSサービス構成に「よく知られているエニーキャストアドレス」を使用して構成を容易にし、これらのシステムにこれらのよく知られたシステムを出荷できるようにするなど、DNSサーバーを構成する必要性に対処するいくつかのオプションについて説明しました「最初から、たとえば工場出荷時のデフォルトとして」設定されたアドレス。提案は後で削除されましたが、分析は出版[RFC4339]で使用されました。
After the final round of revisions to [DNS-DISC] was made, [RFC4339] was published with a very similar focus and overlapping content. The difference was that the writing in [RFC4339] focused on analysis, while [DNS-DISC] covered both the analysis and a specific proposal. The proposal details were removed in what became [RFC4339] although Section 3.3 of that RFC still discusses the approach of using a
[DNS-DISC]の最終回の改訂が行われた後、[RFC4339]は非常に類似した焦点と重複する内容で公開されました。違いは、[RFC4339]の記述が分析に焦点を当てていたのに対し、[DNS-DISC]は分析と特定の提案の両方をカバーしていたことです。提案の詳細は[RFC4339]で削除されましたが、そのRFCのセクション3.3では、
well-known anycast address in this scenario. During publication, the IESG requested that the following "IESG Note" be contained in the document:
このシナリオでは、よく知られたエニーキャストアドレス。公開中、IESGは次の「IESG Note」を文書に含めるように要求しました。
This document describes three different approaches for the configuration of DNS name resolution server information in IPv6 hosts.
このドキュメントでは、IPv6ホストでDNS名前解決サーバー情報を構成するための3つの異なるアプローチについて説明します。
There is not an IETF consensus on which approach is preferred. The analysis in this document was developed by the proponents for each approach and does not represent an IETF consensus.
どちらのアプローチが好ましいかについて、IETFの合意はありません。このドキュメントの分析は、各アプローチの支持者によって開発されたものであり、IETFの合意を表すものではありません。
The 'RA option' and 'Well-known anycast' approaches described in this document are not standardized. Consequently the analysis for these approaches might not be completely applicable to any specific proposal that might be proposed in the future.
このドキュメントで説明されている「RAオプション」および「よく知られているエニーキャスト」アプローチは標準化されていません。したがって、これらのアプローチの分析は、将来提案される可能性のある特定の提案には完全には適用できない可能性があります。
Widespread use of anycast for global Internet-wide services or inter-domain services has some scaling challenges. Similar in ways to multicast, each service generates at least one unique route in the global BGP routing system. As a result, additional anycast instances result in additional paths for a given prefix, which scales super-linearly as a function of denseness of inter-domain interconnection within the routing system (i.e., more paths result in more resources, more network interconnections result in more paths).
グローバルなインターネット全体のサービスまたはドメイン間サービスにエニーキャストを広く使用するには、スケーリングに関するいくつかの課題があります。マルチキャストと同様に、各サービスはグローバルBGPルーティングシステムで少なくとも1つの一意のルートを生成します。その結果、エニーキャストインスタンスが追加されると、所定のプレフィックスのパスが追加され、ルーティングシステム内のドメイン間相互接続の密度の関数として超線形にスケーリングされます（つまり、パスが多いほどリソースが多くなり、ネットワーク相互接続が増える結果、より多くのパス）。
This is why the Anycast BOF concluded that "the use of global anycast addresses was not expected to scale and hence was expected to be limited to a small number of key uses".
このため、エニーキャストBOFは、「グローバルエニーキャストアドレスの使用は拡張が期待されておらず、少数の主要な用途に限定されることが期待されている」と結論付けました。
However, one interesting note is that multiple anycast services can share a route if they are all located in a single announced prefix and if all the servers of all the services are always collocated. If the announced prefix is aggregated differently in different locations though, longest-match routing might result in some anycast locations being unreachable. Hence, extra precaution must be taken when aggregating prefixes used by anycast services.
ただし、興味深い注意点の1つは、複数のエニーキャストサービスがすべて1つのアナウンスされたプレフィックスに配置され、すべてのサービスのすべてのサーバーが常に併置されている場合、ルートを共有できることです。ただし、アナウンスされたプレフィックスがロケーションごとに異なる方法で集約されると、最長一致ルーティングによって、一部のエニーキャストロケーションに到達できなくなる可能性があります。したがって、エニーキャストサービスで使用されるプレフィックスを集約する場合は、さらに注意が必要です。
UDP is the "lingua franca" for anycast today. Stateful transports could be enhanced to be more anycast friendly. This was anticipated in Host Anycasting Services [RFC1546], specifically:
UDPは、今日のエニーキャストの「リングアフランカ」です。ステートフルトランスポートは、よりエニーキャストに対応するように拡張できます。これは、Host Anycasting Services [RFC1546]で予期されていました。具体的には、
The solution to this problem is to only permit anycast addresses as the remote address of a TCP SYN segment (without the ACK bit set). A TCP can then initiate a connection to an anycast address. When the SYN-ACK is sent back by the host that received the anycast segment, the initiating TCP should replace the anycast address of its peer, with the address of the host returning the SYN-ACK. (The initiating TCP can recognize the connection for which the SYN-ACK is destined by treating the anycast address as a wildcard address, which matches any incoming SYN-ACK segment with the correct destination port and address and source port, provided the SYN-ACK's full address, including source address, does not match another connection and the sequence numbers in the SYN-ACK are correct.) This approach ensures that a TCP, after receiving the SYN-ACK is always communicating with only one host.
この問題の解決策は、TCP SYNセグメントのリモートアドレスとしてエニーキャストアドレスのみを許可することです（ACKビットセットなし）。その後、TCPはエニーキャストアドレスへの接続を開始できます。エニーキャストセグメントを受信したホストからSYN-ACKが送り返されると、開始TCPはピアのエニーキャストアドレスを、SYN-ACKを返すホストのアドレスに置き換える必要があります。 （開始TCPは、エニーキャストアドレスをワイルドカードアドレスとして扱うことにより、SYN-ACKの宛先となる接続を認識できます。これは、SYN-ACKが提供されている場合、着信SYN-ACKセグメントと正しい宛先ポート、アドレス、ソースポートを照合します。送信元アドレスを含む完全なアドレスが別の接続と一致せず、SYN-ACKのシーケンス番号が正しい。）このアプローチにより、SYN-ACKを受信した後、TCPは常に1つのホストのみと通信します。
The reason for such considerations can be illustrated through an example: one operationally observed shortcoming of using the Transmission Control Protocol (TCP) [RFC0793] and anycast nodes in DNS is that even during the TCP connection establishment, IP control packets from a DNS client may initially be routed to one anycast instance, but subsequent IP packets may be delivered to a different anycast instance if (for example) a route has changed. In such a case, the TCP connection will likely elicit a connection reset but will certainly result in the disruption of the connection.
このような考慮事項の理由は、例を通じて説明できます。伝送制御プロトコル（TCP）[RFC0793]とDNSのエニーキャストノードを使用することで運用上観察された欠点の1つは、TCP接続の確立中であっても、DNSクライアントからのIP制御パケットが最初は1つのエニーキャストインスタンスにルーティングされますが、（たとえば）ルートが変更された場合、後続のIPパケットは別のエニーキャストインスタンスに配信されます。このような場合、TCP接続はおそらく接続のリセットを引き起こしますが、接続の中断を確実にもたらします。
Multi-address transports (e.g., SCTP) might be more amenable to such extensions than TCP.
マルチアドレストランスポート（SCTPなど）は、TCPよりもこのような拡張に対応しやすい場合があります。
The features needed for address discovery when doing multihoming in the transport layer are similar to those needed to support anycast.
トランスポート層でマルチホーミングを行うときにアドレス検出に必要な機能は、エニーキャストをサポートするために必要な機能と同様です。
Middleboxes (e.g., NATs) and stateful firewalls cause problems when used in conjunction with some ways to use anycast. In particular, a server-side transition from an anycast source IP address to a unique unicast address may require new or additional session state, and this may not exist in the middlebox, as discussed previously in Section 3.4.
ミドルボックス（NATなど）とステートフルファイアウォールは、エニーキャストを使用するいくつかの方法と組み合わせて使用すると問題を引き起こします。特に、セクション3.4で説明したように、エニーキャストソースIPアドレスから一意のユニキャストアドレスへのサーバー側の移行では、新しいまたは追加のセッション状態が必要になる場合があり、これはミドルボックスに存在しない場合があります。
Anycast is often deployed to mitigate or at least localize the effects of distributed denial-of-service (DDoS) attacks. For example, with the Netgear NTP fiasco [RFC4085] anycast was used in a distributed sinkhole model [RFC3882] to mitigate the effects of embedded globally routed Internet addresses in network elements.
エニーキャストは、分散型サービス拒否（DDoS）攻撃の影響を軽減または少なくともローカライズするためにしばしば展開されます。たとえば、Netgear NTPフィアスコ[RFC4085]では、ネットワークエレメントに埋め込まれたグローバルにルーティングされたインターネットアドレスの影響を軽減するために、分散型シンクホールモデル[RFC3882]でエニーキャストが使用されました。
"Internet Denial-of-Service Considerations" [RFC4732] notes that: "A number of the root nameservers have since been replicated using anycast to further improve their resistance to DoS".
「インターネットのサービス拒否に関する考慮事項」[RFC4732]は、次のように述べています。「DoSへの抵抗をさらに改善するために、エニーキャストを使用して多数のルートネームサーバーが複製されています。」
"Operation of Anycast Services" BCP 126 [RFC4786] cites DoS mitigation, constraining DoS to localized regions, and identifying attack sources using spoofed addresses as some motivations to deploy services using anycast. Multiple anycast service instances such as those used by the root name servers also add resiliency when network partitioning occurs (e.g., as the result of transoceanic fiber cuts or natural disasters).
「エニーキャストサービスの運用」BCP 126 [RFC4786]は、DoSの緩和、DoSのローカライズされた地域への制限、エニーキャストを使用してサービスを展開する動機として、スプーフィングされたアドレスを使用した攻撃ソースの特定を挙げています。ルートネームサーバーが使用するエニーキャストサービスインスタンスなどの複数のエニーキャストサービスインスタンスは、ネットワークのパーティション分割が発生したとき（たとえば、大洋横断のファイバーカットや自然災害の結果として）回復力を追加します。
When using anycast, care must be taken not to simply withdraw an anycast route in the presence of a sustained DoS attack, since the result would simply move the attack to another service instance, potentially causing a cascaded failure. Anycast adds resiliency when such an attack is instead constrained to a single service instance.
エニーキャストを使用する場合は、持続的なDoS攻撃の存在下でエニーキャストルートを単に撤回しないように注意する必要があります。その結果、攻撃が別のサービスインスタンスに移動し、カスケード障害が発生する可能性があるためです。エニーキャストは、このような攻撃が代わりに単一のサービスインスタンスに制限されている場合に回復力を追加します。
It should be noted that there is a significant man-in-the-middle (MITM) exposure in either variant of anycast discovery (see Section 3.4) that, in many applications, may necessitate the need for end-to-end security models (e.g., using IPsec [RFC6071] or even DNSSEC [RFC4033]) that enable end systems to authenticate one another, or the data itself.
エニーキャスト発見のいずれかのバリアント（セクション3.4を参照）には、中間者（MITM）の重大な危険性があり、多くのアプリケーションでは、エンドツーエンドのセキュリティモデル（たとえば、IPsec [RFC6071]またはDNSSEC [RFC4033]）を使用して、エンドシステムが相互に、またはデータ自体を認証できるようにします。
However, when considering the above suggestion of enabling end systems to authenticate each other, a potential complication can arise. If the service nodes of an anycast deployment are administered by separate authorities, any server-side authentication credentials that are used must (necessarily) be shared across the administrative boundaries in the anycast deployment. This would likely also be the case with Secure Neighbor Discovery, described in [RFC5909].
ただし、エンドシステムが相互に認証できるようにする上記の提案を検討すると、潜在的な問題が発生する可能性があります。エニーキャスト展開のサービスノードが別の機関によって管理されている場合、使用されるサーバー側の認証資格情報は、エニーキャスト展開の管理境界を越えて（必要に応じて）共有する必要があります。これは、[RFC5909]で説明されているSecure Neighbor Discoveryでも同様です。
Furthermore, as discussed earlier in this document, operational consideration needs to be given to ensure that anycast addresses get advertised and/or filtered in a way that produces intended scope (for example, only advertise a route to your 6to4 relay to ASes that conform to your own Acceptable Use Policy (AUP)). This seems to be operationally expensive, and is often vulnerable to errors outside of the local routing domain, in particular when anycasted services are deployed with the intent to scope associated announcements within some local or regional boundary.
さらに、このドキュメントの前半で説明したように、エニーキャストアドレスが意図したスコープを生成する方法でアドバタイズおよび/またはフィルタリングされるように、運用上の考慮事項を提供する必要があります（たとえば、6to4リレーへのルートを、ASに準拠するASにのみアドバタイズする）独自の利用規定（AUP））。これは運用にコストがかかるようで、ローカルルーティングドメイン外のエラーに対して脆弱であることが多く、特に、ローカルまたは地域の境界内で関連するアナウンスをスコープする目的でエニーキャストサービスがデプロイされている場合はそうです。
As previously discussed, [RFC6382] makes recommendations regarding the use of per-node unique origin ASNs for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network management and monitoring techniques, or other operational mechanisms, may then employ this new discriminator in whatever manner fits their operating environment, for either detection or policy associated with a given anycasted node.
前述のように、[RFC6382]は、特定のエニーキャストプレフィックスにルーティングシステム識別子を提供するために、グローバルエニーキャストされたクリティカルインフラストラクチャサービスに対するノードごとの一意の起点ASNの使用に関する推奨事項を作成します。ネットワーク管理および監視技術、またはその他の運用メカニズムは、特定のエニーキャストノードに関連付けられた検出またはポリシーのいずれかのために、運用環境に適した方法でこの新しい弁別子を使用できます。
Moreover, the use of per-node unique origin ASNs has the additional benefit of overcoming complications that might arise with the potential deployment of the Resource Public Key Infrastructure (RPKI) [RFC6480]. Without per-node unique origin ASNs, the cryptographic certificates needed to attest to the Route Origin Authorizations (ROAs) of a multi-administrative deployment of anycast would need to be shared. However, if each service instance has a separate ASN, then those ASNs can be managed separately in the RPKI.
さらに、ノードごとの一意の起点ASNを使用すると、リソース公開鍵インフラストラクチャ（RPKI）[RFC6480]の潜在的な展開で発生する可能性がある複雑さを克服するという追加の利点があります。ノードごとの固有の発信元ASNがない場合、エニーキャストの複数管理デプロイメントのルート発信元承認（ROA）を証明するために必要な暗号証明書を共有する必要があります。ただし、各サービスインスタンスに個別のASNがある場合、それらのASNはRPKIで個別に管理できます。
Unlike multicast (but like unicast), anycast allows traffic stealing. That is, with multicast, joining a multicast group doesn't prevent anyone else who was receiving the traffic from continuing to receive the traffic. With anycast, adding an anycasted node to the routing system can prevent a previous recipient from continuing to receive traffic because it may now be delivered to the new node instead. As such, if an unauthorized anycast node can inject a route into the network, or be resolved using ARP/Neighbor Discovery on a link with an authorized anycast node, traffic can be diverted thereby triggering DoS or other attacks. Section 6.3 of BCP 126 [RFC4786] provides expanded discussion on "Service Hijacking" and "traffic stealing", and [FanInfocom13] discusses measured instances of anycast nodes and "benign masquerading or hostile hijacking of anycast services", by unauthorized nodes.
マルチキャスト（ユニキャストと同様）とは異なり、エニーキャストではトラフィックを盗むことができます。つまり、マルチキャストの場合、マルチキャストグループに参加しても、トラフィックを受信していた他のユーザーがトラフィックを受信し続けることを妨げることはありません。エニーキャストでは、ルーティングシステムにエニーキャストノードを追加すると、代わりに新しいノードに配信される可能性があるため、以前の受信者がトラフィックを受信し続けるのを防ぐことができます。したがって、許可されていないエニーキャストノードがルートをネットワークに挿入したり、許可されたエニーキャストノードとのリンクでARP /近隣探索を使用して解決したりできる場合、トラフィックが迂回されてDoS攻撃やその他の攻撃が引き起こされる可能性があります。 BCP 126 [RFC4786]のセクション6.3は、「サービスハイジャック」と「トラフィックの盗用」についての詳細な説明を提供し、[FanInfocom13]は、エニーキャストノードの測定されたインスタンスと、不正なノードによる「エニーキャストサービスの良性のマスカレードまたは敵対的なハイジャック」について説明します。
Unlike unicast (but like multicast), the desire is to allow applications to cause route injection. In multicast, one often allows arbitrary applications on hosts to join multicast groups, resulting in multicast routing state. Trying to apply that same model to anycast would present new security concerns, which is why [MAGMA] only got so far. The security concerns include:
ユニキャストとは異なり（ただしマルチキャストと同様）、アプリケーションがルートインジェクションを実行できるようにすることが望まれます。マルチキャストでは、多くの場合、ホスト上の任意のアプリケーションがマルチキャストグループに参加できるため、マルチキャストルーティング状態になります。同じモデルをエニーキャストに適用しようとすると、新しいセキュリティ上の問題が発生します。そのため、[MAGMA]はこれまでのところしか利用できませんでした。セキュリティ上の問題には、次のものがあります。
1. Allowing route injection can cause DOS to a legitimate address owner.
1. ルートインジェクションを許可すると、DOSが正当なアドレス所有者になる可能性があります。
2. Allowing route injection consumes routing resources and can hence cause DOS to the routing system and impact legitimate communications as a result.
2. ルートインジェクションを許可すると、ルーティングリソースが消費されるため、DOSがルーティングシステムに送信され、結果として正当な通信に影響を与える可能性があります。
These are two of the core issues that were part of the discussion during [RFC1884], the [ANYCASTBOF], and the MAGMA [MAGMA] chartering.
これらは、[RFC1884]、[ANYCASTBOF]、およびMAGMA [MAGMA]チャーターでの議論の一部であった2つの中心的な問題です。
Additional security considerations are scattered throughout the list of references provided herein.
追加のセキュリティに関する考慮事項は、ここで提供されるリファレンスのリスト全体に散在しています。
BCP 126 [RFC4786] provides some very solid guidance related to operations of anycasted services and, in particular, the operations of DNS.
BCP 126 [RFC4786]は、エニーキャストサービスの操作、特にDNSの操作に関連する非常に強固なガイダンスを提供します。
This document covers issues associated with the architectural implications of anycast. This document does not address, in any depth, the fact that there are deployed services with TCP transport using anycast today. Evidence exists to suggest that such practice is not "safe" in the traditional and architectural sense (as described in Section 4.2). These sorts of issues are indeed relative, and we recognize sometimes unpredictability in the routing system beyond the local administrative domain can be manageable. That is, despite the inherent architectural problems in the use of anycast with stateful transport and connection-oriented protocols, there is expanding deployment (e.g., for content distribution networks) and situations exist where it may make sense (e.g., such as with service discovery, short-lived transactions, or in cases where dynamically directing traffic to topologically optimal service instances is required). In general, operators should consider the content and references provided herein and evaluate the benefits and implications of anycast in their specific environments and applications.
このドキュメントでは、エニーキャストのアーキテクチャ上の影響に関連する問題について説明します。このドキュメントでは、今日のエニーキャストを使用したTCPトランスポートを使用したサービスが展開されているという事実については詳しく説明していません。そのような慣行が伝統的かつ建築的な意味で「安全」ではないことを示唆する証拠が存在します（セクション4.2で説明）。これらの種類の問題は確かに相対的なものであり、ローカルの管理ドメインを超えたルーティングシステムでは予測できない場合があることを認識しています。つまり、ステートフルトランスポートとコネクション型プロトコルを使用したエニーキャストの使用には固有のアーキテクチャ上の問題がありますが、展開が拡大しており（コンテンツ配信ネットワークなど）、状況に応じて（サービスの検出など） 、有効期間が短いトランザクション、またはトポロジ的に最適なサービスインスタンスにトラフィックを動的に送信する必要がある場合）。一般に、オペレーターは、ここに提供されている内容と参照を検討し、特定の環境とアプリケーションにおけるエニーキャストの利点と影響を評価する必要があります。
In addition, (as noted in Section 2.3) the issue of whether to withdraw anycast routes when there is a service failure is only briefly broached in [RFC3258]. The advice given is that routes should not be withdrawn, in order to reduce operational complexity. However, the issue of route advertisements and service outages deserves greater attention.
さらに、（セクション2.3で述べたように）サービス障害が発生したときにエニーキャストルートを撤回するかどうかの問題は、[RFC3258]で簡単に説明されています。与えられたアドバイスは、運用の複雑さを軽減するために、ルートを撤回すべきではないということです。ただし、ルートアドバタイズメントとサービス停止の問題には、より大きな注意が必要です。
There is an inherent trade-off that exists between the operational complexity of matching service outages with anycast route withdrawals, and allowing anycast routes to persist for services that are no longer available. [RFC3258] maintains that DNS' inherent failure recovery mechanism is sufficient to overcome failed nodes, but even this advice enshrines the notion that these decisions are both application-specific and subject to the operational needs of each deployment. For example, the routing system plays a larger role in DNS when services are anycast. Therefore, operational consideration must be given to the fact that relying on anycast for DNS deployment optimizations means that there are operational trade-offs related to keeping route advertisements (and withdrawals) symmetric with service availability. For example, in order to ensure that the DNS resolvers in a failed anycast instance's catchment [RFC4786] are able to fail over and reach a non-failed catchment, a route withdrawal is almost certainly required. On the other hand, instability of a DNS process that triggers frequent route advertisement and withdrawal might result in suppression of legitimate paths to available nodes, e.g., as a result of route flap damping [RFC2439].
エニーキャストルートの撤回とサービスの停止を一致させる運用上の複雑さと、使用できなくなったサービスに対してエニーキャストルートを維持できるようにすることの間には、固有のトレードオフがあります。 [RFC3258]は、DNSの固有の障害回復メカニズムは障害のあるノードを克服するのに十分であると主張していますが、このアドバイスでさえ、これらの決定はアプリケーション固有であり、各展開の運用ニーズの対象であるという概念を示しています。たとえば、サービスがエニーキャストの場合、ルーティングシステムはDNSでより大きな役割を果たします。したがって、DNS展開の最適化をエニーキャストに依存することは、ルートアドバタイズメント（および撤回）をサービスの可用性と対称に保つことに関連する運用上のトレードオフが存在することを意味する運用上の考慮事項を考慮する必要があります。たとえば、失敗したエニーキャストインスタンスの集水域[RFC4786]のDNSリゾルバーがフェイルオーバーして、失敗していない集水域に到達できるようにするには、ルートの撤回がほぼ確実に必要です。一方、頻繁なルートアドバタイズと撤回をトリガーするDNSプロセスが不安定になると、たとえば、ルートフラップダンピングの結果として、利用可能なノードへの正当なパスが抑制される可能性があります[RFC2439]。
Rather than prescribing advice that attempts to befit all situations, it should simply be recognized that when using anycast with network services that provide redundancy or resilience capabilities at other layers of the protocol stack, operators should carefully consider the optimal layer(s) at which to provide said functions.
すべての状況に適合しようとするアドバイスを処方するのではなく、プロトコルスタックの他のレイヤーで冗長性または回復力の機能を提供するネットワークサービスでエニーキャストを使用する場合、オペレーターは最適なレイヤーを慎重に検討する必要があることを単に認識すべきです。上記の機能を提供します。
As noted in Section 2.3, use of anycast within a subnet does not necessarily suffer from the potential issues with route withdrawals. As such, use of anycast to reach servers that reside in the same subnet can be made more reliable than use of anycast to reach topologically disparate server instances. Within a subnet, however, care must be taken as stated in Section 5.4 of [RFC4862], "Duplicate Address Detection MUST NOT be performed on anycast addresses"; hence, the servers must be configured appropriately.
2.3節で述べたように、サブネット内でエニーキャストを使用しても、ルートの撤回に関する潜在的な問題が必ずしも発生するとは限りません。したがって、同じサブネット内にあるサーバーに到達するためにエニーキャストを使用すると、トポロジ的に異なるサーバーインスタンスに到達するためにエニーキャストを使用するよりも信頼性が高くなります。ただし、サブネット内では、[RFC4862]のセクション5.4にあるように、「エニーキャストアドレスに対して重複アドレス検出を実行してはならない」という注意が必要です。したがって、サーバーを適切に構成する必要があります。
In summary, operators and application vendors alike should consider the benefits and implications of anycast in their specific environments and applications and also give forward consideration to how new network protocols and application functions may take advantage of anycast or how they may be negatively impacted if anycasting is employed.
要約すると、オペレーターとアプリケーションベンダーは、特定の環境とアプリケーションでのエニーキャストの利点と影響を検討し、新しいネットワークプロトコルとアプリケーション機能がエニーキャストをどのように利用できるか、またはエニーキャストがどのように悪影響を受けるかについても事前に検討する必要があります。雇用された。
Many thanks to Kurtis Lindqvist for his early review and feedback on this document. Thanks to Brian Carpenter, Alfred Hoenes, and Joe Abley for their usual careful review and feedback, as well as Mark Smith, Lixia Zhang, Stephane Bortzmeyer, Masataka Ohta, and S. Moonesamy for their detailed reviews. Helpful feedback was also received from others including Edward Lewis, Jean-Michel Combes, Wolfgang Nagele, Mark Townsley, and Abdussalam Baryun.
このドキュメントに関する初期のレビューとフィードバックを提供してくれたKurtis Lindqvistに感謝します。通常の慎重なレビューとフィードバックを提供してくれたBrian Carpenter、Alfred Hoenes、Joe Abley、詳細なレビューをしてくれたMark Smith、Lixia Zhang、Stephane Bortzmeyer、Masataka Ohta、S。Moonesamyに感謝します。エドワードルイス、ジャンミッシェルコムズ、ヴォルフガングナゲレ、マークタウンズリー、アブドゥサラムバリューンなど、他のユーザーからも有益なフィードバックが寄せられました。
[ANYCASTBOF] Deering, S., "IAB Anycast BOF Announcement", October 1999, <http://www.ietf.org/mail-archive/web/ietf/current/ msg11182.html>.
[ANYCASTBOF] Deering、S。、「IAB Anycast BOF Announcement」、1999年10月、<http://www.ietf.org/mail-archive/web/ietf/current/ msg11182.html>。
[DNS-DISC] Durand, A., Hagino, J., and D. Thaler, "Well known site local unicast addresses for DNS resolver", Work in Progress, September 2002.
[DNS-DISC] Durand、A.、Hagino、J。、およびD. Thaler、「DNSリゾルバの既知のサイトローカルユニキャストアドレス」、Work in Progress、2002年9月。
[FanInfocom13] Fan, X., Heidemann, J., and R. Govindan, "Evaluating Anycast in the Domain Name System", Proceedings of the IEEE Infocom 2013, April 2013.
[FanInfocom13] Fan、X.、Heidemann、J。、およびR. Govindan、「Evaluating Anycast in the Domain Name System」、Proceedings of the IEEE Infocom 2013、2013年4月。
[IMR9401] RFC Editor, "INTERNET MONTHLY REPORT", January 1994, <ftp://ftp.rfc-editor.org/in-notes/museum/imr/ imr9401.txt>.
[IMR9401] RFC Editor、「INTERNET MONTHLY REPORT」、1994年1月、<ftp://ftp.rfc-editor.org/in-notes/museum/imr/imr9401.txt>。
[MAGMA] MAGMA (concluded), "Multicast and Anycast Group Membership (MAGMA)", April 2006, <http://www.ietf.org/wg/concluded/magma>.
[MAGMA] MAGMA（終了）、「マルチキャストおよびエニーキャストグループメンバーシップ（MAGMA）」、2006年4月、<http://www.ietf.org/wg/concluded/magma>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[RFC1546]パートリッジ、C。、メンデス、T。、およびW.ミリケン、「Host Anycasting Service」、RFC 1546、1993年11月。
[RFC1884] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995.
[RFC1884] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 1884、1995年12月。
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030] Mills、D。、「Simple Network Time Protocol（SNTP）Version 4 for IPv4、IPv6 and OSI」、RFC 2030、1996年10月。
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[RFC2101] Carpenter、B.、Crowcroft、J。、およびY. Rekhter、「IPv4 Address Behavior Today」、RFC 2101、1997年2月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 2373、1998年7月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、RFC 2439、1998年11月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]ジョンソン、D。、およびS.ディアリング、「予約済みIPv6サブネットエニーキャストアドレス」、RFC 2526、1999年3月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893] Gilligan、R. and E. Nordmark、 "Transition Mechanisms for IPv6 Hosts and Routers"、RFC 2893、August 2000。
[RFC2902] Deering, S., Hares, S., Perkins, C., and R. Perlman, "Overview of the 1998 IAB Routing Workshop", RFC 2902, August 2000.
[RFC2902] Deering、S.、Hares、S.、Perkins、C。、およびR. Perlman、「1998 IAB Routing Workshopの概要」、RFC 2902、2000年8月。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC2991]ターラー、D。およびC.ホップ、「ユニキャストおよびマルチキャストのネクストホップ選択におけるマルチパスの問題」、RFC 2991、2000年11月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「Antocast Prefix for 6to4 Relay Routers」、RFC 3068、2001年6月。
[RFC3258] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast Addresses", RFC 3258, April 2002.
[RFC3258] Hardie、T。、「Distributed Authoritative Name Servers via Shared Unicast Addresses」、RFC 3258、2002年4月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソンD.、パーキンスC.、およびJ.アーコ、「IPv6でのモビリティサポート」、RFC 3775、2004年6月。
[RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service Attacks", RFC 3882, September 2004.
[RFC3882] Turk、D。、「DoS攻撃をブロックするためのBGPの構成」、RFC 3882、2004年9月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964] Savola、P。およびC. Patel、「6to4のセキュリティに関する考慮事項」、RFC 3964、2004年12月。
[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月。
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet Addresses Considered Harmful", BCP 105, RFC 4085, June 2005.
[RFC4085] Plonka、D。、「有害と見なされるグローバルにルーティング可能なインターネットアドレスの埋め込み」、BCP 105、RFC 4085、2005年6月。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330] Mills、D。、「Simple Network Time Protocol（SNTP）Version 4 for IPv4、IPv6 and OSI」、RFC 4330、2006年1月。
[RFC4339] Jeong, J., "IPv6 Host Configuration of DNS Server Information Approaches", RFC 4339, February 2006.
[RFC4339] Jeong、J。、「DNSサーバー情報アプローチのIPv6ホスト構成」、RFC 4339、2006年2月。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC4610] Farinacci、D。およびY. Cai、「Anycast-RP Using Protocol Independent Multicast（PIM）」、RFC 4610、2006年8月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732] Handley、M.、Rescorla、E。、およびIAB、「インターネットサービス拒否の考慮事項」、RFC 4732、2006年12月。
[RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, January 2007.
[RFC4778] Kaeo、M。、「インターネットサービスプロバイダー環境における運用上のセキュリティの現在の実践」、RFC 4778、2007年1月。
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006.
[RFC4786] Abley、J。およびK. Lindqvist、「Operation of Anycast Services」、BCP 126、RFC 4786、2006年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism Identifying a Name Server Instance", RFC 4892, June 2007.
[RFC4892] Woolf、S。およびD. Conrad、「ネームサーバーインスタンスを識別するメカニズムの要件」、RFC 4892、2007年6月。
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[RFC4924] Aboba、B。およびE. Davies、「Reflections on Internet Transparency」、RFC 4924、2007年7月。
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007.
[RFC4942] Davies、E.、Krishnan、S。、およびP. Savola、「IPv6移行/共存セキュリティの考慮事項」、RFC 4942、2007年9月。
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", RFC 5001, August 2007.
[RFC5001] Austein、R。、「DNS Name Server Identifier（NSID）Option」、RFC 5001、2007年8月。
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905] Mills、D.、Martin、J.、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing Neighbor Discovery Proxy: Problem Statement", RFC 5909, July 2010.
[RFC5909] Combes、J-M。、Krishnan、S。、およびG. Daley、「Securing Neighbor Discovery Proxy：Problem Statement」、RFC 5909、2010年7月。
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, February 2011.
[RFC6071]フランケルS.およびS.クリシュナン、「IP Security（IPsec）and Internet Key Exchange（IKE）Document Roadmap」、RFC 6071、2011年2月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、Johnson、D。、およびJ. Arkko、「IPv6でのモビリティサポート」、RFC 6275、2011年7月。
[RFC6382] McPherson, D., Donnelly, R., and F. Scalzo, "Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services", BCP 169, RFC 6382, October 2011.
[RFC6382] McPherson、D.、Donnelly、R。、およびF. Scalzo、「Globally Anycasted Servicesのノードごとの一意のOrigin Autonomous System Numbers（ASNs）」、BCP 169、RFC 6382、2011年10月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
[RSSAC29] "RSSAC 29 Meeting Minutes", December 2007, <http://www.icann.org/en/groups/rssac/meetings/ rssac-29-en.pdf>.
[RSSAC29]「RSSAC 29 Meeting Minutes」、2007年12月、<http://www.icann.org/en/groups/rssac/meetings/ rssac-29-en.pdf>。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Joel Halpern Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Hannes Tschofenig
バーナードアボバジャリアルコマルクブランシェロスカロンアリッサクーパージョエルハルパーンラスハウズリーエリオットリアシンリーエリックノードマークアンドリューサリバンデイブターラーハネスチョーフェニグ
Authors' Addresses
著者のアドレス
Danny McPherson Verisign, Inc. 12061 Bluemont Way Reston, VA USA
Danny McPherson Verisign、Inc. 12061 Bluemont Way Reston、VA USA
EMail: dmcpherson@verisign.com
Dave Oran Cisco Systems USA
Dave Oran Cisco Systems USA
EMail: oran@cisco.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA USA
だゔぇ てゃぇｒ みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ うさ
EMail: dthaler@microsoft.com
Eric Osterweil Verisign, Inc. 12061 Bluemont Way Reston, VA USA
Eric Osterweil Verisign、Inc. 12061 Bluemont Way Reston、VA USA
EMail: eosterweil@verisign.com