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

[Benedikt Stockebrand]

Hi list,

[Steinar Haug]
>> > I would of course be even happier to see a *standardized* solution to
>> > let DHCPv6 hand out a default gateway. The lack of such a feature (and
>> > the strong religious opposition to it in certain circles), despite clear
>> > statements from several big operators that they need it, is one of the
>> > significant factors hampering IPv6 deployment.

I disagree here.  From what I've seen so far the key problem with
regard to IPv6 is that a lot of people try to make IPv6 an "IPv4 with
larger addresses", preserving all the workarounds they have come to
get used to.  "We've always used DHCP", "I want my NAT back", "I've
always written IP addresses in decimal", "There can't be multiple
default routes in a routing table" and so on.

Unless I missed something, nobody in this discussion came up with an
explanation what's wrong about making ones default routers advertise
itself as such.

On the other hand, using autoconfiguration for this job has the
additional advantage that it allows one to provide redundant routers
without having to resort to HSRP or VRRP.  That sort of solution may
not be up to par in a data center setup, but it *is* helpful
especially at small business customers.

And I am not even bothering to bring up the operational issues address
allocation via DHCP brings into office style IPv4 networks.  Using
stateless DHCP is pretty much fine with me, but from an operational
point of view stateless address autoconfiguration is quite a step in
the right direction.

[Mark Smith]
>> I don't think so.
>>
>> What I think is hampering deployment is people constantly discussing
>> and debating design decisions that they don't agree with, 10 to 15
>> years after they were made, rather than accepting them, and getting on
>> with deploying it.

Almost:-).  I'd say it is perfectly valid to keep discussing design
decisions---but only as long as the impact of a design change at the
given point in time is given the appropriate degree of consideration.

>> It may not be perfect in their opinion (and it isn't in mine), but
>> then usually nothing ever is - it's all about trade offs. The
>> pressing problem is deployment.

Right.  And, just for completeness sake: If we can't get the specs to
stabilize, we can't deploy.

[Havard Eidnes]
> The decision "only one protocol to implement a feature" or "only one
> way to hand out addresses" can hardly be called a design decision.  To
> me it sounds more like an article of faith.

If you offer multiple protocols, or protocol features, for a single
feature, you'll eventually have to implement, support and configure
them all.  If you take a look at SIP you'll get an idea of this
problem.

> Not being able to correct mis-designs after operator feedback because
> "it was designed 10-15 years ago, so must now be perfect!" also
> appears more as religious fervor rather than sound engineering.

That's not what Mark wrote.

> Follow down this path, and we're doomed to do IPv4 NAT forever.
> That's not a position I would like to see us end up in.

If we keep disagreeing and messing around with the protocols over and
again, we're just as "doomed to do IPv4 NAT forever".


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

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