Multi6 K. Toyama
Internet-Draft T. Fujisaki
Expires: 9 Aug 2004 NTT
9 Feb 2004
Operational Approach to achieve IPv6 multihomed network
draft-toyama-multi6-operational-site-multihoming-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 9, 2004.
Copyright Notice Copyright (C) The Internet Society (date). All Rights
Reserved.
Abstract
This document proposes an operational solution of IPv6 mulithoming.
This approach is that a group of providers administrates
cooperatively one prefix and one autonomous system number (ASN) for
only their multihoming customers; each multihomed customer is
assigned a longer prefix, such as /48, but only address block of /32
allocated by RIR is advertised through the providers of the group to
the global IPv6 Internet.
This approach does not need allocation of provider-independent
address block to each customer who needs multihomed network, and
therefore saves IPv6 address space.
K. Toyama, et al. Expires August 9, 2004 [Page 1]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
It is not the solution to all the issues of multihoming, but large
portion of customers who needs multihomed network can achieve their
goal by this method.
1. Introduction
Site multihoming in IPv6 becomes more difficult than that in IPv4 due
to the current rules about the allocation and assignment of IPv6
address block and about the global routing policy, which allows
providers to advertise only aggregated address block.
This document describes an operational approach to site multihoming
issue in IPv6. This approach solves the issue by compromising the
current rules about global routing policy, and by permitting to
allocate an address block and an ASN to a group of providers. It
requires the providers of the group to add some configuration to
routers, but does not deploy any new technologies to the networks and
hosts of customers. In other words, it solves the multihoming issue
only using the current routing technologies.
This approach is briefly described as follows: a group of providers
administrates cooperatively one prefix and one ASN for only thier
multihoming customers; each customer is assigned a longer prefix,
such as /48, based on the current assignment rule, but to the global
Internet only the address block /32 is advertised through the
providers of the group.
2. Operational Solution
2.1 Prerequisites
Two providers form a group to provide IPv6 multihoming service
cooperatively. Each provider of the group has their own IPv6 address
block of /32 and ASN. There must exist a peer between the providers.
For example, there are two providers called ISP-a and ISP-b. Their
prefixes are "PA::/32" and "PB::/32", respectively. Also their ASNs
are ASN-a and ASN-b respectively.
There are some customers who need multihomed network.
2.1.1 RIRs
This approach requires RIR to allocate one IPv6 address block whose
prefix length is /32 (minimum allocated size [ADDR]) and one ASN to
K. Toyama, et al. Expires August 9, 2004 [Page 2]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
the group, for the purpose of multihoming.
For example, a RIR allocates to a group of provider ISP-a and ISP-b,
an IPv6 address block "MH::/32" and ASN "ASN-m."
2.1.2 Customers
The customers who need multihoming from the providers of the group
are assigned an address block of /48 from the address block of /32
which has been allocated to the provider group by RIR. Also the
customers are allowed to use the ASN assigned to the provider group.
This address block and ASN is maintained cooperatively by the group,
and parts of the address block are assigned to customers according to
the rules that the providers of the group have agreed with each
other.
For example, there are two multihoming customers, MC-1 and MC-2, and
the assigned address block is "MH:1::/48" and "MH:2::/48"
respectively, and both customers are assigned "ASN-m."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Global IPv6 Internet
________________________________________
^ <MH::/32> ^ <MH::/32>
|<ASN-a ASN-m>|<ASN-b ASN-m>
| |
| |
+---+--++ +---+---+
| ISP-a +#####+ ISP-b + ### peers, where
+---+-+-+ +-+-+---+ <MH:1::/48>
| /---/ | <MH:2::/48>
| --/--- | are exchanged
| / |
| / |
+--+--++ +-+-+--+
| MC-1 | | MC-2 |
+------+ +------+
<MH:1::/48> <MH:2::/48>
<<ASN-m>> <<ASN-m>>
A multihoming customer connects both providers of the group and
advertises the assigned prefix to them with the ASN as its origin.
For example, the Customer MC-1 advertises "MH:1::/48" with its origin
K. Toyama, et al. Expires August 9, 2004 [Page 3]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
"ASN-m."
The customers are prohibited from using this ASN to connect to a
provider which does not belong to the group.
2.1.3 Providers
A provider of the group advertises full routes via BGP to multihoming
customers. In some case the provider may announce a default route to
them.
As described above, the providers of the group must have peers with
each other. Through these peers, they must exchange the more-
specific prefixes assigned to the multihoming customers.
Also, they must advertise only the allocated address block of /32 to
the global Internet.
2.2 Routing and Redundancy
From the global Internet side, multihomed customers can be seen
beyond the group of providers, ASN-a or ASN-b. In case that one of
the two providers is alive and annouces the prefix MH::/32 with ASN-m
as its origin for multihomed customers, these customers can be
reached from the Internet.
When the packets destined to the multihomed customers have reached
ASN-a or ASN-b, they can be delivered to the correct destination
because these providers know the routes to each multihomed customers.
2.3 Extensibility
Provider A can belong to two different groups, although each group
has its own address block and ASN. Therefore, a provider which joins
many groups should maintain neatly different multihoming address
blocks and ASNs.
For example, provider A can share the prefix MHx::/32 and ASN-mx with
provider B, and it can also share another prefix MHy::/32 and ASN-my
with provider C.
2.4 Ease of deployment
This approach is based on the existing routing technologies, and no
K. Toyama, et al. Expires August 9, 2004 [Page 4]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
new technologies are introduced. We propose here to change the rule
that prohibits to advertise more specific routes to the global IPv6
Internet. The rule should be that more specific routes can be
exchanged between two providers which trust each other or have
contract about multihoming service. Therefore, it could be easy to
deploy this multihoming method.
3. Resouce exhausting Issue
In this approach, address blocks and ASN will be allocated more than
now. Although some think it leads to exhaustion of such resources, we
do not expect they are extremely consumed.
If a group of providers can have many multihoming customers, they
require only one address block of /32 instead of allocating a
provider- independent address block of /32 to each cutomer. This
reduces the consumed resouces significantly.
Also, the number of provider groups will not be expanded. The
providers of a group should trust each other with regard to routing
operations. Mistakes on configuration or operation of a provider may
impact on communication of customers of the other provider.
Furthermore, business relationship between providers is one of the
important factors to form a group. They hesitate to cooperate with a
untrusted provider.
These factors, therefore, will suppress the explosion of the number
of groups, which means not so many address blocks and ASNs will be
allocated for the multihoming purpose.
And it could be less if RIRs define the prerequisites for allocating
the resouces to a group of providers, such that a group should have
200 multihomed customers in two years.
4. Evaluation of Multihoming Goals
This section describes the analysis of this solution for IPv6 Site-
Multihoming Architectures [GOALS].
4.1 Capabilities
4.1.1 Redundancy
Redundancy is provided by advertisement of a single prefix over
multiple providers.
K. Toyama, et al. Expires August 9, 2004 [Page 5]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
4.1.2 Load Sharing
Load-sharing of outgoing traffic can be done trivially. Also, load-
sharing incoming traffic is supported to some degree, just as the
existing routing control.
4.1.3 Performance
Performance is the same.
4.1.4 Policy
Using the same prefix allows for policy decisions.
4.1.5 Simplicity
This approach is simple for those deploying it.
4.1.6 Transport-Layer Survivability
Transport-layer survives any re-homing events.
4.1.7 Impact on DNS
There is no impact.
4.1.8 Packet Filtering
Ingress filtering can be deployed.
4.2 Additional Requirements
4.2.1 Scalability
The solution is scalable, when not so many groups of providers are
formed. This can be avoid by restricting address allocation scheme
for multihomed network; for example, they must have 100 multihoming
customers in a year or two.
4.2.2 Impact on Routers
No changes are required.
4.2.3 Impact on Hosts
No changes are required.
K. Toyama, et al. Expires August 9, 2004 [Page 6]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
4.2.4 Interaction between Hosts and the Routing System
There need not be interaction.
4.2.5 Operations and Management
The operators and managers of the providers are able to configure the
multihoming parameters for their network.
4.2.6 Cooperation between Transit Providers
Cooperation is required between the group of providers, but it is not
so difficult because it is normally done.
4.2.7 Multiple solutions
Multiple solutions are required. This only intends to address the
case that the group of providers will be able to have tens or
hundreds of multihoming customers.
5. Evaluation of Things to Think About
A questionaire [QUES] has been published which tries to tease out the
issues which surround different solution proposals. This section
gives the answers.
5.1 How will your solution solve the multihoming problem?
It solves only a part of the problem: for small to large enterprise.
Two providers share a /32 allocation and an AS number, and assign
more specific address block to the multihomed customers whose network
is connected to both providers. The two providers advertise only a
/32 allocation to the global IPv6 Internet, whereas they exchange
more-specific prefixes such as /48 only in their networks.
5.2 Does your solution address mobility?
Mobility is not affected.
5.3 Identifiers and locators
This method does not change the address architecture.
5.4 On the Wire
There are no change on this item.
5.5 Relationship with DNS and Registries
K. Toyama, et al. Expires August 9, 2004 [Page 7]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
There is no change to the relationship with DNS.
RIRs have to consider the definition of route6 and as-num object in
their registry. Because this method allows that a prefix and an AS
number is "owned" by two providers,
5.6 Compatibility
This method is compatible with IPv6 architecture, also totally
compatible with current API.
5.7 Legal stuff
There is no legal stuff in this approach.
Security Considerations
This memo discusses the address allocation and AS number assignment,
how to assign them to multihoming customers, and how to advertise the
routes. It does not have security considerations.
7. References
[GOALS] Abley, J., et al., "Goals for IPv6 Site-Multihoming
Architectures", RFC3582, August 2003.
[ADDR] "IPv6 Address Allocation and Assignment Policy June, 26
2002" ,
http://ftp.apnic.net/apnic/docs/ipv6-address-policy
Author's Address
Katsuyasu Toyama
Nippon Telegraph and telephone Corporation
Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musasihno-shi, Tokyo 180-8585 Japan
Phone: +81-422-59-7906
E-Mail: toyama.katsuyasu@lab.ntt.co.jp
Tomohiro Fujisaki
Nippon Telegraph and telephone Corporation
Information Sharing Platform Laboratories
3-9-11 Midori-cho
K. Toyama, et al. Expires August 9, 2004 [Page 8]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
Musasihno-shi, Tokyo 180-8585 Japan
Phone: +81-422-59-7351
E-Mail: fujisaki.tomohiro@lab.ntt.co.jp
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
K. Toyama, et al. Expires August 9, 2004 [Page 9]
Internet-Drafts Operational Site Multihoming 9 Feb 2004
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
K. Toyama, et al. Expires August 9, 2004 [Page 10]