Fw: IAB/IESG Recommendations on IPv6 Address Delegation

["Thomas Trede" <]

FYI.

Regards,
  Thomas Trede

----- Original Message -----
From: "Steve Deering" deering@localhost
To: ipng@localhost
Cc: ngtrans@localhost; "Bob Hinden" hinden@localhost
Sent: Saturday, September 02, 2000 1:02 AM
Subject: Fwd: IAB/IESG Recommendations on IPv6 Address Delegation


> Appended below is the message that was sent today to the RIRs from the
> IAB and IESG, regarding IPv6 address allocation policy.  It contains most
> of the material that was in the draft I forwarded here on Sunday, but
> reorganized into a more coherent document.
>
> Steve
>
> --------
> >Date: Fri, 01 Sep 2000 12:40:48 -0700
> >To: lir-wg@localhost (RIPE), policy@localhost (ARIN),
> >        apnic-talk@localhost (APNIC)
> >From: Fred Baker chair@localhost
> >Subject: IAB/IESG Recommendations on IPv6 Address Delegation
> >Cc: ipv6-directorate@localhost, iesg@localhost, iab@localhost,
> >        ipv6-wg@localhost (RIPE), sig-ipv6@localhost (APNIC)
> >
> >Folks:
> >
> >The RIR community asked the IETF community for advice regarding the
> >assignment of IPv6 prefixes to service providers and edge networks, both
> >with a view to topological address assignment and to multihomed networks.
> >The IPv6 Directorate prepared a statement, which the IESG and IAB have
> >reviewed and approved. This is attached.
> >
> >I trust that this answers the questions you asked, and serves as a basis
for
> >IPv6 deployment in the near term. If you have questions or issues
concerning
> >it, I would suggest that you address them to the IPv6 Directorate copying
> >the IESG and IAB.
> >
> >We intend to publish an Informational RFC in the near future documenting
the
> >contents of this note.
> >
> >Fred Baker
> >
> >-----------------------------------------------------------------------
> >
> > IAB/IESG Recommendations on IPv6 Address Allocations
> >    September 1, 2000
> >
> >Introduction
> >
> >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.
> >
> >This document was developed by the IPv6 Directorate, IAB and IESG, and
> >is a recommendation from the IAB and IESG to the RIRs.
> >
> >Background
> >
> >The technical principles that apply to address allocation seek to
> >balance healthy conservation practices and wisdom with a certain ease
> >of access.  On the one hand, when managing the use of a potentially
> >limited resource, one must conserve wisely to prevent exhaustion
> >within an expected lifetime.  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 they really need 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.  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 [RFC 2462], 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, e.g., gateways to
> >personal, home, or vehicular networks).  When a network number is
> >delegated to a place that will not require subnetting, therefore, it
> >might be acceptable for an ISP to give a single 64 bit prefix -
> >perhaps shared among the dial-in connections to the same ISP router.
> >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.  Indeed, 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.
> >
> >Address Delegation Recommendations
> >
> >The RIR communities, with the IAB, have determined that reasonable
> >address prefixes delegated to service providers for initial
> >allocations 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.  However,
> >for the reasons described below, we recommend use of a fixed boundary
> >at /48 for all subscribers except the very largest (who could receive
> >multiple /48's), and those clearly transient or otherwise have no
> >interest in subnetting (who could receive a /64).  Note that there
> >seems to be little benefit in not giving a /48 if future growth is
> >anticipated.  In the following, we give the arguments for a uniform
> >use of /48 and then demonstrate that it is entirely compatible with
> >responsible stewardship of the total IPv6 address space.
> >
> >The arguments for the 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, including the techniques already used for IPv4 multihoming.
> >   The main open issue is finding solutions that scale massively
> >   without unduly damaging route aggregation and/or optimal route
> >   selection.  Much 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.  (Multihoming
> >   is discussed in more detail below.)
> >
> > - 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).
> >
> > - remove the burden from the ISPs and registries 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.
> >
> >Note that none of these reasons imply an expectation that homes,
> >vehicles, etc. will intrinsically require 16 bits of subnet space.
> >
> >Conservation of Address 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%.
> >
> > - For transient use by non-routing hosts (e.g., for stand-alone
> >   dial-up users who prefer transient addresses for privacy reasons),
> >   a prefix of /64 might be OK.  But a subscriber who wants "static"
> >   IPv6 address space, or who has or plans to have multiple subnets,
> >   ought to be provided with a /48, for the reasons given above, even
> >   if it is a transiently provided /48.
> >
> >To summarize, 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.
> >
> >Multihoming Issues
> >
> >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 IPNG working
> >group.  Until existing or new proposals become more fully developed,
> >existing techniques known to work in IPv4 will continue to be used in
> >IPv6.
> >
> >Key characteristics of an ideal 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.
> >
> >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 a reasonably good 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.
> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >Fred Baker | 519 Lado Drive
> >IETF Chair | Santa Barbara California 93111
> >www.ietf.org | Desk:   +1-408-526-4257
> > | Mobile: +1-805-886-3873
> > | FAX:   +1-413-473-2403
>
> --------------------------------------------------------------------
> 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 majordomo@localhost
> --------------------------------------------------------------------
>