[DNA] Review of draft-krishnan-dna-simple-01.txt

Section 2

[BA] I would rewrite this section to state the goals in a more positive light. For example,

you might talk about the goals of DNAv6 and the implications of its being an

optimization (e.g. focus on the common case, desire to work with existing routers).

I would also include within this section a statement that DNAv6 optimizations work

regardless of whether stateless or stateful addressing is supported on a given network.

Section 2.1

   Routers adopt procedures which allow for fast unicast Router
   Advertisement (RA) messages. Routers that follow the standard
   neighbor discovery procedure described in [2] will delay the router
   advertisement by a random period between 0 and MAX_RA_DELAY_TIME
   (defined to be 500ms) as described in Section 6.2.6 of [2]. This
   delay can be significant and may result in service disruption.

[BA] To be clear, I don't believe that support for fast unicast RA is a pre-requisite for

the optimizations discussed in this document to work. For example, if NS/ND

completes prior to receipt of an RA, the network can still be identified.

   The host detects that the link-layer may have changed, and then
   probes the network with Router Solicitations (RSs) and Neighbour
   Solicitations (NSs).

[BA] I would say "simultaneously probes".

Section 2.2

   o All the prefixes advertised on the link need to fit into a single
      RA. This implies that the number of prefixes on the link needs to
      be limited. e.g. 15 prefixes per link. If all the prefixes on the
      link do not fit into a single RA, the prefixes that are left out
      of the first RA will be advertised in another RA. A host
      receiving such an RA from another router on the link will
      incorrectly assume that it has changed links.

   o All routers on the link advertise the same subnet prefixes.

   o The number of advertising routers on the link needs to be limited
      to the number defined in MAX_ROUTERS_FOR_SIMPLE_DNA.

[BA] I think there is an implicit assumption here that needs further discussion.

If NS/ND completes and identifies a network, I'd assume that receipt of a

single RA without the expected prefix would not be sufficient for the host

to conclude that the identification was wrong. The host would wait until

it concluded that no RAs with the expected prefix are forthcoming. If so,

are these limitations still operative?

   If these assumptions do not hold, host change detection systems will
   not function optimally. In that case, they may occasionally detect
   change spuriously, or experience some delay in detecting network
   attachment. The delays so experienced will be no longer than those
   caused by following the standard neighbor discovery procedure
   described in [2].

[BA] As noted above, I'm not clear that spurious change identification need

necessarily occur in these cases. It also bring up the question of the

overall assumptions underlying DNAv6. For example, do we have an

understanding of whether DNAv6 shares the objectives of DNAv4 as

expressed in RFC 4436 Section 1.1? To rephrase in DNAv6 terminology:

"The applicability of DNAv6 lead us to a number of conclusions:

      o DNAv6 is a performance optimization. Its purpose is to speed
         up a process that may require as much as a few hundred
         milliseconds (RS/RA, DHCPv6), as well as to reduce multi-
         second conflict detection delays when a host changes networks.

      o As a performance optimization, it must not sacrifice
         correctness. In other words, false positives are not
         acceptable. DNAv6 must not conclude that a host has returned
         to a previously visited link where it has an operable IPv6
         address if this is not in fact the case.

      o As a performance optimization, false negatives are acceptable.
         It is not an absolute requirement that this optimization
         correctly recognize a previously visited link in all possible
         cases.

      o As a performance optimization, where DNAv6 fails to provide a
         benefit, it should add little or no delay compared to today's
         processing. In practice, this implies that RS/RA
         processing needs to proceed in parallel. Waiting for DNAv6 to
         fail before beginning RS/RA processing can increase
         total processing time, the opposite of the desired effect.

      o Trials are inexpensive. DNAv6 performs its checks using small
         unicast NS packets. This means that the
         cost of an unsuccessful attempt is small, whereas the cost of a
         missed opportunity (having the right address available as a
         candidate and choosing not to try it for some reason) is large.
         As a result, the best strategy is often to try all available
         candidate configurations, rather than try to determine which
         candidates, if any, may be correct for this link, based on
         heuristics or hints. For a heuristic to offer the prospect of
         being a potentially useful way to eliminate inappropriate
         configurations from the candidate list, that heuristic has to
         (a) be fast and inexpensive to compute, as compared to sending
         a small unicast packet, and (b) have high probability of not
         falsely eliminating a candidate configuration that could be
         found to be the correct one.

     o Time is limited. If DNAv6 is to be effective in enabling low
         latency handoffs, it needs to complete in less than 10 ms.
         This implies that any heuristic used to eliminate candidate
         configurations needs to take at most a few milliseconds to
         compute. This does not leave much room for heuristics based on
         observation of link-layer or Internet-layer traffic."

Section 3

   The steps involved in basic detection of network attachment are:

   o Link-Layer Indication

   o Optimistic DAD

   o Router Solicitation

   o Neighbour Solicitations to prior router(s)

   o Response gathering and assessment

[BA] This list (and the sections that follow) are confusing because they don't describe the

precise order in which the actions occur. For example, router solicitations and neighbor

solicitations are sent simultaneously, but this is not obvious on reading Sections 3.3

and 3.4. I would add something like the following text to this Section:

"   For each network that it connects to, it is assumed that the host
   saves the following parameters to stable storage:

   [1] The IPv6 and MAC address of one or more test nodes on the
       network.

   [2] The IPv6 configuration parameters, including the IPv6 address and

expiration time, and DHCPv6 DUID (if DHCPv6 was used).

   From the set of networks that have operable IPv6 addresses associated
   with them, the host selects a subset and attempts to confirm the
   configuration for each network. "

Section 3.3

3.3. Router Solicitation

   The primary mechanism used to detect network attachment in IPv6 is
   router solicitation and advertisement. When a host receives a link-
   layer indication, it SHOULD immediately send a Router Solicitation to
   the All-routers address containing one of the host's optimistic
   unicast source address [2][5].

[BA] I would rewrite this as follows:

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

Solicitation is sent to the All-routers multicast address containing

one of the host's optimistic unicast source address [2][5]."

[BA] Question: If the host is in possession of more than one valid IPv6 address, which one

should it use? Should it send more than one RS with each valid IPv6 address?

Section 3.4

[BA] As written, this section is not very useful. I would suggest replacing it with the

following:

"Based on the subset of operable IPv6 addresses that the host selects, it sends

unicast Neighbor Solicitations to each of the corresponding test nodes [2][5].

The host SHOULD NOT send unicast Neighbor Solicitations to a test node

corresponding to an IPv6 address that is no longer valid."

[BA] Do we need to provide more detail on what the unicast NS should contain?

Section 3.5

The Simple IPv6 DNA assessment on the host relies upon tying
advertised prefixes to the advertising routers.

[BA] This is not really accurate given the use of NS/ND. I would delete this

sentence.

   Reception of an
   advertisement from a router which is known to advertise a prefix can
   be used to indicate that the node has reconnected to a link it was
   previously connected to.

   Where a responding Neighbour Advertisement is received from a
   previously configured router, the host MUST verify if the hardware
   address of the router matches the one that was previously known. If
   it does, the host can decide that it hasn't changed networks, and MAY
   continue to use the link configuration information (prefixes, MTU
   etc.) with high probability.

   Reception of a Router Advertisement which contains prefixes which
   intersect with those previously advertised by a known router
   indicates that the host has returned to that link with high
   likelihood.In this case the host can decide that it hasn't changed
   networks, and MAY continue to use the existing prefixes with high
   probability.

   Additionally, where a host receives a solicited router advertisement
   after sending an RS for the purpose of detecting network attachment,
   and this prefix contains only prefixes which are disjoint from known
   advertised prefixes, the host SHOULD conclude with high probability
   that it has moved to a different link.

[BA] I would change this to the following:

" Where a responding Neighbour Advertisement is received from a
test node, the host MUST verify that both the IPv6 and link layer

   addresses of the test node match the expected values before utilizing the
   configuration associated with the detected network (prefixes, MTU
   etc.).

   On reception of a Router Advertisement which contains prefixes which
   intersect with those previously advertised by a known router, the host

utilizes the configuration associated with the detected network.

If after sending an RS, a host receives a solicited router advertisement

containing only prefixes which are disjoint from known advertised prefixes,

the host SHOULD conclude that none of its operable IPv6 addresses are

valid and that it has moved to a new link.

Where the conclusions obtained from the Neighbor Solicitation/Advertisement and the

RS/RA exchange differ, the RS/RA (and potentially a subsequent DHCPv6 exchange)

will be considered definitive."

Section 3.6.2

3.6.2. Actions upon arrival at a new link

   Upon arrival on a new link, the host should unconfigure its existing
   addresses and routers, and begin address configuration techniques, as
   indicated in the received Router Advertisement [2][8].

   The host SHOULD keep information about prefixes advertised by routers
   from the prior link, for the purposes of subsequent change detection
   operations.

[BA] The last sentence belongs much earlier in the document (see comments on Section 3).

Section 4

   Routers wishing to support host change detection need to provide them
   with quick responses to queries. Basic support for DNA for IPv6
   requires two basic operations.

   These procedures allow for a host to receive immediate response to a
   router solicitation, and may simplify a host's internal change
   detection operations.

   The simple IPv6 DNA router components are:

   1. Tentative Option processing

   2. Fast Unicast Response to Solicitation with Token Buckets

   These are described in the following sections.