Internet DRAFT - draft-iab-anycast-arch-implications
draft-iab-anycast-arch-implications
INTERNET-DRAFT Danny McPherson
Verisign, Inc.
Dave Oran
Cisco Systems
Expires: April 2012 October 26, 2011
Intended Status: Informational
Architectural Considerations of IP Anycast
<draft-iab-anycast-arch-implications-04.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Copyright (c) 2010 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. Code Components
extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions and
are provided without warranty as described in the Simplified BSD
License.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
McPherson, Oran [Page 1]
INTERNET-DRAFT Expires: April 2012 October 2011
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (C) (2011) The IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract
This memo discusses architectural implications of IP anycast, and
provides some historical analysis of anycast use by various IETF
protocols.
McPherson, Oran [Page 2]
INTERNET-DRAFT Expires: April 2012 October 2011
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Anycast History . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Use of Anycast in RFCs. . . . . . . . . . . . . . . . . . . 6
2.3. Anycast in IPv6 . . . . . . . . . . . . . . . . . . . . . . 7
2.4. DNS Anycast . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. BCP 126 on Operation of Anycast Services. . . . . . . . . . 9
3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Layering and Resiliency . . . . . . . . . . . . . . . . . . 9
3.2. Anycast Addresses as Destinations . . . . . . . . . . . . . 10
3.3. Anycast Addresses as Sources. . . . . . . . . . . . . . . . 10
3.4. Service Discovery . . . . . . . . . . . . . . . . . . . . . 11
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Regarding Widespread Anycast Use. . . . . . . . . . . . . . 12
4.2. Transport Implications. . . . . . . . . . . . . . . . . . . 12
4.3. Stateful Firewalls, Middleboxes and Anycast . . . . . . . . 13
4.4. Security Considerations . . . . . . . . . . . . . . . . . . 13
4.5. Deployment Considerations . . . . . . . . . . . . . . . . . 15
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
6. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References. . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References. . . . . . . . . . . . . . . . . . . 18
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
10. Appendix A: IAB Members . . . . . . . . . . . . . . . . . . . 21
McPherson, Oran [Page 3]
INTERNET-DRAFT Expires: April 2012 October 2011
1. Overview
IP anycast is used for at least one critical Internet service, that
of the Domain Name System [RFC 1035] root servers. As of early 2009,
at least 10 of the 13 root name servers were 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) [RFC 1305].
Anycast addresses are syntactically indistinguishable from unicast
addresses. Allocation of anycast addresses typically follows a model
similar to that of unicast allocation policies. Anycast addressing
is largely equivalent to that of unicast in multiple locations, and
leverages unicast's destination-based routing to deliver a packet to
either zero or one interface among the set of interfaces asserting
the reachability for the address. The expectation of delivery is to
the "closest" instance as determined by unicast routing topology
metric(s), and there is also a possibility that various load-
balancing techniques (e.g., per-packet, per-microflow) may be used
among multiple equal cost routes to distribute load for an anycasted
prefix.
Unlike IP unicast, it is not considered an error to assert the same
anycast address on multiple interfaces within the same or multiple
systems.
Some consider anycast a "deceptively simple idea". That is, many
pitfalls and subtleties exist with applications and transports, as
well as for routing configuration and operation, when IP anycast is
employed. In this document, we aim to capture many of the
architectural implications of IP anycast.
[BCP 126] 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 IP's 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] and can be used for IPv4 and IPv6.
"On-link anycast" is the formal support of anycast in the address
resolution protocol (ARP) and is only supported under IPv6, with the
introduction of designated anycast addresses on the anycasted hosts,
and the Override flag in Neighbor Discovery (ND) Neighbor
Advertisements (NAs) [RFC 4861]. This method is generally not
supported under IPv4.
McPherson, Oran Section 1. [Page 4]
INTERNET-DRAFT Expires: April 2012 October 2011
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" [RFC 1546]. 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 [IMR 9401]. In the experiment a UDP query was
transmitted to an anycasted address to locate the topologically
closest "supposedly equivalent network resource":
"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 an "identifier" (of a host, an
interface, or anything else) [RFC 2101].
In 1998 the IAB conducted a routing workshop [RFC 2902]. Of the
conclusions and output action items from the report, an Anycast
section is contained in Section 2.10.3. Specifically called out in
the is the need to describe the advantages and disadvantages of
anycast, and the belief that local-scoped well-known anycast
McPherson, Oran Section 2.1. [Page 5]
INTERNET-DRAFT Expires: April 2012 October 2011
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 progress, 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 [RFC 2902], in November of 1999
an Anycast BOF [ANYCAST BOF] was held at IETF 46. A number of uses
for anycast were discussed. No firm conclusion was reached regarding
use of TCP with anycasted services, but 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
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 the initial authentication and access control
issues associated with anycast group membership, but other aspects of
anycast, including architecture and routing, were outside the group's
scope.
Additional work is provided in many of the references below.
2.2. Use of Anycast in RFCs
SNTPv4 [RFC 2030] defined how to use anycast for server discovery.
This was extended in [RFC 4330] as an NTP-specific "manycast"
service, in which anycast was used for the discovery part.
IPv6 defined some reserved subnet anycast addresses [RFC 2526] and
assigned one to "Mobile IPv6 Home-Agents" [RFC 3775].
The original IPv6 transition mechanism [RFC 2893] made use of IPv4
anycast addresses as tunnel endpoints for IPv6 encapsulated in IPv4,
but this was later removed [RFC 4213]. Carpenter's Relay Router [RFC
3056] scheme was augmented by a 6to4 relay anycast prefix [RFC 3068]
aiming to simplify the configuration of 6to4 routers. Incidentally,
6to4 deployment has shown a fair number of operational and security
issues [RFC 3964] 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 intended scope
(e.g., only advertise a route for your 6to4 relay to ASes that
conform to your own acceptable usage policy), an attribute that can
easily become quite operationally expensive.
McPherson, Oran Section 2.2. [Page 6]
INTERNET-DRAFT Expires: April 2012 October 2011
DNS use of anycast was first specified in "Distributing Authoritative
Name Servers via Shared Unicast Addresses" [RFC 3258]. It is notable
that it used the term "shared unicast address" rather than "anycast
address" for the service.
Anycast was used for routing to rendezvous points (RPs) for MSDP and
PIM [RFC 4610].
"Operation of Anycast Services" [BCP 126] 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"
[RFC 4892] cites the use of anycast with DNS as a motivation to
identify individual name server instances, and the NSID option was
defined for this purpose [RFC 5001].
"Reflections on Internet Transparency" [RFC 4924] briefly mentions
how violating transparency can also damage global services that use
anycast.
2.3. Anycast in IPv6
Originally, the IPv6 addressing architecture [RFC 1884] [RFC 2373]
[RFC 3513] severely restricted the use of anycast addresses. In
particular, they provided that anycast addresses MUST NOT be used as
a source address, and must not be assigned to an IPv6 host (i.e.,
only routers). These restrictions were later lifted in 2006 [RFC
4291].
In fact, the recent "IPv6 Transition/Co-existence Security
Considerations" [RFC 4942] 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 [RFC 4861] for additional
information.
McPherson, Oran Section 2.3. [Page 7]
INTERNET-DRAFT Expires: April 2012 October 2011
2.4. DNS Anycast
"Distributed Authoritative Name Servers via Shared Unicast Addresses"
[RFC 3258] described how to reach authoritative name servers using
anycast. It made some interesting points, for example this text from
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."
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
fail-over, as provided in the quoted text above.
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 move to a different server instance (where presumably
it doesn't break), just as it does with normal unicast
failover.
"Unique Per-Node Origin ASNs for Globally Anycasted Services" [RFC
6382] 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. The object was to allow network management and
monitoring techniques, or other operational mechanisms to employ this
McPherson, Oran Section 2.4. [Page 8]
INTERNET-DRAFT Expires: April 2012 October 2011
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.5. BCP 126 on Operation of Anycast Services
"Operation of Anycast Services" [BCP 126]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 primary 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".
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.
Higher layer protocols should make minimal assumptions about lower
layer protocols. E.g., applications should make minimal assumptions
about routing stability, just as they should make minimal assumptions
McPherson, Oran Section 3.1. [Page 9]
INTERNET-DRAFT Expires: April 2012 October 2011
about congestion and packet loss. When designing applications, it
would perhaps be safe to assume that the routing system may deliver
each packet to a different service instance, in any pattern, with
temporal re-ordering being a not-so-rare phenomenon.
Stateful transport protocols (e.g., TCP), without modification, do
not understand the properties of anycast and hence will fail
probabilistically, but possibly catastrophically, when using anycast
addresses in the presence of "normal" routing dynamics.
Specifically, if datagrams associated with a given active transaction
are routed to a new anycasted end system and that end system lacks
state data associated with the active transaction, the session will
be reset need to be reinitiated.
3.2. Anycast Addresses as Destinations
Anycast addresses are "safe" to use as destination addresses for an
application if:
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
multi-packet 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.
3.3. Anycast Addresses as Sources
Anycast addresses are "safe" to use as source addresses for an
McPherson, Oran Section 3.3. [Page 10]
INTERNET-DRAFT Expires: April 2012 October 2011
application if:
o No reflexive (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) [RFC 4778] checking is
on, or the service address is explicitly provisioned to bypass
RPF checks. In addition to the application defined in [RFC 4778],
Section 4.4.5 of [BCP 126] 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 multi-packet 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.
Section 3.3 of Informational [RFC 4339] proposes 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". 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
McPherson, Oran Section 3.4. [Page 11]
INTERNET-DRAFT Expires: April 2012 October 2011
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."
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 [RFC 1546], specifically:
"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
McPherson, Oran Section 4.2. [Page 12]
INTERNET-DRAFT Expires: April 2012 October 2011
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."
Multi-address transports (e.g., SCTP) might be more amenable to such
extensions than TCP.
Some similarities exist between what is needed for anycast and what
is needed for address discovery when doing multi-homing in the
transport layer.
4.3. Stateful Firewalls, Middleboxes and Anycast
Middleboxes (e.g., NATs) and stateful firewalls may cause problems
when used in conjunction with 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 the "Service
Discovery" section.
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 [RFC 4085] anycast was used in a
distributed sinkhole model [RFC 3882] to mitigate the effects of
embedded globally-routed Internet addresses in network elements.
"Internet Denial-of-Service Considerations" [RFC 4732] 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" [RFC 4786] 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).
McPherson, Oran Section 4.4. [Page 13]
INTERNET-DRAFT Expires: April 2012 October 2011
It should be noted that there is a significant man in the middle
(MITM) exposure in either variant of anycast discovery (see Section
12: "Service Discovery") that in many applications may necessitate
the need for end to end security models [RFC 2402] [RFC 2406] that
enable end systems to authenticate one another.
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 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, [RFC 6382] makes recommendations regarding
the use of per-node unique origin ASNs for globally anycasted
critical infrastructure services in order to provide routing system
discriminators for a given anycasted prefix. Network management and
monitoring techniques, or other operational mechanisms may then
employ this new discriminator in whatever manner fits their operating
environment, either for detection or policy associated with a given
anycasted node.
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 one allows unauthorized anycast nodes onto the network,
traffic can be diverted thereby triggering DoS or other attacks.
Section 6.3 of [BCP 126] provides expanded discussion on "Service
Hijacking" and "traffic stealing".
Unlike unicast (but like multicast), the desire is to allow
applications to cause route injection (either directly or as a side
effect of doing something else). This combination is unique to
anycast and presents new security concerns which are 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.
McPherson, Oran Section 4.4. [Page 14]
INTERNET-DRAFT Expires: April 2012 October 2011
These are two of the core issues that were part of the discussion
during [RFC 1884], the [ANYCAST BOF], and the [MAGMA] chartering.
Additional security considerations are scattered throughout the list
of references provided herein.
4.5. Deployment Considerations
[BCP 126] provides some very solid guidance related to operations of
anycasted services, and in particular DNS.
This document covers issues associated with the architectural
implications of anycast. This document does not treat in any depth
the fact that there are deployed services with TCP transport using
anycast today. While we believe that such practice is not "safe" in
the traditional and architectural sense, these things are indeed
relative, and we recognize it is not always the case that
unpredictability in the routing system beyond the local
administrative domain is unmanageable. 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 exist situations where
it may makes sense (e.g., such as with services discovery, short-
lived transactions, or generally where a service is provided via an
anycasted address in order to minimize client or subscriber
configuration variances and topologically localize which servers may
be contacted by a given client). 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.
5. IANA Considerations
No IANA actions are required.
6. Conclusions
In summary, operators and application vendors alike should consider
the benefits and implications of anycast in their specific
McPherson, Oran Section 6. [Page 15]
INTERNET-DRAFT Expires: April 2012 October 2011
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.
McPherson, Oran Section 6. [Page 16]
INTERNET-DRAFT Expires: April 2012 October 2011
7. Acknowledgments
Many thanks to Dave Thaler and Kurtis Lindqvist for their 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 for his detailed review.
McPherson, Oran Section 7. [Page 17]
INTERNET-DRAFT Expires: April 2012 October 2011
8. References
8.1. Normative References
8.2. Informative References
[ANYCAST BOF] Deering, S., "IAB Anycast BOF Announcement", October
1999,
http://www.ietf.org/mail-archive/web/ietf/current/msg11182.html
[BCP 126] Abley, J., Lindqvist, K., "Operation of Anycast
Services", BCP 126 (RFC 4786), December 2006.
[IMR 9401] "INTERNET MONTHLY REPORT", January 1994,
http://mirror.facebook.com/rfc/museum/imr/imr9401.txt
[MAGMA] Multicast and Anycast Group Membership (MAGMA), concluded
IETF
Working Group, April 2006, http://www.ietf.org/wg/concluded/magma.
[RSSAC 29] "RSSAC 29 Meeting Minutes", December 2, 2007,
http://www.rssac.org/meetings/04-08/rssac29.pdf
[RFC 1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION
AND SPECIFICATION", RFC 1035, November 1987.
[RFC 1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC
1305, March 1992.
[RFC 1546] Partridge, C., Mendez, T., Milliken, W., "Host
Anycasting Service", RFC 1546, November 1993.
[RFC 1884] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 1884, December 1995.
[RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP)
Version 4 for IPv4, IPv6 and OSI", RFC 2030,
October 1996.
McPherson, Oran Section 8.2. [Page 18]
INTERNET-DRAFT Expires: April 2012 October 2011
[RFC 2101] Carpenter, B., Crowcroft, J., Rekhter, Y., "IPv4
Address Behaviour Today", RFC 2101, February 1997.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC 2402] Kent, S., and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC 2406] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC 2526] Johnson, D., Deering, S., "Reserved IPv6 Subnet
Anycast Addresses", RFC 2526, March 1999.
[RFC 2893] Gilligan, R., Nordmark, E., "Transition Mechanisms
for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC 2902] Deering, S., Hares, S., Perkins, C., Perlman, R.,
"Overview of the 1998 IAB Routing Workshop", RFC
2902, August 2000.
[RFC 3056] Carpenter, B., "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001.
[RFC 3068] Huitema, C., "An Anycast Prefix for 6to4 Relay
Routers", RFC 3068, June 2001.
[RFC 3258] Hardie, R., "Distributing Authoritative Name Servers
via Shared Unicast Addresses", RFC 3258, April 2002.
[RFC 3513] Hinden, R., Deering, S., "Internet Protocol Version
6 (IPv6) Addressing Architecture", RFC 3513, April
2003.
[RFC 3775] Johnson, D., Perkins, C., Arkko, J., "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC 3882] Turk, D., "Configuring BGP to Block Denial-of-Service
Attacks", RFC 3882, September 2004.
[RFC 3964] Savola, P., "Security Considerations for 6to4", RFC
3964, December 2004.
[RFC 4085] Plonka, D., "Embedding Globally-Routable Internet
McPherson, Oran Section 8.2. [Page 19]
INTERNET-DRAFT Expires: April 2012 October 2011
Addresses Considered Harmful", RFC 4085, June 2005.
[RFC 4213] Normark, E., Gilligan, R., "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC 4291] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC 4330] Mills, D., "Simple Network Time Protocol (SNTP)
Version 4 for IPv4, IPv6 and OSI", RFC 4330,
January 2006.
[RFC 4339] Jeong, J., "IPv6 Host Configuration of DNS Server
Information Approaches", RFC 4339, February 2006.
[RFC 4610] Farinacci, D., Cai, Y., "Anycast-RP Using Protocol
Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC 4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of-
Service Considerations", RFC 4732, November 2006.
[RFC 4778] Kaeo, M., "Current Operational Security Practices in
Internet Service Provider Environments", RFC 4778,
January 2007.
[RFC 4861] Narten, T., et al., "Neighbor Discovery for IP version
6 (IPv6)", RFC 4861, September 2007.
[RFC 4892] Woolf, S., Conrad, D., "Requirements for a Mechanism
Identifying a Name Server Instance", RFC 4892, June
2007.
[RFC 4924] Aboba, B., Davies, E., " Reflections on Internet
Transparency", RFC 4924, July 2007.
[RFC 4942] Davies, E., Krishnan, S., Savola, P., "IPv6
Transition/Coexistence Security Considerations",
RFC 4942, September 2007.
[RFC 5001] Austein, R., "DNS Name Server Identifier (NSID)
Option", RFC 5001, August 2007.
[RFC 6382] McPherson, D., et al., "Unique Origin Autonomous
System Numbers (ASNs) per Node for Globally Anycasted
Services", RFC 6382, BCP 169, October 2011.
McPherson, Oran Section 8.2. [Page 20]
INTERNET-DRAFT Expires: April 2012 October 2011
9. Authors' Addresses
Danny McPherson
Verisign, Inc.
Email: dmcpherson@verisign.com
Dave Oran
Cisco Systems
Email: oran@cisco.com
10. Appendix A: IAB Members
Internet Architecture Board Members at the time this document was
published were:
[TO BE INSERTED]
Copyright Statement
Copyright (C) (2011) The 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, Oran Section 10. [Page 21]
