turning on comcast v6
victor at jvknet.com
Tue Dec 31 05:29:56 UTC 2013
On Mon, Dec 30, 2013 at 6:24 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> On Dec 30, 2013, at 2:49 PM, Lee Howard <Lee at asgard.org> wrote:
> > I'm not really an advocate for or against DHCP or RAs. I really just
> > 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
> 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
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).
> Leo Bicknell - bicknell at ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
More information about the NANOG