rfc1546.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 507 行 · 第 1/2 页

   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.

   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).

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

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



Partridge, Mendez & Milliken                                    [Page 5]

RFC 1546                Host Anycasting Service            November 1993


   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.

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

How UDP and TCP Use 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.

   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).

   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.

   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.



Partridge, Mendez & Milliken                                    [Page 6]

RFC 1546                Host Anycasting Service            November 1993


Applications and 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.

   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.

Anycasting and Multicasting

   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.

   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).

   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.






Partridge, Mendez & Milliken                                    [Page 7]

RFC 1546                Host Anycasting Service            November 1993


   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.

   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.

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.

Security Considerations

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

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

   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.









Partridge, Mendez & Milliken                                    [Page 8]

RFC 1546                Host Anycasting Service            November 1993


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.


Authors' Addresses

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

   EMail: [e-mail]


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

   EMail: [e-mail]


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

   EMail: [e-mail]



















Partridge, Mendez & Milliken                                    [Page 9]