Subject: Proposed M&O bits text for RFC2461bis

From: Bob Hinden <[email-masked]>
Date: Tue, 21 Mar 2006 13:36:18 -0600

Hi,

At the Vancouver meeting we discussed clarifying the use of the M&O  
bits in Neighbor Discovery Router Advertisements.  I made a proposal  
to drop <draft-ietf-ipv6-ra-mo-flags-01.txt> and instead to just  
change the text describing the M&O bits in <draft-ietf- 
ipv6-2461bis-06.txt> along the lines as Thomas Narten suggested on  
the IPv6 list.

The current M&O text from Section 4.2 "Router Advertisement Message  
Format" <draft-ietf-ipv6-2461bis-06.txt> is a follows:

    M              1-bit "Managed address configuration" flag.  When
                   set, it indicates that Dynamic Host Configuration
                   Protocol [DHCPv6] is available for address
                   configuration in addition to any addresses
                   autoconfigured using stateless address
                   autoconfiguration.

    O              1-bit "Other configuration" flag.  When
                   set, it indicates that [DHCPv6lite] is available
                   for autoconfiguration of other (non-address)
                   information. Examples of such information are DNS-
                   related information or information on other servers
                   within the network.

The proposal is to replace this text with the following text.  Note,  
this is same as what was proposed at the meeting with the addition of  
the note at the end as was suggested at the meeting.

    M :
        1-bit "Managed address configuration" flag.  When set, it  
indicates
        that addresses are available via Dynamic Host Configuration  
Protocol
        [DHCPv6], including addresses that were not configured via  
stateless
        address autoconfiguration.  Clients SHOULD use DHC to obtain  
addresses
        (and associated configuration information) as described in  
[ADDRCONF].
        Note that when the M bit is set, the setting of the O bit is
        irrelevant, since the DHC server will return "other"  
configuration
        information together with addresses.

    O :
        1-bit "Other configuration" flag.  When set, it indicates that
        [DHCPv6lite] is available for autoconfiguration of other (non- 
address)
        information.  Examples of such information are DNS-related  
information
        or information on other servers within the network. When set,
         - If the M bit is also set, clients SHOULD use DHC to obtain
           addresses (and associated configuration information) as  
described
           above.
         - If the M bit is not set, clients SHOULD use DHC as  
described in
           RFC3736.

       Note that if M and O are not set, clients SHOULD NOT not  
request any
       information with DHC.

I also reviewed <draft-ietf-ipv6-rfc2462bis-08.txt>.  I didn't find  
any mention of the M and O flags in the RFC2462bis draft.   
Consequently, I don't see any need to modify that draft if we adopt  
these changes for RFC2461bis.

Comments.

Bob

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Mar 2006 20:09:53 +0000

>         - If the M bit is not set, clients SHOULD use DHC as  

That should probably be a reference [DHCPv6lite], or you should say
DHC Lite instead of DHC?
 
> these changes for RFC2461bis.

Yes, the change log for 2462bis says 

   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.)

Which explains why it was removed.

Note another changeklog in 2462bis talks about removing references to
stateful configuration:

   o  Avoided the wording of "stateful configuration", which is known to
      be quite confusing, and simply used "DHCPv6" wherever appropriate.

Maybe the text above should reflect that, and just refer to the DHC
variants without explictly mentioning the s-word?

-- 
Tim/::1

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 21 Mar 2006 16:55:40 -0500

I agree with the questions Tim and Alain brought up. How is this text,
only slightly changed (asterisks mark the changes): 

>     M :
>         1-bit "Managed address configuration" flag.  When
>         set, it indicates that addresses are available via
>         Dynamic Host Configuration Protocol [DHCPv6], *for*
>         addresses that were not configured via stateless
>         address autoconfiguration *or other means*.  Clients
>         SHOULD use DHC to obtain addresses (and associated
>         configuration information) as described in [ADDRCONF].
>         Note that when the M bit is set, the setting of the
>         O bit is irrelevant, since the DHC server will return
>         "other" configuration information together with
>         addresses. *If the M bit is set, clients MAY(?) [or
>         SHOULD(?)] use DHC to set addresses that are not
>         autoconfigured.*
>
>     O :
>         1-bit "Other configuration" flag.  When set, it
>         indicates that [DHCPv6lite] is available for
>         autoconfiguration of other (non-address) information.
>         Examples of such information are DNS-related
>         information or information on other servers within
>         the network. When set,
>          - If the M bit is also set, *proceed as described
>         above.*
>          - If the M bit is not set, clients SHOULD use DHC
>         LITE as described in RFC3736 to obtain "other"
>         configuration information, *and may use address
>         autoconfiguration or static assignments to set IP
>         addresses*.
>
>     If M and O are not set, clients SHOULD NOT request any
>     information with DHC.

It seems unnecessary to repeat what to do if M = 1 in both the M and the
O paragraphs. I think we need to differentiate between DHC and DHC, when
the latter refers to stateless DHC. And it might help to give examples
of how addresses should be set if DHCP is not available for that.

Bert

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Mar 2006 20:10:45 -0600

> >         address autoconfiguration *or other means*.  Clients

I disagree with the above text. I have two concerns.

First, the "or other means" makes no sense, because how can DHC (or
the router that has set the bit) know what "other means" have
configured addresses. E.g., manual configuration.

Also, while I expect that it doesn't make sense to assign the _same_
addresses both via stateless addr conf _and_ DHC, I don't think we
should prohibit it and turn it into some sort of invalid state that
implementations need to explicitely test for. If DHC configures the
same addresses learned via stateless addr conf, just use the most
recently received info as already specified in 2461/2462.

That is, in the spirit of keeping it simple, if the M bit is set, the
client should invoke DHC. End of discussion. If DHC fails and no
address are returned, nothing breaks. If DHC returns the same
addresses already configured via stateless addrconf, again, nothing
breaks. So let's not try to turn these scenarios into extra
implementation work.

See also Section  5.6 of 2462bis (and its predecessors) that talks
explicitly about how to handle the case of getting the same
configuration information from both DHC and stateless addrconf.

> >         SHOULD(?)] use DHC to set addresses that are not

I don't see the last sentence being needed, as it says the same thing
as the first sentence, i.e., "SHOULD use DHC to obtain addresses ... as
described in [ADDRCONF]".  Is that sentence not clear enough?

> >          - If the M bit is also set, *proceed as described

I'm OK with this change. Actually, while composing this note, I've
changed my mind and would rather not make the change. the "proceed as
described above" may be ambiguous, in that its not immediately clear
what "above" refers to. Including  the relevant text (even though
repetitive) eliminates the potential ambiguity. And since its only one
sentence, I don't see the redundancy as a big deal (though I do agree
that its better not be repetitive in general).

> >         autoconfiguration or static assignments to set IP

last part is unnecessary, IMO. Nothing in any spec that I am aware of
suggests that if DHC is in use, you are not supposed to use stateless
addrconf, or manual config, or something else. In contrast, 2461bis
(and its predecesors) say:

which seems very clear to me.

> the latter refers to stateless DHC.

Agree.

> And it might help to give examples of how addresses should be set if
> DHCP is not available for that.

This is adequately covered already elsewhere, IMO.

Given this and my other note, here is the text I would propose:

    M :
    
        1-bit "Managed address configuration" flag.  When set, it
        indicates that addresses are available via Dynamic Host
        Configuration Protocol [DHCPv6], including addresses that are
        likely not available via stateless address autoconfiguration.
        Clients SHOULD use DHC to obtain addresses (and associated
        configuration information) as described in [ADDRCONF].  Note
        that when the M bit is set, the setting of the O bit is
        irrelevant, since the DHC server will return "other"
        configuration information together with addresses.

    O :
    
        1-bit "Other configuration" flag.  When set, it indicates that
        [DHCPv6lite] is available for autoconfiguration of other
        (non-address) information.  Examples of such information are
        DNS-related information or information on other servers within
        the network. When set,

           described above.
	   
           described in RFC3736.

       Note that if neither M nor O are set, clients SHOULD NOT not
       request any information with DHC.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Mar 2006 00:14:41 -0500

In the interest of simplicity and consistency (note that the protocol in
question is referred to as DHCP or DHCPv6 through all of specifications [as
well as in the original version of this text], not "DHC"), I suggest the
text below.

Comments on previous earlier text:

   including addresses that are likely not available via stateless address
   autoconfiguration.

Deleted as it adds no discernible content to the text.

S/Clients/The node/
S/DHC/DHCPv6/
Deleted reference to [ADDRCONF] (what part of [ADDRCONF] was referenced
   here?)
Added reference to interface on which RA was received for clarity

   since the DHC server will return "other"

S/DHC/DHCPv6/
s/"other"/all available configuration information/

s/autoconfiguration/delivery/ because the configuration involves a server
  and is not "autoconfiguration"

Reworded for clarity

=====
    M :
    
        1-bit "Managed address configuration" flag.  When set, it
        indicates that addresses are available via Dynamic Host
        Configuration Protocol [DHCPv6].  When the M flag is set,
        nodes SHOULD use DHCPv6 to obtain addresses (and associated
        configuration information) to be assigned to the interface on
        which the RA was received.  Note that when the M flag is
        set, the setting of the O bit is irrelevant, since the DHCPv6
        server will return all available configuration information
        together with any addresses.

    O :
    
        1-bit "Other configuration" flag.  When set, it indicates that
        DHCPv6 for other configuration information [DHCPv6lite] is available
        for delivery of other (non-address) information.  Examples of such
        information are DNS-related information or information on other
        servers within the network. When the O flag is set,

         - If the M flag is also set, the O flag is irrelevant (as
           described above) and the node SHOULD use DHCPv6 to obtain
           addresses and associated configuration information.
       
         - If the M flag is not set, the node SHOULD use DHCPv6 as
           described in RFC3736.

       Note that if neither M nor O are set, the node SHOULD NOT not
       request any information with DHCPv6.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Mar 2006 00:19:47 -0500

I missed one nit: s/bit/flag/:

- Ralph

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 22 Mar 2006 17:32:36 -0500

For the M bit description, I had proposed:

> >         address autoconfiguration *or other means*.  ...

> configured addresses. E.g., manual configuration.

I'm not sure I understand why the DHCP server or router need to know
what "other means" were used, as long as these other means result in
valid addresses. I'm simply saying that we should not preclude other
methods of assigning addresses even though the M bit might be set.

The discussion veered off in other directions, and I'm not sure that
point ever got resolved. I undertand that perhaps stateless autoconfig
might or might not create the same address as the DHCPv6 server offers.

> client should invoke DHC. End of discussion.

Are you saying that if the M bit is set, no other means of address
configuration should be allowed? I don't think I can agree with that.
Wasn't this already debated some time ago? The M bit should indicate I
have this DHCPv6 option, not that other options are closed to me.

I agree with other contributors that not using DHCPv6 might result in
having fewer addresses configured than the network permits. But, for
example, there are times when I would want exactly this to be the case
for at least some of the clients of the network.

Other than that, I'm okay with the rest of the discussion.

Bert

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Mar 2006 17:09:48 -0600

> configuration should be allowed?

Not at all. If M is set, invoke DHC, in the SHOULD sense.

In addition, use whatever other means that suits your fancy to get
addresses. If addrconf says configure some address, most definitely
also do that. If there are manually configured addresses, do that too.

> I don't think I can agree with that.

What wording in the proposed text suggests that if M is set, you are
not supposed to use other means? IMO, its very clear that you can (and
even should) use  other means,  as appropriate.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Fri, 24 Mar 2006 10:18:32 -0500

Second try, this time with new text on top and explanation below.

   M :
    
        set, the setting of the O flag is irrelevant, since the DHCPv6

    O :

       

text above.

S/Clients/The node/
S/DHC/DHCPv6/

S/DHC/DHCPv6/

Reworded for clarity
 
- Ralph