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 ________________________________________ ^ ^ || | | | | +---+--++ +---+---+ | ISP-a +#####+ ISP-b + ### peers, where +---+-+-+ +-+-+---+ | /---/ | | --/--- | are exchanged | / | | / | +--+--++ +-+-+--+ | MC-1 | | MC-2 | +------+ +------+ <> <> 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]