j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
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 firstname.lastname@example.org To: Usman Latif email@example.com Cc: firstname.lastname@example.org; Skeeve Stevens Skeeve@eintellego.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.
Regards Usman Latif
From: Mark Tinka email@example.com To: Usman Latif firstname.lastname@example.org Cc: Owen DeLong email@example.com; Skeeve Stevens Skeeve@eintellego.net; "firstname.lastname@example.org" email@example.com 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.