Re: [rfc2462bis] relationship between M/O flags and related protocols

[Ralph Droms <rdroms@xxxxxxxxx>]

Your list of behaviors is a good starting point for a BCP document.  As you
point out, if we know there is rough consensus in support of writing such a
doc, RFC 2462bis can proceed without explicit prescription of client behavior.

I remember (my memory, of course, may be faulty) that the behavior of the
client you cite from RFC 2462 was specified to avoid DoS attacks in which
rouge RAs with the M/O flags set to off would not cause hosts to stop using
DHCPv6.

- Ralph


At 03:02 PM 5/18/2004 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
> >>>>> On Mon, 17 May 2004 15:04:17 -0400,
> >>>>> Ralph Droms <rdroms@cisco.com> said:
>
> >> > 3. (optionally) make a separate document (standard or BCP) on how to
> >> >    interact the protocols with these flags
>
> > Can you give some examples of what conditions or interactions might be
> > included in such a document?
>
>It's just a rough sketch, but I'm currently thinking about a document
>that describes
>
>- how a host that implements DHCPv6 should behave.  The host would
>   have an internal (conceptual) variable, controlling the policy about
>   autoconfiguration, which should have at least three values:
>   1: it should invoke DHCPv6 for address autoconfiguration regardless
>      of the content of receiving RAs or the existence of RAs
>   2: it should invoke DHCPv6 for address autoconfiguration if and only
>      if it sees an RA changing the M bit from unset to set
>   3: it should not invoke DHCPv6 for address autoconfiguration
>      regardless of the content of receiving RAs or the existence of
>      RAs
>- same thing for a host that implements the "stateless" subset of
>   DHCPv6 (RFC3736) for other configuration information.
>
>The details can change based on further discussion, of course.  But at
>the moment, I'd like to know if we can start editing rfc2462bis with
>an expectation that we'll have some separate document like above.
>
>And,
>
> > What about the situation if the 'M' flag transitions from set to not 
> set?  I
> > don't have a good answer off the top of my hear...perhaps this situation is
> > an example of what should go into the BCP document you suggest?
>
>Yes, probably.
>
>BTW: RFC2462 currently says the transition from set to unset means
>"nothing":
>
>    If the value of the ManagedFlag
>    changes from TRUE to FALSE, the host should continue running the
>    stateful address autoconfiguration, i.e., the change in the value of
>    the ManagedFlag has no effect.
>    (Section 5.5.3)
>
>Personally, I don't think this behavior makes much sense, but of
>course we'll need to be careful if we try to change this (in the "BCP"
>document, or wherever) since it may have an effect on existing
>implementations.
>
>                                         JINMEI, Tatuya
>                                         Communication Platform Lab.
>                                         Corporate R&D Center, Toshiba Corp.
>                                         jinmei@isl.rdc.toshiba.co.jp


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