Subject: AD Review of draft-ietf-ipv6-rfc2462bis-06.txt

From: Margaret Wasserman <[email-masked]>
Date: Wed, 6 Oct 2004 09:05:53 -0400

Hi Jinmei,

I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt.  I have 
several comments on this document that I believe should be resolved 
before this document is sent to IETF Last Call for publication as a 
Draft Standard.

All of my comments are included below, but my most serious concerns are:

(1) Having decided that "the stateful configuration" mechanism is 
DHCPv6, I don't think that there is a reason to maintain the awkward 
and confusing wording about "the stateful mechanism" in many places. 
I've pointed out the worst cases, but there are many others.  I know 
that this is largely an editorial concern, but the awkwardness and 
lack of clarity are bad enough in some places (see below) that I 
consider this a blocking problem for publication at DS.

(2) I am not comfortable with the idea that we would punt the 
interpretation of the M & O bits to a "separate document" with no 
reference.  I believe that information about how to interpret these 
bits is essential to implementing IPv6 address autoconfiguration. 
See below for the specific text that concerns me.

I'd be interested in your feedback on these issues, as well as on the 
other more minor issues I've noted below.

I've cc:ed the IPv6 WG on this message, and other IPv6 folks should 
also feel free to respond, especially if you think that I'm mistaken 
about something.

Margaret

---

My comments are in-line, marked with ">>"

Abstract

    This document specifies the steps a host takes in deciding how to
    autoconfigure its interfaces in IP version 6.  The autoconfiguration
    process includes creating a link-local address and verifying its
    uniqueness on a link, determining what information can be
    autoconfigured (addresses, other information, or both), and in the
    case of addresses, whether they can be obtained through the stateless
    mechanism, the stateful mechanism, or both.

>>  whether they can be obtained through stateless autoconfiguration, 
>>the Dynamic Host Configuration Protocol (DHCP) or both?

    This document defines
    the process for generating a link-local address, the process for
    generating global addresses via stateless address autoconfiguration,
    and the Duplicate Address Detection procedure.  The details of
    autoconfiguration using the stateful protocol are specified in RFC
    3315; an alternative way of using the stateful protocol to deliver
    'other information' only is specified in RFC 3736.

>>  I'd move the whole last sentence to an introduction and take it 
>>out of the abstract.  Since we can't have references in an 
>>abstract, I think it is useless, anyway.

1.  INTRODUCTION

    This document specifies the steps a host takes in deciding how to
    autoconfigure its interfaces in IP version 6 (IPv6).  The
    autoconfiguration process includes creating a link-local address and
    verifying its uniqueness on a link, determining what information can
    be autoconfigured (addresses, other information, or both), and in the
    case of addresses, whether they can be obtained through the stateless
    mechanism, the stateful mechanism, or both.

>>  s/the stateful mechanism/DHCP

    This document defines
    the process for generating a link-local address, the process for
    generating global addresses via stateless address autoconfiguration,
    and the Duplicate Address Detection procedure.  The details of
    autoconfiguration using the stateful protocol is specified in
    [RFC3315] and [RFC3736].

>>  s/the stateful protocol/DHCP

    IPv6 defines both a stateful and stateless address autoconfiguration
    mechanism.  Stateless autoconfiguration requires no manual
    configuration of hosts, minimal (if any) configuration of routers,
    and no additional servers.  The stateless mechanism allows a host to
    generate its own addresses using a combination of locally available
    information and information advertised by routers.  Routers advertise
    prefixes that identify the subnet(s) associated with a link, while
    hosts generate an "interface identifier" that uniquely identifies an
    interface on a subnet.  An address is formed by combining the two.
    In the absence of routers, a host can only generate link-local
    addresses.  However, link-local addresses are sufficient for allowing
    communication among nodes attached to the same link.

    In the stateful autoconfiguration model, hosts obtain interface
    addresses and/or configuration information and parameters from a
    Dynamic Host Configuration Protocol (DHCPv6) server.  Servers
    maintain a database that keeps track of which addresses have been
    assigned to which hosts.  The stateful autoconfiguration protocol
    allows hosts to obtain addresses, other configuration information or
    both from a server.  Stateless and stateful autoconfiguration
    complement each other.  For example, a host can use stateless
    autoconfiguration to configure its own addresses, but use stateful
    autoconfiguration to obtain other information.

    To obtain other configuration information without configuring
    addresses in the stateful autoconfiguration model, a subset of DHCPv6
    [RFC3736] will be used.  While the model is called "stateful" here in
    order to highlight the contrast to the stateless protocol defined in
    this document, the intended protocol is also defined to work in a
    stateless fashion.  This is based on a result, through operational
    experiments, that all known "other" configuration information can be
    managed by a stateless server, that is, a server that does not
    maintain state of each client that the server provides with the
    configuration information.

>>  This is the part that I consider to be quite awkward, particularly 
>>the vague references to operational experiments that aren't 
>>documented or referenced here.  If you switch to just referring to 
>>DHCP, the preceeding three paragraphs can be substantially 
>>simplified.  I also thin it is unnecessary to say so much about how 
>>DHCP works -- that is the subject of other document.  There are 
>>many other places where the text would be much clearer if DHCP (or 
>>DHCPv6) were used instead of "the stateful mechanism", but I will 
>>not mark them all.

    The stateless approach is used when a site is not particularly
    concerned with the exact addresses hosts use, so long as they are
    unique and properly routable.  The stateful approach is used when a
    site requires tighter control over exact address assignments.  Both
    stateful and stateless address autoconfiguration may be used
    simultaneously.  The site administrator specifies which type of
    autoconfiguration is available through the setting of appropriate
    fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis].

>>  Given this normative reference, would it make sense to hold 
>>2462bis until 2461bis is completed and send them forward together? 
>>Otherwise, this will just block in the RFC Editor, and we won't 
>>have the ability to change it again if we discover issue while 
>>finishing the 2461 update.  Thoughts?

2.  TERMINOLOGY

>>  Is this terminology section intended to be in logical order?  Is 
>>there a reason to prefer this order over an alphabetical listing?

    Nodes (both hosts and routers) begin the autoconfiguration process by
    generating a link-local address for the interface.  A link-local
    address is formed by appending the interface's identifier to the
    well-known link-local prefix.

>>  I think that there should be a reference to the addressing 
>>architecture or the scoped address architecture here...  Something 
>>that tells me how I actually create a link-local address.

    A "managed
    address configuration (M)" flag indicates whether hosts can use
    stateful autoconfiguration [RFC3315] to obtain addresses.  An "other
    stateful configuration (O)" flag indicates whether hosts can use
    stateful autoconfiguration [RFC3736] to obtain additional information
    (excluding addresses).

    The details of how a host may use the M flag, including any use of
    the "on" and "off" transitions for this flag, to control the use of
    the stateful protocol for address assignment will be described in a
    separate document.  Similarly, the details of how a host may use the
    O flag, including any use of the "on" and "off" transitions for this
    flag, to control the use of the stateful protocol for getting other
    configuration information will be described in a separate document.
    However a host uses the M and O flags, and local configuration to
    control autoconfiguration, the default setting will result in
    received Router Advertisements being processed for stateless address
    autoconfiguration.

>>  I don't think it is okay to publish a DS that leaves important 
>>implementation details to a "separate document".  Has the separate 
>>document been published?  If so, it needs to be normatively 
>>referenced here.

    Router Advertisements also contain zero or more Prefix Information
    options that contain information used by stateless address
    autoconfiguration to generate global addresses.  It should be noted
    that the stateless and stateful address autoconfiguration fields in
    Router Advertisements are processed independently of one another, and
    a host may use both stateful and stateless address autoconfiguration
    simultaneously.  One Prefix Information option field, the "autonomous
    address-configuration flag", indicates whether or not the option even
    applies to stateless autoconfiguration.  If it does, additional
    option fields contain a subnet prefix together with lifetime values
    indicating how long addresses created from the prefix remain
    preferred and valid.

>>  What happens if the value of the "autonomous address-configuration 
>>flag" changes over time?

    For safety, all addresses must be tested for uniqueness prior to
    their assignment to an interface.  The test should individually be
    performed on all addresses obtained manually, via stateless address
    autoconfiguration, or via stateful address autoconfiguration.  To
    accommodate sites that believe the overhead of performing Duplicate
    Address Detection outweighs its benefits, the use of Duplicate
    Address Detection can be disabled through the administrative setting
    of a per-interface configuration flag.

>>  I am not sure how the last sentence is consistent with the must in 
>>the first sentence.  Change the must in the first sentence to a 
>>should?

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 12 Oct 2004 02:53:13 +0900

Hi Margaret,

>>>>> On Wed, 6 Oct 2004 09:05:53 -0400, 
>>>>> Margaret Wasserman <[email-masked]> said:

> before this document is sent to IETF Last Call for publication as a 

Thanks for your careful reading and the detailed review.  I'll answer
the review comments within a couple of days (sorry for the delay).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 16 Oct 2004 08:44:06 +0900

Hello,

Sorry about the long delay.  I'll first comment on the two major
points.

> consider this a blocking problem for publication at DS.

I actually wanted to remove the word "stateful" for clarity.  But this
would also require changes to more normative statements in rfc2461bis.
For example, RFC2461 hardcodes the term "stateful" for the 'O' flag of
RA:

      O              1-bit "Other stateful configuration" flag.  When
                     set, hosts use the administered (stateful) protocol
                     for autoconfiguration of other (non-address)
                     information.  The use of this flag is described in
                     [ADDRCONF].

If we remove "stateful" from rfc2462bis, I think we'd also need to
change the name of the bit in rfc2461bis accordingly.  Otherwise, the
result would rather be more confusing.  So I asked the wg whether

- we should clean up all the occurrences of "stateful" and replace
  them with "DHCPv6" in rfc2461bis and rfc2462bis, or
- we should keep the wording but clarify what "stateful" actually
  means (and clarify the possible confusion RFC3736 is also called
  "stateless" while it's a part of DHCPv6)

See the following message and the succeding thread for more details:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg02597.html

Unfortunately, I didn't see many responses to the question, so I
decided to take the second action, considering the "conservative"
nature of the 2462bis work.

But if we, as a wg, can agree on the first choice, which includes
modifications to rfc2461bis, I'm willing to make that change.  (I'd
object to just changing 2462bis with keeping the current wording in
2461bis.  That would just introduce further confusion.)

> See below for the specific text that concerns me.

Please let me check: regarding the M/O flags, we basically introduced
the following two changes from RFC2462:

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)

And, I believe how to "interpret" these bits is very clear with change
1.  In fact, the "mandatory" nature of these flags in RFC2462 has been
confusing people, and I believe the change in rfc2462bis makes the
interpretation much clearer.

Actually, the course of this change was based on a pretty clear
consensus in the wg.  See, for example, the following messages and
succeeding threads:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg02512.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg02513.html

So, I interpret your main concern is about mentioning other
document(s) without a concrete reference.  Is this correct?

If so, there is an ongoing work in this area, although it's still
an individual document: draft-daniel-ipv6-ra-mo-flags-00.txt. (A new
revision of this document will be submitted before the coming IETF
meeting).

With this ongoing work, I can think of the following three choices:

1. simply remove the "other document".  As I said above, the
   "interpretation" of these flags should already be pretty clear.
   And removing the "other document" solves the dangling reference
   issue.
2. assuming the above ongoing work or a different (non existing)
   document is adopted as a wg document, refer to it as an
   *informative* reference.  At the moment, we only have an individual
   I-D, but even a wg I-D cannot be a normative reference in a draft
   standard.  Also, based on our consensus the separate document will
   be published as a BCP.  I'm not sure if a DS can safely have a
   normative reference to a BCP regarding the reference dependency
   issue (the rule is too complicated and it is very hard to find an
   appropriate document!).  BTW: in this sense, we can even not refer
   to the DHCPv6 RFCs as normative references, since those are still
   PS.

I don't have a particular preference between these two, but if none of
them is acceptable, I can't imagine how we can proceed.  Please let me
know what you think.

					JINMEI, Tatuya

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 16 Oct 2004 12:13:46 -0400

Hi Jinmei,

Thanks for the response!

>   "stateless" while it's a part of DHCPv6)

I agree that we would need to make some similar changes to RFC 
2461bis, but I don't see that as a huge change.  It could read 
something like:

      O              1-bit "Other DHCPv6 configuration" flag.  When
                      set, hosts use DHCP to configure other (non-address)
                      information.  The use of this flag is described in
                      [ADDRCONF].

The bigger problem is that the use of this flag is not described in 
the new version of ADDRCONF, so 2461bis will need a normative 
reference to the new document that does describe the use of these 
flags (unless we put it back here).

There is, of course, also a big ambiguity here about whether this 
flag indicates that hosts MUST, SHOULD or MAY use DHCPv6 to configure 
other information.  As you indicated below, we've known about, and 
struggled with, that ambiguity for a while, so I hope it will be 
resolved in RFC 2461bis or 2462bis.

>document(s) without a concrete reference.  Is this correct?

Yes, but maybe not quite in the way you think.  RFC 2461bis and 
RFC2462bis are closely related documents that I think should probably 
go forward together on a single ballot (as I said elsewhere in my 
message).  By moving the description of the M&O bits to another 
document, you aren't really simplifying anything (IMO), you are 
merely creating a third document that is essential to understanding 
these two.  It also presents some problems, because the document is 
not complete yet and will have to start out at PS before moving to 
DS, which may block the publication of 2461bis and 2462bis at DS.

There is really a basic question here:

Are we _changing_ how the M&O bits are interpreted, or are we merely 
clarifying how they are interpreted?

If we are merely clarifying, then I think we should do it here and 
keep the documents at DS.

If we are changing it, I think we need to figure out how to handle 
this so that neither 2461bis nor 2462bis needs to have a normative 
reference to the new document.  To accomplish this, we would need to 
say enough (or perhaps little enough) in these documents that readers 
can completely implement address autoconfiguration and ND without 
knowing anything about the meaning of those bits.  This may be 
possible, if they are truly ignored in deciding how/if to perform ND, 
DAD, address autoconfiguration, etc.  But, that isn't currently clear 
in the documents.

>    And removing the "other document" solves the dangling reference

I could accept this if you make it very clear what hosts that 
implement rfc2461bis and rfc2462bis are supposed to do when these 
bits are set.

>    to the DHCPv6 RFCs as normative references, since those are still

As I'm sure you know, we can't just declare a reference informative 
because the referenced document isn't at a state that would allow 
this document to be published at DS.

IMO, it is quite clear that one can implement ND and addrconf without 
implementing DHCPv6, so it is fine for DHCPv6 to be an informative 
reference.  We either need to make sure that the M&O bits can be 
handle the same way (ignore them in implementations of ND and 
autoconf, worry about them only if you implement DHCPv6), or we need 
to explain them appropriately here.  Either one works, but a hanging 
textual reference to an as-yet-unpublished document doesn't.

I don't think we have any fundamental disagreements here, we just 
need to figure out how to get this right before we send it to IETF LC.

Thanks for all of your work on this document -- you are doing a very 
good job and this is important work!

Margaret

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 20 Oct 2004 09:25:36 +0900

>>>>> On Sat, 16 Oct 2004 12:13:46 -0400, 

>>> reference.

[...]

> DAD, address autoconfiguration, etc.  But, that isn't currently clear 

Okay, I think I understand your point, thanks for the detailed
explanation.  I think many other comments from depend on this issue,
so I'll concentrate on this one at the moment.

Regarding your basic question, it probably depends on the meaning of
"change/clarify".  But we are at least going to *change* some part of
the specification that was described in RFC2462.

To explain the background motivation of the *change*, I'd refer to a
past message in this ML from Christian Huitema:

>>>>> On Sat, 24 Apr 2004 22:08:28 -0700, 
>>>>> "Christian Huitema" <[email-masked]> said:

> The normal IETF practice is that when a document progresses from PS
> do DS and then to standard, parts of the specification that are not
> actually present in implementations get removed from the spec. As
> much as I can tell, we don't have much actual implementation of the
> M/O bits. If we follow the logic of the process, we should remove
> the corresponding sections from the spec.

(Or see
http://www1.ietf.org/mail-archive/web/ipv6/current/msg02372.html
to get the entire message with the context of the discussion)

In the actual discussion, this was just an intermediate post, and we
did not actually "remove" the corresponding sections for the M/O flags
altogether.  But I believe our consensus in this discussion was that
we'd need more time to bake the precise behavior for the M/O flags
and that the status of the specific action had not reached the level
of a DS.  That's why we decided to leave the specific behavior to a
separate document.

I'd first like to know whether the decision so far is acceptable.

If this is acceptable, the "resolution" for this issue is to make
rfc2462bis (and perhaps 2461bis) less confusing (if it currently is)
on the status of the M/O flags.

I personally do not think it is that confusing to say like: "The
details of how a host may use the M flag, [...] will be described in a
separate document" (rfc24622bis-06, Section 4).  In fact, when RFC2462
became a DS, we even did not have a (standardized) specific "stateful
protocol", but we could still say in the RFC that "the details of
autoconfiguration using the stateful protocol are specified elsewhere."
(abstract of RFC2462)

A possible approach that may help is to clarify why we decided to
leave the specific usage to a separate document, explaining the
current maturity of the M/O flags, without referring to a particular
document.  This is my first (and preferred) proposal.

If this is not enough, we'd need to refer to the "separate document".
In this case, we seriously have to consider the reference category as
you pointed out.  But I personally think we can refer to it (whatever
it is) as an Informational reference, considering the current
maturity.  I also believe we'll then have to wait for at least one wg
document for this (since individual documents are so fragile even as
an informational reference).

Thus, my second proposal is to wait for a wg document and to refer to
it as an informational reference.  (This is the "second" proposal
because I *personally* believe we can safely explain the current
situation without specifying a concrete reference and also because
even wg I-Ds are still often subject to change.)

Again, I'd like to know whether the background motivation is
acceptable, and if it is, whether one of the above proposals can be a
resolution for the issue.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Oct 2004 03:15:08 +0900

(This message is a response to a unicasted message, which Margaret
said should have actually been sent to the list.  So I'm cc'ing to the
wg list)

>>>>> On Thu, 21 Oct 2004 14:30:24 -0400, 

> What I think we should do is make it very clear that the M&O bits are 
> not used for either Neighbor Discovery (in 2461bis) or Address 
> Autoconfiguration (in 2462bis).  In other words, the values of these 
> bits can be completely ignored for purposes of ND, DAD, AddrConf, 
> etc. -- we will autoconfigure exactly the same address, in exactly 
> the same way, regardless of the value of these bits. This is true, 
> right?

Yes, I think so.  Whatever the "stateful" protocol(s) is, or however
we invoke the protocol(s) based on the M/O flags, it is completely a
separate process from the base ND protocol or stateless address
autoconfiguration (or DAD for that matter).  In particular, we can (or
"should" when necessary) run stateless address autoconfiguration and
DHCPv6 for address allocation concurrently.

One subtle point is that DAD should apply to addresses allocated
through DHCPv6.  But I believe we can handle this separately from the
meaning/usage of the M/O flags.

I believe the existing documents (2461/2462) already clarify the point
to some extent, but perhaps we'll need to be more specific.

> You could then optionally include an informational reference to a 
> document that describes the meaning and use of these bits and/or say 
> that they meaning and use of these bits will be described in a 
> document to be published later.

> But, I'd leave out the partial description of the meaning of these 
> bits from both 2461bis and 2462bis, as that only creates the 
> impression that these bits have some implications for the protocols 
> described in this document.

Point taken, and I tend to agree.

Since this may cause a significant change to the current version of
the document, I'll make a separate thread on this specific issue.

Thanks,

					JINMEI, Tatuya