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

From: [email-masked]
Date: Fri, 07 Dec 2007 13:58:42 -0800

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

[BA] Recommend rewriting as follows:

"   Routers wishing to support host change detection need to respond
   quickly to queries.  Basic support for DNA for IPv6 requires: 

   1.  Tentative Option processing

   2.  Fast Unicast Response to Solicitation with Token Buckets

   These procedures allow for a host to receive immediate response to a
   router solicitation, and may simplify a host's internal change
   detection operations.  A detailed description is provided in the 
   following sections."

Section 6

   Rate limitation for solicitations.

         In some circumstances, the rate of transmissions for
         solicitations may need to be restricted or limited.  This
         depends highly upon the movement pattern and quality of link-
         layer indications.  Hysteresis mechanisms which slow or prevent
         solicitation operations may be necessary to prevent damage to
         the local network environment.

         Particularly, transmission of unicast solicitations may cause
         packet flooding across a bridged network if received on a
         network where the link-layer unicast destination is unknown.

         This shouldn't cause wireless link utilization, where base
         stations maintain state about attached subscribers.

[BA] "Flooding" implies high bandwidth consumption.  This cannot occur
in bridges conforming to IEEE 802.1d, and implementations that have
exhibited this problem have acknowledged their lack of standards conformance
and have issued a fix. 

What is more important, and what the document does not mention, 
is the recommended retransmission behavior.  Here is some
recommended text on the subject (rephrased from RFC 4436 for DNAv6):

"  In situations where DNAv6, RS/RA and possibly DHCPv6 are used on the same link, it
   is possible that the reachability test will complete successfully,
   and then RS/RA or DHCPv6 will complete later with a different result.  If this
   happens, the implementation SHOULD abandon the reachability test
   results and use the RS/RA or DHCPv6 result instead, unless the address confirmed
   via the reachability test has been manually assigned. 

   Where the reachability test does not return an answer, this is
   typically because the host is not attached to the network whose
   configuration is being tested.  In such circumstances, there is
   typically little value in aggressively retransmitting unicast neighbor 
   solicitations that do not elicit a response.

   Where unicast Neighbor Solicitations and Router Solicitations are sent in parallel, one strategy is to
   forsake retransmission of Neighbor Solicitations and to allow retransmission only of Router Solicitations 
   or DHCPv6.  In order to reduce competition between unicast Neighbor Solicitations and Router Solicitations
   and DHCPv6 retransmissions, a DNAv6 implementation that retransmits may
   utilize the retransmission strategy described in the
   DHCPv6 specification [RFCDHCPv6], scheduling DNAv6 retransmissions
   between Router Solicitation or DHCPv6 retransmissions.

   If a response is received to any unicast Neighbor Solicitation, Router Solicitation or DHCPv6 message,
   pending retransmissions are canceled.  It is RECOMMENDED that a DNAv6
   implementation retransmit a Neighbor Solicitation no more than twice.  To provide damping in
   the case of spurious "Link Up" indications, it is RECOMMENDED that
   the DNAv6 procedure be carried out no more than once a second."  

         Hosts MAY implement hysteresis mechanisms to pace solicitations
         where necessary to prevent damage to a particular medium.
         Implementors should be aware that when such hysteresis is
         triggered, Detecting Network Attachment may be slowed, which
         may affect application traffic.

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 09 Dec 2007 00:09:43 -0500

Hi Bernard,
  Thank you very much for the detailed comments. I will try to get a new revision out that addresses your comments.

Thanks
Suresh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Fri 7/12/2007 4:58 PM
To: [email-masked]; Suresh Krishnan; [email-masked]; [email-masked]; [email-masked]; Jari Arkko
Subject: Review of draft-krishnan-dna-simple-01.txt
 
Section 2

Section 2.1

 Section 2.2

Section 3

   o  Link-Layer Indication

   o  Optimistic DAD

   o  Router Solicitation

Section 3.3

3.3.  Router Solicitation

Section 3.4

Section 3.5

   Reception of an

Section 3.6.2

Section 4

Section 6