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

[Suresh Krishnan <[e-mail]>]

Hi Bernard,
   Thanks for your comments. Please find responses inline.

On 09-10-20 04:08 PM, Bernard Aboba wrote:
> 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?

This refers to the optional changes to routers for sending out fast 
unicast RAs in section 2.4.

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

Sounds good. Will make this change.

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

I will swap the text regarding SLLAO for 4.5.1 and 4.5.2. Does this work?

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

OK. Will do

> 
> Appendix A
> 
> Hence agressive retransmissions are mandated.
> 
> [BA] "mandated" -> "necessary".

OK.

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

OK.

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

OK.

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

Sounds good.

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

OK.

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

OK.

Thanks
Suresh