Leo, On Mon, Dec 30, 2013 at 6:24 PM, Leo Bicknell <bicknell@ufp.org> wrote:
On Dec 30, 2013, at 2:49 PM, Lee Howard <Lee@asgard.org> wrote:
I'm not really an advocate for or against DHCP or RAs. I really just want to understand what feature is missing.
I encourage you to try this simple experiment in your lab, because this happens all day long on corporate networks around the world, and illustrates the differences quite nicely. While not a complete treatment of the operational differences, it's an important illustration.
Configure up a simple network topology of three boxes representing a hub and spoke network:
DHCP SVR | --lan--r1--wan--hubrtr--wan--r2--lan
.....
Here's what you will soon find:
1) The IPv6 pings on both machines cease to work.
2) The IPv4 network continues to work just fine.
Yes, in this very specific case, you may get this result. However, this is a very specific case with very specific parameters and conditions. There are also many cases (again specific in nature) which would cause the IPv4 connection to have problems and not the IPv6 connection. As an example, say the failure is now over and we have running state with r1 and r2 as two potential routers out of the LAN to a common WAN for IPv4 and IPv6 connectivity. The DHCPv4 server provides only the address of the r2 router (original on that LAN). Both r1 and r2 provide RAs and the client works over r2 for IPv6 for now. r1 fails, the machines will lose IPv4 connectivity but IPv6 will keep working (as the hosts will detect r1 as unreachable and then use r2). There are a number of assumptions in this use case - but that's the point. One may say that without IPv4, perhaps we have a problem anyway (since I am sure many networks will have some level of dependance on IPv4 for a while) - but the designers of IPv6 will then say that the IPv6 protocol needs to be free from IPv4 baggage to truly succeed IPv4. I am not fighting against the case of the DHCPv6 option, but I am not sure if use cases like the one you mentioned will convince the right audiences that the option is needed. For reference, this concept has died on the vine before - draft-droms-dhc-dhcpv6-default-router-00 as an example. (where technical comments were made to diminish the technical value of using DHCPv6 as an option to provide default gateway information). We can also reference draft-ietf-mif-dhcpv6-route-option from the MIF working group. I think a new initiative to revive this concept will need to address the [negative] points from those previous experiences and contrast them to the operational benefits of having it available. I am willing to help out here, but we need some folks willing to put the use cases together which make a strong case (oh and they will need email stamina). regards, Victor K
-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Dec 30, 2013, at 9:29 PM, Victor Kuarsingh <victor@jvknet.com> wrote:
I think a new initiative to revive this concept will need to address the [negative] points from those previous experiences and contrast them to the operational benefits of having it available. I am willing to help out here, but we need some folks willing to put the use cases together which make a strong case (oh and they will need email stamina).
Or, alternatively, operators who care about this and vendors who are interested in accepting money to implement what the operators want could get together and form, oh I dunno, the Internet DHCP Task Force, which could specify/implement the standard way of solving this particular problem... Regards, -drc
participants (2)
-
David Conrad
-
Victor Kuarsingh