"Manfredi, Albert E" <[EMAIL PROTECTED]> writes:

> 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

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

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?

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

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

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

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:

      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.

which seems very clear to me.

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

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,

         - 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 neither M nor O are set, clients SHOULD NOT not
       request any information with DHC.

Thomas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to