Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: July 2003 January 2003 Multihoming Using IPv6 Addressing Derived from AS Numbers draft-savola-multi6-asn-pi-00.txt Status of this Memo This document is an Internet-Draft and is subject to 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. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract In IPv6, the current IPv4 site multihoming practises have been operationally disabled, to prevent a creation of an unmanageable swamp of more specific routes. Some argue that the lack of a comprehensive site multihoming solution is hindering the deployment of IPv6. This memo presents a few proposals for end-sites with autonomous system (AS) number to be able to derive a provider independent block of addresses from the first half of the 16-bit AS- number space. This could enable a temporary IPv6 site multihoming solution for those that already employ similar mechanisms in IPv4. Savola [Expires July 2003] [Page 1] Internet Draft draft-savola-multi6-asn-pi-00.txt January 2003 Table of Contents 1. Introduction ............................................... 2 2. Engineering Decisions ...................................... 3 2.1. Discussion ............................................. 3 3. ASN-PI Addressing Format ................................... 4 3.1. Format ................................................. 4 3.2. Discussion ............................................. 5 3.3. Example ASN-PI Address Assignments ..................... 5 4. Operational Guidelines ..................................... 5 4.1. Discussion ............................................. 6 5. Requirements for Registries ................................ 6 6. IANA Considerations ........................................ 6 7. Security Considerations .................................... 6 8. Acknowledgements ........................................... 6 9. References ................................................. 7 9.1. Informative References ................................. 7 Author's Address ............................................... 7 A. Example of Prefix Length Filters ........................... 7 B. Alternative Approach with 32-bit AS Numbers ................ 7 1. Introduction A typical scenario of IPv4 site multihoming is where the site obtains an autonomous system number (ASN), and starts advertizing a block of addresses to the Internet. The addresses may be specifically obtained for this purpose, or more specific routes from an also advertised aggregate. This site multihoming scenario has been currently prevented in IPv6 by operational procedures [6BONEOP], as it has been feared to create an unmanageable address space swamp of more specific routes. However, currently multihoming IPv4 sites may be reluctant to start using IPv6 because no comprehensive IPv6 multihoming mechanism exists: the proposal would remove one excuse for not using IPv6. This memo proposes a few possible approaches which could be used to derive the IPv6 address space automatically from one's AS number. These could then be advertised by the end-site to gain a temporary solution for IPv6 multihoming. The proposed solution limits the number of multihomed sites to 2^15, that is, about 32K. In practise, this would be a lot less. Savola [Expires July 2003] [Page 2] Internet Draft draft-savola-multi6-asn-pi-00.txt January 2003 First, some background and design criteria are presented. Then, proposed different address formats are defined. Next, some operational guidelines are described. Last, requirements for current IP address registries are presented. In the appendix, a prefix filtering example and an alternative approach given. 2. Engineering Decisions When designing the solution, the following have, and will have to be, taken into consideration: 1. Sunset strategy 2. Limited time and impact on the global routing table size 3. Discourage a rush to obtain AS numbers to exhaust the 16-bit space 4. Possibility to easily distinguish ASN-PI and other addresses 5. Easy generation of provider independent addresses 6. Fixed prefix length, enabling easy prefix filtering 7. Incentives to use the addressing for this specific purpose only These lead to at least the following decisions: o Applicable to 16-bit AS numbers only, points 1-2 above o Applicable to AS numbers 1 - 32767 only, points 1-3 o Direct mapping from AS number to the address, points 4-5 o A selected prefix and length, points 4,6 above o Incentives (point 7) will be discussed in the next section. 2.1. Discussion When engineering a site multihoming solution, it is important to consider the scalability of such a solution. It is unprobable that sites (by most definitions of 'site'), in contrast to major ISP's, can each use different service providers and multihome by mechanisms that require a presence or changes in the global routing table. However, this is a relatively common practise today with IPv4, and it has been feared that unless a similar mechanism is offered, current IPv4 enterprises will be very reluctant to start using IPv6 because of the lack of a site multihoming solution. This memo offers a way to provide a similar, or actually better -- due to control -- site multihoming mechanism for those that already have the multihoming capability today. As the number of sites is so high, the maximal number of routes must be limited somehow. For this, the first half of 16-bit AS numbers was selected. This provides the possibility of site multihoming for Savola [Expires July 2003] [Page 3] Internet Draft draft-savola-multi6-asn-pi-00.txt January 2003 all current (at the time of the writing) AS number holders, while avoiding a major rush and exhaustion of the rest of the 16-bit AS number space when new sites would also wish to obtain a way to multihome. 32-bit AS numbers [ASN4BYTE] are explicitly out of scope, as those would create an even worse scaling problem. It seems unnecessary, except for creating administrative hurdles, to encumber RIR's with address allocation for this site-multihoming solution: therefore, an approach where addresses can be derived from a well-known prefix by combining it with one's AS number, creating provider independent addresses was chosen. It is anticipated that this mechanism will be withdrawn when a better, scalable site multihoming solution is developed. Therefore these addresses should not be considered permanent, but rather temporary until other mechanisms can be specified. 3. ASN-PI Addressing Format 3.1. Format The proposed addressing format is as follows: | 16 bits | n | 16 | 96-n bits | +----------+--------+-------+---------------------+ | PRFX | ID | ASN | site-specific parts | +----------+--------+-------+---------------------+ ASN is the AS number in hexadecimal format. PRFX and ID are selected and allocated as discussed below. There are multiple options for the "n" which have different consequences: 1. n = 0: total prefix length is 32 bits long, the same as current (at the time of writing) standard registry allocations 2. n = 16: total prefix length is 48 bits long, the same as the recommended prefix length for end-sites [SITELEN] 3. 0 < n < 16: some value, e.g. n=8, which would allow for sites with longer prefixes In the final version, only one will be selected. Savola [Expires July 2003] [Page 4] Internet Draft draft-savola-multi6-asn-pi-00.txt January 2003 3.2. Discussion n=0 seems to fail criteria point 7, above: end-sites should not need that much address space. n=16 seems like a natural first choice, but there may be sites which need more than a /48. Something between, say n=8, seems like a viable alternative: enough to cater for all cases, but not too many to be useful and to be distinguishable. In all cases, currently installed prefix-length filters are likely to have to be modified -- getting new ones deployed will take some time, but the delay should be quite reasonable. In the case of n=0, a possible allocation could be 2000::/16. In the case of n=16, possible allocations could be, for example, 2001:0::/32 or 2001:FFFF::/32. In the case of 0