Internet DRAFT - draft-ata-anycast-deploy-scenario
draft-ata-anycast-deploy-scenario
IP Version 6 Working Group S. Ata
Internet-Draft Osaka City University
Expires: April 25, 2005 H. Kitamura
NEC Corporation
M. Murata
Osaka University
October 25, 2004
Possible Deployment Scenarios for IPv6 Anycasting
draft-ata-anycast-deploy-scenario-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Today, the use of anycasting is quite limited. In this document we
list possible deployment scenarios in IPv6 anycasting. We consider
three conditions based on the region of anycasting, and list possible
Ata, et al. Expires April 25, 2005 [Page 1]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
scenarios. For each scenario we also clarify example applications as
well as technical issues to be resolved.
1. Introduction
Anycast is service-based addressing architecture, which is promising
for providing new services. However, currently the use of anycasting
is quite limited. One of a main reason is because the use only of the
anycast is not so clear. Another reason is because there are many
technical issues to be resolved in the current definitions of IPv6
anycast. Most of problems are stated in [ANALYSIS].
In this document we list possible deployment scenarios in IPv6
anycasting. We classify three groups according to the applicable
region of anycasting (intra-segment, intra-domain, inter-domain). We
also focus on the necessity of current protocol changes and/or
introducing new protocols/definitions. For each scenario, we clarify
(1) example of possible applications, (2) addressing, (3)
reachability of packets, (4) required functionalities, and (5)
requirements of existing protocol changes.
The objective of this document is to list all considerable cases of
anycast deployment, but concluding what scenario is best is out of
scope.
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119]. Other
terms in this document are defined in [ANYTERM].
2. Background Technologies
2.1 Limitation of IPv6 Anycast
As noted in [ANALYSIS], the main limitations of IPv6 anycast are
1. Only the router node can notify the routing information, thus the
anycast address cannot be assigned to the host node.
2. The anycast address is assigned from the unicast addressing space,
so the anycast address is syntactically indistinguishable from the
unicast address.
3. From the second limitation, the anycast address cannot be set as
the source address of the packet because the anycast initiator
cannot identify packets from different anycast receivers if they
send packets by setting the anycast address as the source.
Ata, et al. Expires April 25, 2005 [Page 2]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
2.2 Shared Unicast
Shared unicast is a similar practice to anycast, in which multiple
nodes can have the same unicast address. The packet destinied to the
shared unicast address is delivered one of those nodes based on the
distance from the source node. But there are several differences
between anycast and shared unicast [ANALYSIS]. We only focus on IPv6
anycasting and the deployment scenarios on shared unicast are not
scope of this document. However, some scenarios in this document can
be applied to shared unicast, and some shared unicast practices are
also useful to consider the deployment scenario on anycasting.
2.3 Discovery of Anycast Members
IPv6 addressing architecture [RFC 2731] prohibits from assigning the
anycast address to the host node until the use of anycast address
becomes safe (in terms of security) and some avoiding mechanism
against illegal use of anycasting arise.
The problem of secure group management are stated in some research
groups (e.g., IRTF Group Security (GSEC) Research Group). But they
are still in discussion. Current possible techniques are:
1. use the extension of MLD (multicast listener discovery) [MLDEXT]
2. establish a virtual p-to-p tunnel from the anycast receiver to the
router with authorization
3. configure (authorize) the router to receive the anycast routing
information from anycast receivers
2.4 Virtual Path
In most cases it is not directly connected between the anycast
receiver and the anycast router (and between two anycast routers). In
this case a virtual path should be established between two anycast
nodes.
2.5 Scope
If we consider a global use of anycasting, the scaling problem of
routing table will be arisen. The router must have "host route" for
the anycast address when multiple anycast receivers are on different
segments which have different unicast prefixes. According to the
increase of the number of anycast address, the explosion of the size
of routing table will lead a serious performance degradation of
routers.
Furthermore, even if there are many anycast receivers, it is rare
that all of receivers will be "appropriate" for each anycast
Ata, et al. Expires April 25, 2005 [Page 3]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
initiator, i.e., for each initiator some of receivers may be
appropriate, but others are not needed. Many of routing entries for
the anycast address are thus not frequently utilized.
In both scalability and usability, most of anycast entries must be
restricted for advertising arbitrary routers. Introducing "scope"
will be preferable to limit the range of propagation of anycast
routing entries.
3. Intra-Segment Anycasting
3.1 Local Served Anycast Receivers
In this scenario the anycast receiver is on the same segment of the
anycast initiator. Fig. 1 shows an example.
+----+
+--| AI |
| +----+
+--------+ |
(WAN)--| Router |--+
+--------+ |
| +----+
+--| AR |
+----+
Fig. 1 Local served anycast receiver
The anycast receiver AR only configures the anycast address AA in
addition to the unicast address. No route information is notified to
Router. The anycast initiator AI discovers the anycast receiver AR by
performing lower layer's address resolving protocols (e.g., Neighbor
Discovery).
* Possible applications:
primitive service discovery (DNS, proxy, SMTP, etc.)
* Addressing:
The anycast receiver MUST assign the ancyast address from:
1. unused space of the subnet prefix which the corresponding
unicast address belongs to.
2. predefined well-known link-local anycast address.
* Packet reachability:
The anycast packet is always delivered when the anycast receiver
Ata, et al. Expires April 25, 2005 [Page 4]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
exists in the same segment.
* Requirements:
1. Nodes SHOULD NOT use the anycast address outside of the
segment.
2. No special routing protocols for the anycast address is NOT
required.
* Requirements of protocol changes:
none
3.2 Multiple Anycast Receivers within the Same Segment
This is one of the simplest scenario. All anycast receivers are on
the segment. The prefix address of the anycast address is the same as
the one of the corresponding unicast address. Fig. 2 shows an example
of this scenario. In this figure there are three anycast receivers
(AR1, AR2, AR3). All anycast receivers have the same anycast address
AA. AA is assigned from the available space of the subnet which
anycast receivers are belonging to.
+-----+
+--| AR1 |
| +-----+
+----+ +--------+ | +-----+
| AI |----- (WAN) -----| Router |--+--| AR2 |
+----+ +--------+ | +-----+
| +-----+
+--| AR3 |
+-----+
Fig. 2 All anycast receivers are on the same segment
The packet destinied to the anycast address AA is forwarded to the
last hop router based on the unicast routing by the subnet prefix of
AA. After arriving at the last hop router, the destination receiver
is determined by the last hop router. The selection of the final
destination is performed by e.g., Neighbor Discovery [RFC 2461].
* Possible applications:
clustering servers, load balancing, replicated servers to improve
reliabilitiy
* Addressing:
The anycast receiver MUST assign the ancyast address from unused
Ata, et al. Expires April 25, 2005 [Page 5]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
space of the subnet prefix which the corresponding unicast address
belongs to.
* Packet reachability:
The anycast packet can be delivered when the anycast receiver
exists in the segment. However, when the selected anycast receiver
falls down, packets will not be delivered until the last hop
router updates its learned information (e.g., Neighbor Cache).
* Requirements:
1. Set the same anycast address only to anycast receivers on the
same segment. Anycast receivers on the different segments MUST
be set the different anycast addresses.
2. No special routing protocols for the anycast address is NOT
required.
3. Configuring the learning time (aging time) on the last hop
router could improve the adaptability of load balancing.
* Requirements of protocol changes:
none
4. Scoped Anycasting
The use of inter-segment anycasting has a scaling problem, in which
the routing of anycast packet requires routers to add a host entry
(e.g., /128 prefix entry) for each anycast membership. To overcome
the scale problem, the advertisement of anycast routing information
is highly restricted. There are some approaches to limit the
advertisement. First is to allow the exchange of anycast routing
information only within the controlled domain (e.g., AS). Second is
to tell the routing information only the neighbor domains. We
consider above both cases separately.
4.1 Inter-Domain Anycasting
In the controlled area (e.g., domain) the influence of adding host
entry for the anycast is limited within the controlled region. Thus
the administrative operator can use anycasting to receive benefits of
anycasting. The simple way to support anycasting to add a host entry
of anycast receiver manually (i.e., the selection of anycast
receivers is performed by the statical configures) by using exting
unicast intra-domain routing protocols (e.g., OSPF). However, in such
a static approach, the blackout time of switching to an alternative
receiver would be long if the active receiver fails. To improve the
service reliability, the selection of anycast receivers would be
Ata, et al. Expires April 25, 2005 [Page 6]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
performed dynamically. The current IPv6 definition [RFC 2373],
however, prohibits host nodes from advertising their route
information to routers. Fig. 3 shows the example of intra-domain
anycasting.
+----------------------Intra-domain region--+
| |
| <===== +----+ |
| +------------| AR | |
| | +----+ |
| | |
| +---+----+ +----+ |
(WAN) --------------| Router |-------------| AR | |
No anycast route | +---+----+ <===== +----+ |
will be notified | | Advertise anycast route |
outside of domain | | +----+ by unicast IGP |
| +------------| AR | |
| <===== +----+ |
+-------------------------------------------+
Fig. 3 Intra-domain Anycasting
* Possible applications:
load balancing, alternative servers for reliabilitiy, service
discovery
* Addressing:
The anycast receiver SHOULD assign the anycast address from any
arbitrary of unused space. However, assigning from the segment-
independent subnet space would be better.
* Packet reachability:
The anycast packet can be delivered when the anycast receiver
exists in the domain. However, when the selected anycast receiver
falls down, packets will not be delivered until the router update
related routing entries.
* Requirements:
1. Routers MUST NOT advertise entries of anycast receivers to
outside of the domain.
2. Routing entry of anycast receivers should be added manually or
dynamically.
3. If manually, the administrative operator configures all of
routing entries of anycast receivers.
Ata, et al. Expires April 25, 2005 [Page 7]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
4. If dynamically, the anycast receiver MUST advertise its host-
based routing entry by running routing daemons. However, this
item requires a modification of current IPv6 definition.
5. Unicast-based routing protocols (IGPs) can be utilized for
exchanging anycast entries.
* Requirements of protocol changes:
To update the routing entry of anycast receiver dymanically, we
MUST change the definition of IPv6 anycast to enable anycast host
nodes to advertise the routing information.
4.2 Regional Anycasting
The second way to limit the propagation of anycast routing
information is to set the scope (e.g., hoplimit) to routing messages.
For example, when we set the hop limit of anycast routing messages to
one, anycast routing information is advertised only the neighbor
domains directly connected to the domain which the anycast receiver
belong to. Fig. 4 shows the example to limit the region of
anycasting.
In this figure, we set the hop limit of anycst routing messages as
the scope of the corresponding anycast address. Anycast receiver AR1
is on the domain AS1, and notify the route for the anycast address to
the edge router of AS1. The edge router of AS1 then sends the routing
entry for the anycast address to neighbor domains AS2, AS3, and AS4.
However, because the hop limit of the routing message is one, the
message is not delivered to domains AS5 and AS6, which are out of
scope of the anycast address.
+-Anycast Routing Region Limited by Scope---+
| |
| EGP (hop limit 1) |
| ===> +-----+ |
| +------------| AS2 | |
| | +-----+ | Not delivered
| | EGP (hop limit 1) | outside scope
| +-- AS 1 ---+---+ ===> +-----+ | +-----+
| | +-------------| AS3 |-------X----| AS5 |
| | Intra-domain | +-----+ | +-----+
| | +----+ | |
| | | AR | | ===> +-----+ | +-----+
| | +----+ +------| AS4 |-------------X--| AS6 |
| +---------------+ +-----+ | +-----+
+-------------------------------------------+
Ata, et al. Expires April 25, 2005 [Page 8]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
Fig. 4 Regional Anycasting
Most characteristics on the regional anycasting are the same as ones
on intra-domain anycasting.
* Possible applications:
providing regional services (e.g., proxy), location dependent
mirror servers (e.g., based on countries)
* Addressing:
The anycast receiver SHOULD assign the anycast address from any
arbitrary of unused space.
* Packet reachability:
The anycast packet can be delivered when the anycast receiver
exists in the domain. However, when the selected anycast receiver
falls down, packets will not be delivered until the router update
related routing entries.
* Requirements:
1. Routing messages for the anycast address MUST include the scope
of the anycast address.
2. Routers MUST NOT advertise entries of anycast receivers to
outside the scope.
3. Routing entry of anycast receivers should be added manually or
dynamically.
4. If manually, the administrative operator configures all of
routing entries of anycast receivers.
5. If dynamically, the anycast receiver MUST advertise its host-
based routing entry by running routing daemons. However, this
item requires a modification of current IPv6 definition.
6. Unicast-based routing protocols (IGPs) can be utilized for
exchanging anycast entries.
* Requirements of protocol changes:
Same as intra-domain anycasting. To update the routing entry of
anycast receiver dymanically, we MUST change the definition of
IPv6 anycast to enable anycast host nodes to advertise the routing
information.
5. Inter-domain Anycasting
Due to the scale problem, the existing unicast routers are not
Ata, et al. Expires April 25, 2005 [Page 9]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
suitable for forwarding anycast packets in case of inter-domain
anycast routing. It is preferable to deploy a special node which
handles anycast packets based on anycast routing. For deploying
anycast routers, we consider three cases based on the number of
anycast routers. Note that this section is also an example of
transition scenario for supporting anycast.
5.1 Single Anycast Router
Anycast seed [ANYTERM] is one of solution for supporting global
anycasting without modification of existing network framework.
Anycast seed is a primary node of the anycast membership. Anycast
members have the anycast address, which is also the unicast address
of the anycast seed. Without any settings, all packets destinied to
the anycast address are once forwarded to the anycast seed by the
unicast routing. After that, the anycast seed then redirect the
"appropriate" anycast receiver via the virtual path between anycast
seed and anycast receiver. As a result, the anycast seed acts as the
anycast router for the anycast address. Fig. 5 shows the example of
anycast seed.
+-----+ Anycast
Unicast ........| AR1 | Address = AA
Addres = AA : +-----+
+----+ +------+ +-----+ Anycast
| AI |----- (WAN) -----| Seed |............| AR2 | Address = AA
+----+ +------+ +-----+
: +-----+ Anycast
:.......| AR3 | Address = AA
+-----+
Fig. 5 Anycast Seed (... : virtual path)
In this figure, there are four member nodes for the anycast address
AA. AA is also the unicast address of Seed. Seed and other members
(AR1, AR2, AR3) are connected virtually (e.g., tunnels). All packets
to the anycast address AA are once sent to Seed node. After receiving
the anycast packet, Seed then decides the appropriate node for the
anycast packet and sent to it through the virtual path.
* Possible applications:
mirroring service, load distribution
* Addressing:
The anycast receiver MUST assign the unicast address of anycast
seed as the anycast address.
Ata, et al. Expires April 25, 2005 [Page 10]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
* Packet reachability:
Whenever the anycast seed is alive, the anycast packet is always
delivered at least to the anycast seed. Otherwise (i.e., the
anycast seed is not available), no packet is delivered even if
other receivers are alive.
* Requirements:
1. Anycast seed MUST have a capability to forward the anycast
packet.
2. Anycast seed SHOULD have a knowledge about the condition of
anycast receivers, and SHOULD have a procedure to select the
appropriate receiver for the anycast packet.
3. Other anycast receiver MUST accept to establish the virtual
path from the anycast seed.
* Requirements of protocol changes:
none
5.2 Multiple Seeds
Anycast seed is a kind of anycast router. When the number of anycast
packets increases, the ancyast seed will become a bottleneck. To
reduce the load of the anycast seed, it is effective to deploy
multiple seeds on the network.
+-----+
........| AR1 |
: +-----+
+-----+ +----+ +-----+
| AI1 |-- (WAN) --| S1 |............| AR2 |
+-----+ +----+ +-----+
+-----+ ::
| AI2 | :::::
+-----+ ::
| +----+ +-----+
+- (WAN) -| S2 |............| AR3 |
+----+ +-----+
Fig. 6 Multiple Seeds (... : virtual path)
Fig. 6 shows the example of multiple seeds. There are two anycast
seeds and three anycast receivers. All of anycast nodes have the same
address AA. The deployment of seeds S1 and S2 is the same as regional
anycasting (See 4.2 for details). All seeds and anycast receivers are
Ata, et al. Expires April 25, 2005 [Page 11]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
connected virtually eath other. In this figure, S1, S2 is a nearest
receiver for AI1, AI2, respectively. When S1 and S2 receive anycast
packets, they forward an approprite receiver selected from all
receivers. By increasing the number of seeds, the load of seed nodes
become degraded.
* Possible applications:
Same as single seed case.
* Addressing:
Same as regional anycasting case.
* Packet reachability:
Same as regional anycasting case. However, if the anycast seed is
not available, no packet is delivered even if other receivers are
alive.
* Requirements:
Requirements of both regional anycasting and single seed cases are
needed.
* Requirements of protocol changes:
Same as regional anycasting case.
5.3 Generalized Anycast Routers
Anycast seed is a specialized anycast router for the single anycast
address. By assigning multiple anycast address into a single anycast
seed node, the anycast seed can support multiple anycast addresses.
As a result, the anycast seed would become a generic anycast router.
The architecture of this scenario is the same as the multiple seeds
case except supporting the multiple anycast addresses. Howver, the
criteria of appropriate node selection may differ between different
anycast addresses. A generic anycast-based routing protocol is needed
to handle multiple node selection criterias.
6. Security Considerations
Anycasting potentially has some technical statements about security
shown in [ANALYSIS].
Ata, et al. Expires April 25, 2005 [Page 12]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
7. References
7.1 Normative References
[ANYTERM] Doi, S., Kahlil, I., Ata, S., Kitamura, H., Murata, M.,
"Anycast Terminology/Functionality Definition," Internet draft,
draft-doi-ipv6-anycast-func-term-01.txt, February 2004, work in
progress.
[ANALYSIS] Hagino, J., and Ettikan, T., "An Analysis of IPv6
Anycast," Internet draft, draft-ietf-ipv6-anycast-
analysis-02.txt, November 2003, work in progress.
7.2 Informative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997.
[RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery
for IP Version 6 (IPv6)," RFC 2461, December 1998.
[RFC 2373] Hinden, R., and Deering, S., "IP Version 6 Addressing
Architecture," RFC2373, July 1998.
Authors' Addresses
Shingo Ata
Osaka City University
3-3-138, Sugimoto, Sumiyoshi-ku
Osaka, 558-8585
Japan
Phone: +81-6-6605-2191
Fax: +81-6-6690-5382
EMail: ata@info.eng.osaka-cu.ac.jp
Hiroshi Kitamura
NEC Corporation
(Igarashi Building 4F) 11-5, Shibaura 2-Chome
Minato-ku, Tokyo 108-8557
Japan
Phone: +81-3-5476-1071
Fax: +81-3-5476-1005
EMail: kitamura@da.jp.nec.com
Ata, et al. Expires April 25, 2005 [Page 13]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
Masayuki Murata
Osaka University
1-5 Yamadaoka, Suita
Suita-shi, Osaka 565-0871
Japan
Phone: +81-6-6879-4543
Fax: +81-6-6879-4544
EMail: murata@ist.osaka-u.ac.jp
Ata, et al. Expires April 25, 2005 [Page 14]
Internet-Draft Deployment Scenario of IPv6 Anycasting October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ata, et al. Expires April 25, 2005 [Page 15]
