Simple Procedures for Detecting Network Attachment in IPv6
RFC 6059

[Ballot comment]
(edited 2010-09-08)

I cleared my DISCUSS.

I think this text in section 2.4 is superfluous, as ND and/or DHCP are completed regardless of the outcome of the simple DNA procedure:

                        If previously encountered routers are not present then
either IPv6 Stateless Address Autoconfiguration and/or DHCPv6 is used
for configuration.

In section 5.3, change "neighbor discovery" to "Neighbor Solicitation"?

[Ballot discuss]
Therefore, I think the changes to DHCPv6 need to be taken out of the document.

There is still the issue of the relationship between this document and RFC 4861, as this document changes the way in which RS messages are sent at startup.  I think the changes to RFC 4861 should be taken out of the doc, as well.

The benefit of DNA can be gained from the simple use of NS/NA to see if the link can be identified through a previously-discovered default router.

Suresh tells me that he is going to review his changes once more
and possibly submit a new version, at that point the draft is ready
for re-review by me, Bernard, and Ralph.

[Ballot comment]
The authors should take a pass over the entire document to confirm that all descriptions of the purpose of this mechanism is to determine if the host has reattached to *any* previously attached link, rather than determining if the host has reattached to the link the host just left.

For example:

4.  Host Operations

  When a host has an existing configuration for IP address prefixes and
  next hop routing, it may be disconnected from its link-layer, and
  then subsequently reconnect the link-layer on the same interface.

  When the link-layer becomes available again, it is important to
  determine whether the existing addressing and routing configuration
  are still valid.

  In order to determine this, the host performs the detecting network
  attachment procedure.

This document describes more than just detecting change; it describes how to find any link the host to which the host might have been previously connected.

In the Introduction:

Why do

  "Hosts require procedures to simply and reliably identify if they have
  moved to a different IP network"

I think all of the text in the first paragraph of the introduction is
more or less at odds with the rest of the document.  Moving to a
different IP network is not what this document is about.  The
machinery in this document identifies if a host reattaches to a link
to which it has been previously attached.  It accomplishes that result
by determining if it has reachability to a router it has previously
used as a default router.  If the host determines it has been
previously attached to its current link, it reuses the previously used
addresses and other configuration information.

Similarly, section 2.1 has several goals that mention "link change"
when, in fact, Simple DNA is all about determining link reattachment.

In section 2.5, if assumption 1 does not hold, a host may make an
incorrect determination of which link it has attached to.

In section 4, the second paragraph describes reattaching to the same
link, while Simple DNA determines whether the host has reattached to
*any* link to which it has previously been attached.

There should be some text somewhere about when info is cached in the
SDAT and when info is flushed from the SDAT.

[Ballot discuss]
I have updated my DISCUSS and COMMENT for this document, as explained below.

In an e-mail discussion, I posted the following summary of how DNA should work:

* Send NS for each candidate link to the default router for that link
* Initiate RS/RA exchange as specified in RFC 4861
* Initiate DHCPv6 exchange as specified in RFC 3315

* If an NA is received, used cached info for corresponding link from SDAT
* Process any received RAs as specified in RFC 4861
* Use info from DHCPv6 exchange as specified in RFC 3315
* Info from RA and/or DHCPv6 overrides any reused cached info based on NA

Bernard Aboba agreed with this summary.  The salient point here is that DNA should not modify the behavior of DHCPv6 whatsover.

Therefore, I think the changes to DHCPv6 need to be taken out of the document.

There is still the issue of the relationship between this document and RFC 4861, as this document changes the way in which RS messages are sent at startup.  I think the changes to RFC 4861 should be taken out of the doc, as well.

The benefit of DNA can be gained from the simple use of NS/NA to see if the link can be identified through a previously-discovered default router.

[Ballot comment]
The authors should take a pass over the entire document to confirm that all descriptions of the purpose of this mechanism is to determine if the host has reattached to *any* previously attached link, rather than determining if the host has reattached to the link the host just left.

For example:

4.  Host Operations

  When a host has an existing configuration for IP address prefixes and
  next hop routing, it may be disconnected from its link-layer, and
  then subsequently reconnect the link-layer on the same interface.

  When the link-layer becomes available again, it is important to
  determine whether the existing addressing and routing configuration
  are still valid.

  In order to determine this, the host performs the detecting network
  attachment procedure.

This document describes more than just detecting change; it describes how to find any link the host to which the host might have been previously connected.

In the Introduction:

Why do

  "Hosts require procedures to simply and reliably identify if they have
  moved to a different IP network"

I think all of the text in the first paragraph of the introduction is
more or less at odds with the rest of the document.  Moving to a
different IP network is not what this document is about.  The
machinery in this document identifies if a host reattaches to a link
to which it has been previously attached.  It accomplishes that result
by determining if it has reachability to a router it has previously
used as a default router.  If the host determines it has been
previously attached to its current link, it reuses the previously used
addresses and other configuration information.

Similarly, section 2.1 has several goals that mention "link change"
when, in fact, Simple DNA is all about determining link reattachment.

Section 2.2:

  When a host moves to a completely new link that
  is previously unknown, the performance of the Simple DNA protocol
  will be identical to that using standard neighbor discovery
  procedures [RFC4861].

But, section 4.6 suggests initiating DHCPv6 before receiving an RA,
which reduces latency in completing DHCPv6 transaction for address
assignment on a new link.

Section 2.4:

  Since simple DNA does not modify the
  DHCPv6 protocol or state machine, the operation of DHCPv6 is
  unchanged.

Not true.  Simple DNA hanges the timing of DHCPv6 transmission and
uses Solicit when Confirm would be appropriate.

In section 2.5, if assumption 1 does not hold, a host may make an
incorrect determination of which link it has attached to.

In section 4, the second paragraph describes reattaching to the same
link, while Simple DNA determines whether the host has reattached to
*any* link to which it has previously been attached.

In section 4.5.2, is there any difference between this RS message
contents and the RS message contents specified in RFC 4861?  If there
is no difference, just reference the appropriate section of RFC 4861.

There should be some text somewhere about when info is cached in the
SDAT and when info is flushed from the SDAT.

[Ballot discuss]
Discuss-discuss: I'm inclined to agree with Tim that this document
updates RFC 4861.  In addition to the change Tim noted, this document
also specifies fast transmission of an RS without the initial delay
specified in section 6.3.7 of RFC 4861.  Similarly, this document
calls for the transmission of an initial DHCPv6 message without the
initial delay specified in section 17.1.2 of RFC 3315.  The document
also modifies the retransmission rules for several messages.  And,
although I hate to raise this issue, this document suggests that
a DHCPv6 transaction is initiated before the hsot has seen the M/O
bits in an RA.

In section 4.1, I think each table entry should include:

  o  Link-local IPv6 address of the router that advertised the prefix.

  o  Link-layer (MAC) address of the router that advertised the prefix.

  o  One or more IPv6 addresses; for each address include:
      * flag to indicate whether the address was obtained through
        SLAAC or DHCPv6
      * preferred lifetime
      * valid lifetime
      * other configuration information if address was obtained
        through DHCPv6:
        - DUID
        - IA_ID
        - flag indicating IA_NA/IA_TA
        - other configuration information (DNS recursive servers, NTP
          servers, etc.)

  o One or more prefixes assigned to the link
      * preferred lifetime
      * valid lifetime
      * on-link flag

In section 4.2:

  o  Sending of neighbor discovery or DHCPv6 probes

is incorrect ("or").  The host always sends NS probes and RS requests;
it *may* send a DHCPv6 confirmation early as an optimization.

In section 4.4:

  For the purpose of sending neighbor solicitations to previous
  routers, the host first identifies the set of operable IPv6 addresses
  (candidate set) that it wishes to use.  If the addresses obtained
  from a previous router are no longer valid, the host does not include
  these addresses in the candidate set for NS based probing.

s/operable/valid/  At this point, the host does not know what link it
is attached to, so it cannot determine which addresses are operable.
Also, the second sentence in this paragraph is redundant assuming the
change to "valid" is made.

More abstractly, I would rewrite this paragraph and the following
paragraph to allow for multiple addresses on an interface:

  For the purpose of sending Neighbor Solicitation messages to
  previous routers, the host first identifies the set of candidate
  routers to probe.  Any router in the SDAT for which there is at
  least one valid address is in the set of candidate routers.

  For each router in the candidate set, the host obtains the
  link-local and MAC addresses of the router from the SDAT.  The host
  then sends a unicast Neighbor Solicitation to the router's
  link-local address.

In the next paragraph, make "Router Solicitations" singular.  The
first paragraph in this section has a MUST requirement that the host
only send one Router Solicitation.

In section 4.5.1, I am baffled by the last paragraph.  No DHCPv6
address is used anywhere else in the probe NS message and I can think
of no reason why "The probing node SHOULD include a Source link-layer
address option in the probe messages if the address was obtained using
DHCPv6".

Section 4.6 is somewhat problematic, in that a host is expected to use
a Confirm message if it already has assigned addresses and a Solicit
message if not.  Thinking about the problem a little, I would suggest
turning the solution around as follows:

* Send a Solicit message
* Compare the addresses in the Advertise message to the addresses in
  the SDAT
* If a match is found, assume connection to the corresponding link;
  otherwise
* Complete the DHCPv6 message exchange with a Request and wait for the
  Reply

Otherwise, the host will need to send a Confirm message for each of
candidate links and a Solicit message in case it is attached to a new
link.

In section 4.7, 2nd para, if the host receives an RA, why wouldn't it just use
the current info in the RA; why would it try to reuse any cached info
from a previous attachment? 

Also in the same para, what does it mean to receive a "DHCPv6 message [...]
which contains prefixes that intersect with those previously
advertised by a known router"?  A DHCPv6 message contains assigned
addresses  and other configuration information, but no prefixes.  I'm
guessing the idea is to use the DHCPv6 response as an optimization, in
case it is received before any NA or RA messages.  If I have that
right, then the check would have to be that the set of addresses in
the DHCPv6 message matches the set of previously assigned addresses
associated with the probed router.

[Ballot comment]
I believe the majority of the SHOULDs in this ID should
  become MUSTs. Some examples below. Please check them all.
  (To clarify: I'm not asking you to blindly change all the SHOULDs
  to MUSTs - I'd like you to simply look at each instance of a SHOULD
  and ask yourself if you can come up with a valid case where it may
  be useful to go against the SHOULD, and where you can't find one,
  make it a MUST.)


Section 2.2., paragraph 1:
>    The Simple DNA protocol provides substantial benefits in some
>    scenarios and does not provide any benefit at all in certain other
>    scenarios.

  Compared to what?


Section 4.1., paragraph 1:
>    In order to correctly perform the procedure described in this
>    document the host needs to maintain a data structure called the
>    Simple DNA address table (SDAT).  This data structure is maintained
>    by the host on a per interface basis.

  Why per-interface? Can't this be shared among all interfaces?


Section 4.3., paragraph 2:
>    After the indication is received, the host considers all currently
>    configured (non-tentative) IP addresses to be deprecated until the
>    change detection process completes.  It SHOULD also set all Neighbor
>    Cache entries for the routers on its Default Router List to STALE.

  Why SHOULD and not MUST?


Section 4.4., paragraph 1:
>    When a host receives a link-layer "up" indication, it SHOULD
>    immediately send both a Router Solicitation and if it retains at
>    least one valid IPv6 address, one or more unicast Neighbor
>    Solicitations.

  Why not MUST?


Section 4.4., paragraph 4:
>    The host SHOULD NOT send
>    unicast Neighbor Solicitations to a test node corresponding to an
>    IPv6 address that is no longer valid.

  Why not MUST NOT?


Section 4.6., paragraph 3:
>    Where an
>    existing valid address is being tested for operability, this address
>    should be placed in the Identity Association's IAADDR element, and
>    the DUID associated with that address should be copied to the DHCP
>    SOLICIT from the SDAT.

  should -> MUST? (2x)


Section 4.7., paragraph 2:
>    On reception of a Router Advertisement or advertising DHCPv6 message
>    (a REPLY or ADVERTISE) which contains prefixes that intersect with
>    those previously advertised by a known router, the host utilizes the
>    configuration associated with the detected network.

  What exactly does "intersect" mean? Do you mean "all prefixes returned
  must match the prefixes in the SDAT associated with a router" or "at
  least one returned prefix must match one of the prefixes associated
  with a router in the SDAT?"


Section 4.7., paragraph 3:
>    When the host receives an advertisement containing only prefixes
>    which are disjoint from known advertised prefixes, the host MUST
>    determine whether the solicited advertisement corresponds to any of
>    the routers probed via NS.

  Do you mean "disjoint" as in "doesn't match *any* of the prefixes
  associated with *any* router in the SDAT?


Section 4.7., paragraph 4:
>    If it does, then the host SHOULD conclude
>    that the IPv6 addresses corresponding to that router are no longer
>    valid.  Since any NS probes to that router will no longer provide
>    useful information, further probing of that router SHOULD be aborted.

  I think these need to be MUSTs, or else explain when it wouldn't be.


Section 4.7., paragraph 6:
>    When the host receives a Router Advertisement in reply to the Router
>    Solicitation it sent, the host SHOULD look for a Neighbor Cache entry
>    for the sending router and SHOULD mark that router's Neighbor Cache
>    Entry as REACHABLE if one was found.  The host SHOULD add a new
>    Neighbor Cache Entry in the REACHABLE state for the sending router if
>    one does not currently exist.

  I think all of the SHOULDs need to be MUSTs.

[Ballot discuss]
Section 2.4., paragraph 1:
>    Detecting Network Attachment is performed by hosts after detecting a
>    link-layer "up" indication.  The host simultaneously sends multicast
>    Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs)
>    in order to determine whether previously encountered routers are
>    present on the link.

  DISCUSS: Section 4.9 has appropriate text on handling retransmissions
  of a single probe. What I'm missing is some text that recommends an
  upper bound for how many previous networks should be probed for.
  Clearly, probing for hundreds of previously known networks will
  results in thousands of packets that will all be sent without any sort
  of congestion control, which would be a problem. Similarly, probing
  for a small number of previously known networks will be fine. Can we
  add a recommendation that says that you should limit yourself to
  probing for at most X (10?) previous network locations?

[Ballot comment]
In the Introduction:

Why do

  "Hosts require procedures to simply and reliably identify if they have
  moved to a different IP network"

I think all of the text in the first paragraph of the introduction is
more or less at odds with the rest of the document.  Moving to a
different IP network is not what this document is about.  The
machinery in this document identifies if a host reattaches to a link
to which it has been previously attached.  It accomplishes that result
by determining if it has reachability to a router it has previously
used as a default router.  If the host determines it has been
previously attached to its current link, it reuses the previously used
addresses and other configuration information.

Similarly, section 2.1 has several goals that mention "link change"
when, in fact, Simple DNA is all about determining link reattachment.

Section 2.2:

  When a host moves to a completely new link that
  is previously unknown, the performance of the Simple DNA protocol
  will be identical to that using standard neighbor discovery
  procedures [RFC4861].

But, section 4.6 suggests initiating DHCPv6 before receiving an RA,
which reduces latency in completing DHCPv6 transaction for address
assignment on a new link.

Section 2.4:

  Since simple DNA does not modify the
  DHCPv6 protocol or state machine, the operation of DHCPv6 is
  unchanged.

Not true.  Simple DNA hanges the timing of DHCPv6 transmission and
uses Solicit when Confirm would be appropriate.

In section 2.5, if assumption 1 does not hold, a host may make an
incorrect determination of which link it has attached to.

In section 4, the second paragraph describes reattaching to the same
link, while Simple DNA determines whether the host has reattached to
*any* link to which it has previously been attached.

In section 4.5.2, is there any difference between this RS message
contents and the RS message contents specified in RFC 4861?  If there
is no difference, just reference the appropriate section of RFC 4861.

There should be some text somewhere about when info is cached in the
SDAT and when info is flushed from the SDAT.

[Ballot discuss]
Discuss-discuss: I'm inclined to agree with Tim that this document
updates RFC 4861.  In addition to the change Tim noted, this document
also specifies fast transmission of an RS without the initial delay
specified in section 6.3.7 of RFC 4861.  Similarly, this document
calls for the transmission of an initial DHCPv6 message without the
initial delay specified in section 17.1.2 of RFC 3315.  The document
also modifies the retransmission rules for several messages.  And,
although I hate to raise this issue, this document suggests that
a DHCPv6 transaction is initiated before the hsot has seen the M/O
bits in an RA.

In section 4.1, I think each table entry should include:

  o  Link-local IPv6 address of the router that advertised the prefix.

  o  Link-layer (MAC) address of the router that advertised the prefix.

  o  One or more IPv6 addresses; for each address include:
      * flag to indicate whether the address was obtained through
        SLAAC or DHCPv6
      * preferred lifetime
      * valid lifetime
      * other configuration information if address was obtained
        through DHCPv6:
        - DUID
        - IA_ID
        - flag indicating IA_NA/IA_TA
        - other configuration information (DNS recursive servers, NTP
          servers, etc.)

  o One or more prefixes assigned to the link
      * preferred lifetime
      * valid lifetime
      * on-link flag

In section 4.2:

  o  Sending of neighbor discovery or DHCPv6 probes

is incorrect ("or").  The host always sends NS probes and RS requests;
it *may* send a DHCPv6 confirmation early as an optimization.

In section 4.4:

  For the purpose of sending neighbor solicitations to previous
  routers, the host first identifies the set of operable IPv6 addresses
  (candidate set) that it wishes to use.  If the addresses obtained
  from a previous router are no longer valid, the host does not include
  these addresses in the candidate set for NS based probing.

s/operable/valid/  At this point, the host does not know what link it
is attached to, so it cannot determine which addresses are operable.
Also, the second sentence in this paragraph is redundant assuming the
change to "valid" is made.

More abstractly, I would rewrite this paragraph and the following
paragraph to allow for multiple addresses on an interface:

  For the purpose of sending Neighbor Solicitation messages to
  previous routers, the host first identifies the set of candidate
  routers to probe.  Any router in the SDAT for which there is at
  least one valid address is in the set of candidate routers.

  For each router in the candidate set, the host obtains the
  link-local and MAC addresses of the router from the SDAT.  The host
  then sends a unicast Neighbor Solicitation to the router's
  link-local address.

In the next paragraph, make "Router Solicitations" singular.  The
first paragraph in this section has a MUST requirement that the host
only send one Router Solicitation.

In section 4.5.1, I am baffled by the last paragraph.  No DHCPv6
address is used anywhere else in the probe NS message and I can think
of no reason why "The probing node SHOULD include a Source link-layer
address option in the probe messages if the address was obtained using
DHCPv6".

Section 4.6 is somewhat problematic, in that a host is expected to use
a Confirm message if it already has assigned addresses and a Solicit
message if not.  Thinking about the problem a little, I would suggest
turning the solution around as follows:

* Send a Solicit message
* Compare the addresses in the Advertise message to the addresses in
  the SDAT
* If a match is found, assume connection to the corresponding link;
  otherwise
* Complete the DHCPv6 message exchange with a Request and wait for the
  Reply

Otherwise, the host will need to send a Confirm message for each of
candidate links and a Solicit message in case it is attached to a new
link.

In section 4.7, 2nd para, if the host receives an RA, why wouldn't it just use
the current info in the RA; why would it try to reuse any cached info
from a previous attachment? 

Also in the same para, what does it mean to receive a "DHCPv6 message [...]
which contains prefixes that intersect with those previously
advertised by a known router"?  A DHCPv6 message contains assigned
addresses  and other configuration information, but no prefixes.  I'm
guessing the idea is to use the DHCPv6 response as an optimization, in
case it is received before any NA or RA messages.  If I have that
right, then the check would have to be that the set of addresses in
the DHCPv6 message matches the set of previously assigned addresses
associated with the probed router.

[Ballot comment]
From Yaron's secdir review:

4.1: DUID - is this the host’s DUID or the router's? Per RFC 3315, both have such a value.
4.3: "all currently configured IP addresses" - but only for this physical interface, right?
4.8: why is no DAD performed? Someone else might have joined the network while I was disconnected, and has a duplicate of my address.

[Ballot discuss]
There are three issues that I would like to see addressed before moving to No Objection.

(1) [Note: this is in direct conflict with Russ's discuss!]

Brian Carpenter suggested that the "Updates 4861" be removed in his Gen-ART review.
I believe this document does update 4861.  Specifically Section 6.2.6 of RFC 4861 states:

  In all cases, Router Advertisements sent in response to a Router
  Solicitation MUST be delayed by a random time between 0 and
  MAX_RA_DELAY_TIME seconds.

Section 2.4 of draft-ietf-dna-simple states:

  As a result, in addition to implementing simple DNA, it is desirable
  that routers adopt procedures which allow for fast unicast Router
  Advertisement (RA) messages.

My interpretation of this statement is that a shorter delay is recommended, which would
be an update to 4861.  (Am I misinterpreting this text?)

(2) Assuming my interpretation regarding the update to 4861 is correct, I believe that the
shorter delay has implications for congestion control and for security (specifcally DoS
attacks).  These implications need to be addressed in the document - the latter should be
addressed in the security considerations.

(3) Yaron Sheffer suggested the following addition to the security considerations

  The DNA procedure does not in itself provide positive, secure authentication of the
  router(s) on the network, or authentication of the network itself, as e.g. would be
  provided by mutual authentication at the link layer. Therefore when such assurance
  is not available, the host MUST NOT make any security-sensitive decisions based on
  the DNA procedure. In particular, it MUST NOT decide it has rejoined a network known
  to be physically secure, and proceed to abandon cryptographic protection.

I believe that something along that line would be a sensible addition.

[Ballot comment]
In section 4.4:

4.4.  Sending Neighbor Discovery probes

  When a host receives a link-layer "up" indication, it SHOULD
  immediately send both a Router Solicitation   
                                              ^^^
I think the text "as specified in section 6.3.7 of RFC 4861" should be added here, to confirm that the delay rules should be followed.
===
Also in section 4.4, the text constraining the candidate set to valid addresses is redundantly in both paragraphs; I suggest deleting the first and changing the second to a MUST NOT requirement:

  For the purpose of sending neighbor solicitations to previous
  routers, the host first identifies the set of operable IPv6 addresses
  (candidate set) that it wishes to use.  If the addresses obtained
  from a previous router are no longer valid, the host does not include
  these addresses in the candidate set for NS based probing.

  For each of the addresses in the candidate set, the host looks up the
  SDAT to find out the link-local and MAC addresses of the router that
  advertised the prefix used to form the address.  It then sends an
  unicast Neighbor Solicitations to each router's link-local address it
  obtained from the lookup on the SDAT.  The host SHOULD NOT send
  unicast Neighbor Solicitations to a test node corresponding to an
  IPv6 address that is no longer valid.

And, it would be a little more clear to explicitly explain "IPv6 address for which the valid lifetime has expired".

[Ballot discuss]
n section 4.1, I think the host also has to record the IAID along with the DUID, to make sure the DHCP server associates the SOLICIT with previous DHCPv6 message exchanges with this host.

In section 4.7.1:

  On reception of a Router Advertisement or advertising DHCPv6 message
  (a REPLY or ADVERTISE) which contains prefixes that intersect with
  those previously advertised by a known router, the host utilizes the
  configuration associated with the detected network.

does the DHCPv6 client continue with the DHCPv6 message exchange in the case where an ADVERTISE is received or does it simply terminate and reuse the previous DHCPv6 configuration?

And, what does the host do if it receives a REPLY message indicating it is on a previously visited link but the information in the IA_NA/IA_TA doesn't exactly match the previous information?

[Ballot comment]
In section 4.4:

4.4.  Sending Neighbor Discovery probes

  When a host receives a link-layer "up" indication, it SHOULD
  immediately send both a Router Solicitation
                                              ^^^
I think the text "as specified in section 6.3.7 of RFC 4861" should be added here, to confirm that the delay rules should be followed.

===
Also in section 4.4, the text constraining the candidate set to valid addresses is redundantly in both paragraphs; I suggest deleting the first and changing the second to a MUST NOT requirement:

  For the purpose of sending neighbor solicitations to previous
  routers, the host first identifies the set of operable IPv6 addresses
  (candidate set) that it wishes to use.  If the addresses obtained
  from a previous router are no longer valid, the host does not include
  these addresses in the candidate set for NS based probing.

  For each of the addresses in the candidate set, the host looks up the
  SDAT to find out the link-local and MAC addresses of the router that
  advertised the prefix used to form the address.  It then sends an
  unicast Neighbor Solicitations to each router's link-local address it
  obtained from the lookup on the SDAT.  The host SHOULD NOT send
  unicast Neighbor Solicitations to a test node corresponding to an
  IPv6 address that is no longer valid.

Also, it would be a little more clear to explicitly explain "IPv6 address for which the valid lifetime has expired".

====

[Ballot discuss]
As already reported in the Gen-ART Review by Brian Carpenter, the
  "Updates: 4861" should be removed from the cover page.  This
  specification makes normative references to RFC 4861, it does not
  update it.  An RFC Editor Note seems like a fine solution.

[Ballot comment]
Section 2.2., paragraph 1:
>    The Simple DNA protocol provides substantial benefits in some
>    scenarios and does not provide any benefit at all in certain other
>    scenarios.

  Compared to what?


Section 4.1., paragraph 1:
>    In order to correctly perform the procedure described in this
>    document the host needs to maintain a data structure called the
>    Simple DNA address table (SDAT).  This data structure is maintained
>    by the host on a per interface basis.

  Why per-interface? Can't this be shared among all interfaces?


Section 4.3., paragraph 2:
>    After the indication is received, the host considers all currently
>    configured (non-tentative) IP addresses to be deprecated until the
>    change detection process completes.  It SHOULD also set all Neighbor
>    Cache entries for the routers on its Default Router List to STALE.

  Why SHOULD and not MUST?


Section 4.4., paragraph 1:
>    When a host receives a link-layer "up" indication, it SHOULD
>    immediately send both a Router Solicitation and if it retains at
>    least one valid IPv6 address, one or more unicast Neighbor
>    Solicitations.

  Why not MUST?


Section 4.4., paragraph 4:
>    The host SHOULD NOT send
>    unicast Neighbor Solicitations to a test node corresponding to an
>    IPv6 address that is no longer valid.

  Why not MUST NOT?


Section 4.6., paragraph 3:
>    Where an
>    existing valid address is being tested for operability, this address
>    should be placed in the Identity Association's IAADDR element, and
>    the DUID associated with that address should be copied to the DHCP
>    SOLICIT from the SDAT.

  should -> MUST? (2x)


Section 4.7., paragraph 2:
>    On reception of a Router Advertisement or advertising DHCPv6 message
>    (a REPLY or ADVERTISE) which contains prefixes that intersect with
>    those previously advertised by a known router, the host utilizes the
>    configuration associated with the detected network.

  What exactly does "intersect" mean? Do you mean "all prefixes returned
  must match the prefixes in the SDAT associated with a router" or "at
  least one returned prefix must match one of the prefixes associated
  with a router in the SDAT?"


Section 4.7., paragraph 3:
>    When the host receives an advertisement containing only prefixes
>    which are disjoint from known advertised prefixes, the host MUST
>    determine whether the solicited advertisement corresponds to any of
>    the routers probed via NS.

  Do you mean "disjoint" as in "doesn't match *any* of the prefixes
  associated with *any* router in the SDAT?


Section 4.7., paragraph 4:
>    If it does, then the host SHOULD conclude
>    that the IPv6 addresses corresponding to that router are no longer
>    valid.  Since any NS probes to that router will no longer provide
>    useful information, further probing of that router SHOULD be aborted.

  I think these need to be MUSTs, or else explain when it wouldn't be.


Section 4.7., paragraph 6:
>    When the host receives a Router Advertisement in reply to the Router
>    Solicitation it sent, the host SHOULD look for a Neighbor Cache entry
>    for the sending router and SHOULD mark that router's Neighbor Cache
>    Entry as REACHABLE if one was found.  The host SHOULD add a new
>    Neighbor Cache Entry in the REACHABLE state for the sending router if
>    one does not currently exist.

  I think all of the SHOULDs need to be MUSTs.

[Ballot discuss]
DISCUSS: I believe the majority of the SHOULDs in this ID should
  become MUSTs. Some examples below. Please check them all.


Section 2.4., paragraph 1:
>    Detecting Network Attachment is performed by hosts after detecting a
>    link-layer "up" indication.  The host simultaneously sends multicast
>    Router Solicitations (RSs) and unicast Neighbor Solicitations (NSs)
>    in order to determine whether previously encountered routers are
>    present on the link.

  DISCUSS: Section 4.9 has appropriate text on handling retransmissions
  of a single probe. What I'm missing is some text that recommends an
  upper bound for how many previous networks should be probed for.
  Clearly, probing for hundreds of previously known networks will
  results in thousands of packets that will all be sent without any sort
  of congestion control, which would be a problem. Similarly, probing
  for a small number of previously known networks will be fine. Can we
  add a recommendation that says that you should limit yourself to
  probing for at most X (10?) previous network locations?

[Ballot discuss]
The OPS-DIR review performed by Bernard Aboba raised a number of technical and editorial issues that need to be answered before approving this document. Moreover, it states that the version of the document sent to IETF last call (now in IESG review) does not incorporate fixes to issues listed in the WG issue tracker as "fixed".  This raises the possibility that changes from WG last call were not properly applied or even that the wrong version of the document may have been sent to IETF last call.

[Ballot discuss]
The OPS-DIR review oerformed by Bernard Aboba raised a number of technical and editorial issues that need to be answered before approving this document. Moreover, it states that the version of the document sent to IETF last call (now in IESG review) does not incorporate fixes to issues listed in the WG issue tracker as "fixed".  This raises the possibility that changes from WG last call were not properly applied or even that the wrong version of the document may have been sent to IETF last call.

I have reviewed this draft. Overall, the draft was easy to read and well written. I have no problem with the specified algorithms. However, the draft appears to contain a fair amount of extra material on Fast RAs and the full-blown dna-protocol that WG worked earlier on. These need to be removed; the specification can and should stand on its own, and not depend on these other components. In addition, there are a few small technical issues.

Here are my specific comments:

Substantial:

> The probing node SHOULD include a Source link-layer address option in the probe messages.  If the node believes that the source address of the NS may not be unique on the newly attached link, it MAY omit the Source link-layer address option in the probe messages.

I would like to understand this better.  How does a general purpose operating system implementation deal with the above? How does it know that "the source address of the NS may not be unique"?

AFAICT, if you omit the SLLA and no link change happened, then most likely the router will remember your NC anyway, and be able to respond. However, if it does not remember you, a new NS/NA would be required, but DNA would still succeed, albeit a bit slower.

However, if the host did move to a new link, then including the SLLA might cause disruption for another host that already holds the same address but uses a different link layer address.

Why is the recommendation written as it is above? Is the assumption that colliding addresses are so rare that the optimization makes sense? On the other hand, it would appear that even without the SLLA DNA would still work in most cases.

In any case, I don't think we can require general purpose implementations to assess the likelihood of collisions. Perhaps it would be easier to require that by default, no SLLA is included and that only through specific configuration option the SLLA use can be turned on and DNA made to operate faster/more reliably.

>    For the purpose of sending neighbor solicitations to previous
>    routers, the host first needs to pick a subset of operable IPv6
>    addresses (candidate set) that it wishes to use.  How this subset of
>    addresses is picked is based on host configuration. e.g.  The host
>    may select configured addresses from each of zero, one or two
>    previously connected links.

Please specify a default strategy. E.g., "How this subset of addresses is picked is based on host configuration. By default the host should select configured addresses from two previously connected links."

> Where flooding may cause performance issues within the LAN, host SHOULD limit the number of unicast solicitations.

Again, the guidance for general purpose implementations in inadequate. Please specify a default strategy. I believe limiting the number of unicast solicitations to some small number (4?) by default is adequate (there are a number of messages on a new link even on DNAv4 and regular ND).

>    The probing node SHOULD NOT include a Source link-layer address
>    option if it has not performed duplicate address detection [RFC4862],
>    for the source address of the NS, on the newly attached link.
>

Performed DAD, when? Presumably it has been performed when the address first configured, no? And since DNA is the first thing that runs after a link change, DAD has not been run at this point either. So what does your recommendation really mean here? Never include SLLA?

In any case, at this point we do not yet *know* if we are on a newly attached link or not. Therefore, we do not know if we've run DAD in the past on this link.

Please clarify.

>    Hosts checking their network attachment are unsure of their address
>    status, and may be using Tentative link-layer addressing information
>    in their router or neighbour solicitations.
>
>    A router which desires to support hosts' DNA operations MUST process
>    Tentative Options from unicast source addressed Router and Neighbour
>    Solicitations, as described in [I-D.ietf-dna-tentative].

This is the first time dna-tentative is referenced in this document. I wonder if there's really a need to have a normative reference, or even mention this.

> 7. Constants
>
>
>    These constants are described as in [I-D.ietf-dna-protocol].
>
>      UNICAST_RA_INTERVAL
>
>          Definition: The interval corresponding to the maximum average
>          rate of Router Solicitations that the router is prepared to
>          service with unicast responses.  This is the interval at which
>          the token bucket controlling the unicast responses is
>          replenished.
>
>          Value: 50 milliseconds
>
>      MAX_UNICAST_RA_BURST
>
>          Definition: The maximum size burst of Router Solicitations that
>          the router is prepared to service with unicast responses.  This
>          is the maximum number of tokens allowed in the token bucket
>          controlling the unicast responses.
>
>          Value: 20
>

None of these appear to have anything to do with the Simple DNA procedure. Please remove. The only item that I can see be of relevance in this section is SEND_NA_GRACE_TIME.

>    When providing fast responses to router solicitations, it is possible
>    to cause collisions with other signaling packets on contention based
>    media.  This can cause repeated packet loss or delay when multiple
>    routers are present on the link.
>
>    As such the fast router advertisement system is NOT RECOMMENDED in
>    this form for media which are susceptible to collision loss.  Such
>    environments may be better served using the procedures defined in
>    [I-D.ietf-dna-protocol].

This does not appear to have anything to do with Simple DNA either (router-side fast responses are not a subject of this specification). Delete?

>    The host MAY delay SEND_NA_GRACE_TIME after transmission before
>    adopting a new default router, if it is operating on a network where
>    there is significant threat of RA spoofing.

I would simply say that this delay MAY be imposed when the host's current default router is a SEND-secured one. This prevents the downgrade from SEND to non-SEND, but does not require any configuration, and it doesn't slow things down when you were already using a non-SEND router.

>    It is easy for hosts soliciting without SEND to deplete a SEND
>    router's fast advertisement token buckets, and consume additional
>    bandwidth.  As such, a router MAY choose to preserve a portion of
>    their token bucket to serve solicitations with SEND signatures.

Again, this has very little to do with this specification. Move this to the fast RA spec instead.

Editorial:

Move draft-ietf-dna-protocol to informative references.

> After the indication is received, the host considers all currently configured (non-tentative) IP addresses to as deprecated until the change detection process completes.

s/to as/to be/

> addresses is picked is based on host configuration. e.g.  The host

s/The/the/

> If systems do not meet these assumptions or if systems seek deterministic change detection operations they are directed to follow the complete dna procedure as defined in [I-D.ietf-dna-protocol].
I would just delete this. I do not think we want to make what sounds like a fairly strong recommendation.

Section 4.5.1 mentions that there are no options, while Setion 4.5.2 does not.

>    message contains an Identity Addociation for either a Temporary
Association?

Title : Simple procedures for Detecting Network Attachment in IPv6
Filename: draft-ietf-dna-simple-06.txt

PROTO Information
=================

Technical Summary
=================

Working Group Summary
=====================
The dna working group reached consensus on this document during the face
to face meetings and on the DNA mailing list. There was strong support
for the document from key contributors to the WG and no opposition.

Protocol Quality
================
This document and has been reviewed by the dna working group and the
required changes have been incorporated into the document.

PROTO Questionnare
==================

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?
-> Yes.

1.b) 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?
-> Yes. There have been no comments from the 6man working group list,
and since this is an update to neighbor discovery (RFC4861), this is
concerning.

1.c) 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.

1.d) 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 have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.
-> No.

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?
-> Strong support from key contributors to the WG and no opposition from
the WG members at large.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.
-> No.

1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).
-> Yes.

1.h) Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)
-> The document is split into normative and informative references.
There are no normative references to IDs, which are not ready for
advancement.