OK, I'm going to wade back into this and say that I believe we've
botched things. Let's take a typical client implementor, who looks at,
say, RFCs 4861, 4862 and/or RFC 3315 (the DHCPv6 spec).
Question: just when are they supposed to invoke DHCPv6? All the time?
Only if the M or O bits are set? This simply isn't clearly
defined. This is broken and teh IETF really needs to make a
recommendation.
Background:
RFC 3315 (the DHCPv6 spec) says:
IPv6 Stateless Address Autoconfiguration [17] specifies procedures
by
which a node may autoconfigure addresses based on router
advertisements [13], and the use of a valid lifetime to support
renumbering of addresses on the Internet. In addition, the protocol
interaction by which a node begins stateless or stateful
autoconfiguration is specified.
But, the two references above point to RFCs 2461 and 2462, which have
been obsoleted. In theory, implementors should be able to look in RFC
4861 and 4862 instead to get the proper guidance. Unfortunately, they
won't find clear guidance.
RFC 4861 (the ND spec) talks about what to do with the M&O bits, but
only from a router's perspective, i.e., it includes configuration
knobs for setting the bits in outgoing RAs. That is all fine, but
doesn't address what a client implementation should do. The text does
say (in the context of defining the bits):
M 1-bit "Managed address configuration" flag. When
set, it indicates that addresses are available
via
Dynamic Host Configuration Protocol [DHCPv6].
If the M flag is set, the O flag is redundant and
can be ignored because DHCPv6 will return all
available configuration information.
O 1-bit "Other configuration" flag. When set, it
indicates that other configuration information is
available via DHCPv6. Examples of such
information
are DNS-related information or information on
other
servers within the network.
But this is very general, and doesn't provide clear guidance to an
implementor.
RFC 4862 is completely silent on what to do. It only says (in the
"changes" section):
o Removed the text regarding the M and O flags, considering the
maturity of implementations and operational experiences.
ManagedFlag and OtherConfigFlag were removed accordingly. (Note
that this change does not mean the use of these flags is
deprecated.)
This is broken. Implementors should be able to look at the (current)
specifications and get clear advice on what to do. And, are we saying,
in fact, that RFC 2461 has not _really_ been obsoleted and
implementors should look at the older RFCs for guidance? I hope not!
Oh, and the Node Requirements specification isn't much better.
draft-ietf-6man-node-req-bis-01.txt: says:
6.2.1. 5.2.1. Managed Address Configuration
The method by which IPv6 nodes that use DHCP for address assignment
can obtain IPv6 addresses and other configuration information upon
receipt of a Router Advertisement with the \'M' flag set is
described
in Section 5.5.3 of RFC 4862.
(RFC 4862 says no such thing actually!)
In addition, in the absence of a router, those IPv6 nodes that use
DHCP for address assignment MUST initiate DHCP to obtain IPv6
addresses and other configuration information, as described in
Section 5.5.2 of RFC 4862. Those IPv6 nodes that do not use DHCP
for
address assignment can ignore the 'M' flag in Router
Advertisements.
Again, RFC 4862 simply doesn't say the above. It uses "may" language,
and even that is indirect:
5.5.2. Absence of Router Advertisements
Even if a link has no routers, the DHCPv6 service to obtain
addresses
may still be available, and hosts may want to use the service. From
the perspective of autoconfiguration, a link has no routers if no
Router Advertisements are received after having sent a small number
of Router Solicitations as described in [RFC4861].
So, I think we have made a mess of things and we need to fix things.
I will assert that the fundamental problem we have is that we have not
yet agreed on when a client should invoke DHCP.
Our options are:
1) We could ignore/deprecate the M&O bits and simply have any
client that implements DHCP invoke DHCP without even bothering to
see what the M&O flags say. I.e, the way DHCPv4 works today.
IMO, this approach would work fine. Indeed, it has the advantage
that the client won't do the wrong thing due to misconfigured
routers sending out M&O bits with the wrong setting. The main
downside is that operators would have no way of signalling to
clients that DHCP isn't available and they shouldn't waste
resources trying to invoke it. In the past, there has been
endless(?) debate about how significant the "waste" would be.
2) We could restore the M&O bits, and tie DHCP invocation to the
settings of those bits. This is what 2461/2462 did, and was the
original model. But, there is still a number of choices to be made
here:
a) Treat the M&O bits as SHOULDs, meaning exactly that. If the bits
are set, one SHOULD invoke DHCP, but it is NOT a MUST
requirement. If one choses (for whatever reason) not to honor
the bits, so be it, but it is not a protocol violation per se.
This is the approach 2462 took, though it used lower case
shoulds.
b) Treat the M&O bits as MUST. You MUST invoke DHC if they are set,
and it is a protocol violation to not do so (if you have
implemented DHC, i.e., you have a non-complient DHCP
implementation).
c) One could also say one MUST NOT invoke DHCP *unless* the M&O
bits are set.
Some people/operators wanted such behavior because they wanted a
way of indicating that no DHCP servers are present, and that
clients shouldn't waste network resources invoking DHCP (this
was asserted to be a potential issue on some types of wireless
WANs).
Others argued that a robust client would be foolish to rely on
the proper settings of those M&O bits, as it could lead to
(unncessary) failures if routers were misconfigured, but DHCP
servers were available. [this leads back to the call for option
1) above]
In summary, the current specs are not clear on when a client should
invoke DHCPv6 and when not. That is broken and should be fixed. I also
suspect that it it less important *which* approach we adopt, than that
we do actually choose one and document it.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
