quietly....

Iljitsch van Beijnum iljitsch at muada.com
Wed Feb 2 20:55:30 UTC 2011


On 2 feb 2011, at 21:18, John Payne wrote:

> Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems.

You should have come to the IETF 10 or even 5 years ago. It's too late now, one day before the global pool of IPv4 addresses runs out. IPv6 is what it is. There will be more tinkering but if you think there's enough time to wait for your pet feature to be standardized and implemented widely, you're sorely mistaken.

> 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.

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?

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.

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.)

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;
  }

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.

> 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.

> 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.  :-)



More information about the NANOG mailing list