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,

Doug Barton <dougb at dougbarton.us> writes:

> On Mon, 24 May 2010, Benedikt Stockebrand wrote:
>
>> sorry for the late and rather hasty reply, but I'm just between
>> conferences.
>
> No problem, for me that life was recent enough that I still remember
> what it was like, and long enough ago that most of the involuntary
> muscle contractions have subsided. :)

Those were technical conferences, not academic ones, and I didn't do
any tutorials or talks for a change:-)

> And what many of us have said, repeatedly over the last decade, is
> that we would like to be able to run our networks with DHCP only, and
> not have to enable RA at all.

Right.  But stateful DHCP on IPv4 has shown a number of significant
drawbacks, so making use of the sparse address space in IPv6 was only
reasonable.

>> I suppose that kind of disqualifies me as an "Autoconf zealot":-)
>
> That puts you in tier 2 of autoconf zealotry, at least in my book.

Oh, great.  Now the DHCP-only people will call me a "tier 2 autoconf
zealot" and at the same time the Autoconf-only people will call me a
"tier 2 DHCP zealot":-)

> The fact that you don't seem to be able to imagine a world with no
> RA prevents you from being disqualified altogether. Although I would
> happily stand corrected if I'm wrong.

Actually, I can imagine a world without Autoconf.

There are however a number of reasons why I consider Autoconf superior
over DHCP with regard to address assignment.

They are to some degree based on the assumption that IPv6 doesn't only
allow people to use a "many small subnets" design (with "small" being
the number of nodes attached, not any prefix lengths).  In any
security sensitive context, and that's pretty much the case in any
enterprise network, this is the reasonable way to go.  (If you don't
want to agree with this assumption I suggest we start an independent
thread here, it's actually a rather complex topic by itself.)

Address configuration with DHCP has a number of serious technical
drawbacks:

- It is more complex, and as such more susceptible to implementation
  errors and possibly even design errors.

- Unless I want to run a DHCP server in every subnet, I have to use
  routed DHCP packets between relays and servers.  These are a
  potential attack vector which doesn't exist with link-local-only
  Autoconf.

- DHCP servers are prone to DoS attacks by simply allocating
  sufficiently large numbers of addresses.  They can be made to either
  run out of addresses (when given a small address range) or either
  performance or persistent storage for the leases DB (given a large
  address range).

- Making DHCP servers redundant either takes twice the number of
  addresses or some extra effort and complexity.

The one drawback that Autoconf has is that, outside Windows/Active
Directory setups there is no commonly available means to update DNS
records.  There are a few old lab-grade tools available for Unix
(*BSD, Solaris, Linux) on my home page, but that's pretty much it.

> That's great, but what I've been trying to get across for a long time
> now is that it really doesn't matter how clever your argument is, how
> much YOU think it's reasonable, etc. The fact is that a lot of large
> enterprises won't even LOOK at IPv6 for their internal networks
> because they don't want to unravel the administrative procedures that
> they already have in place, and that are already working well for them.

I suppose I am less optimistic than you are.  From what I've seen in
the second half of the 1990s I am pretty sure that the large majority
of companies will rush towards IPv6 with a time frame of a few months,
most likely the last about six months until support for Windows XP
runs out.  The level of technical similarities doesn't really matter
that much when it all depends on management allocating money.

As far as the administrative procedures are concerned, in most cases
I've seen it was rather tedious to make the network (Cisco etc.)
people work together with the server (Unix, Windows, whatever the DHCP
server was running on) work together.

>> As I said, some functionality is only available with IPv6.
>
> Can you point some out? References would be fine here. I'd love to
> have some actual ammunition that I can point people to when they ask
> me why they should bother deploying IPv6.

Sure: Direct Access (for enterprise users) and Home Groups (for
private end users).

And of course, statically allocated global addresses for everyone.
This may not be as important to you as you are apparently based in the
U.S., but to people outside the ARIN and RIPE regions it is.

>> 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.
>
> I assume you meant "four" there, and if so I would assert that their
> v4 network architecture was bad and not meeting their needs to begin
> with, so at that point tearing it all down and starting over with IPv6
> is not that great of a marginal expense.

It's not as easy.  Gert already pointed out elsewhere in this thread
that mergers and acquisitions have a huge effect on this.  Beyond that
we have large companies like Comcast who simply need more than the
RFC1918 addresses even for internal purposes.  Others just don't go
public about that same problem.

The customer I was referring to had yet another problem: They are
doing IT operations for various customers.  What happened there was
that two companies both used NAT internally (for reasons I can't go
into) and another layer of NAT towards the outside.  When they merged
and had to connect the "hidden" internal systems this turned out a bit
of a problem for that contractor.

>> 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.
>
> But the costs and upgrade activity (read, pain) are all contained in
> one silo, the network administration group. Compared to the costs
> associated with rolling new things out to every desktop,
> re-architecting existing networks, etc.; whatever costs are involved
> with setting up IPv6 compatibility at the border of the internal
> network are minuscule.

Those "opportunity costs" (I hate these fancy biztalk words, but )
because of lost e-mails or unavailable webshops or whatever are
anything but minuscule.

Rolling out IPv6 to all desktops is another issue.  As far as Windows
is concerned, and that's the vast majority of desktop machines, the
approach I suggest to my customers is to leave XP and the odd Vista
machine on IPv4, set up servers dual-stacked, prepare a new network
infrastructure (read: VLANs) for IPv6 and deploy Windows 7 right into
the IPv6 infrastructure.

The costs you talk about are a penalty for those who first deploy
Windows 7, explicitly disable IPv6 as far as possible on those
machines, and then move to IPv6.

>> 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.
>
> I'm talking internal networks here. Lots of 1918 space available.

In case you have missed it so far: Check your favourite search engine
for "Comcast IPv6 Alain Durand" (sorry I don't have a link handy).

Beyond that, the RFC 1918 address space is too small for a few other
reasons.  Mergers and acquisitions are costly to a significant degree
because they take some significant renumbering.  Less obvious, large
enterprises suffer from unnecessary organizational overhead because
they have to manage that address space centrally.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

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