Subject: gen-art review of draft-ietf-ipv6-2461bis-09.txt

From: Scott W Brim <[email-masked]>
Date: Wed, 8 Nov 2006 07:52:08 -0800

I am the assigned Gen-ART reviewer for draft-ietf-ipv6-2461bis-09.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.  Please
resolve these comments along with any other Last Call comments you may
receive.

Summary statement: This draft is basically ready for publication, but
has nits that should be fixed before publication.

I have one question on the protocol, and several on documentation.
Since this is a significant protocol, documentation is very important.
For the sake of new implementors I have a number of suggestions for
clarity.  Many of them have to do with the use of "SHOULD", since we
have been polishing up its use and advice to implementors.

I'll start with my protocol question:

  7.2.7 Anycast neighbor announcements
  
    - "Second, the Override flag in Neighbor Advertisements SHOULD be
      set to 0, so that when multiple advertisements are received, the
      first received advertisement is used rather than the most
      recently received advertisement."
  
    How does the Override flag work when you advertise an included
    prefix?  In this case, I'm advertising a single route to you with
    the Override flag off.  What if you already have a route to a
    larger prefix that includes it?  Do I punch a hole?  Am I
    discarded?  Is this documented?

OK, onward to non-protocol issues.  

3.0 protocol overview

  - Duplicate address detection

     "Duplicate Address Detection: How a node determines that an
     address it wishes to use is not already in use by another node."

    should be

     "Duplicate Address Detection: How a node determines whether or
     not an address it wishes to use is already in use by another
     node."
      
  - Router advertisement: the phrase "on-link determination" has not
    appeared before.  It should be explained.
    
4.1 router solicitation message

  - Source link-layer address

      "The link-layer address of the sender, if known.  MUST NOT be
      included if the Source Address is the unspecified address.
      Otherwise it SHOULD be included on link layers that have
      addresses."

    We've been tightening up "SHOULD"s recently.  RFC2119 says:
    
      SHOULD   This word, or the adjective "RECOMMENDED", mean that
      there may exist valid reasons in particular circumstances to
      ignore a particular item, but the full implications must be
      understood and carefully weighed before choosing a different
      course.
  
    In this draft, "otherwise ...  SHOULD" implies that there are
    situations in which the link layer address is known, and the
    source address is included, but the link layer address may be
    omitted.  RFC2119 says that deserves explanation.  As guidance to
    implementors, who are supposed to understand the full implications
    and carefully weigh them, when would this be appropriate?  For
    load balancing?  If so just say so.  For example down below in
    Router Advertisement Message, you say "A router MAY omit this
    option in order to enable inbound load sharing across multiple
    link-layer addresses."  Something like that would work here -- if
    nothing else add a pointer to text elsewhere.  

    There are more issues with SHOULDs not being thoroughly explained
    below.  I'm only listing the ones where I believe naive
    implementors might benefit from explanation.  

4.2 router advertisement

  - "Note: If neither M nor O flags are set this indicates that no
    information is available via DHCPv6."

    This means that the responding router always knows if DHCPv6 is
    definitely available or definitely not available.  Is there any
    possibility that the responding router might not know?  If so, how
    about changing the text to "is known to be available"?

  - "SHOULD be sent on links that have a variable MTU (as specified in
    the document that describes how to run IP over the particular link
    type).  MAY be sent on other links."

    Same comment on undocumented SHOULD.  How about changing it to
    "MUST be sent ...  (where specified ...)"?

4.3 neighbor solicitation

  - "Source link-layer address

      The link-layer address for the sender.  MUST NOT be included
      when the source IP address is the unspecified address.
      Otherwise, on link layers that have addresses this option MUST
      be included in multicast solicitations and SHOULD be included in
      unicast solicitations."

  Same thing about SHOULD.  If it SHOULD be included, under what
  conditions is it expected that it would not be?

4.4 Neighbor advertisement

  - Override Flag: "It SHOULD NOT be set in solicited advertisements
    for anycast addresses and in solicited proxy advertisements.  It
    SHOULD be set in other solicited advertisements and in unsolicited
    advertisements.

    SHOULD and SHOULD NOT without explanation.  Should these be MUSTs?

  - Target link-layer address: "When responding to a unicast Neighbor
    Solicitation this option SHOULD be included."

    SHOULD.  When would you not?

4.5 Redirect  

  - "It SHOULD be included (if known).

    SHOULD.  When would you not?

6.2.1 router config variables

  - AdvCurHopLimit

      "The value should be set to that current diameter of the
      Intern iset."

    s/that/the/

6.2.6 processing router solicitations

  - "If the router already has a Neighbor Cache entry for the
    solicitation's sender, the solicitation contains a Source
    Link-Layer Address option, and the received link-layer address
    differs from that already in the cache, the link-layer address
    SHOULD be updated in the appropriate Neighbor Cache entry, and its
    reachability state MUST also be set to STALE."

    Unelaborated SHOULD?

6.3.4 processing received router advertisements

  - In a paragraph that begins "After extracting information" ...

    "If the advertisement contains a Source Link-Layer Address option
    the link-layer address SHOULD be recorded in the Neighbor Cache
    entry for the router ..."

    This seems to be another unexplained SHOULD.

Setting the solicited flag ...

  - In 7.2.5, "An advertisement's Solicited flag should only be set if
    the advertisement is a response to a Neighbor Solicitation."

    However, in 7.2.6, "The Solicited flag MUST be set to zero, in
    order to avoid confusing the Neighbor Unreachability Detection
    algorithm."

    Is there a consistency problem here?

7.3.3 

  - "When a node needs to perform address resolution on a neighboring
    address, it creates an entry in the INCOMPLETE state and initiates
    address resolution as specified in Section 7.2.  If address
    resolution fails, the entry SHOULD be deleted, so that subsequent
    traffic to that neighbor invokes the next-hop determination
    procedure again."

    "SHOULD" again.  When would you not delete the entry?

  - "In the Target Address field: the address to which subsequent
    packets for the destination SHOULD be sent."

    That's talking about the recipient of the redirect.  It's not
    about the sender's behavior, so this SHOULD should not be
    capitalized.

8.3
  
  - "A host receiving a valid redirect SHOULD update its Destination
    Cache accordingly so that subsequent traffic goes to the specified
    target.  If no Destination Cache entry exists for the destination,
    an implementation SHOULD create such an entry."

    Another set of unsupported SHOULDs.  What if it doesn't?

9 Options

  - "Receivers MUST silently ignore any options they do not recognize
    and continue processing the message."

    I would add, as has been done in other WGs, that if a new option
    is so ignored by the receiver, protocol behavior MUST still
    continue as if the option had not been sent.  That is, processing
    of options is always backward compatible unless the option is
    declared as required.

(Did not check state machine)

Thanks.

swb

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

---

From: Scott W Brim <[email-masked]>
Date: Wed, 22 Nov 2006 09:26:04 -0500

Thomas, I agree with everything you say below except that some of what
you say may, in fact, be the justifications we are looking for.  I
didn't say examples, I said explanations.  See below ...

On 11/22/2006 09:06 AM, Thomas Narten allegedly wrote:
> Scott W Brim <[email-masked]> writes:
> 
> ...
>>     From [email-masked] Wed Nov 22 17:40:03 2006
Date: Wed, 22 Nov 2006 09:26:04 -0500
From: Scott W Brim <[email-masked]>
Organization: Cisco Systems, Inc.
To: Thomas Narten <[email-masked]>
Cc: Brian Haberman <[email-masked]>,
	Bob Hinden <[email-masked]>, [email-masked],
	William Allen Simpson <[email-masked]>,
	General Area Review Team <[email-masked]>,
	Erik Nordmark <[email-masked]>, [email-masked], "Soliman,
	Hesham" <[email-masked]>
Subject: Re: gen-art review of draft-ietf-ipv6-2461bis-09.txt

Thomas, I agree with everything you say below except that some of what
you say may, in fact, be the justifications we are looking for.  I
didn't say examples, I said explanations.  See below ...

On 11/22/2006 09:06 AM, Thomas Narten allegedly wrote:
> Scott W Brim <[email-masked]> writes:
> 
> ...
>>     From [email-masked] Wed Nov 22 17:40:03 2006
Date: Wed, 22 Nov 2006 09:26:04 -0500
From: Scott W Brim <[email-masked]>
Organization: Cisco Systems, Inc.
To: Thomas Narten <[email-masked]>
Cc: Brian Haberman <[email-masked]>,
	Bob Hinden <[email-masked]>, [email-masked],
	William Allen Simpson <[email-masked]>,
	General Area Review Team <[email-masked]>,
	Erik Nordmark <[email-masked]>, [email-masked], "Soliman,
	Hesham" <[email-masked]>
Subject: Re: gen-art review of draft-ietf-ipv6-2461bis-09.txt

Thomas, I agree with everything you say below except that some of what
you say may, in fact, be the justifications we are looking for.  I
didn't say examples, I said explanations.  See below ...

On 11/22/2006 09:06 AM, Thomas Narten allegedly wrote:
> Scott W Brim <[email-masked]> writes:
> 
> ...
>>     omitted.  RFC2119 says that deserves explanation.
> 
> I don't agree with your last sentence. Where exactly does 2119 say
> "that deserves explanation"? 

It says "the full implications must be understood and carefully
weighed before choosing a different course".  How do you expect
implementors to carefully way the full implications if you don't give
them information with which to do so?  Why did you choose to say only
"SHOULD"?  Tell them.  The point is to give implementors the benefit
of the weeks of debate that went on in the WG.  If you say something
SHOULD be done, you should also go on to say, for example, "in the
case of implementations that don't support option Y, it can't, and you
need to take that into account".

> If the IESG is now requring all uses of SHOULD to give examples of
> when the SHOULD might not apply, I think that goes a bit far. In some
> cases, SHOULD is chosen because we can imagine a future spec taking
> advantage of something that would not be consistent with the
> SHOULD. 

If that's the justification for the SHOULD, then that is all you need
to say.

> Also, anyone familiar with WG discussions knows that there is often
> support for SHOULD, but not for MUST.

Absolutely.  This isn't about SHOULD versus MUST, it's about helping
implementors understand your reasoning.

swb

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Nov 2006 09:06:04 -0500

swb

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Nov 2006 09:06:04 -0500

swb

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Nov 2006 09:06:04 -0500

...

I don't agree with your last sentence. Where exactly does 2119 say
"that deserves explanation"? Look also at Section 6 of 2119. It says:

> 6. Guidance in the use of these Imperatives
> 
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.

The above bolsters the argument that SHOULD is often more appropriate
than MUST.

In my experience, we often use the word SHOULD because we think that
something is the obvious thing to do, but to make it a MUST simply
goes to far. MUST is absolute and allows for no wiggle room, and can
significantly reduce flexibility of future extensions/specs.

If the IESG is now requring all uses of SHOULD to give examples of
when the SHOULD might not apply, I think that goes a bit far. In some
cases, SHOULD is chosen because we can imagine a future spec taking
advantage of something that would not be consistent with the
SHOULD. That is MUCH harder to do when a previous spec says MUST. When
a party a MUST do something, peers sometimes take that to mean that if
the someone doesn't do the MUST, that is a protocol violation and then
do less-than-ideal things (like silently discard a message, return an
error message, etc.)

Thomas

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 22 Nov 2006 01:51:46 -0800

Thanks for the comments! Sorry for the late reply. Some comments inline 

 > have been polishing up its use and advice to implementors.

=> I appreciate the effort; as a general comment I should highlight that
the main reason for this work was to fix known bugs in the spec in a
backward compatible manner. Some or all of the changes of SHOULD to MUST
below might not be backward compatible.
As I'm sure you're aware, this spec has been widely implemented on all
major platforms and doing things in a non- backward compatible manner is
essentially prohibited.

Also, in general, having to describe situations where the SHOULD in the
spec can be avoided is a very difficult task and not really helpful
given the wide implementations of the spec. It really comes down to how
big a document you want :) I think given the description of keywords, if
something is strongly recommended but the protocol will not break if
it's not done, then it deserves a SHOULD. We don't need to explain all
or a subset of situations where avoiding that SHOULD makes sense.
Implementers who need to avoid the SHOULD already know why they need
that. Those who don't know, should follow the SHOULD. 

 >     - ed: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	kAM9psLh011559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL);
	Wed, 22 Nov 2006 01:51:55 -0800
Content-class: urn:content-classes:message
Date: Wed, 22 Nov 2006 01:51:46 -0800
From: "Soliman, Hesham" <[email-masked]>
To: "Scott W Brim" <[email-masked]>,
	"General Area Review Team" <[email-masked]>,
	"Jari Arkko" <[email-masked]>, "Mark Townsley" <[email-masked]>,
	"Bob Hinden" <[email-masked]>,
	"Brian Haberman" <[email-masked]>,
	"Thomas Narten" <[email-masked]>,
	"Erik Nordmark" <[email-masked]>,
	"William Allen Simpson" <[email-masked]>,
	<[email-masked]>, <[email-masked]>
Cc: 
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

Thanks for the comments! Sorry for the late reply. Some comments inline 

 > have been polishing up its use and advice to implementors.

=> I appreciate the effort; as a general comment I should highlight that
the main reason for this work was to fix known bugs in the spec in a
backward compatible manner. Some or all of the changes of SHOULD to MUST
below might not be backward compatible.
As I'm sure you're aware, this spec has been widely implemented on all
major platforms and doing things in a non- backward compatible manner is
essentially prohibited.

Also, in general, having to describe situations where the SHOULD in the
spec can be avoided is a very difficult task and not really helpful
given the wide implementations of the spec. It really comes down to how
big a document you want :) I think given the description of keywords, if
something is strongly recommended but the protocol will not break if
it's not done, then it deserves a SHOULD. We don't need to explain all
or a subset of situations where avoiding that SHOULD makes sense.
Implementers who need to avoid the SHOULD already know why they need
that. Those who don't know, should follow the SHOULD. 

 >     - ed: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id
	kAM9psLh011559
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verifyúIL);
	Wed, 22 Nov 2006 01:51:55 -0800
Content-class: urn:content-classes:message
Date: Wed, 22 Nov 2006 01:51:46 -0800
From: "Soliman, Hesham" <[email-masked]>
To: "Scott W Brim" <[email-masked]>,
	"General Area Review Team" <[email-masked]>,
	"Jari Arkko" <[email-masked]>, "Mark Townsley" <[email-masked]>,
	"Bob Hinden" <[email-masked]>,
	"Brian Haberman" <[email-masked]>,
	"Thomas Narten" <[email-masked]>,
	"Erik Nordmark" <[email-masked]>,
	"William Allen Simpson" <[email-masked]>,
	<[email-masked]>, <[email-masked]>
Cc: 
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

Thanks for the comments! Sorry for the late reply. Some comments inline 

 > have been polishing up its use and advice to implementors.

=> I appreciate the effort; as a general comment I should highlight that
the main reason for this work was to fix known bugs in the spec in a
backward compatible manner. Some or all of the changes of SHOULD to MUST
below might not be backward compatible.
As I'm sure you're aware, this spec has been widely implemented on all
major platforms and doing things in a non- backward compatible manner is
essentially prohibited.

Also, in general, having to describe situations where the SHOULD in the
spec can be avoided is a very difficult task and not really helpful
given the wide implementations of the spec. It really comes down to how
big a document you want :) I think given the description of keywords, if
something is strongly recommended but the protocol will not break if
it's not done, then it deserves a SHOULD. We don't need to explain all
or a subset of situations where avoiding that SHOULD makes sense.
Implementers who need to avoid the SHOULD already know why they need
that. Those who don't know, should follow the SHOULD. 

 >     prefix?  

=> I don't understand the question. The NA can only include a unicast
address. You can't include a prefix in the NA.

       In this case, I'm advertising a single route to you with

 >      not an address it wishes to use is already in use by another

=> ok.

 >     appeared before.  It should be explained.

=> We can add a reference here.

 >     nothing else add a pointer to text elsewhere.  

=> I'd appreciate comments on this from Thomas or Erik if they want to
add something here. Personally, while I appreciate the clarity
requirements, I think it's not necessary to always explain all possible
options for not following a SHOULD. From personal experience, I found
people using specs in ways that were not originally thought of, while
being legitimate (due to the use of MAYs and SHOULDs). So I'm inclined
to leave it as is but would like to hear if others see such ways of
clarification necessary.

 >     implementors might benefit from explanation.  

=> Ok, I think there are lots (most of the shoulds) in the draft that
are not explained as you describe above.

 >     possibility that the responding router might not know?  

=> I don't think so. It should always know.

 >   - "SHOULD be sent on links that have a "Second, the Override flag in Neighbor Advertisements SHOULD be
 >     prefix?  

=> I don't understand the question. The NA can only include a unicast
address. You can't include a prefix in the NA.

       In this case, I'm advertising a single route to you with

 >      not an address it wishes to use is already in use by another

=> ok.

 >     appeared before.  It should be explained.

=> We can add a reference here.

 >     nothing else add a pointer to text elsewhere.  

=> I'd appreciate comments on this from Thomas or Erik if they want to
add something here. Personally, while I appreciate the clarity
requirements, I think it's not necessary to always explain all possible
options for not following a SHOULD. From personal experience, I found
people using specs in ways that were not originally thought of, while
being legitimate (due to the use of MAYs and SHOULDs). So I'm inclined
to leave it as is but would like to hear if others see such ways of
clarification necessary.

 >     implementors might benefit from explanation.  

=> Ok, I think there are lots (most of the shoulds) in the draft that
are not explained as you describe above.

 >     possibility that the responding router might not know?  

=> I don't think so. It should always know.

 >   - "SHOULD be sent on links that have a "Second, the Override flag in Neighbor Advertisements SHOULD be
 >     prefix?  

=> I don't understand the question. The NA can only include a unicast
address. You can't include a prefix in the NA.

       In this case, I'm advertising a single route to you with

 >      not an address it wishes to use is already in use by another

=> ok.

 >     appeared before.  It should be explained.

=> We can add a reference here.

 >     nothing else add a pointer to text elsewhere.  

=> I'd appreciate comments on this from Thomas or Erik if they want to
add something here. Personally, while I appreciate the clarity
requirements, I think it's not necessary to always explain all possible
options for not following a SHOULD. From personal experience, I found
people using specs in ways that were not originally thought of, while
being legitimate (due to the use of MAYs and SHOULDs). So I'm inclined
to leave it as is but would like to hear if others see such ways of
clarification necessary.

 >     implementors might benefit from explanation.  

=> Ok, I think there are lots (most of the shoulds) in the draft that
are not explained as you describe above.

 >     possibility that the responding router might not know?  

=> I don't think so. It should always know.

 >     "MUST be sent ...  (where specified ...)"?

=> I have to give the same answer here. I don't think it's appropriate
to put MUST instead of the SHOULD above. The flexibility provided by the
SHOULD is important given the variety of link layers and *systems* (e.g.
3GPP, WiMAX ...etc) out there that define how IPv6 is used in their
environments. 
For the rest of the "SHOULD" comments I couldn't add or respond to your
comments any differently from my earlier comments. So I suggest we
handle all the "SHOULD" comments together at least initially. As I
mentioned earlier, in general, it's not a good idea to change SHOULDs to
MUSTs anywhere in the draft unless it's an obvious bug. 

 >       "The value should be set to that current diameter of the

=> ok.

 >     Is there a consistency problem here?

=> None whatsoever, the title of 7.2.6 is "Sending Unsolicited Neighbour
Advertisements", so naturally the Solicited flag must not be set in this
case.

 >     about the sender's behavior, so this SHOULD should not be

=> Hmm. That's true.

Hesham

variable MTU (as 
 > specified in

=> I have to give the same answer here. I don't think it's appropriate
to put MUST instead of the SHOULD above. The flexibility provided by the
SHOULD is important given the variety of link layers and *systems* (e.g.
3GPP, WiMAX ...etc) out there that define how IPv6 is used in their
environments. 
For the rest of the "SHOULD" comments I couldn't add or respond to your
comments any differently from my earlier comments. So I suggest we
handle all the "SHOULD" comments together at least initially. As I
mentioned earlier, in general, it's not a good idea to change SHOULDs to
MUSTs anywhere in the draft unless it's an obvious bug. 

 >       "The value should be set to that current diameter of the

=> ok.

 >     Is there a consistency problem here?

=> None whatsoever, the title of 7.2.6 is "Sending Unsolicited Neighbour
Advertisements", so naturally the Solicited flag must not be set in this
case.

 >     about the sender's behavior, so this SHOULD should not be

=> Hmm. That's true.

Hesham

variable MTU (as 
 > specified in

=> I have to give the same answer here. I don't think it's appropriate
to put MUST instead of the SHOULD above. The flexibility provided by the
SHOULD is important given the variety of link layers and *systems* (e.g.
3GPP, WiMAX ...etc) out there that define how IPv6 is used in their
environments. 
For the rest of the "SHOULD" comments I couldn't add or respond to your
comments any differently from my earlier comments. So I suggest we
handle all the "SHOULD" comments together at least initially. As I
mentioned earlier, in general, it's not a good idea to change SHOULDs to
MUSTs anywhere in the draft unless it's an obvious bug. 

 >       "The value should be set to that current diameter of the

=> ok.

 >     Is there a consistency problem here?

=> None whatsoever, the title of 7.2.6 is "Sending Unsolicited Neighbour
Advertisements", so naturally the Solicited flag must not be set in this
case.

 >     about the sender's behavior, so this SHOULD should not be

=> Hmm. That's true.

Hesham

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Nov 2006 17:00:18 -0500

Here are my comments on draft-ietf-ipv6-2461bis-09.txt.  In general, I think
the document is ready for publication.  Included below are a few substantive
comments that I would like to see addressed before publication, and some
editorial corrections/suggestions/comments.

- Ralph

----- 

Substantive/editorial: I'm confused by the statements in section 3.2,
           Supported Link Types: "Neighbor Discovery should be implemented
           as described in this document."  What is the intent of the
           statement - advice about whether to implement or how to
           implement?  Under what circumstances would a node not implement
           Neighbor Discovery as described in the document.

Substantive: From section 4.6, Option Formats:

   Options should
   be padded when necessary to ensure that they end on their natural 64-
   bit boundaries.

           How, exactly, is this padding encoded?  And, why bother?

Substantive: The definition of the L bit, from the Prefix Information
           option, includes:

                     When
                     not set the advertisement makes no statement about
                     on-link or off-link properties of the prefix.

           This point about "no statement about on-link or
           off-link..." is made other places, as well.  I don't think
           I see any indication of the consequences of this
           definition; that is, what should the implementor be aware
           of as a consequence of the lack of knowledge about whether
           a prefix is on-link or off-link?  If those consequences are
           subtle, perhaps they should be explained?

Editorial/substantive: From section 5.1, Conceptual Data Structures:

      Default Router List
                   - A list of routers to which packets may be sent.

           Is it possible for a host to send packets to routers that
           are not on the Default Router list?

Editorial: In the last paragraph of section 1,
           s/Deering Richard/Deering, Richard/

Editorial suggestion: In the definition of "link MTU" (section 2.1),
           s/piece/transmission unit/ (or some other similar term)

Editorial: In the definition of NBMA (section 2.2), s/it(e.g.,/it (e.g.,/

Editorial: In the definition of "Address Autoconfiguration" in section 3,
           I'm guessing that "How nodes automatically configure..." was
           changed to "Introduces the mechanisms needed in order to allow
           nodes to automatically configure..." because the mechanism is
           defined in RFC 2462.  A citation of RFC 2462 might be in order
           here.

Editorial: In the definitions of "Anycast addresses" and "Proxy
           advertisements" in section 3, the phrases "non-Override
           advertisements" and "non-Override Neighbor Advertisements"
           are used before they are defined.

Editorial: Seems "autonomous address configuration" and "stateless
           address configuration" (and some variants like "autonomous
           address-configuration", "stateless address
           autoconfiguration" and "address autoconfiguration") are
           used interchangeably throughout the document; it would
           improve clarity to pick one phrase and use it uniformly
           throughout the document

Editorial: The definition for Prefix Information option in section 4.2
           includes the text "specify the prefixes that are on-link
           and/or are used for address autoconfiguration".  Is it the
           case that a Prefix Information option will only appear for
           on-link and/or address autoconfiguration; i.e., at least
           one of the L and A bits will always be set in Prefix
           Information  option?

Editorial: In the definition of MinRtrAdvInterval in 6.2.1,
           s/.75 *MaxRtrAdvInterval/.75 * MaxRtrAdvInterval/

Editorial: In section 6.3.4, s/"on-link "/"on-link"/

Editorial suggestion: In Appendix E,
          s/working.  It merely/working; it merely/

---

From: "Ralph Droms \(rdroms\)" <[email-masked]>
Date: Tue, 28 Nov 2006 00:08:05 -0500

Comment about DHCPv6 question in line...

- Ralph

-----Original Message-----
From: Soliman, Hesham [mailto:[email-masked]]
Sent: Wed 11/22/2006 4:51 AM
To: Scott W Brim; General Area Review Team; Jari Arkko; Mark Townsley (townsley); Bob Hinden; Brian Haberman; Thomas Narten; Erik Nordmark; William Allen Simpson; [email-masked]; [email-masked]
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

It's a network config and admin issue.  The router doesn't "learn" or "know" if DHCPv6 is available; rather, the router is explicitly configured by the network admin to advertise the availability of DHCPv6 to hosts.  Presumably, the netowkr admin knows whether DHCPv6 is available and configures the router appropriately.

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Nov 2006 02:18:35 +1100

-----Original Message-----
From: Soliman, Hesham [mailto:[email-masked]]
Sent: Wed 11/22/2006 4:51 AM
To: Scott W Brim; General Area Review Team; Jari Arkko; Mark Townsley
(townsley); Bob Hinden; Brian Haberman; Thomas Narten; Erik Nordmark;
William Allen Simpson; [email-masked]; [email-masked]
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

It's a network config and admin issue.  The router doesn't "learn" or "know"
if DHCPv6 is available; rather, the router is explicitly configured by the
network admin to advertise the availability of DHCPv6 to hosts.  Presumably,
the netowkr admin knows whether DHCPv6 is available and configures the
router appropriately.

=> Sure, that's why the end result is that the router knows whether DHCPv6
is available or not.

Hesham

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Nov 2006 15:33:17 -0500

> address. You can't include a prefix in the NA.

I also don't understand the question. The override flag is only
carried in NA messages, and thus refers to the target address (i.e.,
one unicast address).

>  >       Otherwise it SHOULD be included on link layers that have

There is no reason to include it if the source address if the RS is an
unspecified address. By definition, the unspecified address is never
used as a destination address. Thus, the router can't just insert the
source address of an RS into the destination address of an Ra and send
the packet directly. Morever, since there is no source address, there
is no updating of the neighbor cache. I suspect (but have forgotten)
that the MUST NOT is to preclude some mischief from happening if the
router actually did try to use that link-layer address in conjunction
with an unspecified address.

It is also not a MUST to include on link layers that have addresses
because a router doesn't have to respond with a unicast RA back to the
requestor. It can multicast to the all nodes address instead. So the
SHOULD is to give the router the option of sending back a unicast RA.

If there was a more specific reason why the SHOULD was not a MUST, I
don't recall any more why that was.

Now whether any of the above needs to go into the document
explicitely, I have my doubts...

>  >     possibility that the responding router might not know?

yes. But there is little we can do about this.

In hindsight, the M&O bits (IMO) should probably never have been
defined at all. Indeed, they are classic case of "define the field
first, figure out later how to make it useful". The M&O bits were
defined long before we had DHCPv6 in place.

As James Carlson has also observed, life would be simpler if there
were no (protocol) distinction in DHCPv6 between asking for "all"
parameters and asking for "other" parameters. Then we wouldn't need
two bits. And life would be simple if all nodes just invoked DHC
(regardless of what the M&O bits said -- precisely so that the router
wouldn't have to worry about setting them correctly). But some folk
did/will complain about always invoking DHC. On wireless WAN links,
where "every packet costs someone money", folks have made a lot of
noise about NOT having nodes invoke DHC if there is no DHC server
available. In those (heavily managed infrastructures) it is no problem
having the DHC story and the M&O settings on routers be
consistent. However, for home networks, it's less clear how to ensure
things are in sync...

So, no solution is perfect. If you assume a managed infrastructure,
setting the bits correctly is pretty easy. If always invoke DHC, and
DHC isn't actually present, there is an associated inefficiency.

> 3GPP, WiMAX ...etc) out there that define how IPv6 is used in their

I'll also note that the above SHOULD is to some extent an operational
statement, not a protocol statement.  If it is an implementation
statement, it would be far more appropriate to say SHOULD or MUST in
the specific IPv6 over FOO document, rather than this one.

Thomas

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 29 Nov 2006 02:18:35 +1100

-----Original Message-----
From: Soliman, Hesham [mailto:[email-masked]]
Sent: Wed 11/22/2006 4:51 AM
To: Scott W Brim; General Area Review Team; Jari Arkko; Mark Townsley

Hesham

---

From: Thomas Narten <[email-masked]>
Date: Tue, 28 Nov 2006 15:33:17 -0500

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Nov 2006 10:58:54 +0100

> The M&O bits were

And they were discussed to death in the WG before the draft reached
WG consensus. I'm not inclined to reopen that discussion.

(Somebody added [email-masked] to this thread. I have removed it.)

    Brian

---

From: James Carlson <[email-masked]>
Date: Tue, 28 Nov 2006 11:32:57 -0500

> From: Soliman, Hesham [mailto:[email-masked]]
[...]
> It's a network config and admin issue.  The router doesn't "learn" or "know" if DHCPv6 is available; rather, the router is explicitly configured by the network admin to advertise the availability o…

True, but at least in my own implementation experience, I've found
this to be a bit too brittle.

There's no easy way to make sure that the configuration works out
correctly.  If you happen to have a monolithic implementation, you
might be able to cause the "enable DHCPv6 server" configuration knob
to turn these bits automagically so there are no inconsistencies.
However, for those of us with more flexible environments, or for
deployments where the DHCPv6 server is not itself a router,
rationalizing the configuration is infeasible, and it becomes yet
another error-prone task for humans.

If the administrator enables a DHCPv6 server, he must remember to
update the routers with the corresponding prefixes as well.  If he
forgets, then he ends up in a strange state: hosts that don't happen
to hear those routers "right away" (MAX_RTR_SOLICITATIONS) at
interface configuration time may end up running DHCPv6 and working as
he expected, because they briefly enter the "no routers" state.  Hosts
that do happen to hear these bits will fail to run DHCPv6 at all.  The
results are inconsistent.  (Unrelated issues such as STP port blocking
can cause this to happen more often than might otherwise be expected.)

If he shuts down the DHCPv6 server and clears the RA bits, those hosts
that once heard the "use DHCPv6" bits will continue to run DHCPv6
indefinitely, regardless of the setting of these bits.  Nothing in the
protocol stops them from looking for a server.

Worse still, there's no real guarantee that the authority in charge of
administering "routers" is the same as the authority in charge of
"DHCP" administration on a given network.  It's good if that's true,
and the document seems to assume it tacitly, but these sorts of things
sometimes end up on opposite sides of an administrative divide.

Even more strangely, if the DHCPv6 server is handing out only
configuration information (M=0 O=1), then there's no reason at all to
suppose that the use of DHCPv6 has anything to do with the prefix
management imposed by the routers.  They're effectively unrelated
protocols at that point, and the RAs are serving as a configuration
broadcast mechanism.

The one clear purpose of these bits is in distinguishing between the
"managed" and "other" cases so that the DHCPv6 client knows whether to
start with Solicit or Information-Request.  However, on a routerless
network, the client must still do something sane even though these
bits are absent, and a smart enough client can thus be expected to
right itself regardless of the way the server is configured.

Though they're part of the standard, and I'm forced to support them, I
don't think the ``M'' and ``O'' bits have much to recommend themselves
over simply running DHCPv6 on all interfaces by default and perhaps
fixing the DHCPv6 specification to make switching between the two
modes of operation simpler and more consistent.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Nov 2006 13:16:23 -0500

Hi Ralph.

[ietf list dropped]

>            Neighbor Discovery as described in the document.

I think this is general advice to people thinking about how ND applies
to link layers other than, say, ethernet. Clearly, ND applies to all
specs, unless superceded by another spec for a particular link
layer. That is all that this section is (IMO) trying to say. I.e., to
suggest when another spec might be needed and where not.

>            How, exactly, is this padding encoded?  And, why bother?

See the length field:

      Length         8-bit unsigned integer.  The length of the option
                     (including the type and length fields) in units of
                     8 octets.  The value 0 is invalid.  Nodes MUST
                     silently discard an ND packet that contains an
                     option with length zero.

You have to pad options to fill them out to 8 octets.		     

>            subtle, perhaps they should be explained?

Well, I seem to recall that exact wording was the result of a lot of
discussion at the time. :-)

What this is really trying to say is that if you receive an RA with a
prefix information option in which the on-link bit is not set, you
cannot conclude from that that the prefix is not on link. From section
6.3.4:

   Prefix Information options that have the "on-link" (L) flag set
   indicate a prefix identifying a range of addresses that should be
   considered on-link.  Note, however, that a Prefix Information option
   with the on-link flag set to zero conveys no information concerning
   on-link determination and MUST NOT be interpreted to mean that
   addresses covered by the prefix are off-link.  The only way to cancel
   a previous on-link indication is to advertise that prefix with the
   L-bit set and the Lifetime set to zero.

The last sentence explains why "when not set the advertisment makes no
statement about on-link or off-link properties of the prefix".

>            are not on the Default Router list?

sure, but that  is outside the scope of this spec. The only routers
covered by the ND spec are those learned via ND.

>            improve clarity to pick one phrase and use it uniformly

Agreed. I suggest dropping autonomous, since that term is less well
known.

>            one of the L and A bits will always be set in Prefix

Not necessarily. See RFC RFC3775.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Nov 2006 13:16:23 -0500

Hi Ralph.

[ietf list dropped]

See the length field:

      Length         8-bit unsigned integer.  The length of the option
                     (including the type and length fields) in units of
                     8 octets.  The value 0 is invalid.  Nodes MUST
                     silently discard an ND packet that contains an
 -iport-5.cisco.com with ESMTP; 29 Nov 2006 10:18:24 -0800
Date: Wed, 29 Nov 2006 13:18:48 -0500
From: Ralph Droms <[email-masked]>
To: Brian E Carpenter <[email-masked]>, Thomas Narten <[email-masked]>
Cc: Brian Haberman <[email-masked]>,
	Bob Hinden <[email-masked]>,
	William Allen Simpson <[email-masked]>,
	General Area Review Team <[email-masked]>,
	Erik Nordmark <[email-masked]>, [email-masked], "Soliman,
	Hesham" <[email-masked]>
Subject: Re: [Gen-art] Re: gen-art review of draft-ietf-ipv6-2461bis-09.txt

Yeah.  I have to agree with James and Brian: in retrospect, the M/O bits are
useless and further discussion at this point is even more useless.

- Ralph

                    option with length zero.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Wed, 29 Nov 2006 13:18:48 -0500

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 29 Nov 2006 14:48:40 -0500

Thomas - thanks for the responses...

> suggest when another spec might be needed and where not.

I think I understand the meaning the text is supposed to convey.  But the
text doesn't seem (to me, anyway) to convey that meaning very well; I note
your interpretation is qualified with "IMO" and perhaps another reader might
have a different opinion?

To be more concrete, it appears that the section is describing how or which
parts of ND should be implemented on links with certain attributes.  But the
last several entries don't seem to be very clear or precise.  For example,
from:

     variable MTU   - Neighbor Discovery allows routers to specify a MTU
                      for the link, which all nodes then use.  All nodes
                      on a link must use the same MTU (or Maximum
                      Receive Unit) in order for multicast to work
                      properly.  Otherwise when multicasting, a sender,
                      which can not know which nodes will receive the
                      packet, could not determine a minimum packet size
                      that all receivers can process (or Maximum Receive
                      Unit).

I guess I would infer that "variable MTU" is orthogonal to, say,
"multicast", and the only effect of "variable MTU" is that the network admin
has to pick MTU == min(MRU for each host on the link).

> You have to pad options to fill them out to 8 octets.  

Oh, of course...

OK, so "natural 64-bit boundaries" is a little unclear.  And, shouldn't it
be a MUST?  Does each option describe how to pad; i.e., suppose an option
carries a single variable length value?  Is it the responsibility of the
text defining the option to describe the format of the option so the option
is always a multiple of 8 octets?  Hm, if that's the case, then perhaps the
text I quoted is superfluous?

Backtracking...I reviewed the options defined in this spec, and all except
the Redirected-header option are defined to be an integer multiple of 8
octets in length.  So, is the "padded when necessary" advice for the
definition of future options?

I found another nit while exploring this text: there is at least one
instance each of "link layer address" and "link-layer address"; choose one
or the other for consistency.

> statement about on-link or off-link properties of the prefix".

Yeah, I agree the text means "don't draw any conclusions about on- or
off-link is L bit is not set".  What are the ramifications of the L bit not
being set; what other parts of this or other protocols are affected?

> covered by the ND spec are those learned via ND.

So a host only learns about default routers through ND?

> Agreed. I suggest dropping autonomous, since that term is less well

Except for its use in supplying the initial for the 'A' bit in prefix
options...

> Not necessarily. See RFC RFC3775.

Ah, right, thanks for the pointer.  Just for my own enlightenment, is there
a reason to advertise a prefix that has all three of L, A and R not set;
i.e., a prefix not used for IPv6 mobility, not used for SLAAC and not
on-link?  And, I guess this follows up on my earlier question - if the L bit
is not set, I suppose it means the prefix is not added to the list of
on-link prefixes as a result of receiving the prefix option in an RA.

- Ralph

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Nov 2006 11:53:23 -0800

> Not necessarily. See RFC RFC3775.

By my reading of Section 6, it is permissible for a PIO
to have both 'A' and 'L' = 0; another use-case is for a
"landmark" prefix that identifies a link. However, IMHO
the Section 4.2 text Ralph cites implies that one of 'A'
or 'L' will always be set, and there are several other
occurrences throughout the document that also imply this.

Suggested change for the Section 4.2 text is: "specify
the prefixes that are *associated with the link*", which
is consistent with the Section 3.1 sentence:

  "Multiple prefixes can be associated with the same link."

Also suggest substituting the phrase "associated with the
link" for the other occurrences (I can provide a list).

Editorial comments:
*******************
1) Section 1, reference for [IPv6-NBMA] is missing.
2) Section 2.1, change: "Internet Message Control Protocol"
   to: "Internet Control Message Protocol".
3) Normative References, update references for [ADDR-ARCH]
   and [ICMPv6].
   
Fred
[email-masked]