RFC1546 日本語訳

Network Working Group                                       C. Partridge
Request for Comments: 1546                                     T. Mendez
Category: Informational                                      W. Milliken
                                                                     BBN
                                                           November 1993

コメントを求めるワーキンググループC.ヤマウズラ要求をネットワークでつないでください: 1546年のT.メンデスカテゴリ: 情報のW.ミリケンBBN1993年11月

                        Host Anycasting Service

ホストAnycastingサービス

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This RFC describes an internet anycasting service for IP.  The
   primary purpose of this memo is to establish the semantics of an
   anycasting service within an IP internet.  Insofar as is possible,
   this memo tries to be agnostic about how the service is actually
   provided by the internetwork.  This memo describes an experimental
   service and does not propose a protocol.  This memo is produced by
   the Internet Research Task Force (IRTF).

このRFCはIPのためにサービスをanycastingするインターネットについて説明します。 このメモのプライマリ目的はIPインターネットの中でanycastingサービスの意味論を確立することです。 その程度において、このメモは可能であるように実際にインターネットワークでどうサービスを提供するかに関して不可知論者になろうとします。 このメモは、実験的なサービスについて説明して、プロトコルを提案しません。 このメモはインターネットResearch Task Force(IRTF)によって製作されます。

Motivation

動機

   There are a number of situations in networking where a host,
   application, or user wishes to locate a host which supports a
   particular service but, if several servers support the service, does
   not particularly care which server is used.  Anycasting is a
   internetwork service which meets this need.  A host transmits a
   datagram to an anycast address and the internetwork is responsible
   for providing best effort delivery of the datagram to at least one,
   and preferably only one, of the servers that accept datagrams for the
   anycast address.

ネットワークには多くの状況がホスト、アプリケーション、またはユーザが特定のサービスをサポートするホストの居場所を見つけることを願っていますが、いくつかのサーバがサービスをサポートするならどのサーバが使用されているかを特に気にかけないところにあります。 Anycastingはこの需要を満たす相互ネットワーク・サービスです。 ホストはanycastアドレスにデータグラムを送ります、そして、インターネットワークはanycastアドレスのためにデータグラムを受け入れるサーバの少なくとも1、および望ましくは1つだけにデータグラムのベストエフォート型配送を提供するのに原因となります。

   The motivation for anycasting is that it considerably simplifies the
   task of finding an appropriate server.  For example, users, instead
   of consulting a list of archie servers and choosing the closest
   server, could simply type:

anycastingすることに関する動機は適切なサーバを見つけるタスクをかなり簡素化するということです。例えば、archieサーバのリストに相談して、最も近いサーバを選ぶことの代わりに、ユーザは単にタイプできました:

                             telnet archie.net

telnet archie.net

Partridge, Mendez & Milliken                                    [Page 1]

RFC 1546                Host Anycasting Service            November 1993

Anycastingが1993年11月にサービスを提供するヤマウズラ、メンデス、およびミリケン[1ページ]RFC1546ホスト

   and be connected to the nearest archie server.  DNS resolvers would
   no longer have to be configured with the IP addresses of their
   servers, but rather could send a query to a well-known DNS anycast
   address.  Mirrored FTP sites could similarly share a single anycast
   address, and users could simply FTP to the anycast address to reach
   the nearest server.

そして、最も近いarchieサーバに接続されてください。DNSレゾルバは、もうそれらのサーバのIPアドレスによって構成される必要はなかったでしょうが、むしろよく知られるDNS anycastアドレスに質問を送ることができました。 映されたFTPサイトは同様にただ一つのanycastアドレスを共有するかもしれません、そして、ユーザは単に達する中でサーバ最も近づくanycastアドレスへのFTPを共有できました。

Architectural Issues

構造的な問題

   Adding anycasting to the repertoire of IP services requires some
   decisions to be made about how to balance the architectural
   requirements of IP with those of anycasting.  This section discusses
   these architectural issues.

IPサービスのレパートリーにanycastingしながら加えるのはどうIPの建築要件のanycastingのものとバランスをとるかに関して作られているといういくつかの決定を必要とします。 このセクションはこれらの構造的な問題について論じます。

   The first and most critical architectural issue is how to balance
   IP's stateless service with the desire to have an anycast address
   represent a single virtual host.  The best way to illustrate this
   problem is with a couple of examples.  In both of these examples, two
   hosts (X and Y) are serving an anycast address and another host (Z)
   is using the anycast address to contact a service.

1番目の、そして、最も重要な構造的な問題はどうanycastアドレスに独身の事実上のホストの代理をさせる願望とIPの状態がないサービスのバランスをとるかということです。 この問題を例証する最も良い方法が2、3の例と共にあります。 これらの例の両方では、2人のホスト(XとY)がanycastアドレスに勤めています、そして、別のホスト(Z)はサービスに連絡するのにanycastアドレスを使用しています。

   In the first example, suppose that Z sends a UDP datagram addressed
   to the anycast address.  Now, given that an anycast address is
   logically considered the address of a single virtual host, should it
   be possible for the datagram to be delivered to both X and Y?  The
   answer to this question clearly has to be yes, delivery to both X and
   Y is permissible.  IP is allowed to duplicate and misroute datagrams
   so there clearly are scenarios in which a single datagram could be
   delivered to both X and Y.  The implication of this conclusion is
   that the definition of anycasting in an IP environment is that IP
   anycasting provides best effort delivery of an anycast datagram to
   one, but possibly more than one, of the hosts that serve the
   destination anycast address.

最初の例では、Zがanycastアドレスに扱われたUDPデータグラムを送ると仮定してください。 データグラムがXとYの両方に提供されるのは、それを考えて、現在anycastアドレスが独身の事実上のホストのアドレスであると論理的に考えられるのが可能であるべきですか? この質問の答えが明確にはいでなければならない、XとYの両方への配送は許されています。 IPが写しとmisrouteデータグラムに許容されているので、XとY.の両方に単一のデータグラムを提供できたシナリオが明確にあります。この結論の含意はIP環境でanycastingする定義がIP anycastingがしかし、1、ことによると送付先anycastアドレスに勤めるホストのより多くのひとりにanycastデータグラムのベストエフォート型配送を提供するということであるということです。

   In the second example, suppose that Z sends two datagrams addressed
   to the anycast address.  The first datagram gets delivered to X.  To
   which host (X or Y) does the second datagram get delivered?  It would
   be convenient for stateful protocols like TCP if all of a
   connection's datagrams were delivered to the same anycast address.
   However, because IP is stateless (and thus cannot keep track of where
   earlier datagrams were delivered) and because one of the goals of
   anycasting is to support replicated services, it seems clear that the
   second datagram can be delivered to either X or Y.  Stateful
   protocols will have to employ some additional mechanism to ensure
   that later datagrams are sent to the same host.  Suggestions for how
   to accomplish this for TCP are discussed below.

2番目の例では、Zがanycastアドレスに扱われた2個のデータグラムを送ると仮定してください。 最初のデータグラムはX.に提供されます。それのホスト(XかY)が2番目のデータグラムをするToは提供されますか? 接続のデータグラムのすべてが同じanycastアドレスに提供されるなら、TCPのようなstatefulプロトコルは都合がよいでしょうに。 しかしながら、anycastingするという目標の1つがIPが状態がなく(そして、その結果、以前のデータグラムが提供されたところで動向をおさえることができません)、模写されたサービスをサポートすることであるので、後のデータグラムが同じホストに送られるのを保証するのに何らかの追加メカニズムを使うのはStatefulプロトコルが持っているXかY.のどちらかに2番目のデータグラムを提供できるのが明確に思えます。 以下でTCPのためにどうこれを達成するかためには提案について議論します。

Partridge, Mendez & Milliken                                    [Page 2]

RFC 1546                Host Anycasting Service            November 1993

Anycastingが1993年11月にサービスを提供するヤマウズラ、メンデス、およびミリケン[2ページ]RFC1546ホスト

   After considering the two examples, it seems clear that the correct
   definition of IP anycasting is a service which provides a stateless
   best effort delivery of an anycast datagram to at least one host, and
   preferably only one host, which serves the anycast address.  This
   definition makes clear that anycast datagrams receive the same basic
   type of service as IP datagrams.  And while the definition permits
   delivery to multiple hosts, it makes clear that the goal is delivery
   to just one host.

2つの例を考えた後に、IP anycastingの正しい定義が少なくとも1人のホスト、および望ましくは1人のホストだけへのanycastアドレスに役立つanycastデータグラムの状態がないベストエフォート型配送を提供するサービスであることは明確に見えます。 この定義は、anycastデータグラムがIPデータグラムに対する同じ基本型のサービスを受けることを明らかにします。そして、定義は複数のホストに配送を可能にしますが、それは、目標がちょうど1人のホストへの配送であることを明らかにします。

Anycast Addresses

Anycastアドレス

   There appear to be a number of ways to support anycast addresses,
   some of which use small pieces of the existing address space, others
   of which require that a special class of IP addresses be assigned.

あるようにanycastアドレスをサポートする多くの方法に見えます。その或るものは既存のアドレス空間の小さい断片を使用します。その他のものは、特別なクラスのIPアドレスが割り当てられるのを必要とします。

   The major advantage of using the existing address space is that it
   may make routing easier.  As an example, consider a situation where a
   portion of each IP network number can be used for anycasting.  I.e.,
   a site, if it desires, could assign a set of its subnet addresses to
   be anycast addresses.  If, as some experts expect, anycast routes are
   treated just like host routes by the routing protocols, the anycast
   addresses would not require special advertisement outside the site --
   the host routes could be folded in with the net route.  (If the
   anycast addresses is supported by hosts outside the network, then
   those hosts would still have be advertised using host routes).  The
   major disadvantages of this approach are (1) that there is no easy
   way for stateful protocols like TCP to discover that an address is an
   anycast address, and (2) it is more difficult to support internet-
   wide well-known anycast address.  The reasons TCP needs to know that
   an address is an anycast address is discussed in more detail below.
   The concern about well-known anycast addresses requires a bit of
   explanation.  The idea is that the Internet might establish that a
   particular anycast address is the logical address of the DNS server.
   Then host software could be configured at the manufacturer to always
   send DNS queries to the DNS anycast address.  In other words,
   anycasting could be used to support autoconfiguration of DNS
   resolvers.

既存のアドレス空間を使用する主要な利点はルーティングをより簡単にするかもしれないということです。 例と、anycastingするのにそれぞれのIPネットワーク・ナンバーの部分を使用できる状況を考えてください。 すなわち、それであることでのサイト、願望、anycastアドレスであるサブネットアドレスの案配aセットはそうすることができました。 何人かの専門家が予想するようにanycastルートがまさしくルーティング・プロトコルによるホストルートのように扱われるなら、anycastアドレスはサイトの外で特別な広告を必要としないでしょう--ホストルートでは、ネットのルートで折り重なることができるでしょう。 (ネットワークの外におけるホストがanycastアドレスをサポートするなら、ホストルートを使用することでまだそれらのホストの広告を出していたでしょう。) (2) このアプローチの主要な損失は(1) TCPのようなstatefulプロトコルがアドレスがanycastアドレスであると発見するどんな簡単な方法もないということです、そして、インターネットの広いよく知られるanycastがアドレスであるとサポートするのは、より難しいです。 TCPが、アドレスがさらに詳細に以下でanycastアドレスについて議論するということであることを知る必要がある理由。 よく知られるanycastアドレスに関する心配は少しの説明を必要とします。 考えはインターネットが、特定のanycastアドレスがDNSサーバの論理アドレスであることを確証するかもしれないということです。次に、いつもDNS anycastアドレスへの質問をDNSに送るためにメーカーでホストソフトウェアは構成できました。 言い換えれば、DNSレゾルバの自動構成をサポートするのにanycastingを使用できました。

   The major advantages of using a separate class of addresses are that
   it is easy to determine if an address is an anycast address and
   well-known anycast addresses are easier to support.  The key
   disadvantage is that routing may be more painful, because the routing
   protocols may have to keep track of more anycast routes.

別々のクラスのアドレスを使用する主要な利点はアドレスがanycastアドレスであり、よく知られるanycastアドレスはよりサポートしやすいかどうか決定するのが簡単であるということです。 主要な不都合はルーティングが、より苦痛であるかもしれないということです、ルーティング・プロトコルが、より多くのanycastルートの動向をおさえなければならないかもしれないので。

   An intermediate approach is to take part of the current address space
   (say 256 Class C addresses) and make the network addresses into
   anycast addresses (and ignore the host part of the class C address).
   The advantage of this approach is that it makes anycast routes look

中間的アプローチは、現在のアドレス空間(256Class Cのアドレスを言う)の一部を連れて行って、anycastアドレスにネットワーク・アドレスを作りかえる(クラスCアドレスのホスト部分を無視してください)ことです。 このアプローチの利点はanycastルートを見せるということです。

Partridge, Mendez & Milliken                                    [Page 3]

RFC 1546                Host Anycasting Service            November 1993

Anycastingが1993年11月にサービスを提供するヤマウズラ、メンデス、およびミリケン[3ページ]RFC1546ホスト

   like network routes (which are easier for some routing protocols to
   handle).  The disadvantages are that it uses the address space
   inefficiently and so more severely limits the number of anycast
   addresses that can be supported.

ネットワークルート(いくつかのルーティング・プロトコルが、より扱いやすい)のように。 損失は効率悪くアドレス空間を使用するので、より厳しくサポートできるanycastアドレスの数を制限するということです。

   In the balance it seems wiser to use a separate class of addresses.
   Carving anycast addresses from the existing address space seems more
   likely to cause problems in situations in which either applications
   mistakenly fail to recognize anycast addresses (if anycasts are part
   of each site's address space) or use the address space inefficiently
   (if network addresses are used as anycast addresses).  And the
   advantages of using anycast addresses for autoconfiguration seem
   compelling.  So this memo assumes that anycast addresses will be a
   separate class of IP addresses (not yet assigned).  Since each
   anycast address is a virtual host address and the number of
   anycasting hosts seems unlikely to be larger than the number of
   services offered by protocols like TCP and UDP, the address space
   could be quite small, perhaps supporting as little as 2**16 different
   addresses.

バランスでは、別々のクラスのアドレスを使用するのは、より賢明に思えます。 おそらく、既存のアドレス空間からanycastアドレスを彫るのはアプリケーションがanycastアドレスを誤って認識しないか(anycastsが各サイトのアドレス空間の一部であるなら)、または効率悪くアドレス空間を使用する状況で問題を起こすように思えます(ネットワーク・アドレスがanycastアドレスとして使用されるなら)。 そして、自動構成にanycastアドレスを使用する利点は無視できなく見えます。 それで、このメモは、anycastアドレスが別々のクラスのIPアドレスになる(まだ割り当てられていない)と仮定します。 それぞれのanycastアドレスが仮想のホスト・アドレスであり、anycastingホストの数がTCPとUDPのようなプロトコルによって提供されたサービスの数ほど大きそうにないので、アドレス空間はかなり小さいかもしれません、恐らく最小2**が16の異なったアドレスであるとサポートして。

Transmission and Reception of Anycast Datagrams

Anycastデータグラムのトランスミッションとレセプション

   Historically, IP services have been designed to work even if routers
   are not present (e.g., on LANs without routers).  Furthermore, many
   in the Internet community have historically felt that hosts should
   not have to participate in routing protocols to operate.  (See, for
   instance, page 7 of STD 3, RFC 1122). To provide an anycasting
   service that is consistent with these traditions, the handling of
   anycast addresses varies slightly depending on the type of network on
   which datagrams with anycast addresses are sent.

ルータが存在していなくても(例えば、ルータのないLANの)、歴史的に、IPサービスは、働くように設計されます。 その上、インターネットコミュニティの多くが、ホストが作動するためにルーティング・プロトコルに参加する必要はないはずであると歴史的に感じました。 (STD3、例えば7RFC1122年ページを参照します。) 一貫したanycastingサービスにこれらの伝統を提供するために、anycastアドレスがあるデータグラムが送られるネットワークのタイプに頼っていて、anycastアドレスの取り扱いはわずかに変わります。

   On a shared media network, such as an Ethernet and or Token Ring, it
   must be possible to transmit an anycast datagram to a server also on
   the same network without consulting a (possibly non-existent) router.
   There are at least two ways this can be done.

または、そして、イーサネットなどの共有されたマスメディア網、Token Ring、(ことによると実在しません)のルータに相談しないで同じネットワークでもサーバにanycastデータグラムを送るのは可能であるに違いありません。 これができる少なくとも2つの方法があります。

   One approach is to ARP for the anycast address.  Servers which
   support the anycast address can reply to the ARP request, and the
   sending host can transmit to the first server that responds.  This
   approach is reminiscent of the ARP hack (RFC 1027) and like the ARP
   hack, requires ARP cache timeouts for the anycast addresses be kept
   small (around 1 minute), so that if an anycast server goes down,
   hosts will promptly flush the ARP entry and query for other servers
   supporting the anycast address.

anycastアドレスのためのARPには1つのアプローチがあります。 anycastアドレスをサポートするサーバはARP要求に答えることができます、そして、送付ホストは反応する最初のサーバに伝わることができます。 このアプローチはARPハッキング(RFC1027)のなごりであり、ARPがanycastアドレスのためにハックして、ARPキャッシュタイムアウトを必要とするように(およそ1分)の間、小さく保たれてください、anycastサーバが落ちると、ホストが即座にanycastアドレスをサポートする他のサーバのためのARPエントリーと質問を洗い流すように。

   Another approach is for hosts to transmit anycast datagrams on a
   link-level multicast address.  Hosts which serve an anycast address
   would be expected to listen to the link-level multicast address for

別のアプローチはホストがリンク・レベルマルチキャストアドレスでanycastデータグラムを送ることです。 anycastアドレスがリンク・レベルマルチキャストアドレスが聴かれるとそれのサーブに予想されるホスト

Partridge, Mendez & Milliken                                    [Page 4]

RFC 1546                Host Anycasting Service            November 1993

Anycastingが1993年11月にサービスを提供するヤマウズラ、メンデス、およびミリケン[4ページ]RFC1546ホスト

   datagrams destined for their anycast address.  By multicasting on the
   local network, there is no need for a router to route the anycast
   datagrams.  One merit of this approach is that if there are multiple
   servers and one goes down, the others will still receive any
   requests.  Another possible advantage is that, because anycast ARP
   entries must be quickly timed out, the multicasting approach may be
   less traffic intensive than the ARP approach because in the ARP
   approach, transmissions to an anycast address are likely to cause a
   broadcast ARP, while in the multicast approach, transmissions are
   only to a select multicast group.  An obvious disadvantage is that if
   there are multiple servers on a network, they will all receive the
   anycast message, when delivery to only one server was desired.

データグラムはそれらのanycastアドレスのために運命づけられました。 企業内情報通信網のマルチキャスティングで、ルータがanycastデータグラムを発送する必要は全くありません。このアプローチの1つの長所はそれでも、複数のサーバがあって、1つが落ちると、他のものがどんな要求も受け取るということです。 別の可能な利点はマルチキャスティングアプローチが外ですぐにanycast ARPエントリーを調節しなければならないのでARPアプローチでは、anycastアドレスへのトランスミッションが放送ARPを引き起こしそうですが、トランスミッションがマルチキャストアプローチ選んだマルチキャストグループだけに中であるのでARPアプローチよりさらに少ないトラフィック徹底的であるかもしれないということです。 明白な不都合は複数のサーバがネットワークにあると、彼らが皆、anycastメッセージを受け取るということです、1つのサーバだけへの配送が望まれていたとき。

   On point-to-point links, anycast support is simpler.  A single copy
   of the anycast datagram is forwarded along the appropriate link
   towards the anycast destination.

ポイントツーポイント接続では、anycastサポートは、より簡単です。 適切なリンクに沿ってanycastデータグラムのただ一つのコピーをanycastの目的地に向かって送ります。

   When a router receives an anycast datagram, the router must decide if
   it should forward the datagram, and if so, transmits one copy of the
   datagram to the next hop on the route.  Note that while we may hope
   that a router will always know the correct next hop for an anycast
   datagram and will not have to multicast anycast datagrams on a local
   network, there are probably situations in which there are multiple
   servers on a local network, and to avoid sending to one that has
   recently crashed, routers may wish to send anycast datagrams on a
   link-level multicast address.  Because hosts may multicast any
   datagrams, routers should take care not to forward a datagram if they
   believe that another router will also be forwarding it.

そうだとすれば、そして、ルータがanycastデータグラムを受けるとき、ルータが、それがデータグラムを進めるべきであるかどうか決めなければならない、データグラムのコピー1部をルートの上の次のホップに伝えます。 私たちが、ルータがanycastデータグラムでいつも次の正しいホップを知って、企業内情報通信網にanycastデータグラムをマルチキャストに持っていないことを望んでいるかもしれなくて、たぶん複数のサーバが企業内情報通信網にある状況があって、それが最近1つに発信するのを避けるためにダウンしている間ルータがリンク・レベルマルチキャストアドレスにanycastデータグラムを送りたがっているかもしれないことに注意してください。 ホスト、どんなデータグラム、ルータもそうするべきであるマルチキャストが、また、別のルータがそれを進めると信じているならデータグラムを進めないように注意されますように。

   Hosts which wish to receive datagrams for a particular anycast
   address will have to advertise to routers that they have joined the
   anycast address.  On shared media networks, the best mechanism is
   probably for a host to periodically multicast information about the
   anycast addresses it supports (possibly using an enhanced version of
   IGMP).  The multicast messages ensure that any routers on the network
   hear that the anycast address is supported on the local subnet and
   can advertise that fact (if appropriate) to neighboring routers.
   Note that if there are no routers on the subnet, the multicast
   messages would simply simply ignored.  (The multicasting approach is
   suggested because it seems likely to be simpler and more reliable
   than developing a registration protocol, in which an anycast server
   must register itself with each router on its local network).

特定のanycastのためのデータグラムが受信するというそれの願望を扱うホストは、anycastアドレスを接合したのはルータに広告を出さなければならないでしょう。 共有されたマスメディア網、最も良いメカニズムの上に、たぶんホストのために、定期的にはそれがサポートするanycastアドレスのマルチキャスト情報があります(ことによるとIGMPの高められたバージョンを使用して)。 マルチキャストメッセージは、ネットワークのどんなルータも、anycastアドレスが地方のサブネットでサポートされると聞くのを確実にして、その事実(適切であるなら)の隣接しているルータに広告を出すことができます。 ルータが全くサブネットになければ、マルチキャストメッセージが単に単に無視されていた状態であることに注意してください。 (マルチキャスティングアプローチはanycastサーバが企業内情報通信網の各ルータにそれ自体を登録しなければならない登録プロトコルを開発するよりさらに簡単であって、信頼できるのがありそうに思えるので、示されます。)

   On point-to-point links, a host can simply advertise its anycast
   addresses to the router on the other end of the link.

ポイントツーポイント接続の上では、ホストはリンクのもう一方の端に単にanycastアドレスのルータに広告を出すことができます。

   Observe that the advertisement protocols are a form of routing
   protocol and that it may make sense to simply require anycast servers

広告プロトコルがルーティング・プロトコルのフォームであり、それが単にanycastを必要とする意味をサーバにするかもしれないのを観測してください。

Partridge, Mendez & Milliken                                    [Page 5]

RFC 1546                Host Anycasting Service            November 1993

Anycastingが1993年11月にサービスを提供するヤマウズラ、メンデス、およびミリケン[5ページ]RFC1546ホスト

   to participate (at least partly) in exchanges of regular routing
   messages.

通常のルーティング・メッセージの交換に参加する(少なくとも一部)ために。

   When a host receives an IP datagram destined for an anycast address
   it supports, the host should treat the IP datagram just as if it was
   destined for one of the host's non-anycast IP addresses.  If the host
   does not support the anycast address, it should silently discard the
   datagram.

ホストがそれがサポートするanycastアドレスのために運命づけられたIPデータグラムを受け取るとき、まるでまさしくそれがホストの非anycast IPアドレスの1つのために運命づけられるかのようにホストはIPデータグラムを扱うべきです。 ホストが、anycastがアドレスであるとサポートしないなら、それは静かにデータグラムを捨てるべきです。

   Hosts should accept datagrams with an anycast source address,
   although some transport protocols (see below) may refuse to accept
   them.

いくつかのトランスポート・プロトコル(以下を見る)が、それらを受け入れるのを拒否するかもしれませんが、ホストはanycastソースアドレスでデータグラムを受け入れるべきです。

How UDP and TCP Use Anycasting

UDPとTCPはどうAnycastingを使用するか。

   It is important to remember that anycasting is a stateless service.
   An internetwork has no obligation to deliver two successive packets
   sent to the same anycast address to the same host.

anycastingが状態がないサービスであることを覚えているのは重要です。 インターネットワークには、同じanycastアドレスに送られた2つの連続したパケットを同じホストに提供する義務が全くありません。

   Because UDP is stateless and anycasting is a stateless service, UDP
   can treat anycast addresses like regular IP addresses.  A UDP
   datagram sent to an anycast address is just like a unicast UDP
   datagram from the perspective of UDP and its application.  A UDP
   datagram from an anycast address is like a datagram from a unicast
   address.  Furthermore, a datagram from an anycast address to an
   anycast address can be treated by UDP as just like a unicast datagram
   (although the application semantics of such a datagram are a bit
   unclear).

UDPが状態がなく、anycastingが状態がないサービスであるので、UDPは通常のIPアドレスのようなanycastアドレスを扱うことができます。 anycastアドレスに送られたUDPデータグラムはまさしくUDPの見解とそのアプリケーションからのユニキャストUDPデータグラムに似ています。 anycastアドレスからのUDPデータグラムはユニキャストアドレスからのデータグラムに似ています。 その上、UDPはちょうどユニキャストデータグラム(そのようなデータグラムのアプリケーション意味論は少し不明瞭ですが)のようにanycastアドレスからanycastアドレスまでのデータグラムを扱うことができます。

   TCP's use of anycasting is less straightforward because TCP is
   stateful.  It is hard to envision how one would maintain TCP state
   with an anycast peer when two successive TCP segments sent to the
   anycast peer might be delivered to completely different hosts.

TCPがstatefulであるので、anycastingのTCPの使用はそれほど簡単ではありません。 人が、TCPが、anycast同輩と共にanycast同輩に送られた2つの連続したTCPセグメントがいつ完全に異なったホストに提供されるかもしれないかを述べるとどう主張するだろうかを思い描きにくいです。

   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セグメントのリモートアドレスとしてanycastアドレスを可能にするだけである(ACKがなければ、ビットはセットしました)ことです。 そして、TCPはanycastアドレスに接続を開始できます。 SYN-ACKが返送されるとき、anycastセグメント、開始を受けたホストにTCPは同輩のanycastアドレスを置き換えるはずです、ホストのアドレスがSYN-ACKを返していて。 (開始しているTCPはSYN-ACKがどんな入って来るSYN-ACKセグメントも正しい仕向港、アドレス、およびソースポートに合わせるワイルドカードアドレスとしてanycastアドレスを扱うことによって運命づけられている接続を見分けることができます、ソースアドレスを含むSYN-ACKの完全なアドレスが別の接続に合わないで、SYN-ACKの一連番号が適度であるなら。) このアプローチは、TCPであり、受信した後にSYN-ACKがいつも1人のホストだけとコミュニケートしているのを確実にします。

Partridge, Mendez & Milliken                                    [Page 6]

RFC 1546                Host Anycasting Service            November 1993

Anycastingが1993年11月にサービスを提供するヤマウズラ、メンデス、およびミリケン[6ページ]RFC1546ホスト

Applications and Anycasting

アプリケーションとAnycasting

   In general, applications use anycast addresses like any other IP
   address.  The only worrisome application use of anycasting is
   applications which try to maintain stateful connections over UDP and
   applications which try to maintain state across multiple TCP
   connections.  Because anycasting is stateless and does not guarantee
   delivery of multiple anycast datagrams to the same system, an
   application cannot be sure that it is communicating with the same
   peer in two successive UDP transmissions or in two successive TCP
   connections to the same anycast address.

一般に、アプリケーションはいかなる他のIPアドレスのようなanycastアドレスも使用します。 anycastingの唯一の面倒なアプリケーション使用が、UDPの上のstateful接続を維持しようとするアプリケーションと複数のTCP接続の向こう側に状態を維持しようとするアプリケーションです。 anycastingが状態がなく、複数のanycastデータグラムの配送を同じシステムに保証しないので、アプリケーションは2個の連続したUDPトランスミッションか同じanycastアドレスとの2つの連続したTCP接続で同じ同輩とコミュニケートしているのを確信しているはずがありません。

   The obvious solutions to these issues are to require applications
   which wish to maintain state to learn the unicast address of their
   peer on the first exchange of UDP datagrams or during the first TCP
   connection and use the unicast address in future conversations.

これらの問題の明らかな解決法は、UDPデータグラムの第一交換か最初のTCP接続の間、彼らの同輩のユニキャストアドレスを学ぶために状態を維持したがっているアプリケーションを必要として、今後の会話にユニキャストアドレスを使用することです。

Anycasting and Multicasting

Anycastingとマルチキャスティング

   It has often been suggested that IP multicasting can be used for
   resource location, so it is useful to compare the services offered by
   IP multicasting and IP anycasting.

IPマルチキャスティングによって提供されたサービスとIP anycastingを比較するのが役に立って、しばしばリソース位置にIPマルチキャスティングを使用できることが提案されました。

   Semantically, the difference between the two services is that an
   anycast address is the address of a single (virtual) host and that
   the internetwork will make an effort to deliver anycast datagrams to
   a single host.  There are two implications of this difference.
   First, applications sending to anycast addresses need not worry about
   managing the TTLs of their IP datagrams.  Applications using
   multicast to find a service must balance their TTLs to maximize the
   chance of finding a server while minimizing the chance of sending
   datagrams to a large number of servers it does not care about.
   Second, making a TCP connection to an anycast address makes perfectly
   good sense, while the meaning of making a TCP connection to a
   multicast address are unclear.  (A TCP connection to a multicast
   address is presumably trying to establish a connection to multiple
   peers simultaneously, which TCP is not designed to support).

2つのサービスの違いは意味的に、anycastアドレスが独身(仮想の)のホストのアドレスであり、インターネットワークがanycastデータグラムを独身のホストに提供するために取り組みを作るということです。 この違いの2つの含意があります。 まず最初に、アドレスが必要とするanycastに発信するアプリケーションは彼らのIPデータグラムのTTLsを管理するのを心配しません。サービスを見つけるのにマルチキャストを使用するアプリケーションは、それが心配しない多くのサーバにデータグラムを送るという機会を最小にしている間、サーバを見つけるという機会を最大にするためにそれらのTTLsのバランスをとらなければなりません。 2番目に、TCP接続をanycastアドレスにすると、完全に良い意味はなられます、TCP接続をマルチキャストアドレスにする意味が不明瞭ですが。 (おそらく、マルチキャストアドレスとのTCP接続は同時に複数の同輩に取引関係を築こうとしています、TCPがサポートするように設計されていないもの。)

   From a practical perspective, the major difference between anycasting
   and multicasting is that anycasting is a special use of unicast
   addressing while multicasting requires more sophisticated routing
   support.  The important observation is that multiple routes to an
   anycast address appear to a router as multiple routes to a unicast
   destination, and the router can use standard algorithms to choose to
   the best route.

実用的な見解から、anycastingとマルチキャスティングの主要な違いはマルチキャスティングが、より洗練されたルーティングサポートを必要としますが、anycastingがユニキャストアドレシングの特別な使用であるということです。 重要な観測はanycastアドレスへの複数のルートがユニキャストの目的地への複数のルートとしてルータに現れるということです、そして、ルータは最も良いルートに選ぶのに標準のアルゴリズムを使用できます。

Partridge, Mendez & Milliken                                    [Page 7]

RFC 1546                Host Anycasting Service            November 1993

Anycastingが1993年11月にサービスを提供するヤマウズラ、メンデス、およびミリケン[7ページ]RFC1546ホスト

   Another difference between the two approaches is that resource
   location using multicasting typically causes more datagrams to be
   sent.  To find a server using multicasting, an application is
   expected to transmit and retransmit a multicast datagram with
   successively larger IP TTLs.  The TTL is initially kept small to try
   to limit the number of servers contacted.  However, if no servers
   respond, the TTL must be increased on the assumption that the
   available servers (if any) were farther away than was reachable with
   the initial TTL.  As a result, resource location using multicasting
   causes one or more multicast datagrams to be sent towards multiple
   servers, with some datagrams' TTLs expiring before reaching a server.
   With anycasting, managing the TTL is not required and so (ignoring
   the case of loss) only one datagram need be sent to locate a server.
   Furthermore, this datagram will follow only a single path.

2つのアプローチの別の違いはマルチキャスティングを使用するリソース位置で、より多くのデータグラムを通常送るということです。 マルチキャスティングを使用することでサーバを見つけるために、アプリケーションは、相次ぎより大きいIP TTLsがあるマルチキャストデータグラムを伝えて、再送すると予想されます。 TTLは初めは、サーバの数が連絡した限界に試みるために小さく保たれます。 しかしながら、サーバが全く反応しないなら、遠くでは、利用可能なサーバ(もしあれば)が初期のTTLと共に届いたより遠かったという前提でTTLを増強しなければなりません。 その結果、マルチキャスティングを使用するリソース位置で1個以上のマルチキャストデータグラムを複数のサーバに向かって送ります、サーバに達する前にいくつかのデータグラムのTTLsが期限が切れていて。anycastingで、TTLを管理するのを必要としません、そして、したがって(損失に関するケースを無視する)、サーバの場所を見つけるように1個のデータグラムだけを送らなければなりません。その上、このデータグラムはただ一つの経路だけに続くでしょう。

   A minor difference between the two approaches is that anycast may be
   less fault tolerant than multicast.  When an anycast server fails,
   some datagrams may continue to be mistakenly routed to the server,
   whereas if the datagram had been multicast, other servers would have
   received it.

2つのアプローチの間の小異はanycastがマルチキャストほどフォルト・トレラントでないかもしれないということです。 anycastサーバが失敗するとき、他のサーバはデータグラムがマルチキャストであったなら、それを受けたでしょうにが、いくつかのデータグラムが、サーバに誤って発送され続けるかもしれません。

Related Work

関連仕事

   The ARPANET AHIP-E Host Access Protocol described in RFC 878 supports
   logical addressing which allows several hosts to share a single
   logical address.  This scheme could be used to support anycasting
   within a PSN subnet.

RFC878で説明されたARPANET AHIP-E Host Accessプロトコルは数人のホストが単一の論理アドレスを共有できる論理的なアドレシングをサポートします。 PSNサブネットの中のanycastingをサポートするのにこの体系を使用できました。

Security Considerations

セキュリティ問題

   There are at least two security issues in anycasting, which are
   simply mentioned here without suggested solutions.

anycastingにおける少なくとも2つの安全保障問題があります。(安全保障問題は提案された解決法なしでここに単に言及されます)。

   First, it is clear that malevolent hosts could volunteer to serve an
   anycast address and divert anycast datagrams from legitimate servers
   to themselves.

まず最初に、意地の悪いホストがanycastアドレスをサービスして、正統のサーバから自分たちにanycastデータグラムを紛らすのを買って出ることができたのは、明確です。

   Second, eavesdropping hosts could reply to anycast queries with
   inaccurate information.  Since there is no way to verify membership
   in an anycast address, there is no way to detect that the
   eavesdropping host is not serving the anycast address to which the
   original query was sent.

2番目に、盗聴ホストは不正確な情報でanycast質問に答えることができました。 anycastアドレスには会員資格について確かめる方法が全くないので、それを検出するために、盗聴ホストがオリジナルの質問が送られたanycastアドレスに勤めていない方法が全くありません。

Partridge, Mendez & Milliken                                    [Page 8]

RFC 1546                Host Anycasting Service            November 1993

Anycastingが1993年11月にサービスを提供するヤマウズラ、メンデス、およびミリケン[8ページ]RFC1546ホスト

Acknowledgements

承認

   This memo has benefitted from comments from Steve Deering, Paul
   Francis, Christian Huitema, Greg Minshall, Jon Postel, Ram
   Ramanathan, and Bill Simpson.  However, the authors are solely
   responsible for any dumb ideas in this work.

このメモはスティーブ・デアリング、ポール・フランシス、クリスチャンのHuitema、グレッグMinshall、ジョン・ポステル、牡羊座Ramanathan、およびビル・シンプソンからコメントの利益を得ました。 しかしながら、作者は唯一この仕事におけるどんな馬鹿な考えにも責任があります。

Authors' Addresses

作者のアドレス

   Craig Partridge
   Bolt Beranek and Newman
   10 Moulton St
   Cambridge MA 02138

ニューマン10モールトン通りケンブリッジMA クレイグヤマウズラボルトBeranekと02138

   EMail: craig@bbn.com

メール: craig@bbn.com

   Trevor Mendez
   Bolt Beranek and Newman
   10 Moulton St
   Cambridge MA 02138

ニューマン10モールトン通りケンブリッジMA トレバーメンデスボルトBeranekと02138

   EMail: tmendez@bbn.com

メール: tmendez@bbn.com

   Walter Milliken
   Bolt Beranek and Newman
   10 Moulton St
   Cambridge MA 02138

ニューマン10モールトン通りケンブリッジMA ウォルターミリケンボルトBeranekと02138

   EMail: milliken@bbn.com

メール: milliken@bbn.com

Partridge, Mendez & Milliken                                    [Page 9]

ヤマウズラ、メンデス、およびミリケン[9ページ]