IPv6 Operations F. Baker
Internet-Draft Cisco Systems
Intended status: Informational M. Azinger
Expires: April 19, 2007 ARIN AC
October 16, 2006
Multihomed IPv6 prefix delegation, aggregation, and distribution
draft-baker-v6ops-l3-multihoming-analysis-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents IETF commentary to the Registry and ISP
communities on how to maximize aggregation while supporting
multihoming. Multihomed networks fall broadly into two categories,
those that are in some senses comparable to an ISP and those that are
simply edge networks or VPNs of edge networks. The best solution for
multihoming may be different for these differing categories of
networks.
Baker & Azinger Expires April 19, 2007 [Page 1]
Internet-Draft IPv6 multihoming trade-offs October 2006
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IETF IPv6 delegation advice history . . . . . . . . . . . . . 4
2.1. On Scalability . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Problems with large routing tables . . . . . . . . . . . . 6
2.3. The desirability of traffic engineering in IP routing . . 7
2.4. IETF historical thought on delegations . . . . . . . . . . 8
3. Tradeoffs in Address Multihomed Prefix delegation and
Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Provider-independent prefixes . . . . . . . . . . . . . . 10
3.1.1. Discussion of PI multihoming . . . . . . . . . . . . . 11
3.1.2. Site-multihoming architectural analysis for PI
multihoming . . . . . . . . . . . . . . . . . . . . . 11
3.2. Provider-assigned prefixes . . . . . . . . . . . . . . . . 13
3.2.1. Discussion of PA multihoming with multiple
advertisements of the PA prefix . . . . . . . . . . . 14
3.2.2. Site-multihoming architectural requirements
analysis for PA multihoming with prefix
advertisement to multiple providers . . . . . . . . . 16
3.3. Site Multihoming by IPv6 Intermediation (shim6) . . . . . 18
3.3.1. Discussion of PA multihoming with aggregated
prefix advertisement . . . . . . . . . . . . . . . . . 19
3.3.2. Site-multihoming architectural requirements
analysis for PA multihoming following the shim6
model . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Exchange-based addressing . . . . . . . . . . . . . . . . 21
3.4.1. Exchange-based addressing implementation . . . . . . . 22
3.4.2. Enumerability of exchange-based addressing . . . . . . 23
3.4.3. Site-multihoming architectural requirements
analysis for exchange-based multihoming . . . . . . . 24
4. IETF recommendations on prefix delegation, aggregation,
and filtering . . . . . . . . . . . . . . . . . . . . . . . . 25
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Baker & Azinger Expires April 19, 2007 [Page 2]
Internet-Draft IPv6 multihoming trade-offs October 2006
1. Introduction
This document attempts to address the question: 'what is the best
advice that the IETF can give the Registry and ISP communities on how
to maximize IPv6 prefix aggregation while supporting multihoming?'
It is, in a sense, an expansion on three pre-existing documents:
o IAB/IESG Recommendations on IPv6 Address Allocations to Sites
[RFC3177]
o Requirements for IPv6 Prefix Delegation [RFC3769]
o Architectural Approaches to Multi-homing for IPv6 [RFC4177]
Specifically we attempt to include the details and suggestions that
these documents are missing, or at least some of them.
This is a fairly complex question, because in it the ideals intended
by the IETF in the IPv6 addressing architecture meet the business
realities that the service providers face, and as is often true in
such cases, theory and practical reality diverge. We will also look
at the specific requirements that IPv6 Multihoming practices must
meet as described in [RFC3582], in terms of redundancy, portability,
load sharing, performance, policy, simplicity, transport-layer
survivability, impact on DNS, datagram filtering, and scalability; on
this last point, one must consider issues related to the impact on
routers, impact on hosts, interactions between hosts and the routing
system, operations and management, and cooperation between transit
providers.
Important to note is that there are at least two major types of
multihomed edge networks - big ones and small ones. Fortune 500
companies can often be looked upon as an ISP-like central networking
service with a number of departmental "customers". They are often
geographically distributed, buy services from a variety of global and
regional ISPs, and have multiple interconnections to the global
Internet. Edge networks that can be viewed in this way are perhaps
best treated as if they were ISPs in their own right, which is an
argument for allocating them their own Autonomous System Number and
IPv6 prefix like an ISP does, and expecting them to communicate with
their ISPs using BGP. On the other hand, significant attention has
been placed on companies of 50-100 employees and other smaller
offices, which predominate the business community. It is relatively
unusual for these to multihome at this time, but this is expected to
change. For purposes of nomenclature, these smaller companies are
referred to as SOHO (small office/home office) networks in this
document, which is a wider definition than that term is generally
used for, but the alternative of "SOHO plus small-to-medium sized
Baker & Azinger Expires April 19, 2007 [Page 3]
Internet-Draft IPv6 multihoming trade-offs October 2006
companies" seems cumbersome. The principal characteristics of a
"SOHO" network as the term is used here includes a single point of
attachment to the Internet and a relatively simple internal
structure. Medium-sized companies with a presence in several cities
can be thought of as multiple SOHO networks connected by a VPN for
the purposes of analysis. The requirements of an ISP-like company
and a SOHO-like company are fairly different; one solution for
multihoming need not fit all multihomed networks.
This document's structure is as follows:
o Review the IETF's history of advice to the registries regarding
IPv6 prefix delegation, and the underlying theory it is based on,
in Section 2,
o Attempt to enumerate the trade-offs inherent in various algorithms
that are in use or have been proposed in Section 3, and
o Make specific recommendations regarding delegation, aggregation,
distribution, and filtering in Section 4.
2. IETF IPv6 delegation advice history
The IPv6 address space was originally delegated to the IANA by the
IETF in [RFC1881]. In that document, the IETF stated that it
expected the IANA to further delegate the address space to various
entities and serve the needs of the Internet as a service to the
community.
[RFC2008] gives an overview of the scaling properties of the Internet
Routing System, and argues in favor using hierarchical routing to
good advantage in it. [RFC3582] similarly gives a concrete
discussion of the objectives of the design of IPv4 and IPv6
multihoming. The reader is presumed to be familiar with contents and
recommendations of these documents, which are not repeated here.
IPv6 differs from IPv4 in the size of an address and the size of a
prefix, but follows the same logic in its design.
Further to that architecture, the IETF has given other advice, mostly
with a view to enabling the widespread deployment of IPv6.
2.1. On Scalability
Scaling the Internet is far from the only reason that the IETF
worries about prefix count in the default-free zone; avoiding abuse
and problems caused by deaggregation are probably even more
important. But scaling concerns are important and a common concern.
Baker & Azinger Expires April 19, 2007 [Page 4]
Internet-Draft IPv6 multihoming trade-offs October 2006
We note that deaggregation of prefixes is often accidental, but note
that the operators communities (and notably the CIDR Report) also
consider it intentional, and debate whether intentional deaggregation
is harmful or not.
The IETF has thought long and hard about scalability, but in 355 RFCs
and currently-posted Internet Drafts that mention it at this writing,
none have seen fit to define the term. The earliest RFC to mention
it is RFC 984; the first to give it any sense of parameterization is
[RFC1265], which attempts to analyze BGP's performance
characteristics and scalability by asking what 'link bandwidth,
router memory and router CPU cycles does the BGP protocol consume
under normal conditions' and how it constrains the set of protocol
participants. That document observes that
Since in the steady state the link bandwidth and router CPU cycles
consumed by the BGP protocol are dependent only on the stability
of the Internet, but are completely independent on [sic] the
number of networks that compose the Internet, it follows that BGP
should have no scaling problems in the areas of link bandwidth and
router CPU utilization, as the Internet grows, provided that the
overall stability of the inter-AS connectivity (connectivity
between ASs) of the Internet can be controlled.
The key attributes that seem to define a 'scalable' addressing
architecture include that it
o Enables the network to address an arbitrarily large number of
systems,
o Does so in a manner that is friendly to mobility and other
attributes that contribute to the churning of advertisements,
o Does so in a manner that is friendly to multihoming, which is to
say that it enables edge networks to purchase service from several
providers and in so doing optimize their communications solutions,
o In that environment limits the amount of memory, computational
cycles, and network bandwidth spent on routing to a small fraction
of available capacity, and
o Enable vendors and network administrators to predict the amount of
memory, CPU power, and network bandwidth is required to support
the network.
From that perspective, while it is common to talk about 'scalability'
(usually by way of saying that a protocol or procedure lacks a
necessary characteristic to really be 'scalable'), in the absence of
Baker & Azinger Expires April 19, 2007 [Page 5]
Internet-Draft IPv6 multihoming trade-offs October 2006
a concise definition it may not be helpful. In this document, we
will focus on the ability to 'enumerate' the number of routes that
must be distributed through BGP and the ability to constrain the
advertisement of information to its proper locality, as indicators of
scalability.
In enumerating the number of routes in the "default-free zone" of the
backbone, we will make three assumptions. These are based on
statements commonly made, and were suggested by our reviewers, but
are otherwise offered without proof. If the reader wishes, he may
change the numbers and rerun the calculations for himself. They are:
o In 2050, the population of the earth will be approximately
10,000,000,000 souls.
o In 2050, we will have one multihomed edge network per population
of 1000, distributed throughout the Internet.
o In 2050, everyone on the planet will use the Internet as their
basic communication system, much as today the planet uses a
combination of telephone and postal mail.
2.2. Problems with large routing tables
The IETF and at least some operators have repeatedly stated concerns
about having a large route table. It might be of value to state why
the size of the route table is of concern.
The issue is not fundamentally the scaling factors related to BGP
routing, although some have raised that concern. Regardless of how
routing information is exchanged, three fundamental issues have a
per-advertised-prefix impact. They are:
o The amount of time that it takes a router to join a network from
its initial state and join the converged view of that network is
dependent in part on the rate at which it can receive and process
the routes advertised to it by its peers. Each prefix advertised
requires a certain number of bits on the interconnect, which at
the rate of the interconnect implies a certain amount of time.
o Additionally, even if the prefix is discarded on receipt, the
processing of the prefix requires some amount of information to be
stored in router memory to support validation and other
processing, and requires some computational resources (time and
memory). At this writing, even over high speed optical fiber and
with O(200,000) backbone routes, this is non-trivial. Routers
that manage backbone routing tables are typically configured with
hundreds of megabytes to gigabytes of memory when they support
Baker & Azinger Expires April 19, 2007 [Page 6]
Internet-Draft IPv6 multihoming trade-offs October 2006
O(10^5) routes; routers with O(10^7) routes would seem to call for
tens to hundreds of gigabytes of memory, with the attendant power
consumption issues that large memories bring.
o Any link or equipment has a certain probability of experiencing an
outage, either due to failure, during reconfiguration, or due to
an incorrect configuration. Additionally, the BGP Update Report
[BGP-UPDATE] indicates that a small percentage of Internet
providers have a disproportionately high level of BGP 'chatter',
probably due to dysfunctional configuration or policy. We presume
that the rate of churn per prefix will not be reduced in the
future; if anything, small providers and small edge networks are
more likely to have incorrect configurations due to inexperience,
raising the churn rate. The larger the number of routes in the
backbone, the more stressful this prefix churn is.
In can be readily seen that these concerns apply regardless of how
many prefixes are in the routing system, and increase in gravity
linearly with the increase in the upper bound size of the routing
system. In the extreme case, it is possible to build routers that
manage individual end system addresses in routing, and both Ethernet
switches and MANET routers can be pointed to as examples of such
systems. However, neither of these solutions is generally
implemented in the Internet backbone for cost and scaling reasons.
The logic that takes one there argues in the direction of minimizing
the size of the route table.
Any delegation, aggregation, distribution,or filtering strategy that
increases the number of prefixes ambient in the backbone exacerbate
them, and any proposal that reduces the number of prefixes ambient in
the system helps to mitigate the concerns.
2.3. The desirability of traffic engineering in IP routing
Having just said that the IETF's advice, the registry's advice, and
the periodic BGP Update Report argue in favor of maximizing
aggregation, ISPs world-wide fail to do this and justify it on the
basis of traffic engineering. They advertise longer prefixes than
they were allocated with a view to either soliciting traffic and
therefore being seen as more valuable by potential bilateral partners
and customers, or to manage the ingress point or route of traffic to
or within their networks to reduce their own costs. In the IPv4
Internet, this means a large number of /24 prefixes in the backbone
that could be usefully aggregated to /20, /19, or shorter. The sense
of these operators is that Internet routing is sufficiently robust to
handle the load, and the practice improves their business position,
so it is something they want to do in the IPv6 backbone as well.
This is a matter on which the operators are not of one mind.
Baker & Azinger Expires April 19, 2007 [Page 7]
Internet-Draft IPv6 multihoming trade-offs October 2006
Theoretically, however, if one of the objectives of Internet layer
routing is to engineer traffic loads, then the logical unit of such
engineering is the ISP point of presence, not a small sub-prefix of
it. One would generally not suggest advertising prefixes outside of
a provider's network longer than the prefix assigned to a POP. Doing
so may offer the illusion of greater control, but it also increases
the risk of the route being filtered out by the peer.
2.4. IETF historical thought on delegations
IPv6 is defined in the IPv6 Specification [RFC2460], and its current
address architecture is defined in the IP Version 6 Addressing
Architecture [RFC4291]. The IETF community believes that the
simplest way for the registries to manage the address space and the
routing tables in ISPs is to allocate it in block sizes appropriate
to an ISP or large enterprise, who will in turn sub-allocate to mid-
sized enterprise customers, homes, and small offices (SOHO).
The assumptions behind RFC 3177's recommendations are that
o The Internet Assigned Numbers Authority (IANA) allocates large
blocks to the registries.
o Registries in turn allocate large blocks of IPv6 address space to
entities that can demonstrate a sufficient reason to have such.
o These entities, which may be ISPs or well connected multi-homed
edge networks, delegate prefixes from that address space to
customers or business units.
o These customers and business units in turn subnet their internal
networks within the same prefix.
o On individual LANs, addresses are either derived automatically,
assigned via DHCP, or are assigned manually.
In theory, for the typical ISP, this means that it is in a position
to (and RIR policy recommends that it) aggregate its own and all of
its customer's routing into a single prefix that it advertises beyond
itself. As a direct consequence, it can also expect to receive at
most a few prefixes in BGP routing for each autonomous system in the
Internet, and in addition carry its own internal routing and its
customer's routing. At current numbers, this is a very reasonable
address table size even if every company that currently has an
autonomous system number assigned to it is granted a Provider-
Independent IPv6 prefix. It would be approximately 1/10 the size of
the current IPv4 routing table as reported in the BGP Update Report
[BGP-UPDATE].
Baker & Azinger Expires April 19, 2007 [Page 8]
Internet-Draft IPv6 multihoming trade-offs October 2006
There is only one problem. In today's Internet, this strictly
hierarchical model is at best naive.
Multihoming, the practice of purchasing Internet access from multiple
ISPs, wrinkles this simple landscape in at least four ways.
1. The provider-assigned address model originally proposed in
[RFC1887] presumes that when a multihomed site obtains Internet
connectivity through multiple providers, each provider delegates
a prefix to the the multihomed site, and each host within the
multihomed site configures or is configured with one address per
available prefix. This model, in the presence of ingress
filtering as described in [RFC2827], and egress routing as
described in [RFC3704], has no fail-over path for traffic bearing
a source address that was assigned by an ISP that is currently
unreachable by the edge site.
2. Edge networks are not necessarily willing to deploy multiple
prefixes delegated by ISPs throughout their networks. As
articulated in [RFC3582], they prefer a model in which a single
prefix is assigned to the edge network such as is implemented by
Provider-Independent Addressing (see Section 3.1) for a set of
operational reasons.
3. In this case, one provider assigns a prefix to an edge network
and that edge network advertises it to its other upstream
providers. The scenario, however, creates connectivity problems
for the host. For example, if the prefix is advertised to a
given ISP who in turn advertises it upstream, but whose upstream
ISP doesn't accept the route, even though the alternate ISP is
willing to deliver it, traffic will not be delivered via the
alternate route and traffic sent via it may be ingress filtered
by the upstream ISP.
4. Assignment of a prefix to each edge network, regardless of who
does the assignment, that is individually advertised throughout
the backbone yields the specter the number of prefixes
distributed by the routing system ballooning, as has happened in
the IPv4 Internet. In the very near term, this may be
acceptable, but in the long term the issues of a voluminous table
loom in that domain as well.
These issues are discussed in the RFCs Architectural Approaches to
Multi-homing for IPv6 [RFC4177] and Threats Relating to IPv6
Multihoming Solutions [RFC4218], and the Requirements for IPv6 Prefix
Delegation [RFC3769].
Baker & Azinger Expires April 19, 2007 [Page 9]
Internet-Draft IPv6 multihoming trade-offs October 2006
3. Tradeoffs in Address Multihomed Prefix delegation and Aggregation
As discussed in [RFC2008], all addressing that has hope of producing
an enumerable set of routes in the backbone supports some form of
aggregation model.
Three fundamental models have been proposed:
o a model associating prefixes with ISPs alone,
o a model associating prefixes with ISPs or edge networks as is
found in the IPv4 Internet, and
o a model allocating prefixes to ISPs, larger edge networks, and to
regional exchanges that serve small office/home office
(residential or "SOHO") networks, called 'Exchange-based
addressing'.
Note that each of these models are topological (prefixes are assigned
to points in the routing topology) and are hierarchical; they differ
in that traditional addressing has been disjoint from any sense of
locality, while exchange-based addressing is generally deemed to be
in some sense regional.
A fourth approach to multihoming, the use of network address
translators as is done in the IPv4 network, is not discussed here as
it is addressed in other documents and is not the IETF's preferred
approach. See [I-D.ietf-v6ops-natpt-to-exprmntl] and
[I-D.ietf-v6ops-nap].
3.1. Provider-independent prefixes
[RFC1787] defines the term 'Provider-Independent' (PI) 'Addressing'
in the observation that
It is important to emphasize that the requirement to maintain
topologically significant addresses doesn't need to be applied
indiscriminately to all the organizations connected to the
Internet -- hierarchical routing requires that most, but not all
addresses be topologically significant. For a large organization
it could be sufficient if the set of destinations within the
organization can be represented within the Internet routing system
as a small number of address prefixes, even if these address
prefixes are independent of the providers that the organization
uses to connect to the Internet ('PI' addresses). The volume of
routing information that a large organization would inject into
the Internet routing system would be comparable to the
(aggregated) routing information associated with a large number of
Baker & Azinger Expires April 19, 2007 [Page 10]
Internet-Draft IPv6 multihoming trade-offs October 2006
small organizations.
Provider-Independent assignment of prefixes is the current standard
behavior of the various registries. Some ISPs are acting as Local
Internet Registries, assigning prefixes out of their assigned
prefixes (regarding which see Section 3.2), but more generally the
regional and national registries are assigning prefixes on this
model. [RFC3582] could be summarized as saying that any new approach
to multihoming needs to be as good as PI addressing, and in addition
must scale well in routing.
3.1.1. Discussion of PI multihoming
In the IPv6 Internet, if each edge network (including SOHO) is
granted a PI prefix and all ISPs are expected to route to it
specifically and without aggregation, then the number of prefixes
exchanged the Internet backbone must eventually approximate the
number of edge networks in the world. Given the stated assumptions
(see Section 2.1), this calculates to 10,000,000,000/1,000 or
10,000,000 prefixes. There are various ways to mitigate this, but
they each result in a significant fraction of this number.
At this point, the gentle reader is encouraged to re-read
Section 2.2.
These same issues apply to and are amplified by the ISP practice of
BGP load balancing, in which some ISPs advertise prefixes to upstream
providers in ways that offload the cost of traffic carriage or
traffic at hot spots in their own routing to other providers.
Since PI Addressing maximizes the number of prefixes advertised in
the default-free zone of the backbone, those who have argued against
PI address delegation focus hardest on these issues.
3.1.2. Site-multihoming architectural analysis for PI multihoming
In response to the points raised in [RFC3582], we observe the
following. Fundamentally, we note that the IPv4 Internet uses a
combination of PI and PA addressing, and PI addressing is known to
work in the IPv4 Internet. [RFC3582] sets PI addressing as the gold
standard, and it is widely preferred for edge networks that are
comparable to ISPs in size, structure, and attachment.
Redundancy: PI addressing, as it does in the IPv4 Internet, clearly
shields the multihomed network from failures in individual ISPs
through which it advertises its address.
Baker & Azinger Expires April 19, 2007 [Page 11]
Internet-Draft IPv6 multihoming trade-offs October 2006
Portability: PI addresses, since they are advertised everywhere, are
inherently portable.
Load sharing: Distribution of traffic by the edge network to its
upstreams is at its convenience and according to its policy.
Performance: Edge network distribution policies may be made
dependent on the perceived performance of its providers without
concern.
Policy: Traffic may be distributed according to any policy the
source network considers relevant.
Simplicity: PI prefixes in the IPv6 network are no different than PI
prefixes in the IPv4 network from a user-maintainability
perspective. It could be argued that they are simpler, due to
address auto-configuration.
Transport-layer survivability: Since only one prefix is deployed
within the edge network, TCP, UDP, and SCTP sessions all have a
reasonable expectation of surviving changes in routing.
Impact on DNS: DNS lists the address used, as is done in the IPv4
Internet.
Datagram filtering: PI addressing facilitates BCP 38 ingress
filtering, in that the ISP is cognizant of the addresses used by
the edge network, whether this is accomplished through routing or
configuration.
Scalability-impact on routers: PI addressing has no algorithmic
impact on routing functionality. It does not preclude single-
homed operation and should interoperate with systems that do not
implement routing functionality. However, as noted in
Section 3.1.1, there are serious questions regarding the number of
prefixes in the Internet backbone if PI addressing is applied to
the SOHO environment. The prefix count would have effects on the
amount of memory required for routing, which has both cost and
power implications, and would require increased amounts of state
to be maintained in the network.
Scalability-impact on hosts: This approach is backward compatible
with current RFCs and requires no host changes.
Scalability-interactions between hosts and the routing system: The
interaction between hosts and the routing system is defined by
[RFC2462] and [RFC3315]. As the proposal is currently deployed,
it manifestly requires no change to the system.
Baker & Azinger Expires April 19, 2007 [Page 12]
Internet-Draft IPv6 multihoming trade-offs October 2006
Scalability-operations and management: It is possible for the staff
of a site to monitor and configure the operation of its multihomed
routing system using operations confined to the routers in the
network.
Scalability-cooperation between transit providers: PI addressing
does not require inter-provider cooperation, but does require
cooperation between the provider and his customer.
3.2. Provider-assigned prefixes
The RFCs in which the IETF has commented on this model refer to it as
"Provider-Based" [RFC3587], "Provider-Assigned" [RFC4076], and
"Provider-Aggregatable" [RFC3582] Addressing. In this document, it
will be called PA addressing and may be interpreted in any of those
ways.
The concept of PA addressing has developed with the IPv6 addressing
architecture. It was first described in detail in [RFC2073], refined
in [RFC2374], and is now specified in [RFC3587]. A fundamental
premise of each of these documents is that routing to the end system
from another network involves first routing to the ISP to which the
prefix was allocated, and which assigned a more specific prefix to
one of its customers; the ISP will in turn route the traffic to its
customer.
This differs materially from proposals that suggest the use of
provider-assigned addressing as another way to achieve the equivalent
of a PI prefix by having the customer advertise the same prefix
upstream through another ISP. This second model is reported in
[RFC4116], which says
The site uses PA addresses assigned by a single transit provider.
The set of routes covering those PA addresses (the "site route
set") is announced or propagated by one or more additional transit
providers. The transit provider which assigned the PA addresses
(the "primary transit provider") originates a set of routes which
cover the site route set. The primary transit provider often
originates or propagates the site route set as well as the
covering aggregates.
The use of PA addresses is applicable to sites whose addressing
requirements are not sufficient to meet the requirements for PI
assignments by RIRs. However, in the case where the site route
set is to be announced or propagated by two or more different
transit providers, common operational practice still dictates
minimum /24 prefixes, which may be larger than the allocation
available to small sites.
Baker & Azinger Expires April 19, 2007 [Page 13]
Internet-Draft IPv6 multihoming trade-offs October 2006
There have been well-documented examples of sites filtering long-
prefix routes which are covered by a transit-providers
aggregate...
Interestingly, at this writing, the statuses of these documents are
'proposed standard', 'historic', and 'informational'. What started
as a standard has become a suggestion, and the ISPs appear to be very
interested in using PA addressing as another way to achieve the
equivalent of PI addressing as mentioned in the opening paragraph of
section 3.1.1.2 of [RFC3582]. Since PA addressing as described in
RFCs 2073 and 2374 is incapable of multihoming, for present purposes
we will only address the latter discussion.
3.2.1. Discussion of PA multihoming with multiple advertisements of the
PA prefix
The fundamental argument for multihoming using PA prefixes is that
they are not PI and are therefore presumed to be more scalable than
PI prefixes. The assumption is that they can be aggregated at least
by the first tier of ISPs, and as such need not be advertised
throughout the Internet.
The assumption, of course, has several weaknesses. The first tier of
ISPs, those with truly global scope, do not act as backbones for all
traffic. Many routes pass from major regional ISP to major regional
ISP - the ISPs which have traditionally been called the second tier.
These ISPs are more likely to find it in their interest to not
aggregate multihomed routes.
Further, [RFC2008] observes that
This document expects that when the 'address lending' policy is
used by an Internet Registry associated with a provider, the terms
and conditions of the loan would be coupled to the service
agreement between the provider and the subscribers. That is, if
the subscriber moves to another provider, the loan would be
canceled.
Similarly, [RFC4076] observes in section 3.1 that
One of the fundamental principles of IPv6 is that sites receive
their IPv6 address allocations from an ISP using provider-assigned
(PA) address space. There is currently no provider-independent
(PI) address space in IPv6. Therefore, a site changing its ISP
must renumber its network. Any such site renumbering will require
hosts to reconfigure both their own address and default router
settings and their stateless DHCPv6-assigned settings.
Baker & Azinger Expires April 19, 2007 [Page 14]
Internet-Draft IPv6 multihoming trade-offs October 2006
It may be instructive to imagine what would happen in the event that
this policy was not rigorously applied, and a PA prefix remained with
the subscriber even after it had terminated its relationship with the
assigning provider. In such a case, the prefix would functionally
become a PI prefix, with whatever scaling issues a PI prefix has.
For PA addressing to be more scalable than PI addressing therefore
requires that the address be assigned only while the subscriber
subscribes to the ISP that assigned it the prefix; it is otherwise
indistinguishable operationally. It also requires that the addresses
can be aggregated at some point in the hierarchy and not distributed
globally, which is something not true of a PI prefix.
This latter assumption is also suspect on another score. In the
Internet routing architecture, we route towards the most specific
prefix, an algorithm generally called 'longest match first'. Suppose
that the subscriber in Figure 1 is granted a prefix by ISP A and
advertises it to ISP B, but ISP A does not advertise it to its
upstream ISP (C) while B does. In that case, either ISP C will
accept the prefix from B and route all of the subscriber's traffic
through ISP B, or it will not accept it and route none of the
subscriber's traffic through ISP B. To provide a multihomed service
to the subscriber, ISP C must accept the prefix from both ISPs A and
B, and both ISPs A and B must advertise the prefix to ISP C. It has
also been noted that the original provider often provides the best
route (shortest distance or most widely connected) to its direct
customers, meaning that any more specific route is often a lower
quality route.
,--------------------.
/ \
( ISP C )
\ /
`---+------------+---'
| |
,--+--. ,--+--.
/ \ / \
( ISP A ) ( ISP B )
\ / \ /
`--+--' `--+--'
| |
,----+------------+----.
( subscriber )
`----------------------'
Figure 1: Multihomed Subscriber
Several concerns were raised in Section 2.2. In addition, the clear
Baker & Azinger Expires April 19, 2007 [Page 15]
Internet-Draft IPv6 multihoming trade-offs October 2006
implication is that multi-homed service only really works if upstream
providers accept the prefixes and advertise them to their transit
providers (even if they don't use them themselves or advertise them
to their peers), which implies that if edge networks are
predominantly multihomed, the number of prefixes in the global route
table approximates at best an order of magnitude less than in the PI
case (which we calculated at 10,000,000,000 backbone prefixes in
2050), and potentially no different than that number.
3.2.2. Site-multihoming architectural requirements analysis for PA
multihoming with prefix advertisement to multiple providers
In response to the questions raised in [RFC3582], we observe the
following.
Redundancy: PA addressing that mimics PI addressing in the sense of
advertising prefixes upstream through multiple providers clearly
shields the multihomed network from failures in individual ISPs
through which it advertises its address. However, issues with the
advertisement of these prefixes upstream have been noted.
Portability: PA prefixes are not portable. RIR policy requires that
if the edge network leaves the assigning ISP, it return the
prefix.
Load sharing: PA addressing that mimics PI addressing in the sense
of advertising prefixes upstream through multiple providers
enables the distribution of traffic by the edge network to its
upstreams is at its convenience and according to its policy.
Performance: Edge network distribution policies may be made
dependent on the perceived performance of its providers without
concern.
Policy: Traffic may be distributed according to any policy the
source network considers relevant.
Simplicity: PA prefixes that mimic PI prefixes have a selection of
problems with upstream networks, as discussed in [RFC3704]. If
the assigning ISP does not advertise the prefix to its upstream
but another ISP does, traffic to the edge network will prefer the
alternate ISP's route. If an upstream ISP fails to accept the
advertised prefix, neither it nor any of its downstream ISPs will
participate in the routing of traffic to the edge network, denying
it the contracted service. Ingress filtering can also be an
issue.
Baker & Azinger Expires April 19, 2007 [Page 16]
Internet-Draft IPv6 multihoming trade-offs October 2006
Transport-layer survivability: Since only one prefix is deployed
within the edge network, TCP, UDP, and SCTP sessions all have a
reasonable expectation of surviving changes in routing.
Impact on DNS: DNS lists the address used, as is done in the IPv4
Internet.
Datagram filtering: PA addressing that mimics PI addressing in the
sense of advertising prefixes upstream through multiple providers
facilitates BCP 38 ingress filtering, in that the ISP is cognizant
of the addresses used by the edge network, whether this is
accomplished through routing or configuration. There are
potential problems, however, with upstream providers, as discussed
in [RFC3704].
Scalability-impact on routers: PA addressing that mimics PI
addressing requires no algorithmic impact on routing
functionality, although changes have been proposed as in
[I-D.van-beijnum-v6ops-pa-mhome-community]. It does not preclude
single-homed operation and should interoperate with systems that
do not implement routing functionality. However, as noted in
Section 3.2.1, there are serious questions regarding the number of
prefixes required to be in the Internet backbone if the approach
is applied to the SOHO environment. The prefix count would have
effects on the amount of memory required for routing, which has
both cost and power implications, and would require increased
amounts of state to be maintained in the network.
Scalability-impact on hosts: This approach is backward compatible
with current RFCs and requires no host changes.
Scalability-interactions between hosts and the routing system: The
interaction between hosts and the routing system is defined by
[RFC2462] and [RFC3315]. As the proposal is currently deployed,
it manifestly requires no change to the system.
Scalability-operations and management: It is possible for the staff
of a site to monitor and configure the operation of its multihomed
routing system using operations confined to the routers in the
network.
Scalability-cooperation between transit providers: PA addressing
that mimics PI addressing requires some level of inter-provider
cooperation, in the sense that a prefix that is a sub-prefix of
one allocated by a registry to provider A and advertised upstream
by provider B must be accepted by a provider C that is not a party
to the agreement between the edge network and its providers. The
implications of this are discussed in [RFC3704].
Baker & Azinger Expires April 19, 2007 [Page 17]
Internet-Draft IPv6 multihoming trade-offs October 2006
3.3. Site Multihoming by IPv6 Intermediation (shim6)
A variation on PA multihoming is in the process of definition by the
shim6 working group and may be standardized in the future; the
protocol is described in [I-D.ietf-shim6-proto], and there are
several related documents discussing address pair selection policy,
failure detection and management, and so on. The premise of this is
that an edge network obtains PA space from each of several providers
and allocates addresses from each provider to each host interface
within the network. The question is then which of each system's
several addresses is to be used in communications between any two
systems, noting that each address pair implies a different route.
Datagrams will leave the source network using the ISP that the
address is derived from and will be delivered to the destination
using the ISP implied by the destination address. For example, in
Figure 2, depending on the selection of addresses at a system in the
source network, the same datagram might be sent through ISPs A and C,
ISPs A and D, ISPs B and C, or ISPs B and D. Imagine, for example,
that A<->C was a satellite path each way, A->D was a satellite path
while D->A was terrestrial fiber with a long propagation delay, and
the links from B<->A and B<->A were shorter; the choice of address
prefix pair would clearly have a tremendous impact on round trip
delays.
,-----. ,-----.
/ \ / \
/ \ / \
,---. ( ISP A +---------------+ ISP C ) ,---.
/ \ \ +. .+ / / \
/ +=+ / `. .' \ +=+ \
/ \ `-----' `. .' `-----' / \
; : `. .' ; :
| | `.' | |
| Source | .' `. |Destination|
| | .' `. | |
: ; .' `. : ;
\ / ,-----. .' `. ,-----. \ /
\ +=+ +' `+ +=+ /
\ / / \ / \ \ /
`---' ( ISP B +---------------+ ISP D ) `---'
\ / \ /
\ / \ /
`-----' `-----'
Figure 2: Shim6 PA proposal
Baker & Azinger Expires April 19, 2007 [Page 18]
Internet-Draft IPv6 multihoming trade-offs October 2006
3.3.1. Discussion of PA multihoming with aggregated prefix
advertisement
From the perspective of prefix enumeration, this is very attractive;
the only prefixes in the backbone are those of ISPs and large edge
networks, and the end systems find ways to use those routes to their
benefit according to their desires. If, for example, the
statistically least mean delay path is important to the Source
network's administration or user, it can cache information about the
delays incurred by various sessions' address pairs and choose the one
that has historically worked the best. If ISP B's service is at a
higher cost, it can also try address pairs involving ISP A before
trying address pairs involving ISP B.
Weaknesses in the approach have also been pointed out, in that it
presumes that the edge networks will be willing to renumber (in the
sense of deploying address space from each ISP) as it changes
contracts with providers, and that the edge network will be willing
to pay the cost of the lease of PA space sufficient for its entire
company from every ISP it uses. Renumbering technology has been
worked out to a certain degree, as documented in [RFC2071],
[RFC2894], and [RFC4076]. However, as noted in [RFC4192], the large
issues in renumbering relate to human stupidity, against which there
is no proof. Renumbering therefore remains a non-trivial effort in
large networks, usually because of errors in judgement in application
or network design.
Some in the operational community believe that portable address space
that does not require renumbering upon a change of provider is a
customer requirement.If this is the case, the prospects of deploying
this architecture are in doubt.
3.3.2. Site-multihoming architectural requirements analysis for PA
multihoming following the shim6 model
In response to the questions raised in [RFC3582], we observe the
following.
Redundancy: PA addressing from a host equipped with multiple IPv6
addresses enables a certain level of redundancy, in the sense that
SCTP sessions can use multiple addresses and thus survive as long
as some connectivity exits. TCP sessions through the failing ISP
will be lost, although new TCP sessions originated using other
addresses will continue to work. In the event that the multiple
addresses consist of one global and one local (ULA or link-local)
address, a failure of the ISP supporting the global address will
limit the edge network to internal communications, but those
internal communications will continue to work. If there are
Baker & Azinger Expires April 19, 2007 [Page 19]
Internet-Draft IPv6 multihoming trade-offs October 2006
multiple global addresses, the shim6 model allows for session
recovery if the other global address is known to the peer system
(e.g., if the session has been up long enough for certain
exchanges to have taken place).
Portability: PA prefixes are not portable. RIR policy requires that
if the edge network leaves the assigning ISP, it return the
prefix.
Load sharing: PA addressing that assigns a different prefix from
each upstream, if the upstream filters traffic by source address
on ingress, has a selection of problems discussed in [RFC3704].
That RFC also discusses strategies for mitigating the concerns.
Performance: As noted previously in this section, PA addressing of
this type makes performance estimation an issue that the host has
to deal with in its address pair selection algorithms as opposed
to an issue dealt with in routing. The host does have the option
of selecting address pairs to optimize performance. However, it
lacks information on which to base that decision, and so must base
it either on cached history, present measurement, or random
chance.
Policy: Traffic must be distributed according to the routing of the
address pair in question. However, address pairs may be selected
according to any policy the source network considers relevant.
Simplicity: From the perspective of upstream ISPs, PA addressing of
this type is transparent and therefore simple. However, the edge
network is required to distribute every ISP's prefix through an
appropriate subset of its network, and if those subsets are not
congruent may encounter anomalies such as having internal systems
that share no prefix communicating via the global Internet due to
routing. Large networks, such as those of Fortune 1000 companies,
are most likely to experience this sort of issue.
Transport-layer survivability: [I-D.ietf-shim6-multihome-shim-api]
and [I-D.ietf-shim6-proto] describe a mechanism that could be used
to enable TCP sessions to be portable across multiple address
pairs on systems that implement it. SCTP, which is capable of
changing addresses, can also survive. In both cases, host changes
(the implementation of the shim6 protocol or the implementation of
SCTP) are required to have transport survivability.
Impact on DNS: DNS lists the addresses (plural) used, as is done in
the IPv4 Internet. IPv6 address-selection algorithms, however,
modify the behavior of the DNS resolver to some extent. Rather
than selecting a destination address from the list at random, the
Baker & Azinger Expires April 19, 2007 [Page 20]
Internet-Draft IPv6 multihoming trade-offs October 2006
source may use additional policy such as historical RTTs from
various addresses or prefixes in its address selection algorithms
or other techniques.
Datagram filtering: PA addressing that assigns a different prefix
from each upstream facilitates BCP 38 ingress filtering, in that
the ISP is cognizant of the addresses used by the edge network,
whether this is accomplished through routing or configuration.
Scalability-impact on routers: PA addressing that assigns a
different prefix from each upstream requires no changes to routing
functionality. Since the only prefixes in the network would be
those of ISPs and the largest companies, this is the most scalable
of the options considered in this note, with a global route table
on the order of 10^5 to 10^6 routes.
Scalability-impact on hosts: Host changes are required to fully
implement the shim6 proposal, but a host that does not implement
the changes will still get some service from the network.
Scalability-interactions between hosts and the routing system: The
interaction between hosts and the routing system is defined by
[RFC2462] and [RFC3315]. As the proposal is currently deployed,
it manifestly requires no change to the system, although there are
proposed changes to the system that would improve its performance.
Scalability-operations and management: It is possible for the staff
of a site to monitor and configure the operation of its multihomed
routing system. The configurations will include router
configurations and host configurations, and may include middleware
capabilities.
Scalability-cooperation between transit providers: PA addressing
does not require inter-provider cooperation beyond that present in
the IPv4 Internet.
3.4. Exchange-based addressing
Several variations on Metropolitan Addressing [METRO] have been
proposed. These are generally viewed as "geographic", in the sense
that it maps readily to a city, which in turn works with the relevant
providers to provide an exchange. Geographic locality is not central
to the concept, however; what is central is the notion of a service
domain. That domain could as easily be the customers of a
cooperative as the citizens of a government. Each of the providers
advertises the exchange's prefix to the Internet, accepts (either by
protocol or by contract) longer prefixes from subscribers that are
within the service domain, and interchanges traffic to other relevant
Baker & Azinger Expires April 19, 2007 [Page 21]
Internet-Draft IPv6 multihoming trade-offs October 2006
providers appropriately.
3.4.1. Exchange-based addressing implementation
One implementation would have the cooperative or regional authority
actually operate or contract the operation of a routing interchange
point, similar in some respects to the operation of an internet
exchange point and possibly co-resident with one. This is a
mechanism that [RFC2374] calls "exchange-based aggregation". The
interchange point would in fact be an ISP; it would buy transit from
some set of providers and sell transit to all of the providers that
served multihomed SOHO networks in the service domain. Unlike other
ISPs that do this, however, it would advertise a prefix to all of its
providers upstream and downstream and (perhaps through them) lease
more specific prefixes from that prefix to SOHO networks. These
would obtain service from their providers using those more specific
prefixes, either advertising them upstream or having their providers
behave as if they were on the basis of configuration, and their
providers would in turn advertise the prefixes of their customers to
the interchange point. Any traffic that comes to the region that is
not delivered directly to a customer is delivered to the interchange
router, which in turn passes it to the relevant provider. This could
occur in a co-location center, for example.
Another implementation would have a cooperative or regional authority
that assigned the prefixes, as in the first implementation approach,
but would have all of the relevant providers directly contract and
exchange SOHO routes with each other, and the transit providers among
them advertise the exchange's general prefix beyond them using their
own AS numbers. In this model, the definition of an "exchange" is
more subjective - it exists in the sense that all of the routes are
exchanged, although multiple AS numbers are associated with the
prefix. This approach has issues in advertisement validation by ISPs
not involved in the exchange - they are not likely to believe all of
the transit ISPs simultaneously.
The two approaches can also be combined. There could be a central
exchange as described, and in addition some ISPs choose to exchange
SOHO routes through their bilateral links and exchange value
directly, bypassing the exchange.
The big issue in this approach is exchange of value. The present
Internet model lays the burden of datagram transport on the
receiver's ISP - traffic goes to that ISP via the least expensive
route, and it is required to deliver it. This model inverts that -
the sender's ISP determines the route to the interchange point. As
such, larger providers tend to carry the burden of transport while
smaller providers can often switch a datagram directly from network
Baker & Azinger Expires April 19, 2007 [Page 22]
Internet-Draft IPv6 multihoming trade-offs October 2006
ingress to the customer. In addition, implementation via bilateral
contracts among the carriers constitutes a barrier to entry: while
the major carriers very likely already have bilateral interchanges,
smaller carriers are forced to purchase transport contracts from all
of their larger competitors. As such, anti-competitive behavior or
the appearance of it is a serious danger.
3.4.2. Enumerability of exchange-based addressing
Given a 2050 world population of 10,000,000,000 (see Section 2.1),
addressing of exchanges for regions with populations on the order of
one million persons would add approximately 10,000 prefixes to the
IPv6 route table and permit multihoming of individual homes or small
to medium sized businesses (e.g., SOHO networks). Reducing the
presumptive size of the region an exchange could address to 100,000
means that we would add a total of 100,000 globally routed prefixes
under the same assumptions.
Note that the number of people in the domain is not critical to the
concept; numbers are used here for purposes of estimation, not
definition. A large region like the megalopolis incorporating
California's Ventura, Los Angeles, Riverside, Orange, and San Diego
counties might use multiple prefixes or a single very large one,
while smaller regions like Edinburgh and its suburbs might use a
single smaller prefix. At one multihomed network per 1000 people, a
/36 prefix could be subdivided into 4096 /48's, or a /48 prefix
assigned to an exchange could be subdivided into 4096 /60 prefixes.
At one prefix per 1000 people, either distribution might serve a
region containing four million people. The important point here is
not the size of an exchange or the prefix it might use, but the
concept on which it is based.
This suggests that the use of PI addressing for ISPs and larger
enterprises with multiple geographically disparate access to the
Internet, in concert with some form of exchange-based addressing for
the SOHO environment, yields a solution in which backbone route table
size is predictable and comparable in size to that of Section 3.3
without the issues it entails.
While exchange-based routing requires exchange-based addressing, the
opposite isn't true: it would be possible to deploy exchange-based
addressing in the relative short term, and hold off implementation of
exchange-based routing until such time that the size of the default-
free routing table becomes unmanageable without it. Until that
happens, exchange-based prefixes will function exactly like regular
PI prefixes. The difference is that implementing exchange-based
addressing now provides more options in the future.
Baker & Azinger Expires April 19, 2007 [Page 23]
Internet-Draft IPv6 multihoming trade-offs October 2006
3.4.3. Site-multihoming architectural requirements analysis for
exchange-based multihoming
In response to the questions raised in [RFC3582], we observe the
following. The key point is that exchange-based addressing has many
of the same characteristics as a PI address from the edge network's
perspective; it differs only in that the address must be released
when the edge network leaves the exchange.
Redundancy: Exchange-based addressing clearly shields the multihomed
network from failures in individual ISPs in the exchange as long
as one of its providers survives.
Portability: A prefix assigned in this manner is portable among
participating providers within the service domain of the exchange,
but not across service domain boundaries. Generally, a SOHO that
changes address, however, changes IP prefix even it stays with the
same provider.
Load sharing: Distribution of traffic by the edge network to its
upstreams is at its convenience and according to its policy.
Performance: Edge network distribution policies may be made
dependent on the perceived performance of its providers without
concern.
Policy: Traffic may be distributed according to any policy the
source network considers relevant.
Simplicity: Exchange-based prefixes in the IPv6 network are no
different than PI prefixes in the IPv4 network from a user-
maintainability perspective. It could be argued that they are
simpler, due to address auto-configuration. From the ISP's
perspective, cooperation within the exchange is necessary. It is
not, however, significantly more complex for the ISP than PI
addressing, in the sense that the edge network will provide its
prefix as a condition of the contract and the ISP will include
that prefix in its routing configurations and policies.
Transport-layer survivability: Since only one prefix is deployed
within the edge network, TCP, UDP, and SCTP sessions all have a
reasonable expectation of surviving changes in routing.
Impact on DNS: DNS lists the address used, as is done in the IPv4
Internet.
Baker & Azinger Expires April 19, 2007 [Page 24]
Internet-Draft IPv6 multihoming trade-offs October 2006
Datagram filtering: Exchanged-based addressing facilitates BCP 38
ingress filtering, in that the ISP is cognizant of the addresses
used by the edge network, whether this is accomplished through
routing or configuration.
Scalability-impact on routers: Exchange-based addressing does not
change routing technology, although it changes how it is used.
Since the only prefixes in the network would be those of ISPs and
the largest companies and those corresponding to relatively large
regional networks, perhaps related to cities in some sense, this
is the second-most scalable approach considered in this note, with
a global route table on the order of 10^6 routes.
Scalability-impact on hosts: This approach is backward compatible
with current RFCs and requires no host changes.
Scalability-interactions between hosts and the routing system: The
interaction between hosts and the routing system is defined by
[RFC2462] and [RFC3315]. As the proposal is currently deployed,
it manifestly requires no change to the system.
Scalability-operations and management: It is possible for the staff
of a SOHO site to monitor and configure the operation of its
multihomed routing system using operations confined to the routers
in the network.
Scalability-cooperation between transit providers: PI addressing
does not require inter-provider cooperation with respect to any
given customer, apart from using the prefix assigned to the
customer by the exchange, but it does require cooperation between
each provider and the exchange. To the extent that the "exchange"
is implemented via bilateral contracts instead of a central
routing system, providers using bilateral relationships must
perform in accordance with them.
4. IETF recommendations on prefix delegation, aggregation, and
filtering
The IETF's first observation is that it is not its place to dictate
business rules for ISPs. If anywhere - and the ISPs will hotly
dispute even this - it is properly the place of the Regional Internet
Registries, ISP associations, and bilateral contracts. What the IETF
understands that it is being asked in this context is what the design
goals and assumptions are that went into the system, and should be
considered in writing those rules.
As such, the IETF's advice cannot be summarized as 'allocate,
Baker & Azinger Expires April 19, 2007 [Page 25]
Internet-Draft IPv6 multihoming trade-offs October 2006
aggregate, and filter at the following fixed prefix lengths' or 'the
IETF knows its not its place to dictate a boundary but if a boundary
were to be chosen /___ would be suggested'. It must be stated in
terms of design guidelines that must in turn be interpreted in the
context of the policies and intentions of the registries and ISPs.
The design guidelines that the IETF considers most critical are
these:
o In the general case, the number of prefixes distributed via
routing is a direct byproduct of the level of aggregation of
prefixes. Since large route tables require more time to exchange
than smaller ones and more computation to interpret, smaller route
tables - and therefore a higher level of prefix aggregation - are
to be preferred over larger ones [RFC2008]. The IETF recommends
in the general case that ISPs exchange and filter at the length of
prefix delegations from the registry to the ISP. At this writing,
the most frequent delegation is a /32, but there are shorter
prefixes such as /19 [ARIN-MICRO] [ALLOCSIZE-RIPE]
[ALLOCSIZE-LACNIC] [ALLOCSIZE-APNIC], and longer ones such as /48
PI space as well. They SHOULD be announced without further
deaggregation and filtered to their allocation length.
o Prefixes assigned by registries are not all of the same length.
For example, at this writing ARIN is assigning PI prefixes for
medium-sized enterprise use at /48, and to ISPs and large
enterprises at /32, and some ISPs reportedly have assigned /56
prefixes to their customers. Peer ISPs SHOULD filter prefixes
received, and the ISPs announcing them SHOULD provide the means
for them to readily do so.
o Business considerations will always override general rules in
specific cases. As such, an ISP that contractually agrees to
accept a PA prefix from a customer that was assigned by another
ISP needs to coordinate with that ISP, its own transits, and its
own peers, to enable them to properly assess the route. This is
mostly easily accomplished through a validation database
established by mutual agreement or by a routing mechanism such as
the use of a BGP community
[I-D.van-beijnum-v6ops-pa-mhome-community] (which will in turn
require receiver validation). This will allow the receiving ISP
or customer to determine whether it will accept the prefix under
its own business rules, and manage its ingress filters in the data
plane. However, it SHOULD be understood that even if an ISP
accepts a more specific PA prefix from a customer, this cannot be
guaranteed to be routed by other transit providers in the chain,
which is what makes multihoming as described in Section 3.2
addresses problematic.
Baker & Azinger Expires April 19, 2007 [Page 26]
Internet-Draft IPv6 multihoming trade-offs October 2006
o For the purposes of origin-filtering policies such as used in
Secure Origin BGP [I-D.white-sobgp-architecture], the IETF further
recommends that the association of a multi-homed prefix (PA or PI)
with an Autonomous System number SHOULD be documented in an
appropriate database in the Internet Routing System, perhaps at
the allocating registry.
o Despite the different policies set in different regions, the
routing table is a unique one, shared globally. Any delegation
policy SHOULD be widely published in a form that enables ISPs to
readily filter announcements to the prefixes that were in fact
allocated.
o In the event that ISPs agree to advertise prefixes longer than the
allocation boundary to each other for traffic engineering
purposes, the principles of [RFC2008] and considerations of
Section 2.2 remain valid and important. For scalability, the
prefixes advertised should be no longer than necessary to
accomplish the goal. This document conjectures that the correct
unit of advertisement in this case is the prefix assigned to an
Internet Point of Presence or POP.
In addition, the numbers would suggest that the operational
communities seriously consider the deployment of some form of
exchange-based addressing for the aggregation of multihomed SOHO
prefixes in addition to using PI addressing for ISPs and for ISP-
sized organizations that require multihoming. While the use of PA
Prefixes for non-multihomed networks remains very promising, the
explosion of the route table resulting from using PA prefixes as if
they were PI prefixes, as discussed in Section 3.2 will have direct
costs to the ISPs in terms of memory, power, and money.
5. IANA Considerations
This memo requests no services from the IANA.
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are
required. From the author's perspective, it may therefore be removed
upon publication as an RFC at the RFC Editor's discretion.
6. Security Considerations
As discussed, each of the proposed forms of multihoming have
advantages and disadvantages. PI multihoming is the "gold standard"
by which all others are measured in [RFC3582]. But it has serious
Baker & Azinger Expires April 19, 2007 [Page 27]
Internet-Draft IPv6 multihoming trade-offs October 2006
scaling difficulties in the sense that it would inject tens of
millions of prefixes into the backbone. PA multihoming that mimics
PI multihoming suffers from the same issue, and additionally makes
the Internet's present routing architecture complex and in some ways
unpredictable by the edge network. PA multihoming as described by
shim6 is significantly more scalable, but fails to met many of the
requirements that service providers believe to be important.
Exchange-based addressing is both scalable and generally meets
[RFC3582]'s other requirements, but requires changes to the business
model of the backbone.
This document does not address the protocols or the architecture of
that system, but it does make observations regarding the trade-offs
in their use. As such, the recommendations do not increase or reduce
the security of the architecture or of Internet routing, but when
mis-used or mis-applied, problems can result.
7. Acknowledgements
This discussion occurred in the IPv6 Operations Working Group, and
specifically within a design team that included the authors, Alain
Durand, Brian Carpenter, Iljitsch van Beijnum, Jordi Palet Martinez,
Kurt Lindqvist, Pekka Savola, Randy Stewart, Thomas Narten, and Tony
Hain. Comments were also received from Russ White, Paul Wilson, and
Eliot Lear. Miya Kohno orchestrated a very helpful discussion with
several Japanese operators, which included Ichiro Mizukoshi, Arifumi
Matsumoto, Yasushi Ono, Yasuo Igano, Kuniaki Kondo (JANOG chair), and
Akinori Maemura (JPNIC chair). .
8. References
8.1. Normative References
[RFC2008] Rekhter, Y. and T. Li, "Implications of Various Address
Allocation Policies for Internet Routing", BCP 7,
RFC 2008, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
Allocations to Sites", RFC 3177, September 2001.
Baker & Azinger Expires April 19, 2007 [Page 28]
Internet-Draft IPv6 multihoming trade-offs October 2006
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
[RFC4177] Huston, G., "Architectural Approaches to Multi-homing for
IPv6", RFC 4177, September 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
8.2. Informative References
[ALLOCSIZE-APNIC]
APNIC, "Allocation sizes within APNIC IPv4 address
ranges", <http://www.apnic.net/db/min-alloc.html>.
[ALLOCSIZE-LACNIC]
LACNIC, "LACNIC - Registration Services",
<http://lacnic.net/en/registro/index.html>.
[ALLOCSIZE-RIPE]
RIPE NCC, "RIPE-380 Address Space Managed by the RIPE
NCC", <https://www.ripe.net/ripe/docs/
ripe-ncc-managed-address-space.html>.
[ARIN-MICRO]
ARIN, "ARIN Micro-allocations",
<http://www.arin.net/reference/micro_allocations.html>.
[BGP-UPDATE]
Huston, G., "BGP Update Report",
<http://bgpupdates.potaroo.net/instability/bgpupd.html>.
[I-D.ietf-shim6-multihome-shim-api]
Komu, M., "Socket Application Program Interface (API) for
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-00
(work in progress), October 2006.
[I-D.ietf-shim6-proto]
Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim
protocol", draft-ietf-shim6-proto-05 (work in progress),
May 2006.
[I-D.ietf-v6ops-nap]
Velde, G., "IPv6 Network Architecture Protection",
draft-ietf-v6ops-nap-03 (work in progress), July 2006.
Baker & Azinger Expires April 19, 2007 [Page 29]
Internet-Draft IPv6 multihoming trade-offs October 2006
[I-D.ietf-v6ops-natpt-to-exprmntl]
Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work
in progress), October 2005.
[]
Beijnum, I., "BGP Community for PA Multihoming",
draft-van-beijnum-v6ops-pa-mhome-community-01 (work in
progress), September 2006.
[I-D.white-sobgp-architecture]
White, R., "Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)",
draft-white-sobgp-architecture-02 (work in progress),
June 2006.
[METRO] Deering, S., "Metro-Based Addressing", July 1995, <ftp://
ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/95jul/
presentations/delegation/deering.slides.ps>.
[RFC1265] Rekhter, Y., "BGP Protocol Analysis", RFC 1265,
October 1991.
[RFC1787] Rekhter, Y., "Routing in a Multi-provider Internet",
RFC 1787, April 1995.
[RFC1881] Internet Architecture Board and Internet Engineering
Steering Group, "IPv6 Address Allocation Management",
RFC 1881, December 1995.
[RFC1887] Rekhter, Y. and T. Li, "An Architecture for IPv6 Unicast
Address Allocation", RFC 1887, December 1995.
[RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering
Overview: Why would I want it and what is it anyway?",
RFC 2071, January 1997.
[RFC2073] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S., and J.
Postel, "An IPv6 Provider-Based Unicast Address Format",
RFC 2073, January 1997.
[RFC2374] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global
Unicast Address Format", RFC 2374, July 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Baker & Azinger Expires April 19, 2007 [Page 30]
Internet-Draft IPv6 multihoming trade-offs October 2006
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894,
August 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
Requirements for Stateless Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations",
RFC 4116, July 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005.
Authors' Addresses
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Email: fred@cisco.com
Baker & Azinger Expires April 19, 2007 [Page 31]
Internet-Draft IPv6 multihoming trade-offs October 2006
Marla Azinger
ARIN AC
Vancouver, Washington 98662
USA
Phone: +1-360-816-3034
Email: marla_azinger@czn.com
Baker & Azinger Expires April 19, 2007 [Page 32]
Internet-Draft IPv6 multihoming trade-offs October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Baker & Azinger Expires April 19, 2007 [Page 33]