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

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Tue May 18 12:08:41 CEST 2010


Hi Havard,

On Tue, 18 May 2010 07:36:44 +0200 (CEST)
Havard Eidnes <he at uninett.no> wrote:

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

It's an architectural principle of the Internet (RFC1958) -


3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

I don't believe DHCPv6 only verses RA+DHCPv6 is a significant
improvement, worth the additional costs. It doesn't save significant RAM
or packets, would require additional code - which means new and
different bugs, and causes more confusion as to what options to pick
when deploying IPv6.

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

Where did I say it was perfect? In fact I said I disagree with some
of the design. But it's too late to change it - that opportunity is
gone, and as long as what exists is adequate, I'll deploy it how it is.
I don't want tacked on, second system syndrome solutions to problems
that have already been solved adequately, which will only cause more
delay, additional deployment design solutions, and more problems due to
feature or parameter interaction.

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

That's exactly my point. IPv6 methods work. They may not work how some
people want them to, but tough, deployment of something that works is
more important now than trying to change design decisions that have
been in place for 10 to 15 years.

Regards,
Mark.


More information about the ipv6-ops mailing list