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: Sun, 18 Sep 2011 20:23:34 -0700 (PDT)
  • Cc: Skeeve Stevens <Skeeve at eintellego dot net>, APNIC Address Policy SIG <sig-policy at apnic 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: <CBF8B3C2-72AC-43BC-83C0-602A9E5B0558 at delong dot com>
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • References: <CA996BAA.4735C%skeeve@eintellego.net> <34B9CF8A-CF39-4D3C-9B2D-4CAF05BF17C3@delong.com> <1316316279.59320.YahooMailNeo@web110209.mail.gq1.yahoo.com> <201109181432.31855.mtinka@globaltransit.net> <1316345150.27071.YahooMailNeo@web110202.mail.gq1.yahoo.com> <CBF8B3C2-72AC-43BC-83C0-602A9E5B0558@delong.com>
  • Reply-to: Usman Latif <osmankh@yahoo.com>
    • > The default router isn't discovered through ND so much as through Router Discovery which is part of the same RA    > packets used for SLAAC.
       
      Okay then please explain to me the following statement from RFC-4861 (ND for IPv6) which has no dependancy on SLAAC (RFC-4862):

      I quote: Page-11 (http://tools.ietf.org/html/rfc4861):

        "On multicast-capable links, each router periodically multicasts a
         Router Advertisement packet announcing its availability.  A host
         receives Router Advertisements from all routers, building a list of
         default routers.  Routers generate Router Advertisements frequently
         enough that hosts will learn of their presence within a few minutes,
         but not frequently enough to rely on an absence of advertisements to
         detect router failure; a separate Neighbor Unreachability Detection
         algorithm provides failure detection."
       
       
      regards
      Usman
       

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


      On Sep 18, 2011, at 4:25 AM, Usman Latif wrote:

      Mark - I do not see any relevance between SLAAC and getting information about "Default Router". The SLAAC is an extra feature as per RFC 4862.
      On the other hand, default router can be discovered by using IPv6 ND as per RFC 4861.


      The default router isn't discovered through ND so much as through Router Discovery which is part of the same RA packets used for SLAAC.


      So why do we think that until the draft (http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00) gets mature enough, we cannot use DHCPv6 effectively for high-volume single-user customer scenarios?


      Because the people running the customer network may not want to use DHCP and may prefer SLAAC?

      So when folks say that "we need atleast /64 subnets for all sites (including residential single-user customers) because SLAAC would fail" then we should ask ourselves the question:


      You are still coming back to this theory of /64 per site. It's /64 per segment. A site should be a /48.

      - Do we have alternatives to SLAAC?
      I'd say yes we do (DHCPv6 and ND)...


      There are alternatives, but, there are many environments where SLAAC is useful.

      - Is SLAAC the reason we are wasting 18446744073709551616 worth of address space for residential sites?
      I'd say this is not a good enough reason...


      I believe you are incorrect. I believe it is a perfectly good reason to use that many addresses. Especially since those bits were placed there in the protocol specifically to be used in that manner.


      But without going into an endless debate on this subject, I think we all have our own perspectives of looking at things and when I initially started my query "Need to understand logic behind /64 IPv6 addresses" - I can only say that I am only partially convinced and cannot convince myself with the reasoning provided so far that its worth wasting that much address space using a one-size-fit-all approach of /64 - especially as I said in the case of home-user CPEs etc.


      You are mistaken sir. It is very much worth doing so. So much so that we added the bits to the protocol so that they could be used in that way.

      Thanks everyone for your involvement and I hope IPv6 fulfills our addressing requirements for thousands of years to come ...... :)


      I doubt that the protocol has any chance of lasting that long. There are many scaling limits unrelated to address space which will likely obsolete the IPv6 protocol. I hope it achieves a nice 50 year lifespan, but, I think even that may be optimistic.

      This is not the first time we've had to change protocols and I doubt it will be the last.

      Owen


      Regards
      Usman Latif


      From: Mark Tinka <mtinka at globaltransit dot net>
      To: Usman Latif <osmankh at yahoo dot com>
      Cc: Owen DeLong <owen at delong dot com>; 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 4:32 PM
      Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses

      On Sunday, September 18, 2011 11:24:39 AM Usman Latif wrote:

      > I sense the recommendations for /64 assignments even to
      > residential users looks more political than technical.

      I think it's simpler than that, Usman :-).

      Because SLAAC, today, is much more useful than DHCPv6 when
      it comes to acquiring a default gateway for your host, /64's
      makes sense because SLAAC will work only if an interface is
      assigned with a /64 address.

      The day DHCPv6 gets the Default Router option implemented
      (along with much-needed DHCPv6 Snooping capability), you may
      begin to see flexibility in this area, whether it's good or
      bad.

      > 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.

      DHCPv6 is now shipping in Mac OS X: Lion (10.7), which was
      one of the major OS's out there still lacking it. It's just
      that without a Router option in DHCPv6, widespread use in
      enterprise situations that prefer centralized address
      management is still limited.

      > 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:

      The requirement for growth in home networks being supported
      by SLAAC, which in turn requires /64 prefix lengths on CPE
      home gateways, is implied by RFC 6177.

      Things could be different if DHCPv6 becomes a viable
      alternative to SLAAC.

      > 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 (?)

      If DHCPv6 actually becomes operationally similar to DHCPv4,
      I think we shall have 3 camps:

          o those that prefer SLAAC + DHCPv4.
          o those that prefer SLAAC +