[167840] in North American Network Operators' Group
Re: turning on comcast v6
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Dec 30 19:58:19 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <52877BE3-CDE9-49D2-8D3D-4B7CF4576E4B@ufp.org>
Date: Mon, 30 Dec 2013 16:56:42 -0800
To: Leo Bicknell <bicknell@ufp.org>
Cc: Jamie Bowden <jamie@photon.com>,
North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
You can accomplish the same thing in IPv4=85.
Plug in Sally=92s 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=92d=
have to pay attention if you plugged in a DHCP server you were getting =
ready to recycle.
Incompetence in execution really isn=92t the protocol=92s fault.
Owen
On Dec 30, 2013, at 3:24 PM, Leo Bicknell <bicknell@ufp.org> wrote:
>=20
> On Dec 30, 2013, at 2:49 PM, Lee Howard <Lee@asgard.org> wrote:
>=20
>> I'm not really an advocate for or against DHCP or RAs. I really just =
want
>> to understand what feature is missing.
>=20
> 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.
>=20
> Configure up a simple network topology of three boxes representing a =
hub
> and spoke network:
>=20
> DHCP SVR
> |
> --lan--r1--wan--hubrtr--wan--r2--lan
>=20
> Number it up as expected for both protocols:
>=20
> wan links: IPv4 /30, IPv6 /64
> lan links: IPv4 /24, IPv6 /64
>=20
> 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.
>=20
> Now, take r1 turn it off, and stick it in a closet. You see, that =
office
> closed. Normal every day thing.
>=20
> 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.
>=20
> 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.
>=20
> Here's what you will soon find:
>=20
> 1) The IPv6 pings on both machines cease to work.
>=20
> 2) The IPv4 network continues to work just fine.
>=20
> 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.
>=20
> 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.
>=20
> (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.)
>=20
> 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=20=
> every switch in your network so you can safely deploy IPv6.
>=20
> Now do you understand why people just want to put the route in DHCPv6 =
and
> move on?
>=20
> 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.
>=20
> --=20
> Leo Bicknell - bicknell@ufp.org - CCIE 3440
> PGP keys at http://www.ufp.org/~bicknell/
>=20
>=20
>=20
>=20
>=20
