> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part.