Simple Procedures for Detecting Network Attachment in IPv6
draft-ietf-dna-simple-17

  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.

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.

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.