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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf