One document matched: draft-savola-multi6-asn-pi-00.txt
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<n<16, a possible allocation with
n=8 could be 2001:FF00::/24.
3.3. Example ASN-PI Address Assignments
As examples, using possible example allocations above, the AS number
"1741" (0x6CD), would become:
n=0: 2000:6CD::/32
n=16: 2001:0:6CD::/48 or 2001:FFFF:6CD::/48
0<n<16, assume n=8: 2001:FF06:CD00::/40
4. Operational Guidelines
Every end-site with the AS-number in range 1-32767 may generate an
address prefix as desribed in this memo. Routability is not
guaranteed.
Networks which have received an address allocation must not use the
ASN-PI addressing as described in this memo; it is meant for a
specific set of end-sites only.
If the route of full prefix length is advertised with a protocol like
BGP [BGP], the origin AS of the route must always equal the embedded
AS number.
End-sites should advertise the maximum prefix length of the prefix,
even if the whole space would not be used, so that the advertisement
Savola [Expires July 2003] [Page 5]
Internet Draft draft-savola-multi6-asn-pi-00.txt January 2003
lengths would be uniform. This is especially the case with e.g. n=8.
An example of prefix-length filters is given in the appendix.
TBD.
4.1. Discussion
This mechanism is not meant to be used by those who have already
received address allocations, or those who would be eligible for
ones: it is not meant to substitute or augment address space
allocated from registries.
"Proxy-announcements" e.g. by someone's ISP are not allowed. If the
AS holder is incapable of advertising the addresses itself, they
should be assigned addresses conventionally. Also, someone else
hijacking unused addresses is also forbidden. Advertising a less
specific route (e.g. an aggregate of 2000::/16, using the example
above, from ISP to customers) is acceptable, though.
5. Requirements for Registries
The RIR's and other supporting registries for the AS number holder
should provide for basic IP address services, such as reverse IP
address delegations.
6. IANA Considerations
IANA will allocate and reserve an address prefix for this specific
purpose, pending selection of the alternative approaches.
Reverse IPv6 delegations will be configured to the RIR's where
respective AS number allocations have been made.
7. Security Considerations
This memo discusses address assignment based on AS numbers and
corresponding practises. It does not have security considerations.
8. Acknowledgements
Antti Jarvenpaa, Aki Anttila and Patrick Frejborg brought up an
initial idea to base site multihoming on those who have AS numbers
and PI addresses. Karst Koymans noticed an error in text
representation of prefix lengths.
Savola [Expires July 2003] [Page 6]
Internet Draft draft-savola-multi6-asn-pi-00.txt January 2003
9. References
9.1. Informative References
[6BONEOP] Rockell, R., Fink, R., "6Bone Backbone Routing
Guidelines", RFC2772, February 2000.
[ASN4BYTE] Vohra, Q., Chen, E., "BGP support for four-octet AS
number space", draft-ietf-idr-as4bytes-06.txt,
work-in-progress, December 2002.
[BGP] Rekhter, Y., Li, T., "A Border Gateway Protocol 4",
RFC1771, March 1995.
[SITELEN] IAB, IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC3177, September 2001.
Author's Address
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
A. Example of Prefix Length Filters
As an example of possible prefix length filter, one such is given
(using possible example allocations above) is given in a format of a
popular router configuration syntax:
[n=0] : ipv6 prefix-list ASN-PI permit 2000::/17 ge 32 le 32
[n=8] : ipv6 prefix-list ASN-PI permit 2001:FF00::/25 ge 40 le 40
[n=16]: ipv6 prefix-list ASN-PI permit 2001:FFFF::/33 ge 48 le 48
Note that /17 is used instead of /16 (and others, respectively) to
accept only the first half of the 16-bit AS-number space.
B. Alternative Approach with 32-bit AS Numbers
Some argue that 32-bit AS numbers must be supported. The author
believes this could have very harmful consequences in the long term,
as the model is inherently unscalable. However, if so inclined, the
possible addressing format could be:
Savola [Expires July 2003] [Page 7]
Internet Draft draft-savola-multi6-asn-pi-00.txt January 2003
| 16 bits | 32 bits | 80 bits |
+----------+----------------+---------------------+
| PRFX | ASN | site-specific parts |
+----------+----------------+---------------------+
Here, 16 bit AS numbers would just be prepended with 16 bits of zero.
Of course, PRFX could be shorter than 16 bits too.
Savola [Expires July 2003] [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-22 06:12:27 |