Subject: RE: [rfc2462bis] M/O flags and DHCPv6

From: "Dave Thaler" <[email-masked]>
Date: Wed, 3 Mar 2004 18:25:35 -0800

> -----Original Message-----
> From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]]
> Sent: Thursday, March 04, 2004 11:24 AM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [rfc2462bis] M/O flags and DHCPv6
> 
> >>>>> On Wed, 3 Mar 2004 17:47:17 -0800,
> >>>>> "Dave Thaler" <[email-masked]> said:
> 
> >> But the first condition seems to me a bit subjective.  Under which
> >> requirement can we decide a document must be read for a different
> >> document?
> >>
> >> The second condition is a bit clearer, but assuming we basically
> >> agreed that implementing DHCPv6 is basically optional, isn't "must be
> >> present" too strong?  And if so, can't we still safely use this RFC as
> >> an informative reference?
> > [...]
> 
> > I suspect not.  My suggestion in the WG meeting was to not reference
> DHCPv6
> > here, but instead leave it to the node requirements doc to say that
> DHCPv6
> > is the stateful protocol.
> 
> I'm personally happy with this approach.  But then rfc2462bis will
> need to refer to the node requirements draft, and we'll face similar
> questions:

Personally, I don't think there's any need to refer to the node-req doc.
We could just keep the language as it was before.

-Dave
1H>����"�+��fj)b�	b�ة�����+�f�x�������z����!��l��0�X���+����Y���b�ا~���

---

From: [email-masked]
Date: Thu, 4 Mar 2004 06:36:46 +0200

Pekka,

I suspect we are playing games with language, but ...

> > The easiest solution to them would be to list RFC3315 as an
> > informative reference.  I don't know whether this is acceptable.
> > According to Section 2.7 of draft-rfc-editor-rfc2223bis-07.txt,
> > Normative references specify
> > 
> >   - documents that must be read to understand or implement the
> >     technology in the new RFC
> >   - documents whose technology must be present for the technology
> >     in the new RFC to work
> > 
> I don't think this is a problem.  You don't have to understand DHCPv6 
> to ignore M/O bits -- which you only act upon IF you have implemented 
> DHCPv6 -- and then you understand it already :).

.. but the goal of 2462(-bis) is STATELESS ADDRESS AUTOCONFIG.  I don't think
that this document has ANY normative dependencies on Stateful Address
Autoconfig.  Re-reading the draft several times, I can only see that
DHCPv6 is informative, at best.

John

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

---

From: [email-masked]
Date: Thu, 4 Mar 2004 09:24:12 +0200

Jinmei,

> So far, all the responses in this thread seem to support having
> RFC3315 (DHCPv6) in rfc2462bis as an informative reference, and not
> referring to the node-req draft.  Is my understanding correct?

Yes, I think so.
 
> I can live with this approach.  But I also think it is helpful to
> mention like "what is the stateful protocol (and propbably the
> mandatory level to implement it) is beyond the scope of rfc2462bis and
> is specified in a separate document".  Otherwise, readers would
> continue to wonder what the stateful protocol is while we could
> actually answer the question.

How about:

  This document does not define stateful address autoconfiguration, which
  is specified in a seperate document [informative reference here].

> In summary, I'd like to propose
> 
> - in the body of rfc2462bis, we do not explicitly say what the
>   stateful protocol is but mention that it is specified in a separate
>   document.
> - regarding reference, we only list RFC3315 as an informative
>   reference.  (and we probably need some additional text in the body
>   that refers to the reference)
> 
> Does this make sense?

I'm happy with it.

John

---

From: [email-masked]
Date: Thu, 4 Mar 2004 09:48:00 +0200

Hi Ralph,

> John - I agree that "the goal of 2462(-bis) is STATELESS ADDRESS
> AUTOCONFIG."  However, the bits controlling use of stateless/stateful are
> also defined in RFC 2462bis, so RFC 2462bis goes a little beyond just
> defining how stateless address autoconfig.  Invoking the camel's nose
> principle, and striving for clarity, I would suggest that it would be
> appropriate for RFC 2462bis to explicitly define  the 
> stateful protocol as RFC 3315, with an informative reference to RFC 3315.

I have no problem with 2462-bis saying that Stateless Address Autoconfiguration
is DHCPv6, with an Informative Ref to 3315.  This seems like a truth in
advertising point.

John

---

From: Ralph Droms <[email-masked]>
Date: Thu, 04 Mar 2004 02:41:23 -0500

John - I agree that "the goal of 2462(-bis) is STATELESS ADDRESS
AUTOCONFIG."  However, the bits controlling use of stateless/stateful are
also defined in RFC 2462bis, so RFC 2462bis goes a little beyond just
defining how stateless address autoconfig.  Invoking the camel's nose
principle, and striving for clarity, I would suggest that it would be
appropriate for RFC 2462bis to explicitly define  the stateful protocol as
RFC 3315, with an informative reference to RFC 3315.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 05 Mar 2004 00:44:49 -0500

Comments in line...

At 09:31 PM 2/27/2004 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>[...]
>*** regarding question c ****
>
>I'd first like to answer this question.  RFC2462 currently says:
>
>    Stateful autoconfiguration for IPv6 is the subject of future work
>    [DHCPv6].
>(Section 1)
>
>And, considering the latest standardization status, the current
>revision of rfc2462bis says:
>
>    Stateful autoconfiguration for IPv6 is the subject of DHCPv6 [7].
>
>However, I still don't think this is crystal clear.  I believe we
>should first clarify whether "stateful autoconfiguration" *equals to*
>DHCPv6 (as specified in RFC3315), or whether we should still leave the
>possibility of (future) other stateful protocols.  And then we should
>clarify this point in rfc2462bis more explicitly.
>
>Personally, I would prefer the first option (i.e., the "stateful
>protocol" equals to DHCPv6).  Flexibility is in general a good thing,
>but in this case, I don't see a reasonable practical reason to leave
>other possibilities with ambiguous wording, particularly because the
>ambiguity has annoyed people and caused similar questions/discussions
>again and again.
>
>If we can agree on this, I'll change the above sentence like:
>
>    In this document, Stateful autoconfiguration for IPv6 means DHCPv6
>    [7].
>
>In the followings, I assume we adopt this interpretation (but it won't
>matter much even if we do not).

I think it would be more clear to simply replace "the stateful
autoconfiguration for IPv6" with "DHCPv6" throughout the document.
It might be necessary to append "for address assignment" when
discussing the "M" bit and "for other configuration information"
when discussing the "O" bit.

>*** regarding question a ****
>
>First, I think we can concentrate on Section 5 "PROTOCOL
>SPECIFICATION" (and its subsections).  For example, someone pointed
>out that the following sentence in section 4 is "ambiguous":
>
>    A "managed address
>    configuration" flag indicates whether hosts should use stateful
>    autoconfiguration to obtain addresses.
>
>because it uses "should", not "SHOULD".

I would replace "stateful address autoconfiguration" with "DHCPv6"
here.

>kBut I don't think we should care about the wording in Section 4, since
>it's just an overview of the protocol, not the protocol specification
>itself.  In fact, there are no RFC2119 keywords throughout Section 4.
>Of course, we may have to revisit the wording when we resolve question
>b ("which keyword?") though.

OK; it makes sense to me that section 4 should use no RFC 2119 words...

>Concentrating on Section 5, I've found the following candidates of
>RFC2119 keywords:
>
>======================      start candidates    ======================
>1. Section 5.2
>       ManagedFlag      Copied from the M flag field (i.e., the ...
>                        The flag indicates whether or not addresses are
>                        to be configured using the stateful
>                        autoconfiguration mechanism.
>
>    where "are to be" may need to be, e.g., "SHOULD be".

Assuming that everyone is comfortable with the 'M' and 'O' bits being hints
and not controls, "SHOULD" seems right.  I would replace "stateful
autoconfiguration mechanism" with "DHCPv6" (looking ahead, I think this
substitution simplifies the next proposed change).

>2. Section 5.2
>       OtherConfigFlag  Copied from the O flag field (i.e., the "other ...
>                        The flag indicates whether or not information
>                        other than addresses is to be obtained using the
>                        stateful autoconfiguration mechanism.
>
>    where "is to be" may need to be, e.g., "SHOULD be".

I agree with the change to SHOULD be.  I would also replace "stateful
autoconfiguration mechanism" with "DHCPv6".

I make this suggestion because I think the phrase "stateful
autoconfiguration mechanism" was used in RFC 2462 because there was no
explicit protocol to point at.  That is, I don't think differentiating
between "stateful autoconfiguration mechanism" and "DHCPv6" is
useful; what is useful is to use 'M' and 'O' bits as hints to the host to
use DHCPv6.

>3. Section 5.5.3
>
>    ... If the value of ManagedFlag changes from FALSE to
>    TRUE, and the host is not already running the stateful address
>    autoconfiguration protocol, the host should invoke the stateful
>    address autoconfiguration protocol, ...
>
>    where "the host should invoke" may need to be, e.g., "the host
>    SHOULD invoke".

OK, and change "stateful address autoconfiguration protocol" to "DHCPv6".

>4. Section 5.5.3
>
>    ...  If the value of the ManagedFlag
>    changes from TRUE to FALSE, the host should continue running the
>    stateful address autoconfiguration, ...
>
>    where "the host should continue" may need to be, e.g., "the host
>    SHOULD continue".

Ditto.

>5. Section 5.5.3
>
>    ... If the
>    value of OtherConfigFlag changes from FALSE to TRUE, the host should
>    invoke the stateful autoconfiguration protocol, ...
>
>    where "the host should invoke" may need to be, e.g., "the host
>    SHOULD invoke".

Ditto.

>6. Section 5.5.3
>
>    ...  If
>    the value of the OtherConfigFlag changes from TRUE to FALSE, the host
>    should continue running the stateful address autoconfiguration
>    protocol, ...
>
>    where "the host should continue" may need to be, e.g., "the host
>    SHOULD continue".

Ditto.

>======================      end candidates    ======================
>
>In my current impression, we can leave 1 and 2 unchanged, but we'll
>need to use RFC2119 keywords for the rest.
>
>*** regarding question b ****
>
>In addition to the above candidates, the following parts already using
>RFC2119 keywords will need to be discussed here:
>
>7. Section 5.5.2
>    If a link has no routers, a host MUST attempt to use stateful
>    autoconfiguration to obtain addresses and other configuration
>    information.
>
>8. Section 5.5.2
>    An implementation MAY provide a way to disable the
>    invocation of stateful autoconfiguration in this case, but the
>    default SHOULD be enabled.
>
>9. Section 5.5.3
>    In particular, a host MUST
>    NOT reinvoke stateful address configuration if it is already
>    participating in the stateful protocol as a result of an earlier
>    advertisement.
>
>10. Section 5.5.3
>    In particular, a host MUST NOT reinvoke stateful
>    configuration if it is already participating in the stateful protocol
>    as a result of an earlier advertisement.
>
>To choose appropriate keywords, I'd like to be synchronized with the
>node requirements draft (draft-ietf-ipv6-node-requirements-08.txt).
>It says in Section 4.5.5 that:
>
>    Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
>    3315] is the standard stateful address configuration protocol; see
>    section 5.3 for DHCPv6 support.

I suggest replacing "Stateless Address Autoconfiguration" with "DHCPv6"
in the first sentence.

>    Nodes which do not support Stateful Address Autoconfiguration may be
>    unable to obtain any IPv6 addresses aside from link-local addresses
>    when it receives a router advertisement with the 'M' flag (Managed
>    address configuration) set and which contains no prefixes advertised
>    for Stateless Address Autoconfiguration (see section 4.5.2).
>    ...

s/Stateful Address Autoconfiguration/DHCPv6/ throughout this paragraph.

>That is (in my understanding), implementing DHCPv6 is basically
>optional with warnings about the case of not implementing it.  I know
>this was a controversial issue, but I believe the node-requirements
>draft made a reasonable decision in terms of practical and realistic
>deployment path while honoring future flexibility.

OK.

>So, I'd like to propose changing candidate 7 to:
>
>    If a link has no routers, a host MAY attempt to use stateful
>    autoconfiguration to obtain addresses and other configuration
>    information.

s/stateful autoconfiguration/DHCPv6/  I don't think RFC 2462 intended
to differentiate between stateful and stateless DHCPv6.

>Similarly, change candidate 8 to:
>    An implementation MAY provide a way to enable the
>    invocation of stateful autoconfiguration in this case, but the
>    default SHOULD be disabled.
>
>Another reason for the change is because we can at least use
>link-local addresses within a single link without a router.

s/stateful autoconfiguration/DHCPv6/

>For candidates 3 to 6, I think "SHOULD" is appropriate, since this
>only happens the network manager explicitly turns on the M or O flag
>and the effect of this setting is described in the node-requirements
>draft with warnings.

OK.

>I also think "MUST NOT"s in candidates 9 and 10 are okay for the same
>reason.

OK.

>*** regarding question d ****
>
>(I interpret "the configuration-only version of DHCPv6" as so called
>"stateless DHCPv6" described in draft-ietf-dhc-dhcpv6-stateless-04.txt.)
>
>This is not a strong opinion, but I'd currently say "no" for this
>question.  The reasons are:
>
>- in my opinion, the stateless DHCPv6 service should be a "ubiquitous"
>   service, and hosts that need autoconfiguration should try it by
>   default (that is, without seeing an O flag set, which needs an
>   explicit configuration in routers).
>
>- the O bit indicates a "stateful" mechanism for other configuration
>   information than addresses.  If the information actually includes
>   some real "other" stateful resources (probably in a future
>   extension), using the stateless version of DHCPv6 may result in an
>   incomplete service.

We've spent a lot of time discussing "other stateful resources" in
the dhc WG.  Although the concept sounds sensible, in practice we've
never been able to identify an example of a stateful resource to manage
with DHCPv6 other than addresses and prefixes.  Therefore, I would say
we don't need to worry that stateless DHCPv6 won't be adequate
for the assignment of other configuration information.

>Even if we agree on my opinion, however, it might still be useful to
>note that the protocol invoked by the O bit should be the full-spec
>DHCPv6 instead of the stateless version.
>
>                                         JINMEI, Tatuya
>                                         Communication Platform Lab.
>                                         Corporate R&D Center, Toshiba Corp.
>                                         [email-masked]
>