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

[Doug Barton]

On Mon, 24 May 2010, Benedikt Stockebrand wrote:

> Hi Doug and list,
>
> 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. :)

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

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.

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

That puts you in tier 2 of autoconf zealotry, at least in my book. 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.

[snipping here to get to the juicy bits]

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

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.

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

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.

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

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

I'm using "NAT" in a generic sense here, yes.

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

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


Doug

-- 

 	Improve the effectiveness of your Internet presence with
 	a domain name makeover!    http://SupersetSolutions.com/

 	Computers are useless. They can only give you answers.
 			-- Pablo Picasso