Neighbor Discovery for IP version 6 (IPv6)
draft-ietf-ipv6-2461bis-11

[Note]: 'Brian Haberman <brian@innovationslab.net> is the Document shepherd
NOTE: Tentatively put on the agenda. Still need to check if everything was actually revised correctly' added by Jari Arkko

[Ballot comment]
Nit in Appendix F


    o Clarified that inconsistency checks for CurHopLimit are done for
      none zero values only.

should be "non-zero", most likely.

IANA 2nd Last Call Comment:

As stated in the IANA Considerations section, we understand
this document to have NO new IANA Actions.

However, upon approval references to RFC 2461 in IPv6
registries will be updated to reflect the new RFC.

The IANA Matrix does NOT require a reference change as a
result of approval of this document.

The registry located at:

http://www.iana.org/assignments/icmpv6-parameters

requires the following references to be updated:

[1] five references to RFC2461 in the message types section;
[2] five references to RFC2461 in the ICMP type code fields; and,
[3] five references to RFC2461 in the neighbor discovery option
    types

In each of these cases the new document reference (RFC number)
will be substituted for RFC2461.

In addition, in the case of neighbor discovery option types,
the IANA will document the policy for adding neighbor
discovery option types in the future.

It will be:

1. The IANA should allocate and permanently register new
option types from IETF RFC publication. This is for all
RFC types including standards track, informational, and
experimental status that originate from the IETF and have
been approved by the IESG for publication.

2. IETF working groups with working group consensus and area
  director approval can request reclaimable Neighbor
  Discovery option type assignments from the IANA. The IANA
  will tag the values as "reclaimable in future".

The "reclaimable in the future" tag will be removed when an
RFC is published documenting the protocol as defined in 1).
This will make the assignment permanent and update the
reference on the IANA web pages.

At the point where the option type values are 85% assigned,
the IETF will review the assignments tagged "reclaimable in
the future" and inform the IANA which ones should be
reclaimed and reassigned.

3. Requests for new option type value assignments from outside
  the IETF are only made through the publication of an IETF
  document, per 1) above. Note also that documents published
  as "RFC Editor contributions" [RFC3667] are not considered
  to be IETF documents.

[Ballot discuss]
According to appendix F, one of the changes to this document was to add section 3.3, which says:

Neighbor Discovery messages are needed for various functions. Several
  functions are designed to allow hosts to ascertain the ownership of
  an address or the mapping between link layer and IP layer addresses.
  Vulnerabilities related to Neighbor Discovery are discussed in
  section 11.1. A general solution for securing Neighbor Discovery is
  outside the scope of this specification and is discussed in [SEND].
  However, Section 11.2 explains how and under which constraints IPsec
  AH or ESP can be used to secure Neighbor Discovery.

Appendix F also, however, says:

Removed references to IPsec AH and ESP for securing messages or as part of validating
the received message.

Was the reference to AH and ESP in 3.3 meant to be removed?

[Ballot comment]
Section 6.2.1., paragraph 12:
>                      Default: 0.33 * MaxRtrAdvInterval

  The default MinRtrAdvInterval can only be calculated according to this
  formula if MaxRtrAdvInterval >= 9 seconds, because otherwise
  (MaxRtrAdvInterval can be as low as 4 seconds) it becomes less than
  the minimum of 3 seconds.

[Ballot comment]
I believe that the first and second sentence in the first paragraph of 6.2.1 may be interpreted as contradictory and be confusing:

OLD:

  A router MUST allow for the following conceptual variables to be
  configured by system management.  The specific variable names are
  used for demonstration purposes only, and an implementation is not
  required to have them, so long as its external behavior is consistent
  with that described in this document.  Default values are specified
  to simplify configuration in common cases.

I suggest to add a few words of clarification and turn this into:

NEW:

  A router MUST allow for the following conceptual variables to be
  configured by system management.  The specific variable names are
  used for demonstration purposes only, and an implementation is not
  required to have them, so long as its external behavior is consistent
  with that described in this document, and the functions described
  by the conceptual variables are configurable by some external
  management interface.  Default values are specified to simplify
  configuration in common cases.

[Ballot comment]
Dialogue between Gen-ART reviewer (Scott Brim) and author:

> 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."

=> ok.

>     
>  - Router advertisement: the phrase "on-link determination" has not
>    appeared before.  It should be explained.

=> We can add a reference here.

> 6.2.1 router config variables
>
>  - AdvCurHopLimit
>
>      "The value should be set to that current diameter of the
>      Internet."
>
>    s/that/the/

=> ok.

["Current diameter of the Internet" is an interesting concept - BC]

> 8.2.  Router Specification
...
>  - "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.

=> Hmm. That's true.

IANA Last Call Comments:

As stated in the IANA Considerations section, upon approval
of this document there are no new registrations for IANA to
make.

However, upon approval of this document, references to RFC 2461
should be updated to this document in the ICMP IPv6 registry
maintained by IANA:

http://www.iana.org/assignments/icmpv6-parameters

IANA understands this to be the only action required upon
approval of the document.

AD review results posted to the authors and chairs. Only minor issues uncovered, but the document should be revised so that it is clean of editorial problems when it goes to IETF LC and IESG review.

Talked to Thomas and Erik. I want at least one of them to state that they are OK with the current document; Thomas hadn't done a review in a while. He promised to do a review. Request for review was also sent to Erik.

State Change Notice email list have been change to ipv6-chairs@tools.ietf.org,hsoliman@qualcomm.com,bill.simpson@um.cc.umich.edu,nordmark@sun.com,narten@raleigh.ibm.com from ipv6-chairs@tools.ietf.org,h.soliman@flarion.com,bill.simpson@um.cc.umich.edu,nordmark@sun.com,narten@raleigh.ibm.com

[Note]: '1/12/06:&nbsp; Document remains on hold pending resolution of M&amp;O bit issues.&nbsp; Brian Haberman &lt;brian@innovationslab.net&gt; is the PROTO shepherd for this document.' added by Jari Arkko

[Note]: '1/12/06:  Document remains on hold pending resolution of M&O bit issues.  Brian Haberman <brian@innovationslab.net> is the PROTO shepherd for this document.' added by Jari Arkko

[Note]: '1/12/06:  Document remains on hold pending resolution of M&O bit issues.  Brian Haberman <brian@innovationslab.net> is the PROTO shepherd for this document.' added by Margaret Wasserman

Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do

    they believe this ID is sufficiently baked to forward to the IESG

    for publication?



Yes



2) Has the document had adequate review from both key WG members and

    key non-WG members? Do you have any concerns about the depth or

    breadth of the reviews that have been performed?



The document has been reviewed by numerous members of the IPv6 WG.

We, the chairs, have no concern over the reviews performed.



3) Do you have concerns that the document needs more review from a

    particular (broader) perspective (e.g., security, operational

    complexity, someone familiar with AAA, etc.)?



No.



4) Do you have any specific concerns/issues with this document that

    you believe the ADs and/or IESG should be aware of? For example,

    perhaps you are uncomfortable with certain parts of the document,

    or whether there really is a need for it, etc., but at the same

    time these issues have been discussed in the WG and the WG has

    indicated it wishes to advance the document anyway.



No concerns.



5) How solid is the WG consensus behind this document?  Does it

    represent the strong concurrence of a few individuals, with others

    being silent, or does the WG as a whole understand and agree with

    it?



This document appears to have strong support throughout the WG.



6) Has anyone threatened an appeal or otherwise indicated extreme

    discontent?  If so, please summarize what are they upset about.



No.



7) Have the chairs verified that the document adheres to _all_ of the

    ID nits?



Yes.  There are three instances of obsolete boilerplate usage.
This does not need to be addressed until substantive comments
are being worked.



- Technical Summary



    This specification defines the Neighbor Discovery (ND) protocol for
    Internet Protocol Version 6 (IPv6).  Nodes (hosts and routers) use
    Neighbor Discovery to determine the link-layer addresses for
    neighbors known to reside on attached links and to quickly purge
    cached values that become invalid.  Hosts also use Neighbor Discovery
    to find neighboring routers that are willing to forward packets on
    their behalf.  Finally, nodes use the protocol to actively keep track
    of which neighbors are reachable and which are not, and to detect
    changed link-layer addresses.  When a router or the path to a router
    fails, a host actively searches for functioning alternates.


- Working Group Summary



The IPv6 working group has done extensive reviews of this document and

this document reflects the consensus of the group.



- Protocol Quality



This document has been reviewed by members of the ipv6@ietf.org

mailing list and by the working group chairs.