[apnic-talk] FW: IAB/IESG Recommendations on IPv6 Address Delegation

  • To: <apnic-talk at lists dot apnic dot net>
  • Subject: [apnic-talk] FW: IAB/IESG Recommendations on IPv6 Address Delegation
  • From: "Paul Wilson" <pwilson at apnic dot net>
  • Date: Tue, 5 Sep 2000 14:00:19 +1000
  • Importance: Normal
  • Sender: owner-apnic-talk@lists.apnic.net
    • Date: Fri, 01 Sep 2000 12:40:48 -0700
      To: lir-wg at ripe dot net (RIPE), policy at arin dot net (ARIN),
              apnic-talk at apnic dot net (APNIC)
      From: Fred Baker <chair at ietf dot org>
      Subject: IAB/IESG Recommendations on IPv6 Address Delegation
      Cc: ipv6-directorate at sunroof.eng dot sun dot com, iesg at ietf dot org, iab@ISI.EDU,
              ipv6-wg at ripe dot net (RIPE), sig-ipv6 at lists dot apnic dot net (APNIC)
      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
      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.
      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
        - 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
        - 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
      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
      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
      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
      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
      *              APNIC-TALK: General APNIC Discussion List             *
      * To unsubscribe: send "unsubscribe" to apnic-talk-request at apnic dot net *