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

From: "Durand, Alain" <[email-masked]>
Date: Tue, 18 Apr 2006 09:17:30 -0400

-----Original Message-----
>From: Ralph Droms [mailto:[email-masked]]
>Sent: Mon 4/17/2006 11:18 PM
>To: Erik Nordmark; Thomas Narten
>Cc: IPv6 Mailing List
>Subject: Re: Proposed M&O bits text for RFC2461bis
>
>On 4/17/06 5:51 PM, "Erik Nordmark" <[email-masked]> wrote:
>
>> Thomas Narten wrote:
> 
>>>> 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. 
>
>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.

This *is* a protocol issue because of the way default address selection works.

BTW, M&A bot set *is* a valid configuration, where on the same subnet
one would like to use both servers that want to use nothing but DHCP and
laptops who are perfectly happy with stateless autoconf (or small devices
who do not have  implemented anything else)

IMHO, the real problem with those bits is that their scope is wrong,
it applies indiferently on all nodes on the link, and I think this is not correct.
Such a scope is fine for things like basic RS/RA, but config information
is to be applied on a per node basis, and not subnet wide.

This is the reason why I'm opposing the SHOULD for M&O.

BTw, I agreee with a previous post, there is no reason anymore to have two bits
fot that. The only thing that IMHO those bits mean is that DHCP service is available,
i.e. there is either a DHCP server on the subnet or there is a relay agent.
Trying to differentiate on the capabilities of the said DHCP server
(full DHCP or only "other parameters" is meaningless, so I think
we could live with only one indicaive bit here.

    - Alain.

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Apr 2006 09:33:48 -0400

> who do not have  implemented anything else)

This is the crux of the fundamental underlying disagreement we are
having on what we are trying to solve here.

In my view, it is nuts to have devices "that choose to implement only
stateless addrconf" because they are "simple" or "perfectly happy" or
something. If we go down this route, it is not an operational choice
whether to run DHC, because implementations have already made that
choice.

If folk chose not to implement DHC or stateless addrconf, that is
fine, and that is their choice. But the consequences may well be that
they can't get addresses in all environments. We need to be
clear/truthful about that. You seem to be suggesting that this  is not
acceptable and that instead, operations need to provide stateless addr
conf in all cases since some devices may require that. Is this
_really_ what you intend?

Having the M&O bits say "use dhc" (if you have implemented it) or
"don't bother with DHC" is useful, independent of the above.  But what
seems to be happening now (as in the past) is that the M&O bits are
being viewed as somehow mandating the implementation of DHC, and folk
don't want that.

IMO, having the M bit say "invoke DHC" does not mandate implementing
DHC any more than having an RA a Prefix Information Option with the
"A" bit set "mandates" that one MUST implement stateless address
autoconfiguration.

And, BTW, I know of one implementation that does NOT implement
stateless addr conf and isn't all bent of out shape the specs seeming
to require (or not require) implementation of stateless
autoconfiguration. So I really do not understand why we are making
such a big deal out of this.

Chairs, Perhaps we need to just accept that we can't get consensus on
revised wording for the M&O bits and leave the text unchanged
relative to RFC2461?

It's long past time for getting closure on this issue and moving on,
yet we continue to have the same back-and-forth on the mailing
list. :-(

Thomas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 19 Apr 2006 00:51:01 +0900

>>>>> On Tue, 18 Apr 2006 09:33:48 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> revised wording for the M&O bits and leave the text unchanged

One quick comment: we cannot simply do this (module the meaning of
"relative") because in the original text of RFC2461:

      M              1-bit "Managed address configuration" flag.  When
                     set, hosts use the administered (stateful) protocol
                     for address autoconfiguration in addition to any
                     addresses autoconfigured using stateless address
                     autoconfiguration.  The use of this flag is
                     described in [ADDRCONF].

      O              1-bit "Other stateful configuration" flag.  When
                     set, hosts use the administered (stateful) protocol
                     for autoconfiguration of other (non-address)
                     information.  The use of this flag is described in
                     [ADDRCONF].

"described in [ADDRCONF]" is no longer valid (if ADDRCONF=2462bis, not
RFC2462) because 2462bis has completely removed text related to these
bits.

One possible easy compromise, considering the view of not getting
consensus on this, would be to the last sentences to: "(further
details of) The use of this flag is not determined yet".  I'm not sure
if this can be any more useful than saying nothing about these bits,
though.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]