[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 5006 status
- To: Ole Troan <otroan@employees.org>
- Subject: Re: RFC 5006 status
- From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
- Date: Fri, 19 Mar 2010 08:41:49 +1030
- Cc: "Durand, Alain" <Alain_Durand@cable.comcast.com>, Fred Baker <fred@cisco.com>, IPv6 Operations <v6ops@ops.ietf.org>, Lindqvist Kurt Erik <kurtis@kurtis.pp.se>, Ralph Droms <rdroms@cisco.com>, 6man Chairs <6man-chairs@tools.ietf.org>, Dave Thaler <dthaler@windows.microsoft.com>, Jari Arkko <jari.arkko@piuha.net>, <jjeong@cs.umn.edu>, <luc.beloeil@orange-ftgroup.com>, <smadanapalli@gmail.com>, Daniel Park <soohong.park@samsung.com>
- In-reply-to: <BAB50883-C74A-4EEE-A9CE-9F5180C0B7C2@employees.org>
- References: <C7C67F1D.37A5F%alain_durand@cable.comcast.com> <BAB50883-C74A-4EEE-A9CE-9F5180C0B7C2@employees.org>
On Thu, 18 Mar 2010 14:15:20 +0100
Ole Troan <otroan@employees.org> wrote:
> > Here is my input to this.
> >
> > First of, we have in IPv6 two competing auto-config mechanisms: RA & DHCP. For a subset of parameters, they more or less overlap. For others, they do not.
> > DNS is in the later category, only in the standard track for DHCP. An example of what can only be discovered with RA is default router or prefix info.
> > This has been a very poisonous discussion for many years, with the result that the IPv6 autoconf story is more complicated that the IPv4 one.
> >
> > At this point, I would favor opening the larger discussion of “How can we fix this mess” rather than pushing a particular technique from experimental to standard track.
> > It might be that the only acceptable answer is we need to defined BOTH mechanisms for every value to discover.
>
> we already have proposals for doing other options in ND, which already exist in DHCP.
> should we reconsider the idea of a generic DHCPv6 option container option for ND?
>
We could also have a go at re-inventing the wheel.
Sorry to be sarcastic, but now is not the time to be clean
slating autoconf methods when there is not another 10 to 15 years
before we need to deploy IPv6. Further more, going down that path now
will cause even more people to hesitate to deploy it - including me.
Why would I want to invest time in deploying today's autoconf
methods that work if there is a chance that they'll be completely
replaced in 5 to 10 years?
People need to accept the existing methods, even though they may not be
completely happy with them. The time to influence their design has gone
- it was 15 years ago.
> cheers,
> Ole
>
>