Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addr

  • To: Owen DeLong <owen at delong dot com>
  • Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
  • From: Usman Latif <osmankh at yahoo dot com>
  • Date: Sat, 17 Sep 2011 20:24:39 -0700 (PDT)
  • Cc: Skeeve Stevens <Skeeve at eintellego dot net>, "sig-policy at lists dot apnic dot net" <sig-policy at lists dot apnic dot net>
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • In-reply-to: <34B9CF8A-CF39-4D3C-9B2D-4CAF05BF17C3 at delong dot com>
  • List-archive: <>
  • List-help: <>
  • List-id: APNIC SIG on resource management policy <>
  • List-post: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • References: <> <> <> <> <> <>
  • Reply-to: Usman Latif <>
    • I sense the recommendations for /64 assignments even to residential users looks more political than technical.

      It seems that because end-hosts and other systems have already been built with more support for stateless autoconfig, this may act as a roadblock for us.

      First of all, the RFC-6177 does not give the reasoning behind suggesting /64 as being technically motivated but more from the perspective of growth and scalability - I for one am having a hard time imagining how a "residential site" can grow to such a length that it would need 2^64 address space.
      I quote from 6177:

      At the same time, it might be tempting to give home sites a single /64, since that is already significantly more address space compared with today's IPv4 practice. However, this precludes the expectation that even home sites will grow to support multiple subnets going forward. Hence, it is strongly intended that even home sites be given multiple subnets worth of space, by default. Hence, this document still recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either."

      As regards stateless auto-configuration, one might argue that we have alternatives like RFC-3315 (DHCPv6) are also available but this may make the stateless implementation completely redundant (?)

      From: Owen DeLong <owen at delong dot com>
      To: Usman Latif <osmankh at yahoo dot com>
      Cc: "mtinka at globaltransit dot net" <mtinka at globaltransit dot net>; Skeeve Stevens <Skeeve at eintellego dot net>; "sig-policy at lists dot apnic dot net" <sig-policy at lists dot apnic dot net>
      Sent: Sunday, 18 September 2011 8:25 AM
      Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses

      Sent from my iPad

      On Sep 17, 2011, at 14:42, Usman Latif <osmankh at yahoo dot com> wrote:

      Ditto Mark -

      And I tend to disagree that if IPv6 did not have autoconfiguration feature, then IPv6 would have been devised with only 64 bits ?? It does not make sense coz then you are only increasing 32 bits more to the current size of the IP which IMO would not have been a significant increase in the IP size. IMO IPv6 was

      It would have been a 4.2Billion x increase. You don't think that's significant? You and I have very different ideas of what constitutes a significant increase in size.

      If you go back and review the records of the IETF from the time, you will find that the discussion centered largely around a 64 bit address space until the idea of stateless auto configuration was proposed and that it did, indeed, spur the idea to add another 64 bits to cover it.

      devised with 128 bits and was meant to address infinitely large number of hosts so that we never run out of addresses - and autoconfiguration etc were features added to IPv6 protocol later to make addressing easy.
      I see autoconfiguration as a feature only and nothing more than that.

      The history in the IETF mailing lists differs from your statement here.

      RFC 4291 does not pose any restriction or requirement on the IPv6 address assignment architecture that every subnet should or must be /64 or /48 etc and why it cannot be a /112 or something smaller.

      Correct. You can do whatever you want with your network. There are other places where /64, /48, and /32 are recommended and, IMHO, /64 per subnet, /48 per end site and minimum /32 per ISP are good starting points and current best common practice.

      You are welcome to do otherwise, just as you are welcome to put sugar into your gas tank. However, being stingy with IPv6 resources will degrade the overall capability of your network(s) and possibly the internet, just as putting sugar in your gas tank will degrade the performance of your car.


      From: Mark Tinka <mtinka at globaltransit dot net>
      To: Owen DeLong <owen at delong dot com>
      Cc: Skeeve Stevens <Skeeve at eintellego dot net>; sig-policy at lists dot apnic dot net
      Sent: Sunday, 18 September 2011 4:02 AM
      Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses

      On Sunday, September 18, 2011 01:43:13 AM Owen DeLong wrote:

      > Multiple prefix sizes, address fragmentation, etc.
      > Admittedly, it's a small complication, but, it is a
      > complication.

      > Further, it violates the principle of least surprise as
      > your organization scales and brings in new engineers.

      A good v6 address assignment policy for one's infrastructure
      is neither difficult to create nor maintain.

      No issues here since we started running v6 over 6 years ago.
      We know how v6 can make address management within an ISP's
      network brain-dead to maintain, but it's not reason enough
      to use /64's where we can comfortably use /112's and still
      not overly complicate our lives.

      > So did I. I was being a little tongue in cheek/snarky
      > with just presenting the math on the number of
      > addresses,...

      I know what you were getting at, with multiple v6 addresses
      on a single interface, e.t.c.

      > but the reality is that there may be some
      > cases where having multiple addresses for one end of a
      > point to point or the other (or both) may prove useful.
      > These are admittedly rare.

      Agree, but having run multiple networks with v6 over the
      last several years, we're yet to find with a reason that has
      required us to have multiple addresses on point-to-point
      links either between infrastructure, or between AS domains.
      Some things really are that simple :-).

      Obviously, I can't speak for anyone else's network, just


      *              sig-policy:  APNIC SIG on resource management policy          *
      sig-policy mailing list