From dna-owner@webcamserver.eng.monash.edu.au Fri Dec 07 17:03:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lHi-0004Ov-RN for dna-archive@lists.ietf.org; Fri, 07 Dec 2007 17:03:02 -0500 Received: from kenny.its.monash.edu.au ([130.194.13.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0lHe-000736-OH for dna-archive@lists.ietf.org; Fri, 07 Dec 2007 17:03:02 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JSP00EW098TR5K0@kenny.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 08 Dec 2007 09:02:54 +1100 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 327C4AB542; Sat, 08 Dec 2007 09:02:53 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id D05FE4FB07; Sat, 08 Dec 2007 09:02:50 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id lB7LwsU08747 for dna-list; Sat, 08 Dec 2007 08:58:54 +1100 Received: from kyle.its.monash.edu.au (kyle.its.monash.edu.au [130.194.13.163]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id lB7LwrF08743 for ; Sat, 08 Dec 2007 08:58:53 +1100 Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JSP00F013RDYE00@kyle.its.monash.edu.au> (original mail from bernard_aboba@hotmail.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sat, 08 Dec 2007 08:58:54 +1100 (EST) Received: from larry.its.monash.edu.au ([130.194.13.82]) by kyle.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JSP00711921D4K0@kyle.its.monash.edu.au> for dna@eng.monash.edu.au; Sat, 08 Dec 2007 08:58:54 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 3A87B80003; Sat, 08 Dec 2007 08:58:54 +1100 (EST) Received: from bay0-omc2-s13.bay0.hotmail.com (bay0-omc2-s13.bay0.hotmail.com [65.54.246.149]) by larry.its.monash.edu.au (Postfix) with ESMTP id E0ED93C007; Sat, 08 Dec 2007 08:58:48 +1100 (EST) Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 07 Dec 2007 13:58:46 -0800 Date: Fri, 07 Dec 2007 13:58:42 -0800 From: Bernard_Aboba@hotmail.com Subject: [DNA] Review of draft-krishnan-dna-simple-01.txt X-Originating-IP: [130.129.20.161] Sender: owner-dna@ecselists.eng.monash.edu.au To: dna@eng.monash.edu.au, suresh.krishnan@ericsson.com, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V12.0.1606 X-Mailer: Microsoft Windows Live Mail 12.0.1606 Content-type: multipart/alternative; boundary="----=_NextPart_000_0097_01C838D9.470C5B70" Importance: Normal X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-Originating-Email: [bernard_aboba@hotmail.com] X-OriginalArrivalTime: 07 Dec 2007 21:58:46.0630 (UTC) FILETIME=[57489060:01C8391C] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 51ff531286660f8b04ab529f52c08327 This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C838D9.470C5B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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).=20 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.=20 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. =20 [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.=20 The host detects that the link-layer may have changed, and then probes the network with Router Solicitations (RSs) and Neighbour Solicitations (NSs).=20 [BA] I would say "simultaneously probes".=20 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.=20 If NS/ND completes and identifies a network, I'd assume that receipt of = a=20 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=20 it concluded that no RAs with the expected prefix are forthcoming. If = so, are these limitations still operative?=20 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. =20 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).=20 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]. =20 [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=20 Solicitation is sent to the All-routers multicast address containing=20 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?=20 Section 3.4 [BA] As written, this section is not very useful. I would suggest = replacing it with the=20 following:=20 "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].=20 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?=20 Section 3.5 The Simple IPv6 DNA assessment on the host relies upon tying advertised prefixes to the advertising routers. =20 [BA] This is not really accurate given the use of NS/ND. I would = delete this sentence.=20 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=20 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.=20 If after sending an RS, a host receives a solicited router = advertisement=20 containing only prefixes which are disjoint from known advertised = prefixes,=20 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."=20 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. =20 [BA] The last sentence belongs much earlier in the document (see = comments on Section 3).=20 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:=20 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=20 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.=20 What is more important, and what the document does not mention,=20 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.=20 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=20 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=20 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." =20 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. ------=_NextPart_000_0097_01C838D9.470C5B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Section 2
 
[BA] I would rewrite this section to = state the=20 goals in a more positive light.  For example,
you might talk about the goals of DNAv6 = and the=20 implications of its being an
optimization (e.g. focus on the common = case, desire=20 to work with existing routers).
 
I would also include within this = section a=20 statement that DNAv6 optimizations work
regardless of whether stateless or = stateful=20 addressing is supported on a given network.
 
Section 2.1

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

 
[BA] To be clear, I don't believe that = support for=20 fast unicast RA is a pre-requisite for
the optimizations discussed in this = document to=20 work.  For example, if NS/ND
completes prior to receipt of an RA, = the network=20 can still be identified.
 
   The host detects that the link-layer = may have=20 changed, and then
   probes the network with Router = Solicitations=20 (RSs) and Neighbour
   Solicitations = (NSs). 
 
[BA] I would say "simultaneously probes". =
 
 Section = 2.2
 

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

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

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

[BA] I think there = is an=20 implicit assumption here that needs further discussion. =
If NS/ND completes and identifies = a=20 network, I'd assume that receipt=20 of a
single RA without the expected = prefix would=20 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=20 so,
are these limitations still operative?=20
 
   If these assumptions do not hold, host = change=20 detection systems will
   not function optimally.  In = that=20 case, they may occasionally detect
   change spuriously, or = experience some delay in detecting network
   = attachment.  The=20 delays so experienced will be no longer than those
   = caused by=20 following the standard neighbor discovery procedure
   = described in=20 [2].
 
[BA] As noted above, I'm not clear that = spurious=20 change identification need
necessarily occur in these cases.  = It also=20 bring up the question of the
overall assumptions underlying = DNAv6.  For=20 example, do we have an
understanding of whether DNAv6 shares = the=20 objectives of DNAv4 as
expressed in RFC 4436 Section = 1.1?  To=20 rephrase in DNAv6 terminology:
 
"The applicability of DNAv6 lead us to a number of=20 conclusions:

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

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

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

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

     =20 o  Trials are inexpensive.  DNAv6 performs its checks using=20 small
         unicast NS=20 packets.  This means that=20 the
         cost of an = unsuccessful=20 attempt is small, whereas the cost of=20 a
         missed opportunity = (having=20 the right address available as=20 a
         candidate and = choosing not=20 to try it for some reason) is=20 large.
         As a result, = the best=20 strategy is often to try all=20 available
         candidate=20 configurations, rather than try to determine=20 which
         candidates, if = any,=20 may be correct for this link, based=20 on
         heuristics or=20 hints.  For a heuristic to offer the prospect=20 of
         being a = potentially=20 useful way to eliminate=20 inappropriate
         = configurations=20 from the candidate list, that heuristic has=20 to
         (a) be fast and=20 inexpensive to compute, as compared to=20 sending
         a small = unicast=20 packet, and (b) have high probability of=20 not
         falsely = eliminating a=20 candidate configuration that could=20 be
         found to be the = correct=20 one.
     o  Time is = limited.  If=20 DNAv6 is to be effective in enabling=20 low
         latency = handoffs, it=20 needs to complete in less than 10=20 ms.
         This implies = that any=20 heuristic used to eliminate=20 candidate
         = configurations=20 needs to take at most a few milliseconds=20 to
         compute.  = This does=20 not leave much room for heuristics based=20 on
         observation of = link-layer=20 or Internet-layer traffic."

Section=20 3
 
   The steps involved = in basic=20 detection of network attachment are:

   o  = Link-Layer=20 Indication

   o  Optimistic = DAD

  =20 o  Router Solicitation

   o  Neighbour = Solicitations=20 to prior router(s)

   o  Response gathering and=20 assessment
[BA] This list (and the sections that = follow) are=20 confusing because they don't describe the
precise order in which the actions occur.  For = example,=20 router solicitations and neighbor
solicitations are sent simultaneously, but this is = not obvious=20 on reading Sections 3.3
and 3.4.   I would add something like the = following=20 text to this Section:
 
"   For each network that it connects to, = it is=20 assumed that the host
   saves the following parameters to = stable=20 storage:

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

   [2] The IPv6 configuration parameters, = including=20 the IPv6 address and
   expiration time, and DHCPv6 DUID (if = DHCPv6 was=20 used).

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

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

 
[BA] I would rewrite this as follows:

   "When a host receives a link-layer = "up"=20 indication, it SHOULD immediately
   send both a Router Solicitation and if=20 it retains at least one valid IPv6
   address, one or more unicast = Neighbor=20 Solicitations.  The Router
   Solicitation is sent to the All-routers = multicast=20 address containing
   one of the host's optimistic = unicast source=20 address [2][5]."
 
[BA] Question: If the host is in = possession of more=20 than one valid IPv6 address, which one
should it use?   Should it send more than = one RS=20 with each valid IPv6 address?
 
Section 3.4
 
[BA]  As written, this section is not very = useful. =20 I would suggest replacing it with the
following:
 
"Based on the subset of operable IPv6 addresses that = the host=20 selects, it sends
 unicast Neighbor Solicitations to each of the=20 corresponding test nodes [2][5]. 
 The host SHOULD NOT send unicast Neighbor = Solicitations=20 to a test node
 corresponding to an IPv6 address that is no = longer=20 valid."
 
[BA] Do we need to provide more detail on what = the=20 unicast NS should contain?
 
Section 3.5

   The Simple IPv6 DNA = assessment=20 on the host relies upon tying
   advertised prefixes to the = advertising routers. 
 
[BA] This is not really accurate given the use of=20 NS/ND.   I would delete this
sentence.
 
   Reception of an
   = advertisement=20 from a router which is known to advertise a prefix can
   = be used=20 to indicate that the node has reconnected to a link it = was
  =20 previously connected to.

   Where a responding = Neighbour=20 Advertisement is received from a
   previously configured = router,=20 the host MUST verify if the hardware
   address of the = router=20 matches the one that was previously known.  If
   it = does, the=20 host can decide that it hasn't changed networks, and MAY
   = continue to use the link configuration information (prefixes,=20 MTU
   etc.) with high probability.
 
   Reception of a Router Advertisement = which=20 contains prefixes which
   intersect with those previously=20 advertised by a known router
   indicates that the host has = returned to that link with high
   likelihood.In this case = the host=20 can decide that it hasn't changed
   networks, and MAY = continue to=20 use the existing prefixes with high
  =20 probability.

   Additionally, where a host receives a = solicited=20 router advertisement
   after sending an RS for the purpose = of=20 detecting network attachment,
   and this prefix contains = only=20 prefixes which are disjoint from known
   advertised = prefixes, the=20 host SHOULD conclude with high probability
   that it has = moved to=20 a different link.
 
[BA] I would change this to the = following:
 
"  Where a responding Neighbour = Advertisement is=20 received from a
   test node, the host MUST = verify that both=20 the IPv6 and link layer 
   addresses of the test = node match the=20 expected values before utilizing=20 the
   configuration associated with the detected = network (prefixes, MTU
   etc.).

   On reception of a = Router=20 Advertisement which contains prefixes which
   intersect = with those=20 previously advertised by a known router, the host
   utilizes the configuration = associated=20 with the detected network. 

   If after sending an RS, a host receives = a=20 solicited router advertisement
   containing only prefixes = which are=20 disjoint from known advertised prefixes,
   the host SHOULD conclude = that none of=20 its operable IPv6 addresses are
   valid and that it has = moved to a new=20 link.
 
   Where the conclusions = obtained from=20 the Neighbor Solicitation/Advertisement and the
   RS/RA exchange differ, the = RS/RA (and=20 potentially a subsequent DHCPv6 exchange)
   will be considered = definitive."=20
 
Section 3.6.2
 
3.6.2.  Actions upon arrival at a = new=20 link

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

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

 
[BA] The last sentence belongs much = earlier in the=20 document (see comments on Section 3).
 
Section 4
 
   Routers wishing to support host change = detection=20 need to provide them
   with quick responses to = queries. =20 Basic support for DNA for IPv6
   requires two basic=20 operations.

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

  =20 The simple IPv6 DNA router components are:

   1. =20 Tentative Option processing

   2.  Fast Unicast = Response=20 to Solicitation with Token Buckets

   These are = described in=20 the following sections.
 
[BA] Recommend rewriting as=20 follows:
 
"   Routers wishing to = support host=20 change detection need to respond
   quickly to=20 queries.  Basic support for DNA for IPv6 requires: =
 
   1.  Tentative = Option=20 processing

   2.  Fast Unicast Response to = Solicitation=20 with Token Buckets

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

Section 6
 
   Rate limitation for=20 solicitations.

         = In some=20 circumstances, the rate of transmissions=20 for
         solicitations = may need=20 to be restricted or limited. =20 This
         depends highly = upon the=20 movement pattern and quality of=20 link-
         layer=20 indications.  Hysteresis mechanisms which slow or=20 prevent
         solicitation = operations may be necessary to prevent damage=20 to
         the local network = environment.
         = Particularly,=20 transmission of unicast solicitations may=20 cause
         packet = flooding across=20 a bridged network if received on=20 a
         network where the=20 link-layer unicast destination is unknown.
 
         = This=20 shouldn't cause wireless link utilization, where=20 base
         stations = maintain state=20 about attached subscribers.
 
[BA] "Flooding" implies high bandwidth = consumption.  This=20 cannot occur
in bridges conforming to IEEE 802.1d, and = implementations=20 that have
exhibited this problem have acknowledged their lack = of=20 standards conformance
and have issued a fix. 
 
What is more important, and what the document does = not=20 mention,
is the recommended retransmission behavior.  Here is some
recommended text on the subject (rephrased = from RFC=20 4436 for DNAv6):
 
"  In situations where DNAv6, RS/RA and = possibly DHCPv6=20 are used on the same link, it
   is possible that the = reachability=20 test will complete successfully,
   and then RS/RA or = DHCPv6 will=20 complete later with a different result.  If this
   = happens,=20 the implementation SHOULD abandon the reachability test
   = results=20 and use the RS/RA or DHCPv6 result instead, unless the address=20 confirmed
   via the reachability test has been manually = assigned.=20

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

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

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

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


 
 


 ------=_NextPart_000_0097_01C838D9.470C5B70-- From dna-owner@webcamserver.eng.monash.edu.au Sun Dec 09 00:15:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1EW8-0001lA-0Y for dna-archive@lists.ietf.org; Sun, 09 Dec 2007 00:15:52 -0500 Received: from cartman.its.monash.edu.au ([130.194.13.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1EW5-0007mH-Nj for dna-archive@lists.ietf.org; Sun, 09 Dec 2007 00:15:51 -0500 Received: from curly.its.monash.edu.au ([130.194.13.87]) by cartman.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JSR00IE8NY93JI0@cartman.its.monash.edu.au> for dna-archive@lists.ietf.org; Sun, 09 Dec 2007 16:15:46 +1100 (EST) Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 066A4AB543; Sun, 09 Dec 2007 16:15:45 +1100 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id E26424FB05; Sun, 09 Dec 2007 16:15:42 +1100 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id lB95BK619437 for dna-list; Sun, 09 Dec 2007 16:11:20 +1100 Received: from stan.its.monash.edu.au (stan.its.monash.edu.au [130.194.13.165]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id lB95BJF19433 for ; Sun, 09 Dec 2007 16:11:19 +1100 Received: from moe.its.monash.edu.au ([130.194.13.88]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) id <0JSR00G01JDZGC00@stan.its.monash.edu.au> (original mail from suresh.krishnan@ericsson.com) for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Sun, 09 Dec 2007 16:11:20 +1100 (EST) Received: from moe.its.monash.edu.au ([130.194.13.88]) by stan.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0JSR004A8NQWENI0@stan.its.monash.edu.au> for dna@eng.monash.edu.au; Sun, 09 Dec 2007 16:11:20 +1100 (EST) Received: by localhost (Postfix, from userid 510) id 174BCAB545; Sun, 09 Dec 2007 16:11:20 +1100 (EST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by moe.its.monash.edu.au (Postfix) with ESMTP id A58C24FB04; Sun, 09 Dec 2007 16:11:15 +1100 (EST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id lB95BAwA029447; Sat, 08 Dec 2007 23:11:10 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 08 Dec 2007 23:11:10 -0600 Date: Sun, 09 Dec 2007 00:09:43 -0500 From: Suresh Krishnan Subject: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt Sender: owner-dna@ecselists.eng.monash.edu.au To: Bernard_Aboba@hotmail.com, dna@eng.monash.edu.au, greg.daley@eng.monash.edu.au, narten@us.ibm.com, erik.nordmark@sun.com, Jari Arkko Message-id: <6D19CA8D71C89C43A057926FE0D4ADAA542EF0@ecamlmw720.eamcs.ericsson.se> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 X-MIME-Autoconverted: from quoted-printable to 8bit by webcamserver.eng.monash.edu.au id lB95BJF19434 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: Review of draft-krishnan-dna-simple-01.txt Thread-index: Acg5HG26UDdBEedzRb+InF3B9fso9ABBUfI/ X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-OriginalArrivalTime: 09 Dec 2007 05:11:10.0531 (UTC) FILETIME=[E9777130:01C83A21] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c 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: Bernard_Aboba@hotmail.com [mailto:Bernard_Aboba@hotmail.com] Sent: Fri 7/12/2007 4:58 PM To: dna@eng.monash.edu.au; Suresh Krishnan; greg.daley@eng.monash.edu.au;= narten@us.ibm.com; erik.nordmark@sun.com; Jari Arkko Subject: Review of draft-krishnan-dna-simple-01.txt =20 Section 2 [BA] I would rewrite this section to state the goals in a more positive l= ight. 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).=20 I would also include within this section a statement that DNAv6 optimizat= ions work regardless of whether stateless or stateful addressing is supported on a = given network.=20 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. =20 [BA] To be clear, I don't believe that support for fast unicast RA is a p= re-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.= =20 The host detects that the link-layer may have changed, and then probes the network with Router Solicitations (RSs) and Neighbour Solicitations (NSs).=20 [BA] I would say "simultaneously probes".=20 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 disc= ussion.=20 If NS/ND completes and identifies a network, I'd assume that receipt of a= =20 single RA without the expected prefix would not be sufficient for the hos= t to conclude that the identification was wrong. The host would wait until= =20 it concluded that no RAs with the expected prefix are forthcoming. If so= , are these limitations still operative?=20 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 ne= ed 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. =20 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 solicitati= ons 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=20 expiration time, and DHCPv6 DUID (if DHCPv6 was used).=20 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]. =20 [BA] I would rewrite this as follows: "When a host receives a link-layer "up" indication, it SHOULD immediat= ely send both a Router Solicitation and if it retains at least one valid I= Pv6 address, one or more unicast Neighbor Solicitations. The Router=20 Solicitation is sent to the All-routers multicast address containing=20 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 a= ddress, which one should it use? Should it send more than one RS with each valid IPv6 add= ress?=20 Section 3.4 [BA] As written, this section is not very useful. I would suggest repla= cing it with the=20 following:=20 "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].=20 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 cont= ain?=20 Section 3.5 The Simple IPv6 DNA assessment on the host relies upon tying advertised prefixes to the advertising routers. =20 [BA] This is not really accurate given the use of NS/ND. I would delete= this sentence.=20 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=20 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.=20 If after sending an RS, a host receives a solicited router advertiseme= nt=20 containing only prefixes which are disjoint from known advertised pref= ixes,=20 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/Advertis= ement and the RS/RA exchange differ, the RS/RA (and potentially a subsequent DHCPv6 = exchange) will be considered definitive."=20 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. =20 [BA] The last sentence belongs much earlier in the document (see comments= on Section 3).=20 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:=20 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=20 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 conforma= nce and have issued a fix.=20 What is more important, and what the document does not mention,=20 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 s= ame 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.=20 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= =20 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 retransm= ission only of Router Solicitations=20 or DHCPv6. In order to reduce competition between unicast Neighbor So= licitations and Router Solicitations and DHCPv6 retransmissions, a DNAv6 implementation that retransmits ma= y 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." =20 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.