[dna] Review of draft-ietf-dna-simple-09

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 20 October 2009 20:08 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: dna@core3.amsl.com
Delivered-To: dna@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3933A67D8; Tue, 20 Oct 2009 13:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=1.601, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EToSWiFAGMl1; Tue, 20 Oct 2009 13:08:46 -0700 (PDT)
Received: from blu0-omc2-s8.blu0.hotmail.com (blu0-omc2-s8.blu0.hotmail.com [65.55.111.83]) by core3.amsl.com (Postfix) with ESMTP id E4A043A67B3; Tue, 20 Oct 2009 13:08:42 -0700 (PDT)
Received: from BLU137-W17 ([65.55.111.71]) by blu0-omc2-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 13:08:51 -0700
Message-ID: <BLU137-W1789AE9F11D8C0F889105093C00@phx.gbl>
Content-Type: multipart/alternative; boundary="_469e98b6-16d9-49e9-9218-50394412ed0c_"
X-Originating-IP: [70.58.72.16]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <ietf@ietf.org>, <ops-dir@ietf.org>, <dna@ietf.org>
Date: Tue, 20 Oct 2009 13:08:51 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Oct 2009 20:08:51.0614 (UTC) FILETIME=[247C3BE0:01CA51C1]
Subject: [dna] Review of draft-ietf-dna-simple-09
X-BeenThere: dna@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNA working group mailing list <dna.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dna>
List-Post: <mailto:dna@ietf.org>
List-Help: <mailto:dna-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dna>, <mailto:dna-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2009 20:08:49 -0000

Review of draft-ietf-dna-simple-09

I have reviewed draft-ietf-dna-simple.  Overall, I believe this document still
contains significant technical issues that need to be addressed before
it would be suitable for publication as a Proposed Standard.  In particular,
the version of the document sent to IETF last call 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. 

Given the potential problems, a careful check needs to be made of the changes
between -08 and -09 to make sure that resolutions to WG last call and AD 
review comments were properly applied. 

Technical

Abstract

   This document provides simple procedures for detecting network
   attachment in IPv6 hosts, and procedures for routers to support such
   services.

[BA] My understanding was that the goal of Simple DNA was to avoid 
changes to routers.  Given that, what router procedure need to be
specified? 

Section 2.4

2.4. DNA Roles


   Detecting Network Attachment is performed by hosts by sending IPv6
   neighbor discovery and router discovery messages to routers after
   connecting to a network.

   It is desirable that routers adopt procedures which allow for fast
   unicast Router Advertisement (RA) messages.  Routers that follow the
   standard neighbor discovery procedure described in [RFC4861] 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 [RFC4861].  This delay can be significant and may result in
   service disruption.  Please note that support for fast unicast RAs is
   not necessary since the simple dna procedure can continue to work
   using the NS/NA exchange, which will complete earlier than the RA
   arrives.

   The host detects that the link-layer may have changed, and then
   simultaneously probes the network with Router Solicitations (RSs) and
   Neighbor Solicitations (NSs).  The host uses advertisements to
   determine if the routers it currently has configured are still
   available.

   Additionally, on links with no statelessly configured addresses, the
   host may make use of DHCPv6 procedures to identify an operable
   address.

[BA] This paragraph does not describe the situations in which 
RA delays will be significant.  Clarity would be enhanced by
describing this. 

The description of the role of DHCPv6 in this section appears to
conflict with the description in Section 4.6.  Section 4.6 discusses 
use of Neighbor Discovery probing in parallel with DHCPv6 probing, 
implying that RS probing is not used.  This section implies that 
DHCPv6 probing is only done after a combination of RS and NS 
probing does not result in a statelessly configured address.  

Perhaps the best way to explain the interaction is to think of 
simple DNA as independent of DHCPv6.  That is, implementation 
of simple DNA does not change the DHCPv6 state machine or timers;  
implementations continue to send the same DHCPv6 packets in the 
same situations and with the same timing as they did without 
simple DNAv6.  The only new wrinkle is the potential for conflicts
between simple DNA and DHCPv6, in which case the information 
obtained via DHCPv6 wins. 

This is true regardless of whether an implementation waits for an
RA before deciding whether to use DHCPv6, or whether it sends
DHCPv6 packets regardless of the state of the 'M' and 'O' bits
in the RA.  

My suggested text is as follows: 

2.4. DNA Overview

   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. 

   Hosts implementing simple DNA may also send DHCPv6 packets,
   as described in Section 4.6.  Since simple DNA does not
   modify the DHCPv6 protocol or state machine, the operation
   of DHCPv6 is unchanged. 

   Routers that follow the standard neighbor discovery procedure 
   described in [RFC4861] 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 [RFC4861].  Hosts implementing 
   simple DNA can detect the presence of a previously encountered 
   router using unicast Neighbor Solicitations.  As a result, where 
   the host with a valid configuration is returning to a previously 
   encountered link, delays in the sending of a Router Advertisement 
   (RA) will not delay configuration as long as NS probing is
   successful.  However in situations where the host is
   attaching to a link for the first time, or where it does not
   have a valid IP address on the link, it will be dependent
   on the receipt of an RA for stateless auto-configuration.  In
   these situations delays in the receipt of an RA can be significant
   and may result in service disruption. 

   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.

Section 4.5.1

   The probing node SHOULD NOT include the Source link-layer address
   option in the probe messages.

[BA]  In looking through versions of the document, it appears that this text 
changed between -08 and -09, but it is not clear why.  Was this the result
of an editorial error, or was it made in response to the AD review? 
My recommendation is that the -08 text be restored:

   The probing node SHOULD include a Source link-layer address option in
   the probe messages if the address was obtained using DHCPv6 and the
   lease has not expired.  Otherwise the probing node SHOULD NOT include
   the Source link-layer address option in the probe messages.

The existing text is problematic since if the SSLAO is not included, 
then the ND cache on the router will not be seeded, and return reachability 
will not be enabled. This significantly impacts the utility of simple DNA, 
which in the v4 version was able to both configuration configuration and 
establish bi-directional reachability in a single step.  Since the NS is sent
to a unicast MAC and IP address only when the host has a valid IP address,
I don't think there is a danger of cache pollution. 

Section 4.5.2

   The probing node SHOULD include a Source link-layer address option in
   the probe messages if the address was obtained using DHCPv6 and the
   lease has not expired.  Otherwise the probing node SHOULD NOT include
   the Source link-layer address option in the probe messages.

[BA] As listed in Issue #15 (listed as fixed in the tracker),
the text was to be changed to indicate that the SLLAO should not be
included in the Router Advertisement:
See http://webcamserver.eng.monash.edu.au/~warchive/dna/2009-09/msg00003.html

Although this issue was resolved as fixed, the fix does not appear to have 
been applied in the document sent to IETF last call.  Was the correct version 
of the document sent to WG last call? 

The existing text does not make sense because a single router solicitation is
sent, not one for each address.  Since the router solicitation is sent
once via multicast, it is not clear to me how the advice in this paragraph
can be implemented, since until simple DNA is completed, the host cannot know
which address (if any) will turn out to be valid. 

Section 4.6

   Where the host has acquired addresses from DHCPv6 or the host does
   not have a global prefix, it MAY prefer to use DHCPv6 probe messages
   in parallel with the Neighbor Discovery probing.  The DHCPv6 probing
   procedures described in this document do not imply any changes to the
   DHCPv6 protocol or state machine.

[BA] The first sentence appears to imply that DHCPv6 probing is done instead
of sending a multicast RS.  I don't think this is what was intended. 

Rather, I think what this section is trying to communicate is that implementation
of simple DNA is largely orthogonal to DHCPv6.  If a DHCPv6 implementation decides
whether to send DHCPv6 packets based on the contents of the RA, then it will continue
to do that after implementing DNA.  If it sends DHCPv6 packets regardless of the 
contents of the RA, then it will continue to do that.  Since the timing, state
machine and contents of DHCPv6 packets is unaffected, simple DNA continues to 
guarantee that it will "do no harm" with respect to performance, regardless of the
details of the DHCPv6 implementation. 

Here is my recommended rewrite of Section 4.6:

4.6. DHCPv6 operation

   Simple DNA does not require a host to implement DHCPv6, nor does it 
   imply any changes to the DHCPv6 protocol or state machine. 
   Hosts MAY attempt to obtain IPv6 configuration via DHCPv6 
   in parallel with simple DNA probing.  This ensures that the 
   simple DNA procedure will not result in additional delay in 
   the case where reachability tests fail, or where a DHCPv6 exchange 
   completes more quickly than the reachability tests.    

   In situations where both simple DNA and DHCPv6 are used on the same link, 
   it is possible that simple DNA probing will complete successfully,
   and then DHCPv6 will complete later with a different result.  If this
   happens, the procedure described in Section 4.7.1 are utilized. 

   Where the host attempts to obtain IPv6 configuration in parallel with
   simple DNA, on receiving a link-layer "up" indication, it
   sends a DHCPv6 SOLICIT to All_DHCP_Relay_Agents_and_Servers.  This
   message contains an Identity Association for either a Temporary
   Address (IA_TA) or Non-Temporary Address (IA_NA) [RFC3315].  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.

   In order to quickly acquire a new address in the case that link
   change has occurred, this SOLICIT message MAY contain the Rapid-
   Commit option.

   Where the Rapid-Commit option has not been used, a present DHCP
   server will respond with an ADVERTISE message.  The IP address
   contained in the Identity Association (IA_TA or IA_NA) will contain
   an IP Address which is operable for the link.

   Where Rapid-Commit option has been sent, a DHCPv6 server will respond
   with REPLY.  In addition to being operable, this address is allocated
   to the host for the lease duration indicated in the Identity
   Association.

Section 5

It probably should be noted that the pseudo code does not include
sending of DHCPv6 packets, since that is orthogonal to simple DNA. 

Appendix A

Hence agressive retransmissions are mandated.

[BA] "mandated" -> "necessary".

   o  Another issue comes up when the host moves between two networks,
      one where manual addressing is being used (say NET1)and the other
      where dynamic addressing (DHCPv6) is being used (say NET2).  When
      the host moves to NET1 from NET2 it tries to confirm both the
      manual address and the dynamic address in parallel.  If the probe
      for the manually assigned address is lost, the DHCPv6 probe will
      succeed and the host will incorrectly end up using the DHCPv6
      assigned address (from NET2) on NET1.

[BA] Since the manual address is only supposed to be used on NET1, this
     example is not actually a problem -- it is valid for the host to use 
     a DHCPv6 assigned address if it moves from NET1 to NET2.  The problem
     occurs if DHCPv6 is enabled on NET1 and the host ends up using a 
     DHCPv6 (or stateless autoconfig) address instead of a static one 
     when it connects to NET1.  Suggested change:


   o  Another issue comes up when the host moves between two networks,
      one where manual addressing is being used (say NET1)and the other
      where dynamic addressing (stateless autoconfig or DHCPv6) is 
      being used (say NET2).  Since the host can obtain a dynamic address
      in some situations, it will need to send simple DNA probes and
      may also engage in a DHCPv6 exchange.  In a situation where the
      host moves to NET1 and the NS probes are lost and in addition an
      RA is not received, the host will not be able to confirm that it
      attached to NET1, and therefore that it should use the manual
      configuration for that network. As a result, if DHCPv6 is enabled on
      NET1, then the host could mistakenly obtain a dynamic address and
      configuration instead of using the manual configuration.  To 
      prevent this problem, simple DNA probing needs to continue even
      after the DHCPv6 exchange has completed, and DNA probes need to
      take precedence over DHCPv6, contrary to the advice
      provided in Section 4.7.1. 

Editorial

Section 2

   Hosts require procedures to simply and reliably identify if they have
   moved to a different IP network to the one which they have been
   recently connected. 

[BA] "to the one which" -> "than the one to which"

Section 2.1

   The goal of this document is to specify a simple procedure for
   detecting network attachment (Simple DNA) that has the following
   characteristics.

   o  Routers do not have to be modified to support this scheme.

   o  Handle only the simplest and most likely use cases.

   o  Work at least as quickly as standard neighbor discovery.


[BA] The second and third bullets do not have a parallel grammatical
structure.  How about this? 

   The goal of this document is to specify a simple procedure for
   detecting network attachment (Simple DNA) that has the following
   characteristics:

   o  Routers do not have to be modified to support this scheme;

   o  The most common use cases are optimized;

   o  In the worst case, detection latency is equal to that of 
      existing schemes so that performance is never degraded; 
      

Section 4.7.1

   It is possible that the DHCPv6 based probes and the neighbor
   discovery based probes complete with conflicting results.  In this
   case, the host SHOULD use the following rules to determine the final
   result.

   o  If the DHCPv6 exchange was authenticated, use the result from the
      DHCPv6 probe.

   o  If the DHCPv6 exchange was not authenticated and the neighbor
      discovery exchange was protected by SEND [RFC3971], use the result
      from the neighbor discovery probe.

   o  If both the DHCPv6 and neighbor discovery exchanges were not
      authenticated, use the result from the DHCPv6 probe

[BA] The use of the term "DHCPv6 probe" is a bit confusing in that it seems
to imply that DHCPv6 operates differently with simple DNA.  My recommendation
is to eliminate use of this term, as follows:

   It is possible that DHCPv6 exchanges and the neighbor
   discovery based probes complete with conflicting results.  In this
   case, the host SHOULD use the following rules to determine the final
   result:

   o  If the DHCPv6 exchange was authenticated, use the result from
      DHCPv6.

   o  If the DHCPv6 exchange was not authenticated and the neighbor
      discovery exchange was protected by SEND [RFC3971], use the result
      from the neighbor discovery probe.

   o  If both the DHCPv6 and neighbor discovery exchanges were not
      authenticated, use the result from DHCPv6.

Section 4.9

The first paragraph isn't about retransmission, so it might be better to
move it to section 4.7.1.