[141672] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Fri Jun 10 09:32:49 2011
Date: Fri, 10 Jun 2011 06:32:43 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <A6D6AAAA-D815-4ED4-B13F-736609267FF8@lists.zabbadoz.net>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. Ze=
eb wrote:
> On Jun 10, 2011, at 10:10 AM, sthaug@nethelp.no wrote:
> > Several large operators have said, repeatedly, that they want to use
> > DHCPv6 without RA. I disagree that this is stupid.
>=20
> I wonder if it's just a "violation" of rule #1: stop thinking legacy!
>=20
> People are used to what they have done for a decade or two. It's hard to
> see the change and results in "why is this all so different and complicat=
ed?".
> It's hard to open ones mind for the new, but it is essential to do with n=
ew
> technology.
The problem in this case is that the failure modes are significantly
different. Some folks have learned this the hard way.
It's a very easy scenario to reconstruct. Consider the "branch
office router" in a typical corporate enviornment. We're talking
a device with one WAN port, and one LAN port. Configure it for
dual stack, speaking IPv4, and in IPv4 configure it the typical
corporate way with a "DHCP Helper" forwarding requests over the WAN
to a central DHCP server. In IPv6, configure it with RA's, the
supposed "better" way.
Now, take the 100% working branch router and have it sent back to
corporate. Maybe they got a bigger router, maybe the office closed.
A network engineer gets the router and is tasked with making it
ready to redeploy.
The network engineer plugs it into the switch on his desktop, plugs in a
serial cable, turns it on and steps out to get a coffee while it boots.
He's planning to erase the configuration and then load new software over
the network.
As soon as the router boots the IPv6 network fails for all the users on
his subnet. IPv4 keeps working fine.
Oops.
What happened? Well, the router sent IPv6 RA's as soon as it came
up, and every workstation instantly started using them. In IPv4,
the router received DHCPv4 requests and forwarded them per the
helper address, except that its WAN port is down, and thus it in
fact didn't send them anywhere.
The important points:
- IPv4 "failed safe" with the DHCP config. This "rogue device" will
never disrupt the IPv4 configuration. DHCP snooping isn't even needed
in your switches, since it never returns a response.
- IPv6 "failed immediately" with the RA configuration. What's worse is
if you simply turn the device off after you realized you took down the
entire network devices will continue to be broken for 2-4 hours until
the RA's time out. The only method to mitigate is to deploy RA guard
on all of your switches, which probably means replacing 100% of your
hardware with new stuff that can do that, and then deploying new
features.
The fact of the matter is that the failure modes of these two
protocols are vastly different operationally. The DHCP failure
semantics are not only better understood, but cause less disruption
to the network. Even a properly rouge DHCP server will only damage
_new_ clients coming up on a network, existing folks will work just
fine. Contrast with RA's which instantly break 100% of the users.
Even more annoying is that if I use RA's for the default gateway,
I still have to run DHCPv6 anyway. If I don't my boxes don't have
DNS servers, NTP servers, know where to tftpboot, etc. It's not a
choice of one or the other, it's I always run DHCPv6, do I need
RA's or not.
Given the failure modes I would much prefer to run with RA's turned off
completely, and have DHCPv6 able to provide a default gateway just as it
works in IPv4.
My opinion comes not from "thinking legacy", indeed my employer has been
fully dual stacked since 2003. My opinion comes from the fact that in
the 8 years of operational experience we have RA's are significantly
more fragile, and IMHO not ready for widespread IPv6 deployment.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--3V7upXqbjpZ4EhLz
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIUAwUBTfIc+7N3O8aJIdTMAQJZcw/2NWfE2VyrrTqoRgUbtgtpxhfrIixmAREt
zXAwUHlWBtwO7sNIqng2FXFytLNIFV7vylKsr6SbeowhcfyBGt5uFlz0A+fKkPsZ
WgkKtfNeNUKmEMVJK04+UUfxQ0/bZ99ixXdF9lxfX9s5qbvRGL/cgN22vsmS6IVb
LUn8DlZoYqIkNDIVbZckUc71nCHYq5r621ip4oezZx5Kn3ZIG8v8eqexRrbZngp0
cj22xlaZKUcsQ8s58zRR/2xC5P3OT20Du8YDcX5VxkjaomKUiV3yHvp9PCLF909K
Hi6ZoJKSalNBRTOUSo7FmXbMSLi0vHygivXv39/WX4AJtX2z68aoYZomTcV2urDt
QhIjVxcm4e22mrtuuR3d8WOx1QjaqZbP7bFf02yoei8bBvnSP28LchudM6HLcRFY
YjjVdTByLCnHgbYH6BFjFuMGcc475Oble4wt3CCJzHaytfkVu0gMWKx/z1vuDGJ7
yU1Dvn4CCkzKR/b375M4mzxogvEaXrIy1Bc+aOxtv3A6MCS9tBpg3WnXXhJjKcV3
YZJORaoJ7ruFq3AOY0JbwdRrBwwavSiUyUzzxIpSlGLzN/PmYw9/o+a3oe/R3t2I
Jrw28HrT22N/ftQpfcUq9lmojgykY4m+RNL88ihW7Xqmar5svtXh7dEjYB9Cs8rX
rWInB9XPxA==
=Twxq
-----END PGP SIGNATURE-----
--3V7upXqbjpZ4EhLz--
