turning on comcast v6

Leo Bicknell bicknell at ufp.org
Mon Dec 30 23:24:54 UTC 2013


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

Number it up as expected for both protocols:

wan links: IPv4 /30, IPv6 /64
lan links: IPv4 /24, IPv6 /64

Drop a DHCP server off the hubrtr, set r1 and r2 to forward DHCP requests
to it.  Verify a machine plugged into either of the LANs gets a fully
functional network for both protocols.

Now, take r1 turn it off, and stick it in a closet.  You see, that office
closed.  Normal every day thing.

Plug up two PC's to the remaining LAN off r2.  This represents your desktop,
and your neighbors desktop.  Think Bob from accounting perhaps.  Open two
windows on each, one with an IPv4 ping, one with an IPv6 ping running.

Now, boss man comes in and has a new office opening up.  Go grab the r1 box
out of the closet, you need to upgrade the code and reconfigure it.  Cable
it up to your PC with a serial port, open some some sort of terminal program
so you can catch the boot and password recover it.  Plug it's ethernet into
your lan, as you're going to need to tftp down new config, and turn it on.

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.

Now, for even more fun, turn on another PC, say Sally from HR just rebooted
her machine.  It will come up in the same state, IPv6 not working, while
IPv4 works just fine.

Lastly, for extra credit, explain to Mr MoneyBagsCEO why Bob and Sally are
now complaining to him that their network is down, again.  Make sure you
not only understand the technical nuances of why the problem above happened,
but also how to explain them to a totally non-technical CEO.

(Oh yeah, go ahead and unplug r1 to "fix" the problem, and observe how long
until the pings start working again.  I think it's 15 minutes, IIRC.  For
super-extra credit tell me how to make that time shorter for everyone on
the LAN with Cisco or Juniper commands on r2.)

I'll give you a hint on understanding this issue.  The IETF's grand
solution is to replace every ethernet switch in your entire network
with new hardware that supports "RA Guard", and then deploy new configuration
on every single port of every single device in your network.  Please
develop a capital justification plan for Mr MoneyBagsCEO for replacing 
every switch in your network so you can safely deploy IPv6.

Now do you understand why people just want to put the route in DHCPv6 and
move on?

It's not a "feature" that's different between the two, it's that operationally
they have entirely different attack surfaces and failure modes.  And yes,
it involves people doing stupid things.  However if the IETF is going to
rely on smart people deploying networking devices we might as well give up
and go home now.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131230/9c812a18/attachment-0001.bin>


More information about the NANOG mailing list