Mysterious missing DHCPv6 feature, was Re: How does one obtain an IPv6 DNS server when VPNing to an ASA?

[Benedikt Stockebrand]

Hi Doug and list,

sorry for the late and rather hasty reply, but I'm just between
conferences.

Doug Barton <dougb at dougbarton.us> writes:

> You're attempting to minimize the significance of the arguments you
> don't agree with, which is a fine rhetorical technique, but not very
> useful from an operational perspective.

Actually, no.  What seems to you like a "fine rhetorical technique" is
apparently a misunderstanding.  Let's get straight about what I was
talking about: Distributing a *default route* via DHCP.  That's a
functionality already available via Autoconfiguration.

I have never said that using (stateless) DHCP for application layer
configuration was a bad move.  In fact I consider the combination of
Autoconfiguration (for network layer configuration) and stateless DHCP
(for application layer configuration) the way to go.

I suppose that kind of disqualifies me as an "Autoconf zealot":-)

Unfortunately, at least David Barak seems to believe that anybody who
considers stateful DHCP inferior to Autoconf wants to get rid of DHCP
entirely.

> Whether you agree with the reasons enterprises want DHCP or not,
> enough folks have repeated those reasons often enough at this point
> that by disregarding or diminishing them it only makes you look
> foolish, and out of touch.

Maybe.  But maybe I've seen too many people who want IPv6 to be
nothing more than "IPv4 with longer addresses".

> In no particular order, the main reasons enterprises like DHCP:
> 1. It allows them to configure multiple aspects of Host Configuration,
> not just the bare minimums required for connectivity.

So does Autoconfiguration and stateless DHCP.

> 2. Configuring one (or at most a few) DHCP servers is easier than
> configuring many routers.

The way DHCPv6 works, you still have to set up DHCP relays in all
subnets.

> 3. The administrative domains covered by network administration and
> those who configure DHCP are often different, and the needs of the
> latter are often more dynamic (pardon the pun) which requires fast
> response times to meet effectiveness goals.

Hmm, from my personal experience I usually found it quite tedious to
first deal with the network people and then with the server people to
get a new subnet up and running.  But that may be a matter of personal
experience.

What I consider a more important reasoning is that Autoconf takes care
of network layer configuration (ignoring this rather questionable
approach to deploy DNS related information via Autoconf) while
stateless DHCP, with vendor extensions and all, takes care of the
application side.  Keeping these two separated appears quite
reasonable to me.

> 4. Security concerns related to rogue/misconfigured RA messages. (This
> is the everyone fails instantly vs. only failing when you renew your
> lease problem.) Yes, I know that RA guard is "almost done," but the
> concern remains valid.

I agree that that's a point, but there's a tendency towards a "many
small subnet" topology where only few machines are affected by that
scenario.  (Sorry, there's more to say about this, but I'm running out
of time right now.)

An issue with stateful DHCPv6 is that it uses routed traffic and as
such is more or less vulnerable to remote attacks.  Autoconfiguration
is inherently limited to link-local scope.

In security sensitive contexts I actually recommend to configure a
stateless DHCP server (rather than relay) in every subnet, provided
that the routers used can be used for this.  Doing so however requires
a bit of scripting to ensure that the DHCP data is managed centrally.

> Telling enterprise users, "But this is a New Thing(TM), so you have to
> learn (read spend money on) new ways of doing things" is going to
> continue to get you the same response it has for the last 10 years, "No
> thanks, we'll just use NAT."

There are increasingly more people actually setting up IPv6
internally, and using proxies to communicate with the outside.  This
is partly due to the impact of Windows 7, including Direct Access and
Home Groups.

> It's actually really important to understand this, since there is
> ABSOLUTELY no argument you can advance for why IPv6 is "better" that is
> persuasive here.

Actually, there are two: Additional functionality and reduced costs.

As I said, some functionality is only available with IPv6.

At another customer I recently got them moving towards IPv6 by simply
pointing out that this would get them rid of the problems they
currently have with NAT; they mentioned that at least in one case they
have to cross for consecutive NAT gateways "in the wrong way".  This
is costing them actual money.

Reliability, or, more generally, expenses are what makes managers do
things.

> Even in a world where 99.99999% of the content "on the
> intarwebz" is available ONLY over IPv6, IPv6 NAT at the border of their
> IPv4-only network will work just as well for them as NAT at the border
> of their IPv4-only network works for them now.

(I suppose you mean protocol translation, and possibly proxies, not
(IPv4) NAT.)

Your reasoning assumes that you can get both at the same cost.  NAT
gateways, proxies and NAT-PT stuff all cost significant money,
especially if you count the "opportunity costs" in when they fail.
And from the experience with large scale NAT gateways I have serious
doubts that these coses are negligible.

Yet another issue is actually running out of addresses.  That's not
much of an issue in the U.S., and not too much of an issue here in
central Europe, but the situation is worse in the LACNIC, AfriNIC and
APNIC regions.

If you have to pay twice as much for IPv4, then you'll move to IPv6.
If you can't get any static IPv4 addresses but need them, you'll move
to IPv6, too.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/