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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf