Subject: Re: Proposed M&O bits text for RFC2461bis

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Apr 2006 15:42:27 -0400

Erik Nordmark <[email-masked]> writes:

> Thomas Narten wrote:

> > Per my comment above, if you don't invoke DHC, you won't get all the
> > addresses the network is configured to be giving you. Hence, you
> > SHOULD invoke DHC to get them.

> I think making that a SHOULD is premature and too strong, since we
> haven't explored what the desirable behaviors are when both M and A
> bits are set.  (When M is set and no prefix has A, then using DHCP
> is a no-brainer.)

Here is how RFC 2119 defines SHOULD:

     3. SHOULD This word, or the adjective "RECOMMENDED", mean that
        there may exist valid reasons in particular circumstances to
        ignore a particular item, but the full implications must be
        understood and carefully weighed before choosing a different
        course.

That is, it is not a standards violation to not follow this, but
unless you have a good reason to ignore the advice, follow it.

Given that, I think SHOULD is exactly right. This is what
implementations (that don't know any better) ought to be doing.
	
> I can imagine that a host wants to have the option to have local policy 
> to handle the case when both M and A bits are set, but there is nothing 
> in the "SHOULD" that allows for local policy control.

I can imagine that too. (And while I'm skeptical that this would
actually be useful in practice, that's beside the point). Adding such
a local option seems like a fine thing for implementations to add if
they want to. Nothing in our standards prevents an implementation from
doing so, and neither would the SHOULD above.

Stated another way, if an implementation added a local policy
mechanism that allowed the user to change the default behavior, I'd be
very surprised if that policy mechanism disallowed the setting of a
policy that would be consistent with the recommended behavior. Thus,
there would be no reason to consider it to be uncompliant (unless
perhaps the default configuration was inconsistent with the
recommended SHOULD - but even that would be open for debate). And if
it chose to set the default to something else, presumably the
implementor "understood and carefully weighed" the issues, and thus
ignoring the SHOULD was justified. 

> If we want to work out more details in this space, I suspect we need to 
> start with understanding why some operator would set both M and A bits. 
> But I think we can defer that discussion until we have more deployment 
> experience.

Rather than spend a lot of time thinking up use cases (and whether
they are compelling or not, since we might even agree that such cases
don't make much sense), I think we should just make it clear what the
expected behavior should be, given what we know today. (And, to cover
the cases that _will_ happen in practice where a client is forced to
deal with this situation, even if only due to a misconfiguration.)

If we can't agree that a SHOULD is appropriate, then to be completely
honest, I don't know why we've been wasting all this time discussing
the M&O bits for the last umpteen months. The original text doesn't
have a SHOULD in it, and people complained mightily that it is
unclear what implemenations are supposed to do. Or am I missing
something?

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Apr 2006 14:51:58 -0700

> implementations (that don't know any better) ought to be doing.

I've seen to many places were a stronger meaning has been assigned to 
"SHOULD" to be happy with this. For instance, the implication has been 
that to be fully compliant all MUST/MUST NOT has to be satisfied, as 
well as all SHOULD/SHOULD NOT, and some vaguer notion of "conditional 
compliance" or something like it if all the SHOULD/SHOULD NOT are not 
satisfied.

> doing so, and neither would the SHOULD above.

We have a history of making such knobs explicit - for instance, see the 
discussion about default values in RFC 1122.

If what we really want to say is
	An implementation MAY have a configuration option ignore
	stateless addresses and/or stateful (DHCPv6) addresses when both
	are present from their configuration protocols. If so, that
	option SHOULD default to accepting addresses from both stateless
	and DHCPv6.
then why can't we explicitly say that?

    Erik

---

From: Ralph Droms <[email-masked]>
Date: Mon, 17 Apr 2006 23:18:46 -0400

In line...

On 4/17/06 5:51 PM, "Erik Nordmark" <[email-masked]> wrote:

>>> bits are set. 

I disagree - the M and A flags are independent of each other.  When both are
set, the host uses SAAC to assign itself an address on the advertised
prefix, and uses DHCP to have addresses and other configuration information
assigned from the DHCP service.

Whether or not that configuration makes any sense is an operational issue,
not a protocol issue.

On my soapbox for a second, it seems to me that we are trying to wordsmith
the behaviors for address assignment *much* more carefully than is necessary
for interoperable implementations.

>>> (When M is set and no prefix has A, then using DHCP
>>> is a no-brainer.)
>> 

I don't see why this spec should define anything aobut host local policy.
SHOULD is explicit enough.

> then why can't we explicitly say that?

- Ralph