IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
draft-ietf-6man-ipv6-subnet-model-12

[Ballot comment]
I still find the description of the example in section 5 unclear.  The syntax in this passage is tortured:

  An address
  could be acquired through the DHCPv6 IA_NA option (which does not
  include a prefix length), or through manual configuration (if no
  prefix length is specified).  The host incorrectly assumes an
  invented prefix is on-link.  This invented prefix typically is a /64
  that was written by the developer of the API as a "default" prefix
  length when a length isn't specified.  This may cause the API to seem
  to work in the case of a network interface initiating SLAAC, however
  it can cause connectivity problems in NBMA networks.

What is the API referred to in the example?

The changes to the word "deprecate" and the new section on changes to RFC 4861 satisfy my comments on those details.

[Note]: 'On the agenda on May 6th to search for 1 additional vote
Brian Haberman (brian@innovationslab.net) is the document shepherd.' added by Jari Arkko

[Ballot comment]
I still find the example in section 5 confusing.  It would be better to simply state the observer behavior, which is (I think) that the host, when an IPv6 address is configured through CLI, adds an inferred /64 from the manually configured address to its prefix list, even if that prefix has not appeared as on-link in a PIO.

For clarity, all of the specific updates to RFC 4861 should be clearly defined in a separate section.

[Ballot discuss]
I concur with Ralph's DISCUSS. There is very little new in this document. Maybe the issues is best handled with an errata to the document that it updates.

[Ballot comment]
The Gen-ART Review by Pete McCann on 2010-03-09 included some
  editorial comments.  Please consider them if an update to this
  document is needed for any reason.

[Ballot discuss]
This is a DISCUSS DISCUSS, which I believe needs clarification before I can approve this document. Some of the requirements in sections 3 and 4 modify the hosts behavior defined in RFC 4861 that this document updates. RFC 4861 is however a Draft Standard, so would not approving these changes modify the interoperability conditions on which base the advancement of 4861 from PS to Draft was approved?

[Ballot comment]
This document needs a terminology section to define or point to the intended definition of "subnet" and various terms from RFC 4291, et al. such as Prefix List.  Pointers to some of the terms are given in the body of the doc, not always on first reference, and a terminology section would be helpful.
---
"The original Neighbor Discovery (ND) specification [RFC4861]": s/original//; RFC4861 is the current ND specification.
---
From bullet 2 of section 2:

      Redirect
      Messages do not contain sufficient information to signal that an
      address is off-link.

Redirect messages give no indication either way about on- or off-link; perhaps reword as:

      Redirect
      Messages do not contain any information about whether an address is
      on- or off-link.
---

[Ballot discuss]
Regrettably, I'm having some trouble with access to the datatracker today, and my original DISCUSS text was lost.  Retyping...

I'm raising a discuss-discuss.  Do we need a full document to achieve the goals?  Can the changes to RFC 4861 be accomplished with an Errata?  Much of the document is a restatement of other RFCS and I worry that the RFC 2119 requirements may be confusing or subtly in conflict with other RFCs.  How often has the behavior in section 4 been observed; I'm aware of one mis-implementation that was corrected some time ago.

From list item 3 of section 2:

      Neither of these tests are acceptable definitions for an address
      to be considered as on-link as defined above, and this document
      deprecates and removes both of them from the formal definition of
      on-link.

Why are these test not acceptable definitions for on-link?

[Ballot comment]
This document needs a terminology section to define or point to the intended definition of "subnet" and various terms from RFC 4291, et al. such as Prefix List.  Pointers to some of the terms are given in the body of the doc, not always on first reference, and a terminology section would be helpful.
---
"The original Neighbor Discovery (ND) specification [RFC4861]": s/original//; RFC4861 is the current ND specification.
---
From bullet 2 of section 2:

      Redirect
      Messages do not contain sufficient information to signal that an
      address is off-link.

Redirect messages give no indication either way about on- or off-link; perhaps reword as:

      Redirect
      Messages do not contain any information about whether an address is
      on- or off-link.
---

[Ballot discuss]
From list item 3 of section 2:

      Neither of these tests are acceptable definitions for an address
      to be considered as on-link as defined above, and this document
      deprecates and removes both of them from the formal definition of
      on-link.

Why are these test not acceptable definitions for on-link?

[Ballot discuss]
Section 4., paragraph 0:
>    4.  Implementations compliant with [RFC4861] MUST adhere to the

  DISCUSS: The document seems to lack a both a reference to RFC 2119 and
  the recommended RFC 2119 boilerplate, even if it appears to use RFC
  2119 keywords.

I have reviewed this draft. The draft is in good shape and a welcome clarification. However, I had two small issues I wanted to talk about before moving the draft to last call:

> 5. Hosts MUST verify that on-link information is still valid after
>    IPv6 interface re-initialization before using cached on-link
>    determination information.  Failure to do so may lead to lack of
>    IPv6 network connectivity.  For example, a host receives an RA
>    from a router with on-link prefix A. The host powers down.
>    During the power off, the router sends out prefix A with on-link
>    bit set and a zero lifetime to indicate a renumbering.  The host
>    misses the renumbering.  The host powers on and comes online.
>    Then, the router sends an RA with no PIO.  The host uses cached
>    on-link prefix A and issues NS's instead of sending traffic to a
>    default router.  The "Observed Incorrect Implementation Behavior"
>    section below describes how this can result in lack of IPv6
>    connectivity.

"... MUST verify ... before using ..." appears to be in conflict with the DNA specification (draft-ietf-dna-simple, in IESG review). The DNA specification suggests the use of NS/NA and RS/RA exchanges in parallel to verify that previously seen network configuration is still in effect. The question is whether reception of NA is sufficient for the host to continue operations (even if it still waits for the RS and re-configures the interface if it shows different information). My understanding is that the DNA specification wants to let hosts do this.

I would suggest that the first sentence above could actually be written like this, without sacrificing anything substantial:

  Hosts MUST verify that on-link information is still valid after
  IPv6 interface re-initialization.

This leaves room for different verification techniques, e.g., verifying before usage or in parallel as DNA does.

> In an access
> concentrator network ([RFC4388]), a host receives a Router
> Advertisement Message with no on-link prefix advertised.  The host
> incorrectly assumes an invented prefix is on-link and performs
> address resolution when the host should send all non-link-local
> traffic to a default router.

I am not sure I understand the "invented prefix" case above. Where does the prefix information come from, if there is no prefix in the RA? Or is this a prefix from some previous network, or assigned as a part of some other exchange that is not mentioned here? The example seems incomplete.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Brian Haberman is the document shepherd and he believes this draft is
ready for IESG review and publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, it has received adequate review and there are no concerns about
those reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns.

(1.e) 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 has been the subject of many WG discussions involving a
wide variety of participants.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document currently has 1 error and 1 warning from ID nits that may
be due to the difference in the publication date of the draft and the
recent updates to the nits tool. These can be resolved during a future
edit.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are in proper order.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

IANA Considerations are properly addressed.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

N/A.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

IPv6 specifies a model of a subnet that is different than the IPv4
subnet model. The subtlety of the differences has resulted in
incorrect implementations that do not interoperate. This document
spells out the most important difference; that an IPv6 address isn't
automatically associated with an IPv6 on-link prefix. This document
also updates (partially due to security concerns caused by incorrect
implementations) a part of the definition of on-link from [RFC4861].

Working Group Summary
This document represents the consensus of the 6MAN Working Group.

Document Quality
This document has been reviewed by members of the 6MAN Working Group.