Multi-6
Internet Draft T. Hain
Document: draft-hain-ipv6-pi-addr-use-00.txt Cisco
Expires: December 2001 June 2001
Application and Use of the IPv6 Provider-Independent
Global Unicast Address Format
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This document discusses the expected use of the address format
discussed in the companion document [2] in the Internet. In addition
to covering implementations where it adds value in managing the
growth of the Internet routing tables, the document will discuss
implementations which should be avoided due to the negative impact
on the routing tables.
Conventions used in this document
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 [3].
Hain Expires - December 2001 1
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
Status of this Memo...................................................1
Abstract..............................................................1
Conventions used in this document.....................................1
Introduction..........................................................3
IPv6 Provider-Independent Global Unicast Address Format Overview......4
Meritorious implementations...........................................5
Troublesome implementations...........................................6
Routing issues........................................................7
Operational Issues...................................................10
Considerations.......................................................11
Address Selection..................................................11
Partitioning.......................................................12
Path Selection.....................................................12
Renumbering........................................................13
Relationship to telephony addressing model.........................13
General Considerations.............................................14
Security Considerations..............................................15
Relationship to Multi-6 WG multi-homing requirements.................15
Redundancy û.......................................................15
Load Sharing û.....................................................16
Performance û......................................................16
Policy û...........................................................16
Simplicity û.......................................................16
Transport-Layer Survivability û....................................16
Scalability û......................................................16
Impact on Routers û................................................16
Impact on Hosts û..................................................17
Interaction between hosts & routing system û.......................17
Operations and Management û........................................17
Random thoughts....................................................17
References...........................................................18
Acknowledgments......................................................18
Author's Addresses...................................................18
Hain Expires - December 2001 2
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
Introduction
This document discusses the application of the Provider-Independent
global unicast address format for the IPv6 address assignment. This
address format is based on WGS-84 [4] derived geographic location.
There have been many debates about the value of geographic versus
provider based allocation schemes. One interesting observation about
this debate is the overriding assumption that the Internet will have
to be built using one or the other rather than leveraging the
strengths of each in context. The intent here is not to reopen that
debate, but to present the case that the approaches can be used in a
complementary manner. This document will highlight the operational
configurations where the geographic-based provider-independent
addresses provide value in minimizing the size of the global routing
table, as well as those situations where they should be avoided in
favor of the provider aggregates.
Provider based address aggregation has its roots in the IPv4 routing
table growth limiting effort known as CIDR [5]. The basic premise is
that routing entries can be summarized in such a way that a large
number of sites, which subscribe to the same service provider,
generate a single entry in the global inter-provider routing table.
While this works well when sites connect to a single provider, it is
inadequate for providing a site with redundant access through
multiple service providers. Sites that expect redundant service
through multiple service providers require the global routing table
to carry an explicit entry for the full-length prefix allocated to
the site. Traditionally this was accomplished by having a site
acquire an address allocation out of the pre-CIDR range of the IPv4
address space, which remained provider-independent (thus the term PI
space). Lately this process has evolved into simply arranging with
each of the service providers involved to announce the longer prefix
allocated to the site by one of those providers. While the effect on
the global routing table is the same in either case, the act of
'punching holes' in provider aggregates increases operational
complexity, and makes it very difficult for a site to disconnect
from the service provider that allocated the address prefix.
As noted, the prime motivation for CIDR deployment was reduction on
the size of the IPv4 routing table. The mechanism, of aligning site
allocations with the provider they attached to, worked well for this
purpose, but at the same time was directly contrary to the needs of
the site for provider independence. The primary operational
motivation for sites to connect to multiple providers and/or regions
is resiliency. Other factors that come into play are managing
overall cost, and optimizing performance or balancing load.
Collectively these issues drive sites away from the nicely
structured single-connection hierarchical model that is the
foundation of Provider-Aggregatable [6] allocation. At the same
time, due to the evolving state of infrastructure deployments, the
concepts of geographic locality and least-cost locality often don't
Hain Expires - December 2001 3
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
match. The consequence of the collective situation is that no one
approach to addressing will solve the entire set of route scaling
problems.
The goal of the Provider-Independent address format is restoring the
integrity of Provider-Aggregatable prefix format for use by the
single homed sites, while simultaneously providing a scaleable
approach for multi-homed sites. This is accomplished by relating one
of the IPv6 address prefixes of the multi-homed sites to an
unambiguous geographic reference point in a way that summarizes well
over physical distance. This is not an attempt to have routers
understand geography. Rather it is simply a mechanism to allocate
address prefixes to sites in a way that can be abstracted into a
minimum number of routing table entries from a distance.
This approach has a strong advantage over the IPv4 PI space (which
is effectively randomly assigned) in that there is a clear structure
that allows for efficient abstractions. While a site may inject any
full /48 prefix into an attached service provider, it MUST recognize
that other non-attached service providers may be routing on
aggregates of either the Provider-Aggregatable or the Provider-
Independent prefixes.
While this address format is designed to support exchange-based
aggregation in the context of various scope sizes, it is not
dependent on exchanges for it's overall route aggregation
properties. It will provide efficient route aggregation in a global
context when providers in a given scope interconnect by whatever
means (ie: common third party), such that only the shorter prefix is
announced outside that scope. Any provider announcing a short prefix
SHOULD be able to deliver packets to anywhere in the scope, either
directly or through other arrangements. In the case where a service
provider does not interconnect with others in its scope it MUST
advertise the longer prefixes associated with its customers. As this
action is directly contradictory to the goal of reducing the routing
table size, there SHOULD be a strong needs-based justification for
this action.
IPv6 Provider-Independent Global Unicast Address Format Overview
Details of the provider-independent address format are provided in
the companion document [7]. A high level overview is provided here
for local context.
Addresses defined with the Provider-Independent format prefix 0001
are by definition NOT-PORTABLE when a network attachment point
changes geographic locations. Entities that expect identifiers to be
portable across physical location moves MUST use alternatives such
as Provider-Aggregatable prefixes or DNS names.
Hain Expires - December 2001 4
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
Provider-Independent addresses are constructed using a bit
interleave of the WGS-84 based latitude and longitude of a site.
While the available 44-bit field allows for resolution of a grid
approximately 10 meters on a side, addressing privacy concerns may
require the allocation to be at 40-bits with the expectation that
site assignments in that 40 meter grid will be managed by the
smallest appropriate local jurisdiction. Accommodating areas of
dense population may require that the grid size be increased to 150
meters or more to allow a sufficient number of bits in the locally
assigned field identifying the specific site. This will allow more
flexible assignments for multi-story buildings and business centers
with multiple independent sites per geographic grid. Actual
assignments within a geographic grid SHOULD be a local
jurisdictional issue (matching scope jurisdiction; building owner,
community board, local government, etc.), and independent of any
service provider. The only rules are that the allocation point MUST
be contained within a grid, and any overlap must be coordinated. If
a grid needs to be expanded to accommodate density, it MUST avoid or
otherwise coordinate use of any existing values that fall within its
new boundaries.
Specification of the WGS-84 reference point SHOULD be the
responsibility of the local jurisdiction (who may defer to the
layer-1 service provider for expediency), and SHOULD represent the
demarcation point of the layer-1 service. In the case where
reference points overlap, the local jurisdiction SHOULD provide
coordination over the smallest workable scope.
In the case where the local jurisdiction also acts as a local
service provider to its tenants (ie: hotel, apartment, or high-rise
business complex) or is unable to expand the scope through a shorter
prefix, it MAY choose to allocate prefix lengths longer than /48, as
appropriate for the number and needs of its customers. In any case
the allocation MUST NOT exceed 64 bits in length to preserve the
Interface ID portion of the address.
Constructive implementations
The geographic nature of the Provider-Independent address format is
designed to allocate addresses to sites which aggregate well in
direct proportion to the physical distance from the site. It also
allows a locally connected site to easily change providers without
impacting the nodes or connections within a site.
In this context, one appropriate use of the Provider-Independent
address format is a site connecting to multiple providers within a
constrained geographic scope such as a city (actual size depends on
the local cooperative interconnection between service providers).
When used in this way, only those routers providing service within
the scope need to know the details about the interconnections, and
the global routing table would see a single entry for that scope.
Hain Expires - December 2001 5
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
Another appropriate use of the Provider-Independent address format
is when a site will be switching service providers. By preferring
the Provider-Independent address prefix for a period overlapping the
switch, a site may be able to maintain connections while the new
service is installed and the old removed.
A third appropriate use would be for an organization providing
global content services to provide clients with a proximity hint.
The longest match between the list returned from DNS and the PI
address of the client should provide the closest physical proximity
(though not necessarily the closest topological proximity).
Troublesome implementations
This address format does not provide any benefit to the routing
system for sites that insist on redundancy through direct
connections to providers who do not provide service for their
location (such as a site in Chicago with a direct connection to a
provider who's service area is London). Essentially these sites will
require the full /48 prefix to be carried globally, independent of
address format type. If the arrangement were simply for direct
access to the customers of the remote service provider, and not
global redundancy, then this prefix would be suitable. On a case-by-
case basis the design goals of such sites may show a slight
preference toward one of the types, but terminating provider
policies will determine the actual result.
The Provider-Independent address allocation mechanism SHOULD NOT be
used on a temporary access network (such as a dial point of
presence), because scaling routes to sites attached this way are
best addressed through provider based allocations consistent with
Provider-Aggregatable [6]. The reasons for this are:
1) Temporary access endpoints can not expect to maintain higher-
layer connections between physical access events, and therefore
should be using a Provider-Aggregatable allocation to minimize
the scope of their impact on the routing system as they come and
go.
2) The location of the intermittent endpoint is unknown so the
address would have to be based on the access point location. If
such an access point were scaled to handle 10,000 attachments it
would have to subsume the neighboring addresses for the 2.5 km
square it is centered in. Since the currently deployed temporary
access points tend to be located in densely populated areas,
using them with geographic rather than provider based addresses
would have the maximum negative impact.
That said, geography provides distinguished meaning to the term
'home address', so a site using Mobile-IPv6 [8] with provider-
independent addresses as the home address and the current value from
the intermittent access provider for the care-of-address could
Hain Expires - December 2001 6
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
expect to maintain connections across access events. Note this does
not mean the geographic address is allocated or even known to the
intermittent access point. The routing system doesn't need to know
the binding for the geographic address since packets are routed
according to the Provider-Aggregatable care-of-address. The home-
agent would need a way to inject its provider-independent prefix and
current binding. This could be a form of tunnel-broker within a
region.
Routing issues
The basic mechanism is a bit interleave of the WGS-84 latitude and
longitude values with the intent to minimize routing table size.
While the prefix length MAY be established on any bit boundary, the
operational choices will naturally be limited by the requirement for
all service providers at that boundary to directly interconnect with
all others for traffic delivery. The result is that at some point in
the hierarchy all service providers for a scope have to agree on the
boundary then share routes and traffic. It becomes an engineering
tradeoff between the size of the routing table, and the number of
points where interconnections occur.
Note: exchanges for a scope don't have to be physically located
in the scope of interest; they are simply required to have
service provider agreement about which scopes are aggregated at
specific exchanges
Operational experience shows that over time service providers have
deployed exchanges with 40 û 600 km spacing loosely based on
connected population density [9] (2-1991 -> ~ 200-2001). At the same
time private interconnections between service providers have been
occurring to bypass congestion at these exchange points. Both
interconnect strategies work with the Provider-Independent address
format, as long as the scope of the prefix being advertised is
contiguous.
Care must be given to the fact that when an area scope is too large,
it may become partitioned by natural terrain based boundaries. In
these cases, either the more specific prefix values must be
advertised, or the providers involved must carry the specifics
necessary to heal the partition.
At a high level injecting /48s of any format has the same effect on
the local routing table. The difference between the schemes is that
for the Provider-Aggregatable allocation scheme to work for backup
purposes the full /48 needs to propagate globally, where as in the
provider-independent case the prefix may be aggregated as a function
of distance from the alternative providers.
As a simple 2-level example, global Core routing (aka: DFZ) might be
based on longest match of sparsely populated table using fixed first
3 bytes (FP + 20 bits) to find a region, while Regional routing
Hain Expires - December 2001 7
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
might be based on longest match of moderately populated table using
next 2-3 bytes to find neighborhood-site.
If a router believes it can get to the entire concatenation it
should announce a short prefix, if not it will need to announce
specifics. All providers would need to be aware of the current scope
of its ability to deliver within a region. If a region were to
become partitioned the upstream announcements would need to reflect
the current scope.
Implications:
Announcements in general:
'have arrangements to deliver everywhere within this scope'
Announcements upstream (provider) û
shortest prefix with expectation of full coverage
Announcements counterpart (peer) -
explicit downstream lists need to be exchanged
Announcements downstream (customer) û
explicit customer routes within the downstream's scope + list
of short prefixes
Example 1:
Network DEF provides transit services within Europe. For global
connectivity it subscribes to provider ABC. It has local transit
agreements with competitive service providers GHI and JKL. The
company XYZ is a customer of both DEF and JKL with offices in Paris
and Moscow. XYZ policy is to prefer the internal network to the
public network.
-------
| ABC |
-------
/ |
------ ------ ------
| DEF |-| GHI |-| JKL |
------ ------ ------
\ '-----------' /
------ ------
|XYZ-P|-----|XYZ-M|
------ ------
Route announcement between:
XYZ-P & XYZ-M full provider-independent and provider-dependent /48
of the each site
XYZ-P & DEF full provider-independent /48 of this site up; DEF
explicit customers + 1::/4 down
XYZ-M & JKL full provider-independent /48 of this site up; JKL
explicit customers + 10::/8 down
DEF & GHI explicit customers + 1092 of XYZ-M
DEF & JKL explicit customers
JKL & GHI explicit customers + 1080 of XYZ-P
Hain Expires - December 2001 8
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
DEF & ABC 1080 up; 1::/4 down
GHI & ABC 1080 up; 1::/4 down
ABC & peers 1080 out; explicit /16s from each
Nodes in the Paris office of XYZ would use the 1092::/16 prefix when
talking to sites in the Moscow region, and conversely nodes in the
Moscow office would use the 1080::/16 prefix when talking to sites
around Paris.
If XYZ opens an office in New York, it would announce that each of
that site's /48 prefixes to the other two sites, but that should not
extend beyond to DEF or JKL. Nodes within the XYZ network SHOULD NOT
use the US prefix to talk to nodes in Europe unless the internal
connection across the Atlantic is unavailable. In that case, only
the New York office nodes would be receiving the local provider-
independent prefix so they might choose to use it. If the provider
serving the New York office were acquiring its allocation from ABC,
the address selection longest match would lead hosts to select
Provider-Aggregatable.
Example 2:
ISP-1 prefers connections to region 2 via ISP-2, and accepts the
short aggregate over that path. ISP-3 has an arrangement with ISP-1
to provide service for its customers over a direct connection
between them, and announces the Provider-Aggregatable prefix along
with the Provider-Independent specifics of its customers.
Sub-scenario 1:
The Site uses its provider-independent address. Customers of ISP-1
would use the path via ISP-3 due to the longer prefix announcement.
If the link between the Site and ISP-3 failed, ISP-3 would reroute
via ISP-4 due to the intra-region announcements. ISP-3 may choose to
stop announcing the Site prefix in this case, which would cause ISP-
1 to route via ISP-2 due to the short region prefix announcement.
Connections between ISP-1's customers and the Site would remain
intact during these rerouting events.
Sub-scenario 2:
For cost reasons the Site prefers ISP-4. Implementing the site's
preference would require them to use the prefixes from each
provider, and then via local policy order the selection rules
appropriately. Customers of ISP-1 would not be aware of the site's
preferences, and would use their own local policies when initiating
connections to decide between the values returned by DNS.
Connections between ISP-1's customers and the Site would drop if the
connection from ISP-4 to the Site, or ISP-2, failed.
------ | ------
|ISP-1 |------|-----|ISP-2 |-
------ | ------ \
\ | | \
\ | ------ \ ------
Hain Expires - December 2001 9
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
----|-----|ISP-3 |----|ISP-4 |
| ------ ------
| \ /
| ------
1 | 2 | Site |
| ------
Region Boundary
Example 3:
|
ISP-1 ---- ISP-2 --|- ISP-3 -
| \_ | |/ | \
| \_ | _/| | Site-2
| \ | / | | /
ISP-4 ---- ISP-5 --|- ISP-6 û
/ |
Site-1 |
Scope Boundary
If the link between ISP-3 & ISP-6 failed causing a partition of the
scope, specifics announced to ISP-5 could be used to heal.
Question about how does an ISP find out what scope they can
aggregate. ???
If everyone just starts announcing site specific /48's, and use the
upstream backpressure to correct the situation, there is no need for
a specific registration. Clearly all of the significant players in a
region need to communicate well to contain the specifics, but the
consequence of not doing that is simply a larger table at the next
larger boundary. Providers at the larger scopes are motivated to
encourage providers in the smaller scopes to interconnect locally
and avoid announcing the specifics any wider than necessary.
Operational Issues
Multi-site networks SHOULD internally advertise all the appropriate
natural prefixes the network manager is willing to use and let the
rules [10] sort it out. This would result in systems selecting a
source address that most closely matches the destination. Thus
return traffic would naturally be directed toward the site boundary
closest to the destination site (ie: traffic would traverse the
public network as little as possible).
How a site that is multi-homed by fixed and dial-based access
decides between provider and geographic based addresses? Basically
it comes down to the relationship between the access paths. If they
Hain Expires - December 2001 10
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
are to the same provider then Provider-Aggregatable addressing is
appropriate. If the dial-path were to a different provider than the
fixed line, it would make more sense to use the Provider-Independent
address because the site would maintain its prefix and active
connections through the routing switch without the need to globally
punch a hole in either provider based aggregate.
Observations and Considerations
Address Selection
IPv6 defines the case that nodes will have multiple addresses, so
having a set of Provider-Independent ones as well as potentially
several sets of Provider-Aggregatable ones should not present any
particular concerns to the end nodes. The primary technical issue
will be limitations in the size of a DNS response packet. Managers
of large multi-national organization networks should exercise
operational care to administer the distribution scope of any prefix.
It is generally unlikely that nodes in a 10,000-seat office complex
would be expected to use the local Internet access provided for a 3-
person office halfway around the world. If this is true the small-
office prefix SHOULD NOT be propagated that far, because doing so
would only clutter and slow the address selection process for the
larger segment of the organization's network.
Longest match should be enough to decide between Provider-
Aggregatable and Provider-Independent prefixes. (Is this true?)
FP's alone would bias toward geographic, but the reserved bits make
TLAs appear longer. If the two sites share some part of the provider
hierarchy and some degree of geographic locality, it will become a
case-by-case issue as to which one is longer. Worst case they are
geographic neighbors using different providers with no relationship
in the TLA. Longest match rule would cause hosts to select PI based.
Contrasting case, they share the same provider but are on opposing
sides of the globe. Longest match rule would cause hosts to select
Provider-Aggregatable prefix.
The case where one end is single-homed provider-dependent and the
other is multi-homed provider-independent ...
This presumes that the multi-homed site is not informing its hosts
or DNS about any provider prefixes it may have; otherwise the TLA
length issue would prevent it. ...this may be the case for a content
provider trying to do global load distribution...
Explicitly causing a preference to Provider-Independent would
require a local policy override of the selection rules.
Src/dst selection would only know these are global unicast and
handle appropriately.
If the provider of the dependent site is not interconnected within
the geographic scope of the multi-homed site, traffic flow may take
a less-than-optimal route from the perspective of one or the other
Hain Expires - December 2001 11
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
endpoint, but will follow the optimal route based on current inter-
provider policies.
Partitioning
Discuss what happens when the peering in a scope breaks down.
Do the providers announce longer prefixes or live with the black
hole?
How can they tell the difference between expected holes in a peer's
advertisement, customers switching providers, and a partition?
Strong recommendation for 2 or more interconnects in a scope.
In the case of example 2 above: if the connection between ISP-3 &
ISP-4 dropped, the only difference this would make is if ISP-3 had
been transiting traffic from ISP-1 to ISP-4 for ISP-4 multi-homed
customers that are not customers of ISP-3 (would require a different
scenario policy). In this case, ISP-1 should be receiving the short
region-2 prefix announcements from both ISP-2 & ISP-3, so it becomes
a regional healing policy issue to be worked out locally between
ISP-2, 3, and 4. The most resilient case would be for ISP-3 and 4 to
maintain a short prefix for their own scope pointed at ISP-2. This
would cause any partitions in that scope to be healed via the
specifics being announced to ISP-2. The cost to ISP-2 would be
transiting intra-region traffic, and dealing with connection
attempts for PI addresses that are not currently being announced
even when the region is intact.
Another approach would be for the scope-associated operators to
participate in a route server that knows the set of PI addresses in
use within the scope and the relationship of AS's. If the scope
becomes partitioned, either the active set of prefixes changes, or
the relationship between the AS's change. Either way it should be
possible to respond appropriately to a partition as long as the AS
doing the healing has full routes for the scope.
If a layer-1 service provider also provides layer-3 service, should
their layer-3 service simply announce the provider-independent
aggregate for the layer-1 coverage and let more specifics from
layer-3 competitors override?
Advantage: smaller table
Cost: they eat connection attempts when the competitor
partitions from the scope or script-kiddies are trolling the PI
space.
Path Selection
How does a source select the correct first hop?
Many arguments about address selection revolve around the host's
knowledge (or lack thereof) about the technically optimum path for
the metrics of bit-rate, loss-rate, delay, and jitter, but they
generally avoid the topic of actual access cost. One of the issues
Hain Expires - December 2001 12
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
is that the most popular current business model assumes that a
subscriber pays for access based on the capacity of or actual bits
delivered to their site. In this environment the bias toward the
technical metrics for deciding sending rules is understandable since
a source can't know the cost optimization of an arbitrary
destination site. What a source can know is its cost for outbound
access (assuming the business model is based on that), and therefore
could bias its first-hop provider selection on a real local business
policy. This is independent of the choice for either a Provider-
Aggregatable source address, or a Provider-Independent one.
Basically a destination address should be chosen based on longest-
match with the lowest cost first hop for the available address set.
ie: the set of possible destination addresses needs to be aligned
with the set of possible source addresses resulting in a (local
outbound policy) lowest cost selection of the pair. Regardless of
the host selection, the border router is in control of the actual
hand-off of the packets, therefore ultimately in control of costs
(when based on outbound rather than the current inbound).
*** actually this would work for destination based costs as
well û the basic issue is that the source address needs to be
picked first based on the lowest resulting cost for the return
packets, then let longest match resolve the destination.
While many discussions assume the destination's ISP choice
determines the source's routing; the reality is the source's ISP
choice has always determined at least the first hop.
The other consideration is PI may cause the traffic flow
between ISPs to flip from dump-early to dump-late (in smallest
peering scope of destination). The number of packets carried
should remain the same, but the transit agreements may be the
opposite direction from Provider-Aggregatable allocations. The
only question I see as a sticking point is; will transit
providers be willing to charge for ingress offered loads in
addition to the egress they charge for today? If so they will
be happy because they are getting paid to carry traffic, if not
they will really be against this since it would cause them to
carry traffic they are not getting paid for.
Renumbering
Even though this address format is derived from geographic
information, renumbering is not required as devices move within a
network, unless the public demarcation at layer 1 changes as a
result.
Relationship to telephony addressing model
This is fundamentally the telephone solution.
This is not the telephone model. In that environment as the address
space was divvied up, the resulting provider boundaries happened to
Hain Expires - December 2001 13
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
align with the political notion of geography at that time. The
Provider-Independent address format is even devoid of any political
context (beyond agreement on WGS-84 as the reference tool).
IF we had a pretty solid "distance = cost" dominant cost model then
there would be a fair incentive for local interconnection. If we
_also_ had a different inter-provider settlement model where every
packet was purchased from its originating provider and on-sold to
its terminating provider (to borrow some PSTN settlement terms with
a reselling margin equal to the marginal cost of transit), then
there would be an even stronger case for local interconnection, and,
furthermore if the packet accounting settlement rates were fixed
according to some imposed industry model, then the case for
regionally aggregateable addresses would be pretty solid.
General Considerations
In a few places there may exist regions with extreme densities
(greater than 1M independent multi-homed sites per 10 km grid);
where it is not reasonable to expand any given grid to a
sufficiently large area to provide enough addresses for local
administration. Generally these are expected to be adjacent to
sizable regions of water where it is highly unlikely there will ever
be permanent Internet service provided. The local jurisdiction for
areas of extreme density MAY choose to map a nearby unusable grid
onto an area requiring more addresses. When this is done the
jurisdiction MUST coordinate with neighbors to avoid duplication.
> Also the cost pressure is going to be against local exchanges
> and in favour of large regional exchanges.
Take the example of an 8-bit reference using the PI format. The
globe divides into 128 regions, with 68 unusable (32 are polar, 36
are basically water). Of the remaining, it appears that 16 that map
into current telecommunications centers. While some neighboring
regions may find it advantageous to leak full routes between
themselves, there should be at least 12 that end up summarized. Yes
a region has flat routes, but it doesn't need 3/4 of the global
table, and all but a couple of cases will probably do better than
that. The interconnection robustness at this scale is fairly high,
so we could get some gain. Within the regions, it becomes a mater of
local politics and business practice as to how much further the plan
can go. Certainly it will be more difficult in either Europe or the
US than all the others combined, but if you write off those 4
regions as hopelessly intertwined there is still an opportunity for
significant gain in the rest of the world not having to know the
details of that mess.
> Not if the solution is worse than the problem. I believe that
> geo addressing simply reproduces pre-CIDR IPv4, since it is based
Hain Expires - December 2001 14
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
> on unrealistic assumptions about inter-ISP connectivity.
Only over a given scope. The CIDR roll out effort also showed what
backpressure from the top could do to constrain entropy. It also
showed what happens if you push too hard. When you try to over-
engineer and enforce controls for maximum optimization you will
loose control and be back where you started. This is where the
rewriting the goop plan falls flat, because they are targeted at
absolute optimization in the middle, without concern for systemic
impact.
In either case, geo or provider, if provider policies allow the
entire prefix to be carried in the DFZ there is nothing a protocol
design can do about that. All that can be done is provide a tool
that allows connectivity to be maintained when prefixes are
abstracted. If a site wants absolute global control of its routing
policy it will have to arrange for the full /48 to be carried and FP
makes no difference.
> Only if you revolutionise ISP interconnection strategies and
> find some way to change the underlying economics.
There is no need to change human nature, just provide a reasonable
tool for aggregation then expect to charge for carrying explicit
routes when people insist on them. Match the economics to human
nature rather than trying to invent a technological restraint
system.
Security Considerations
While there may be concerns about location privacy raised by the
geographic scheme, there is nothing inherent in this address format
that would raise any more security considerations than any other
global addressing format. If location privacy were an issue it would
be wise to avoid this mechanism in favor of location independent
mechanisms such as provider based [6] allocations.
Relationship to Multi-6 WG multi-homing requirements
The multi-homing requirements for IPv6, consistent with current IPv4
usage, are detailed in [11]. The capability of the Provider-
Independent address format to deal with each of the points in that
document will be addressed here.
Redundancy û
The Provider-Independent address format is designed to provide
redundancy between attached providers. By having the site prefix
independent of all service providers, link and routing failures in
one provider should be completely transparent to the site. The
primary case where things may break is a link or routing failure in
a part of the path that lacks redundancy.
Hain Expires - December 2001 15
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
Load Sharing û
The Provider-Independent address format allows sites to manage
outbound traffic without concern for undue filtering in the routing
system. It also allows for a course-grain load sharing on inbound
traffic, by managing service provider subscriptions to achieve the
desired traffic flow matrix.
Performance û
The Provider-Independent address format allows traffic to arrive
from a variety of sources over the set of available paths, but does
not explicitly provide for remote flow control. A site may exercise
some course level of remote traffic flow management by arrangements
for service from multiple providers. At a minimum, traffic from the
other customers of an attached provider would follow the site's path
to that provider, and not transit any other provider.
Policy û
Traffic class alignment as policy routing is not an IP routing
issue. As such the Provider-Independent address format will not
offer any explicit support. Achieving the goal of this bullet is
best met with a mix of Provider-Independent and Provider-
Aggregatable prefix announcements.
Simplicity û
The target of the Provider-Independent address format is simplicity,
both in the method of allocation, and in the routing expectations.
The primary increase in complexity over current IPv4 deployments is
the requirement for service providers within a short prefix scope to
be capable of delivering traffic to all other providers serving the
scope.
Transport-Layer Survivability û
The Provider-Independent address format explicitly deals with
transport-layer survivability by isolating the connection from the
intervening providers. As long as the routing system converges
within the timeout period of the transport-layer, the connection
will survive.
Scalability û
No one approach will solve all scalability concerns. An appropriate
mix of Provider-Independent and Provider-Aggregatable will solve
most concerns without undue complexity in either the host or the
routing system.
Impact on Routers û
The impact on routers outside a region is a significantly smaller
routing table, both from the reaggregation of the provider prefixes
and from the ability to abstract geographically distant sites.
Within a scope, the full routes need to be carried, but this is no
worse than the holes punched in provider aggregates, and can be
managed through interconnecting at smaller scopes.
Hain Expires - December 2001 16
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
Impact on Hosts û
Hosts will have an additional address to select from. Using longest-
match rules should easily sort between Provider-Independent and
Provider-Aggregatable prefixes. Other than that they may choose to
use this as a distinguished form of 'Home' address for mobile
applications.
Interaction between hosts & routing system û
Routers providing for IPv6 auto-configuration through announcement
of the site prefixes will have an additional one in the list.
Operations and Management û
The mechanism for deriving the Provider-Independent address is
specifically designed to simplify this operations issue by using the
globally ubiquitous WGS84 system of measurement.
Random thoughts
For global load-balancing hints to work all nodes will need to know
their PI address, even if they never use it for anything else.
The combination of Provider-Independent & Provider-Aggregatable
should reduce the DFZ part of any router's table to < 256 entries.
Local customers + administrative policy overrides of aggregates will
make the entire table larger, but scale is directly controlled by
the local administration.
Due to the provider based allocation & interconnection matrix a
multi-homed site may receive 8-16 FP-001 prefixes. If so, and the
network manager feels this is a burden on the hosts, an appropriate
subset should be selected to announce in the RA. Adding PI will not
significantly make the problem worse.
It is likely that policies would be biased to prefer PI for multi-
homed sites, as connections would survive routing flaps. If so are
they explicitly trading off fine-grained inbound policy control for
resilience? If fine-grained inbound policy control is the goal, can
that be achieved without complete pollution of the global routing
table? How many sites really want inbound policy control vs. simple
path redundancy and fail-over? If the vast majority are the latter
will ISPs finally start charging the few remaining for the former?
Hain Expires - December 2001 17
Application and Use of the IPv6 Provider- June 2001
Independent Global Unicast Address Format
References
1 RFC-2026, Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
2 Geo, Hain, T., "IPv6 Provider Independent global unicast address
format", June 2001
3 RFC-2119, Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
4 http://www.wgs84.com/files/wgsman24.pdf
5 RFC-1518, Rekhter & Li, "An Architecture for IP Address
Allocation with CIDR", September 1993
6 RFC-2374, Hinden, B., O'Dell, M., Deering, S., " An IPv6
Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
7 draft-hain-ipv6-PI-addr-00.txt, Hain, T., "An IPv6 Provider-
Independent (Geographic Reference) Global Unicast Address
Format", June 2001.
8 mobile-ipv6, Johnson, D., Perkins, C., " Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-13.txt, November 2000
9 http://www.ep.net/
10 addr-selection, Draves, R., " Default Address Selection for
IPv6", draft-ietf-ipngwg-default-addr-select-04.txt, May 2001.
11 requirements, Black, et. al., " IP Multihoming Requirements",
draft-ietf-multi6-multihoming-requirements-01.txt, June 2001
Acknowledgments
Early feedback was provided by Iljitsch van Beijnum, Brian
Carpenter, Sean Doran, and Geoff Huston.
Author's Addresses
Tony Hain
Cisco Systems
500 108th Ave. N.E. Suite 500
Bellevue, Wa. 98004
Email: alh-ietf@tndh.net
Hain Expires - December 2001 18