[141725] in North American Network Operators' Group
Re: The stupidity of trying to "fix" DHCPv6
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Fri Jun 10 16:28:04 2011
Date: Fri, 10 Jun 2011 13:27:58 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: "nanog@nanog.org" <nanog@nanog.org>
Mail-Followup-To: "nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <AE120605-D8D0-42F1-AB85-CABF6A3D91F6@muada.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--d6Gm4EdcadzBjdND
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 09:57:07PM +0200, Iljitsch van=
Beijnum wrote:
> If only. Having third parties point to routers is less robust than having=
routers announce their own presence. In the telco world, there's a separat=
ion between the control and data channels, which has important security adv=
antages. But the IETF has always favored fate sharing. It makes routing pro=
tocols more robust and it makes RA more robust than IPv4 DHCP.
Apparently we don't have a long enough view of history, as history
will tell you that this is wrong.
You see, we tried the RA experiement once before. Let's go back
to the Internet circa 1988, or so.
There was a time when it was very common for routers to run RIP.
There was a time when Sun systems (in particular, other vendors did
the same) shipped with routed enabled by default. Many of these
systems learned their default gateway by listening to these RIP
announcements.
The funny thing is, no one does this anymore. We turned off RIP,
turned off routed, and invented things like HSRP to handle router
redundancy. These things weren't done because someone was bored,
no, they were done because these RIP deployments failed, repeatedly
and often. Any device could broadcast bad information, and they
did. It could be a legitimate network admin plugging a cable into
the wrong jack, or it could be a hacker who rooted a machine and
is injecting bad information on purpose.
I submit to you those who designed RA's do not remember those days,
and did not study history. The only difference is that RA's only
carry a default route, where as RIP could carry several routes.
The security model is identical. The failure modes are largely
overlapping.
IPv4 also had a similar feature, ICMP router discovery, RFC 1256.
Works a little different than RA's do, but not a lot. Have you ever
seen it used? I haven't.
Least you think the IETF is proud of their RA work, one needs look
no further than RFC 6104, where they carefully document the problem
of rogue RA's and provide a list of solutions. Indeed, my proposed
DHCP solution is documented in section 3.10. The IETF seems to
think SEND is the solution, but it also requires deploying new
software to 100% of all devices in order to be the solution.
> People who don't like this should blame their younger selves who failed t=
o show up at the IETF ten years ago to get this done while DHCPv6 was still=
clean slate.
I participated until a working group chair told some protocol wonks
"Don't listen to him, he's an operator and doesn't understand IPv6
yet." The IETF has a long history of being openly hostle to operators.
That was the day I gave up on the IETF.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--d6Gm4EdcadzBjdND
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
iQIVAwUBTfJ+TrN3O8aJIdTMAQLc9g/8CJ0F1UmoD540RUgIGf1T9dDzkL4B1lwP
5SSuy2+o/nsOB71Uaj3GaP3vMYTg96oseHZY+JD+KbpWMY78/zHX2I4pG83LrN6v
EH45YiaWKQx68fSkMgUqNbgF9xexCVREuH14woFglhKLyn9TmbC+njXB5NZLfTNO
pMuR8VZ8EAFCP9pYdcdKGjNZK6c2Yli5ys03fnU4iwCDdNvm6RiSvBrkQckr62N5
hdKwUNbasAH6Hc703dBtlNnjOj3oOfKG9fdwn+TonuGbE+0IEcHV0UInd+JZGhtG
QyCJ8E4vMYZQcagPMrkIw0k7dakrytMlEspM4SbtJdmh4mJfyrvZJoKJLCqoAWKx
lmrqTtu3y2uKi4fK6S7bNPVOufpa+D/kGICxAj3jGRS3mLigR63ZYkzj0FlGkQn6
NRHNpnhNNBzgRTbKR/VlBIJuS8fGOOTdWzvWS8bnRm/CKnNRt84iUkyM9/dZqAMk
EDrnU72m7GxdTobKVc94UbjeHWiygJjRqgQHUUW0mjmUQzX6xJJeeYBIQo0ansD/
vmb3P+4Uo7XSNpihXBCYgedurEiuNPd+VqevcWpa4y895PrQY5NqCALr5LP37D7e
m/X3rXzYNvxXe/Iy8zhWuK5jY5IWA1xzWm7TA5DUPBuDsEL8ywK1YXiZoWvUoL8I
qcpkvphQ8mc=
=Kz6H
-----END PGP SIGNATURE-----
--d6Gm4EdcadzBjdND--
