doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc7094.txt b/doc/rfc/rfc7094.txt
new file mode 100644
index 0000000..617dc17
--- /dev/null
+++ b/doc/rfc/rfc7094.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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
+
+Abstract
+
+   This memo discusses architectural implications of IP anycast and
+   provides some historical analysis of anycast use by various IETF
+   protocols.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 1]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+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
+
+1.  Overview
+
+   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 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.
+
+   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
+
+
+
+McPherson, et al.             Informational                     [Page 2]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   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.
+
+   Unlike IP unicast, it is not considered an error to assert the same
+   anycast address on multiple interfaces within the same or multiple
+   systems.
+
+   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.
+
+   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.
+
+2.  Background
+
+   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.
+
+2.1.  Anycast History
+
+   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.
+
+   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":
+
+
+
+
+McPherson, et al.             Informational                     [Page 3]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+      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.
+
+   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.
+
+   In 1997, the IAB clarified that IPv4 anycast addresses were pure
+   "locators" and could never serve as "identifiers" of hosts or
+   interfaces [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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 4]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   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.
+
+   IPv6 defined some reserved subnet anycast addresses [RFC2526] and
+   assigned one to "Mobile IPv6 Home-Agents" [RFC3775] (obsoleted by
+   [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.
+
+   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).
+
+   Anycast was used for routing to rendezvous points (RPs) for PIM
+   [RFC4610].
+
+   "Operation of Anycast Services" BCP 126 [RFC4786] deals with how the
+   routing system interacts with anycast services and the operation of
+   anycast services.
+
+   "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
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 5]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   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).
+
+   The IAB's "Reflections on Internet Transparency" [RFC4924] briefly
+   mentions how violating transparency can also damage global services
+   that use anycast.
+
+2.2.  Anycast in IPv6
+
+   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].
+
+   In fact, the more recent "IPv6 Transition/Co-existence Security
+   Considerations" [RFC4942] overview now recommends:
+
+      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.
+
+2.3.  DNS Anycast
+
+   "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:
+
+      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.
+
+
+
+McPherson, et al.             Informational                     [Page 6]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   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  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  It argued that failure modes involving state were not serious,
+      because:
+
+      *  the vast majority of DNS queries are 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.
+
+   "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
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 7]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   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.
+
+2.4.  BCP 126 on Operation of Anycast Services
+
+   "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.
+
+   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].
+
+3.  Principles
+
+3.1.  Layering and Resiliency
+
+   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.
+
+   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
+
+
+
+McPherson, et al.             Informational                     [Page 8]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   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.
+
+3.2.  Anycast Addresses as Destinations
+
+   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:
+
+   o  A request message or "one shot" message is self-contained in a
+      single transport packet.
+
+   o  A stateless transport (e.g., UDP) is used for the above.
+
+   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  The server side of the application keeps no hard state across
+      requests.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+McPherson, et al.             Informational                     [Page 9]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+3.3.  Anycast Addresses as Sources
+
+   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:
+
+   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  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.
+
+3.4.  Service Discovery
+
+   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.
+
+   [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].
+
+   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
+
+
+
+McPherson, et al.             Informational                    [Page 10]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   well-known anycast address in this scenario.  During publication, the
+   IESG requested that the following "IESG Note" be contained in the
+   document:
+
+      This document describes three different approaches for the
+      configuration of DNS name resolution server information in IPv6
+      hosts.
+
+      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.
+
+      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.
+
+4.  Analysis
+
+4.1.  Regarding Widespread Anycast Use
+
+   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).
+
+   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".
+
+   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.
+
+4.2.  Transport Implications
+
+   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:
+
+
+
+
+McPherson, et al.             Informational                    [Page 11]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+      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.
+
+   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.
+
+   Multi-address transports (e.g., SCTP) might be more amenable to such
+   extensions than TCP.
+
+   The features needed for address discovery when doing multihoming in
+   the transport layer are similar to those needed to support anycast.
+
+4.3.  Stateful Firewalls, Middleboxes, and 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.
+
+4.4.  Security Considerations
+
+   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.
+
+
+
+
+McPherson, et al.             Informational                    [Page 12]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   "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".
+
+   "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).
+
+   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.
+
+   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.
+
+   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].
+
+   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.
+
+   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
+
+
+
+McPherson, et al.             Informational                    [Page 13]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   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.
+
+   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.
+
+   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.
+
+   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:
+
+   1.  Allowing route injection can cause DOS to a legitimate address
+       owner.
+
+   2.  Allowing route injection consumes routing resources and can hence
+       cause DOS to the routing system and impact legitimate
+       communications as a result.
+
+   These are two of the core issues that were part of the discussion
+   during [RFC1884], the [ANYCASTBOF], and the MAGMA [MAGMA] chartering.
+
+   Additional security considerations are scattered throughout the list
+   of references provided herein.
+
+
+
+McPherson, et al.             Informational                    [Page 14]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+4.5.  Deployment Considerations
+
+   BCP 126 [RFC4786] provides some very solid guidance related to
+   operations of anycasted services and, in particular, the operations
+   of 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.
+
+   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.
+
+   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,
+
+
+
+McPherson, et al.             Informational                    [Page 15]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   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].
+
+   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.
+
+5.  Conclusions
+
+   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.
+
+6.  Acknowledgements
+
+   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.
+
+7.  Informative References
+
+   [ANYCASTBOF]
+              Deering, S., "IAB Anycast BOF Announcement", October 1999,
+              <http://www.ietf.org/mail-archive/web/ietf/current/
+              msg11182.html>.
+
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 16]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   [DNS-DISC] Durand, A., Hagino, J., and D. Thaler, "Well known site
+              local unicast addresses for DNS resolver", Work in
+              Progress, September 2002.
+
+   [FanInfocom13]
+              Fan, X., Heidemann, J., and R. Govindan, "Evaluating
+              Anycast in the Domain Name System", Proceedings of the
+              IEEE Infocom 2013, April 2013.
+
+   [IMR9401]  RFC Editor, "INTERNET MONTHLY REPORT", January 1994,
+              <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>.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
+              793, September 1981.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
+              Anycasting Service", RFC 1546, November 1993.
+
+   [RFC1884]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 1884, December 1995.
+
+   [RFC2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+              for IPv4, IPv6 and OSI", RFC 2030, October 1996.
+
+   [RFC2101]  Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
+              Address Behaviour Today", RFC 2101, February 1997.
+
+   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 2373, July 1998.
+
+   [RFC2439]  Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
+              Flap Damping", RFC 2439, November 1998.
+
+   [RFC2526]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
+              Addresses", RFC 2526, March 1999.
+
+   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+              IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 17]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   [RFC2902]  Deering, S., Hares, S., Perkins, C., and R. Perlman,
+              "Overview of the 1998 IAB Routing Workshop", RFC 2902,
+              August 2000.
+
+   [RFC2991]  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
+              Multicast Next-Hop Selection", RFC 2991, November 2000.
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+              RFC 3068, June 2001.
+
+   [RFC3258]  Hardie, T., "Distributing Authoritative Name Servers via
+              Shared Unicast Addresses", RFC 3258, April 2002.
+
+   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+              (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+              in IPv6", RFC 3775, June 2004.
+
+   [RFC3882]  Turk, D., "Configuring BGP to Block Denial-of-Service
+              Attacks", RFC 3882, September 2004.
+
+   [RFC3964]  Savola, P. and C. Patel, "Security Considerations for
+              6to4", RFC 3964, December 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+   [RFC4085]  Plonka, D., "Embedding Globally-Routable Internet
+              Addresses Considered Harmful", BCP 105, RFC 4085, June
+              2005.
+
+   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+              for IPv6 Hosts and Routers", RFC 4213, October 2005.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+   [RFC4330]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+              for IPv4, IPv6 and OSI", RFC 4330, January 2006.
+
+   [RFC4339]  Jeong, J., "IPv6 Host Configuration of DNS Server
+              Information Approaches", RFC 4339, February 2006.
+
+
+
+
+McPherson, et al.             Informational                    [Page 18]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   [RFC4610]  Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
+              Independent Multicast (PIM)", RFC 4610, August 2006.
+
+   [RFC4732]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
+              Service Considerations", RFC 4732, December 2006.
+
+   [RFC4778]  Kaeo, M., "Operational Security Current Practices in
+              Internet Service Provider Environments", RFC 4778, January
+              2007.
+
+   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
+              Services", BCP 126, RFC 4786, December 2006.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862, September 2007.
+
+   [RFC4892]  Woolf, S. and D. Conrad, "Requirements for a Mechanism
+              Identifying a Name Server Instance", RFC 4892, June 2007.
+
+   [RFC4924]  Aboba, B. and E. Davies, "Reflections on Internet
+              Transparency", RFC 4924, July 2007.
+
+   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
+              Co-existence Security Considerations", RFC 4942, September
+              2007.
+
+   [RFC5001]  Austein, R., "DNS Name Server Identifier (NSID) Option",
+              RFC 5001, August 2007.
+
+   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
+              Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, June 2010.
+
+   [RFC5909]  Combes, J-M., Krishnan, S., and G. Daley, "Securing
+              Neighbor Discovery Proxy: Problem Statement", RFC 5909,
+              July 2010.
+
+   [RFC6071]  Frankel, S. and S. Krishnan, "IP Security (IPsec) and
+              Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
+              February 2011.
+
+   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
+              in IPv6", RFC 6275, July 2011.
+
+
+
+
+McPherson, et al.             Informational                    [Page 19]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+   [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.
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, February 2012.
+
+   [RSSAC29]  "RSSAC 29 Meeting Minutes", December 2007,
+              <http://www.icann.org/en/groups/rssac/meetings/
+              rssac-29-en.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 20]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+Appendix A.  IAB Members at the Time of Approval
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 21]
+
+RFC 7094            Arch Considerations of IP Anycast       January 2014
+
+
+Authors' Addresses
+
+   Danny McPherson
+   Verisign, Inc.
+   12061 Bluemont Way
+   Reston, VA
+   USA
+
+   EMail: dmcpherson@verisign.com
+
+
+   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
+
+   EMail: eosterweil@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McPherson, et al.             Informational                    [Page 22]
+