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.

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?

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:

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

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

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.

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


Regards
Usman Latif


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.