From: Mark Tinka <mtinka@globaltransit.net>
To: Usman Latif <osmankh@yahoo.com>
Cc: Owen DeLong <owen@delong.com>; Skeeve Stevens <Skeeve@eintellego.net>; "sig-policy@lists.apnic.net" <sig-policy@lists.apnic.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 +
DHCPv6.
o those that prefer just DHCPv6.
Cheers,
Mark.