Hi Thomas,
On Mon, 23 May 2011 17:11:28 -0400
Thomas Narten <nar...@us.ibm.com> wrote:
> Christopher Morrow <christopher.mor...@gmail.com> writes:
>
> > one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6
> > is on-net, but require full config from a dhcpv6 server".
> > How does a host know that v6 is available otherwise? (this may be why
> > someone said "you don't really want to do that..')
>
> Well, if I could go back in time, I would never have defined the M&O
> bits at all.
>
> Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use
> whatever is available. That would have been simple and
> predictable. (And avoided 10GB of mailing list discussion!)
>
What if both are available, accidentally or intentionally (due to
misunderstanding that it should be one or the other)? Conflict
resolution in these sorts of situations isn't always simple and
predictable. You've now got twice as many things to configure
correctly, and at least twice as many things to troubleshoot if they
don't work.
I'd think either leaving the status quo, or dumping one of them, and
adding the features to the remaining one to make it the functionally
equivalent to the dumped one would be a better thing to do at this time.
I'm not particularly pro-SLAAC, however I sit back and wonder what is
missing from it that makes DHCP essential? It seems to me that the
functional reason people want DHCP is that they think it will track
address use - but it won't if end-nodes are manually assigned static
addresses. SLAAC won't prevent that either - so both SLAAC and DHCP
aren't adequate if your goal is to track address use. In other words,
its a problem that neither of them adequately address and have tried to
address.
> (Hmm, maybe I should just write such a spec now, given the M&O bit
> definitions are in the twilight zone anyway... Discussion of what to
> do with them was effectively removed from the last revisions of the
> SLAAC documents, so now there is no clear guidance on how to process
> them. The IETF at its finest...)
>
I'm a bit confused, I find this text in RFC4862 quite clear as to what
to do -
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.
About the only thing I'd have changed in the above to make it more
clearer is to use the word "stateful" in the M section when referring to
DHCPv6 and "stateless" in the O section.
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
