quietly....

Wed Feb 2 21:28:06 UTC 2011

>> 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?
> 
> 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.
> 
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:
> 
>> it's hard to describe how
>> frustrating this is without resorting to thrown fragile objects
>> against hard walls.
> 
> Ok, I know I'm going to regret this, but:
> 
> 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?
> 
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:
> 
>>> 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.
> 
>> 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.
> 
> 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.
> 
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:
> 
>> <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.
> 
> 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.)
> 
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;
>  }
> 
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.
> 
Exactly.

>> Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector
> 
> You also get to stop worrying about a few old ones.
> 
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.
> 
> 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).
> 
> 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