[136384] in North American Network Operators' Group
Re: quietly....
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Feb 2 16:29:26 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com>
Date: Wed, 2 Feb 2011 13:28:06 -0800
To: Iljitsch van Beijnum <iljitsch@muada.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>> Why do we need mommy-IETF telling us no for default routes in DHCP =
but letting RAs run wild?
>> Why does the mere mention of NAT cause daddy-IETF to round up the =
troops and insist that everyone is wrong?
>=20
> Because IPv4-style DHCP often breaks because the DHCP server points to =
the wrong router address and because NAT breaks end-to-end connectivity =
so severe workaround in applications become necessary. But you knew =
that.
>=20
IPv4 style DHCP occasionally (not often) breaks things because the DHCP =
server points to the wrong router address.
On NAT, I actually agree with you.
> On 2 feb 2011, at 21:15, George Herbert wrote:
>=20
>> it's hard to describe how
>> frustrating this is without resorting to thrown fragile objects
>> against hard walls.
>=20
> Ok, I know I'm going to regret this, but:
>=20
> Can you explain what exactly the problems with DHCPv6 are that you're =
running into that are inherent to DHCP and/or IPv6 host configuration =
and won't be fixed by bringing IPv4 ethernet switch features to IPv6?
>=20
The lack of default router capabilities in DHCPv6 is a major =
disappointment. Yes, there are ways to work around this limitation in =
most environments, but, it is problematic to have this limitation.
> On 2 feb 2011, at 21:18, Owen DeLong wrote:
>=20
>>> If you're connecting at a Starbuck's, and you care more than =
"hopefully
>>> somebody will tell me the right time within a minute", yes, it *is* =
essentially
>>> random.
>=20
>> While that is true, the people that are asking for the ability to =
advertise
>> NTP servers in DHCP are not running the networks at Starbucks.
>=20
> But whatever the IETF comes up with needs to work at Starbucks as well =
as enterprise networks, everything else you can think of and then some =
you can't.
>=20
Which is why the IETF should build an assortment of complete solutions =
that allow operators to choose the one that best meets their needs. It =
is absurd to limit the entire industry to a solution which cannot =
possibly be broken by misconfiguration by a barista.
What we needed was RA/SLAAC with a way to specify DNS, NTP, and Next =
Server and DHCP with the ability to specify a default router. If we had =
these two complete solutions, operators would be able to choose =
whichever
one fit best in each environment.
Unfortunately, instead, what we got was two half-solutions that have to =
be combined to produce a suboptimal
solution that sort of mostly works in most environments, mostly.
> On 2 feb 2011, at 21:36, Lamar Owen wrote:
>=20
>> <put on op hat>
>> What I want is to add an IPv6 subnet or subnets to my already tuned =
DHCP server config, add IPv6 addresses to the addresses handed out (in =
the same config clause as the IPv4 addresses are stored, preferably), =
update the DHCP server software to IPv6-capability, restart the DHCP =
server, and both IPv4 and IPv6 clients get what they need, through the =
same already locked down channels, with no other upgrades required.
>=20
> You can do that today. For instance, this is what I have in a test =
setup. (However, the ISC dhcpd can only do either v4 or v6, not both at =
the same time.)
>=20
Which means you can't do what he said, but...
> subnet6 2001:960:7bf:d::/64
> {
> option dhcp6.name-servers 2001:1af8:2:5::2;
> option dhcp6.domain-search "bonjour.muada.nl";
> range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff;
> }
>=20
Where's the default router?
Right... No feature parity.
> Of course there are some subtleties such as the fact that some IPv6 =
systems don't support DHCPv6 so you also need stateless autoconfig if =
you want to be able to use those, and some (all?) routers automatically =
enable stateless autoconfig and don't tell hosts to use DHCP. But that =
can be fixed with two lines of config.
>=20
Exactly.
>> Instead, I'll have to completely relearn how dynamic allocation =
works, learn about and protect against a new attack vector
>=20
> You also get to stop worrying about a few old ones.
>=20
Not so much.
>> It doesn't seem that different until you add all those pesky little =
details up. Try that exercise one day, and add up *all* the differences =
that operators have to know and implement to go IPv6, and balance that =
against smaller staffs and smaller budgets.
>=20
> I did this for routing. I can explain everything you need to know =
about how to run IPv6 BGP, RIP and OSPF in an hour and a half. Did that =
at a RIPE meeting some years ago. Setting up Apache to use IPv6 is one =
line of config. BIND two or three (not counting IPv6 reverse zones).
>=20
> There are some good books on running IPv6, you know. :-)
I have to agree here... The conversion to dual-stack is not that hard in =
most situations.
OWen
