Not trying to oversimplify things here, but to me it makes the most sense to
start with what we have working now and *not* make any broad, sweeping
changes. To do otherwise is not only a tremendous disservice to all of
those who have implemented/adopted IPv6 (or are considering doing so) but
also fails IMHO to be a good, technical approach to the problem at hand.
I am in no way saying we can't continue adding capabilities (e.g. - XML
config via RA-provided URL) ... but to make drastic changes to functions
that real people are using in real networks to provide real services seems,
well, sub-optimal.
What we have:
SLAAC
Stateless DHCPv6
Stateful DHCPv6
(Manual Configuration, out of scope for / irrelevant to this
conversation)
SLAAC is well defined, and works quite well - even w/o DNS-option support
being widespread. Once RFC5006 support is in place, this will be sufficient
for most uses, with a valid concern about the host identification /
(dynamic) name resolution areas. We can address those, rather than toss the
baby with the bath water.
DHCPv6 is also well defined, with some questions rising around the acillary
pieces - e.g. when does a host run it, and choose which mechanism. IMHO,
simply making a clearer definition of the M & O bits would be sufficient.
In my world view, the following would be the least painful and most
functional approach:
Host sends RS
If RA recevied - look for A/prefix, M, O bits and act accordingly.
... if one RA specifies one approach, and one RA specifies
the another, do both ...
In almost all properly functioning scenarios this is all the we need, yes?
Additionally ...
If no RA received, I am OK with the host making a one-shot attempt
at both stateless and stateful DHCP, just in case
... the question here - what is the assumed prefix length /
"on link" approach?
... if we stick with the "right" answer of /128,
well then DHCPv6 didn't accomplish much
... unless something else comes in to play
... LLMNR, etc. providing a
hint on onlinkedness, or somesuch.
... if we assume /64 we raise other problems /
questions
I think this case is somewhat degenerate and should be rare;
but should nonetheless have a consistent, well defined behavior.
Am I missing anything fundamental here?
/TJ
PS - I totally agree with Iljitsch's "the amount of people that complain
that IPv6 changes too much seems to be about the same as those that complain
that IPv6 doesn't change enough so my guess is that they got this more or
less right" ... I believe another relevant quote would be "rough consensus
and running code".
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
