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.