Dear IPng Working Group,
The following text was generated by the IPv6 Directorate, IAB, and IESG
as comments on the draft IPv6 address allocation policy developed by the
Regional Internet Registries (RIRs). Though it is not a product of the
IPng working group, we (the IPng chairs) believe that it is consistent
with the (rough) consensus position of the working group, based on
previous discussions on the ipngwg mailing list, and we wanted to give
the working group a chance to look at it before it goes to the RIRs.
The RIRs will be holding policy meetings starting in mid-September and
the plan is to send these comments to the RIRs on September 1st to give
them time to review it before their meetings, so if you'd like to provide
further input to the text, please do so before Friday of this week.
Steve Deering / Bob Hinden
---------
Comments on IPv6 address allocation guidelines
----------------------------------------------
-DRAFT--DRAFT---DRAFT----DRAFT-----DRAFT 6 of August 25, 2000
During a discussion between IETF and RIR experts at the Adelaide IETF,
a suggestion was made that it might be appropriate to allocate /56 prefixes
instead of /48 for homes and small businesses. However, subsequent
analysis has revealed significant advantages in using /48 uniformly.
This note is an update following further discussions at the Pittsburgh
IETF.
By way of preamble, note that IPv6 partitions address space into public
topology and site topology, and the expectation is that the RIRs will
only need to manage the public topology. However, they may need to
provide guidance and to ensure fairness of address distribution.
Also note that it is widely expected that all IPv6 subscribers,
whether domestic (homes), mobile (vehicles or individuals), or
enterprises of any size, will eventually possess multiple always-on
hosts, at least one subnet with the potential for additional
subnetting, and therefore some internal routing capability.
Note that in the mobile environment, the device connecting
a mobile site to the network may in fact be a third generation
cellular telephone. In other words the subscriber allocation unit
is not always a host; it is always potentially a site.
This then sets the scene for proposing a fixed boundary
at /48 for all subscribers except the very largest. First we
give the arguments for such a guideline, and then we demonstrate
that it is entirely compatible with responsible stewardship
of the total IPv6 address space. Finally a technical annex
goes into some important details.
The arguments for such a fixed boundary are:
- only by having an ISP-independent boundary can we guarantee
that a change of ISP will not require a costly internal
restructuring or consolidation of subnets.
- to enable straightforward site renumbering, i.e. when a site
renumbers from one prefix to another, the whole process,
including parallel running of the two prefixes, would be
greatly complicated if the prefixes had different lengths
(depending of course on the size and complexity of the site).
- there are various possible approaches to multihoming for IPv6 sites,
in addition to the techniques already used for IPv4 multihoming.
More work remains to be done in this area, but it seems likely that
several approaches will be deployed in practice, each with their
own advantages and disadvantages. Some (but not all) will work
better with a fixed prefix boundary. The technical annex
discusses multihoming in more detail.
- to allow easy growth of the subscribers' networks -- no need
to keep going back to ISPs for more space (except for that
relatively small number of subscribers for which a /48 is
not enough).
- to get the ISPs and registries out of the business of judging
sites' needs for address space, unless the site requests more
space than a /48, with several advantages:
- ISPs no longer need to ask for details of their customers'
network architecture and growth plans
- ISPs and registries no longer have to judge rates of address
consumption by customer type
- registry operations will be made more efficient by reducing
the need for evaluations and judgements
- address space will no longer be a precious resource for customers,
removing the major incentive for subscribers to install v6/v6 NATs,
which would defeat the ability of IPv6 to restore address transparency.
- to allow the site to maintain a single reverse-DNS zone covering
all prefixes.
- If and only if a site can use the same subnetting structure
under each of its prefixes, then it can use the same zone file
for the address-to-name mapping of all of them. And, using the
conventions of RFC 2874, it can roll the reverse mapping data
into the "forward" (name-keyed) zone.
Specific advantages of the fixed boundary being at /48 include
- to leave open the technical option of retro-fitting the GSE
(Global, Site and End-System Designator, a.k.a "8+8")
proposal for separating locators and identifiers, which assumes
a fixed boundary between global and site addressing at /48.
Although the GSE technique was deferred a couple of years ago,
it still has strong proponents. Also, the IRTF Namespace
Research Group is actively looking into topics closely related
to GSE. It is still possible that GSE or a derivative of GSE
will be used with IPv6 in the future.
- since the site local prefix is fec0::/48, global site prefixes
of /48 will allow sites to easily maintain a simple 1 to 1
mapping between the global topology and the site local topology
in the SLA field.
- similarly, if the 6to4 proposal is standardized, migration from
a 6to4 prefix, which is /48 by construction, to a native IPv6 prefix
will be simplified if the native prefix is /48
- existing running code and products conforming to existing RFCs
Note that none of these reasons imply an expectation that
homes, vehicles, etc. will intrinsically require 16 bits of
subnet space.
The question naturally arises whether giving a /48 to every
subscriber represents a profligate waste of address space.
Objective analysis shows that this is not the case. A /48
prefix under the Aggregatable Global Unicast Address (TLA)
format prefix actually contains 45 variable
bits, i.e. the number of available prefixes is 2**45
or about 35 trillion (35,184,372,088,832). If we take the
limiting case of assigning one prefix per human, then the
utilization of the TLA space appears to be limited to
approximately 0.03% on reasonable assumptions.
More precisely,
- RFC 1715 defines an "H ratio" based on experience in
address space assignment in various networks. Applied
to a 45 bit address space, and projecting a world
population of 10.7 billion by 2050 (see
http://www.popin.org/pop1998/ ), the required
assignment efficiency is log_10(1.07*10^10) / 45 = 0.22.
This is less than the efficiencies of telephone numbers and
DECnetIV or IPv4 addresses shown in RFC 1715, i.e. gives
no grounds for concern.
- We are highly confident in the validity of this analysis,
based on experience with IPv4 and several other address spaces,
and on extremely ambitious scaling goals for the Internet
amounting to an 80 bit address space *per person*. Even so,
being acutely aware of the history of under-estimating demand,
we have reserved more than 85% of the address space (i.e. the
bulk of the space not under the Aggregatable Global Unicast
Address (TLA) format prefix).
Therefore, if the analysis does one day turn out to be wrong,
our successors will still have the option of imposing much more
restrictive allocation policies on the remaining 85%.
- It has been suggested that even if the above analysis is valid
for terrestrial and near-Earth networks, it may fail for
interplanetary networking and beyond. This is conceivable, but
the challenges in dealing with packet transit times of many minutes
or more, and with such remote deployment, are such as to turn
addressing into a side issue.
- For transient use by non-routing hosts (e.g., temporary addresses
acquired and released while passing through wireless cells, and
for stand-alone dial-up users who prefer transient addresses for
privacy reasons), a prefix longer than /48 would be OK. But a
subscriber who wants "static" IPv6 address space ought
to be allocated a /48 for the reasons given above.
Final comments:
We argue that although careful stewardship of IPv6 address space
is essential, this is completely compatible with the convenience
and simplicity of a uniform prefix size for IPv6 sites of any size.
The numbers are such that there seems to be no objective risk
of running out of space, giving an unfair amount of space to
early customers, or of getting back into the over-constrained
IPv4 situation where address conservation and route aggregation
damage each other.
----
Technical Annex
The technical principles that apply to address allocation seek to balance
healthy conservation practices and wisdom with a certain ease of access. On
one hand, with any resource, one wants to spend wisely; the housewife in
the bazaar doesn't spend more than she needs to for a purchase even if her
purse is unlimited. On the other hand, the IPv6 address space is in no sense
as precious a resource as the IPv4 address space, and unwarranted
conservatism acts as a disincentive in a marketplace already dampened by
other factors. So from a market development perspective, we would like to
see it be very easy for a user or an ISP to obtain as many IPv6 addresses as
she really needs without a prospect of immediate renumbering or of scaling
inefficiencies.
The IETF makes no comment on business issues or relationships. However, in
general, we observe that technical delegation policy can have strong
business impacts. For example, early versions of the IPv6 addressing
architecture proposed that the 50-60 dominant IPv4 ISPs (as demonstrated in
http://www.caida.org/analysis/topology/as_core_network/AS_Network.xml and
http://www.telstra.net/ops/bgptable.html) be given sweeping allocations,
and permitted to redelegate subsets of them to their downstream peers. This
would have the technical effect of biasing routing of traffic between those
lesser ISPs through their upstream neighbors. To avoid that, the lesser
ISPs would be forced to arrange special-case punch-through agreements with
their other peers, as they do now in the IPv4 world. This would tend to
lock in existing Tier 1 and Tier 2 operators indefinitely. In
addition, technically, routing would suffer; it is desirable for every ISP's
traffic to be routed by the best available path consistent with policy, and
to be resilient to temporary outages, rather than seeing traffic to be
biased through a few operators for potentially historic reasons. One would
like to achieve this as a natural result rather than having to consciously
counteract the aggregation of addresses. So a strong requirement of the
address delegation plan is that it not be predicated on or unduly bias
business relationships or models.
The IPv6 address, as currently defined, consists of 64 bits of "network
number" and 64 bits of "host number". The technical reasons for this are
several. The requirements for IPv6 agreed to in 1993 included a plan to be
able to address approximately 2^40 networks and 2^50 hosts; the 64/64 split
effectively accomplishes this. Procedures used in host address assignment,
such as the router advertisement of a network's prefix to hosts, which in
turn place a locally unique number in the host portion, depend on this
split. Examples of obvious choices of host number (IEEE Mac Address, E.164
number, E.214 IMSI, etc) suggest that no assumption should be made that
bits may be stolen from that range for subnet numbering; current generation
MAC layers and E.164 numbers specify up to 64 bit objects. Therefore, subnet
numbers must be assumed to come from the network part. This is not to
preclude routing protocols such as IS-IS level 1 (intra-area) routing,
which routes individual host addresses, but says that it may not be
depended upon in the world outside that zone.
The IETF has also gone to a great deal of effort to minimize the impacts of
network renumbering. None-the-less, renumbering of IPv6 networks is neither
invisible nor completely painless. Therefore, renumbering should be
considered an acceptable event, but to be avoided if reasonably avoidable.
The IETF's IPNG working group has recommended that the address block given
to a single edge network which may be recursively subnetted be a 48 bit
prefix. This gives each such network 2^16 subnet numbers to use in routing,
and a very large number of unique host numbers within each network. This is
deemed to be large enough for most enterprises, and to leave plenty of room
for delegation of address blocks to aggregating entities.
It is not obvious, however, that all edge networks are likely to be
recursively subnetted; an individual PC in a home, or a single cell in a
mobile telephone network, for example, may or may not be further
subnetted (depending whether they are acting as gateways to personal,
home, or vehicular networks). When a network number is delegated to a place
which will not require subnetting, therefore, wisdom suggests that it be given
a single 64 bit prefix - perhaps shared among the dial-in connections to the
same ISP router. It is suggested that business practices therefore consider
whether the edge network is or is not likely to be recursively subnetted,
and allocate /48 or /64 prefixes accordingly. However this decision may be
taken in the knowledge that there is objectively no shortage of /48s,
and the expectation that personal, home and vehicle networks will
become the norm.
The RIR communities, with the IAB, have determined that reasonable address
prefixes delegated to service providers should be on the order of 29 to 35
bits in length, giving individual delegations support for 2^13 (8K) to 2^19
(512K) subscriber networks. Allocations are to be given in a manner such
that an initial prefix may be subsumed by subsequent larger allocations
without forcing existing subscriber networks to renumber. We concur that
this meets the technical requirement for manageable and scalable backbone
routing while simultaneously allowing for managed growth of individual
delegations.
The same type of rule could be used in the allocation of addresses in edge
networks; if there is doubt whether an edge network will in turn be
subnetted, the edge network might be encouraged to allocate the first 64
bit prefix out of a block of 8..256, preserving room for growth of that
allocation without renumbering up to a point.
In the realm of multi-homed networks, the techniques used in IPv4 can all
be applied, but they have known scaling problems. Specifically,
if the same prefix is advertised by multiple ISPs, the routing tables
will grow as a function of the number of multihomed sites. To go beyond this
for IPv6, we only have initial proposals on the table at this time,
and active work is under way in the IETF IPNGWG working group.
Key characteristics of a definitive multi-homing proposal
include (at minimum) that it provides routing connectivity to any
multi-homed network globally, conserves address space, produces high
quality routes at least as well as the single-homed host case previously
discussed via any of the network's providers, enables a multi-homed network
to connect to multiple ISPs, does not inherently bias routing to use any
proper subset of those networks, does not unduly damage route
aggregation, and scales to very large numbers of multi-homed networks.
One class of solution being considered amounts to permanent parallel running
of two (or more) prefixes per site. In the absence of a fixed prefix boundary,
such a site might be required to have multiple different internal
subnet numbering strategies, (one for each prefix length) or, if it
only wanted one, be forced to use the most restrictive one as defined by
the longest prefix it received from any of its ISPs.
In this approach, a multi-homed network would have an address
block from each of its upstream providers. Each host would either
have exactly one address picked from the set of upstream
providers, or one address per host from each of the upstream providers.
The first case is essentially a variant on RFC 2260, with known scaling
limits.
In the second case (multiple addresses per host), if two multi-homed networks
communicate, having respectively m and n upstream providers, then the one
initiating the connection will select one address pair from the n*m
potential address pairs to connect from and to, and in so doing will select
the providers, and therefore the applicable route, for the life of the
connection. Given that each path will have a different ambient bit rate,
loss rate, and delay, if neither host is in possession of any routing
or metric information, the initiating host has only a 1/(m*n) probability
of selecting the optimal address pair. Work on better-than-random address
selection is in progress in the IETF, but is incomplete. In addition, use
of a singly-announced address for a long-lived session exposes that session to
being broken by routing outages, near the source and elsewhere in the
network. This approach also tends to encourage ASPs who offer a
service of bypassing end-to-end IP routing to improve user response times,
often known as "content-based routing".
An existence proof exists in the existing IPv4 Internet that a network whose
address is distinct from and globally advertised to all upstream providers
permits the routing network to select the optimal path within the
applicable policy. Present-day routing policies are not QoS policies but
reachability policies, which means that they will not necessarily select
the optimal delay, bit rate, or loss rate, but the route will be the best
within the metrics that are indeed in use. One may therefore conclude that
this would work correctly for IPv6 networks as well, apart from scaling issues.
It would be useful to study a more scalable version of the latter approach for
IPv6. One interim option is to allocate 29-35 bit prefixes regionally, and
allocate /48 prefixes out of them to multi-homed networks they contain or
touch. Within the region, each such /48 is globally advertised. Outside the
region, the /29-/35 bit prefix may be advertised, to improve aggregation and
scaling. A multi-homed network which spans multiple regions may use an address
block from each region, and internally advertise its addresses to stop the edge
network from inappropriately using external connectivity for internal
traffic. In this context, the word "region" is intentionally vague but
relates more to network topology than to geography. The GSE proposal also
tackled multihoming somewhat in this way.
---------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
