Internet Engineering Task Force P. Savola
Internet Draft CSC/FUNET
Expiration Date: July 2004
January 2004
Multihoming Using IPv6 Addressing Derived from AS Numbers
draft-savola-multi6-asn-pi-01.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 2004] [Page 1]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
Table of Contents
1. Introduction ............................................... 3
2. Engineering Decisions ...................................... 3
2.1. Discussion ............................................. 4
3. ASN-PI Addressing Format ................................... 5
3.1. Format ................................................. 5
3.2. Discussion ............................................. 5
3.3. Example ASN-PI Address Assignments ..................... 6
4. Operational Guidelines ..................................... 6
4.1. Discussion ............................................. 6
5. Requirements for Registries ................................ 7
6. IANA Considerations ........................................ 7
7. Evaluation of Multihoming Goals ............................ 7
7.1. Capabilities ........................................... 7
7.1.1. Redundancy ......................................... 7
7.1.2. Load Sharing ....................................... 7
7.1.3. Performance ........................................ 7
7.1.4. Policy ............................................. 7
7.1.5. Simplicity ......................................... 8
7.1.6. Transport-Layer Survivability ...................... 8
7.1.7. Impact on DNS ...................................... 8
7.1.8. Packet Filtering ................................... 8
7.2. Additional Requirements ................................ 8
7.2.1. Scalability ........................................ 8
7.2.2. Impact on Routers .................................. 8
7.2.3. Impact on Hosts .................................... 8
7.2.4. Interaction between Hosts and the Routing System ... 8
7.2.5. Operations and Management .......................... 8
7.2.6. Cooperation between Transit Providers .............. 8
7.2.7. Multiple solutions ................................. 9
8. Evaluation of Things to Think About ........................ 9
8.1. How will your solution solve the multihoming problem? .. 9
8.2. Does your solution address mobility? ................... 9
8.3. Identifiers and locators ............................... 9
8.4. On the Wire ............................................ 9
8.5. Relationship with DNS and Registries ................... 9
8.6. Compatibility .......................................... 10
8.7. Legal stuff ............................................ 10
9. Security Considerations .................................... 10
10. Acknowledgements .......................................... 10
11. References ................................................ 10
11.1. Normative References .................................. 10
11.2. Informative References ................................ 10
Author's Address ............................................... 11
A. Example of Prefix Length Filters ........................... 11
B. Alternative Approach with 32-bit AS Numbers ................ 11
Savola [Expires July 2004] [Page 2]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
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.
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:
Savola [Expires July 2004] [Page 3]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
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
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.
Savola [Expires July 2004] [Page 4]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
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.
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.
Savola [Expires July 2004] [Page 5]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
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
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.
Savola [Expires July 2004] [Page 6]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
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. Evaluation of Multihoming Goals
Goals for IPv6 Site-Multihoming Architectures [GOALS] defines a set
of conflicting goals ("requirements") which a solution should meet.
This section briefly analyzes how those goals apply to this solution.
7.1. Capabilities
7.1.1. Redundancy
Redundancy is provided by advertisement of a single prefix over
multiple providers.
7.1.2. Load Sharing
The site administators are able to control load-sharing. Outbound
load-sharing works trivially. Inbound load-sharing is supported to a
degree even if the ISPs would deploy prefix length limiters
disallowing the use of longer prefixes for load-sharing. Using just
one long advertisement with an appropriate community tagging with the
transit ISPs may be able to provide similar service if not.
7.1.3. Performance
This would typically require, unless clever operational mechanisms
are used like above, advertisement of more specific routes which is
possible but not advisable.
7.1.4. Policy
Using the same prefix allows for policy decisions.
Savola [Expires July 2004] [Page 7]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
7.1.5. Simplicity
The solution is very simple for those deploying it.
7.1.6. Transport-Layer Survivability
With just one prefix, transport-layer survives any re-homing events.
7.1.7. Impact on DNS
There is no impact; just one address is published in the DNS.
7.1.8. Packet Filtering
Ingress filtering can be deployed.
7.2. Additional Requirements
7.2.1. Scalability
The solution is scalable, when applied only to the largest
enterprises requiring such a solution.
7.2.2. Impact on Routers
No changes are required.
7.2.3. Impact on Hosts
No changes are required.
7.2.4. Interaction between Hosts and the Routing System
There need not be interaction.
7.2.5. Operations and Management
The site operators and managers are able to configure the multihoming
parameters for the whole site, so this is extremely simple.
7.2.6. Cooperation between Transit Providers
There is no need for cooperation.
Savola [Expires July 2004] [Page 8]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
7.2.7. Multiple solutions
Multiple solutions are required. This only intends to address the
case of the largest enterprises for which deploying a multi-
addressing architecture throughout the infrastructure may not be
feasible.
8. 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.
8.1. How will your solution solve the multihoming problem?
It solves only a part of the problem: the very big enterprises.
Multiaddressing is probably not an option, so they have to have
either /32 allocations (via cheating the RIRs or legitimately) or
something similar. This provides something similar.
8.2. Does your solution address mobility?
Mobility is not affected.
8.3. Identifiers and locators
As there is no split between the identifiers and locators, this is a
moot point.
8.4. On the Wire
Similarly, there are no changes at all to the packets on the wire, so
these questions are moot.
8.5. Relationship with DNS and Registries
There is no change to the relationship that would be different from
IPv4 DNS. However, a related "centralized registration" point is
that the RIRs have to consider when/how to hand out the "golden ASes"
which are allowed to multihome using this method. This has policy
concerns.
Savola [Expires July 2004] [Page 9]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
8.6. Compatibility
The solution is compatible in API level, and with old IPv6
architecture. Compatibility with IPv4 is provided by out-of-the-box
transition mechanisms. Middleboxes are not a concern. There are no
concerns with scoped addressing or multicast. There are no layer 2
implications, or referrals to worry about.
8.7. Legal stuff
The policy concerns wrt. who is eligible for the "multihoming
prefixes" might raise some policy and legal concerns.
9. Security Considerations
This memo discusses address assignment based on AS numbers and
corresponding practises. It does not have security considerations.
10. 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.
11. References
11.1. Normative References
[GOALS] Abley, J., et al., "Goals for IPv6 Site-Multihoming
Architectures", RFC3582, August 2003.
[QUES] Lear, E., "Things MULTI6 Developers should think
about", draft-lear-multi6-things-to-think-about-00,
work-in-progress, December 2003.
11.2. 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.
Savola [Expires July 2004] [Page 10]
Internet Draft draft-savola-multi6-asn-pi-01.txt January 2004
[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:
| 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 2004] [Page 11]