[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

further clarifications on M/O flags in rfc2462bis



Hello,

Based on a recent discussion on rfc2462bis with Margaret in a part of
her AD review results, I now think we'll need further clarifications
on the M/O flags.

As I said in a previous response to Margaret, we have decided and made
the following change to rfc2462bis:

1. remove some "mandatory" wording on these flags and clarify that
   these flags are just hints of availability of the corresponding
   services (DHCPv6).
2. leave more details to other document(s)

The basic background of this decision is that we've not reached a
matured level for a DS on deployment experiences of DHCPv6.  (see
http://www1.ietf.org/mail-archive/web/ipv6/current/msg02372.html
to get the entire message with the context of the discussion)

I'm quite sure that we saw a clear consensus on the basic idea.

But as a result, we have a vague reference to the "other document",
without specifying a particular document in the references section.
This may make rfc2462bis "incomplete".

There is an ongoing work on the detailed usage of the M/O flags, and
we could refer to that document from rfc2462bis.  However, the only
"ongoing work" is currently just an individual document, and I'm not
sure how long it takes to be completed, or even whether we adopt it as
a wg item in the first place.  This would make the reference from
rfc2462bis unstable and/or would cause another delay for rfc2462bis.

We need to endure the delay if it's inevitable.  However, as Margaret
indicated, most part of rfc2462bis is independent from the usage of
the M/O flags.  In fact, creating a link-local/global address by the
stateless autoconfiguration procedure, DAD, or address lifetime
management are basically all independent from how we use the M/O
flags.  Also, whether we invoke DHCPv6 when receiving an RA with the M
flag being ON does not affect whether we perform stateless address
autoconfiguration when receiving an RA with some prefix information,
or vice versa.  In some cases (e.g., for DAD), we need to consider
addresses allocated via DHCPv6 as well as addresses configured through
stateless configuration.  However, I believe we can simply say
"addresses allocated via DHCPv6" in such cases without mentioning the
M/O flags.

So, I now tend to propose the following approach:

- clearly saying in rfc2462bis "it does not specify the use of the M/O
  flags." (not mentioning other documents).  Specifically, remove the
  7th paragraph of Section 4 (beginning with "The details of how a
  host may use the M flag...")
- also clarifying in rfc2462bis that the protocol described in
  rfc2462bis should be performed independently from these flags (in a
  clearer way).

(and, if we take this idea, the "separate document", whatever it is,
should become a PS instead of a BCP as we originally planned).

Please note that this is NOT an attempt to "remove" or "deprecate" the
M/O flags.  We've already discussed the idea and rejected it, and I
don't see a reason for revisiting the past arguments.  This is an
attempt to make rfc2462bis more self-contained and more matured as a
DS, considering the current implementation/deployment experiences of
the M/O flags and the other parts of the original RFC2462.

Still, this will require non-trivial changes to the current version of
rfc2462bis, so I'd like to get explicit agreement/disagreement from
the working group.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@xxxxxxxxxxxxxxxxxxxxx

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