turning on comcast v6

Owen DeLong owen at delong.com
Tue Dec 31 00:56:42 UTC 2013


You can accomplish the same thing in IPv4….


Plug in Sally’s PC with Internet Connection Sharing turned on and watch as her
DHCP server takes over your network.

Yes, you have to pay attention when you plug in a router just like you’d have to pay attention if you plugged in a DHCP server you were getting ready to recycle.

Incompetence in execution really isn’t the protocol’s fault.

Owen

On Dec 30, 2013, at 3: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 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/
> 
> 
> 
> 
> 





More information about the NANOG mailing list