[dna] next steps on draft-ietf-dna-simple

[Jari Arkko <[e-mail]>]

The IESG reviewed this draft in our meeting yesterday. A number of 
issues were brought up, most of it already resolved but some still 
remain. Here are the changes that I've entered as RFC Editor notes:

1) Updates 4861 issue per Brian Carpenter's review comments:

  Please remove the "Updates 4861" claim from the header.

2) Unclear specification with respect to what the draft requires about 
fast RAs. I believe the current wording referred to draft-ietf-dna-frd. 
Some readers thought our specification was requiring a change from the 
4861 rules that dictate a delay before the RS can go out.

  Please remove the following text from Section 2.4:

  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.

3) An additional security consideration issue was brought in secdir review.

  Please add the following text to the end of the security
  considerations section:

  The DNA procedure does not in itself provide positive, secure 
  authentication of the router(s) on the network, or authentication of
  the network itself, as e.g. would be provided by mutual authentication
  at the link layer. Therefore when such assurance is not available, the
  host MUST NOT make any security-sensitive decisions based on the DNA
  procedure. In particular, it MUST NOT decide it has rejoined a network
  known to be physically secure, and proceed to abandon cryptographic
  protection.

4) Lars Eggert was happy that the draft included retransmission rules, 
but noted that the draft should also set an upper limit on how many 
previous routers are probed.

  Please add the following text to end of Section 4.4:

  A Simple DNA implementation SHOULD limit probing to at most
  six previously seen routers.

Everyone happy with these changes? Also, we have a few remaining issues:

5) Lars asked whether some of the SHOULDs in the document should really 
be MUSTs. In my review this is not universally true at least. For 
instance, you may give some freedom for implementations to avoid sending 
probes if there are too many link up events in a short time period. 
However, we'd like you Suresh go through the document and for each 
SHOULD think about what the right keyword is. Sometimes it might be a 
MUST, sometimes a SHOULD. In some of the cases where its a SHOULD, it 
might be good to include a sentence or two about what issues might be 
considered when implementing it.

6) We need to respond to Ralph Droms' detailed review. (Thank you 
Ralph!) I think we can forget the Updates 4861 part of his discuss, but 
the rest is relevant. I'm including his Discuss here for completeness sake:

This document calls for the transmission of an initial DHCPv6 message 
without the
initial delay specified in section 17.1.2 of RFC 3315.  The document
also modifies the retransmission rules for several messages.  And,
although I hate to raise this issue, this document suggests that
a DHCPv6 transaction is initiated before the hsot has seen the M/O
bits in an RA.

In section 4.1, I think each table entry should include:

  o  Link-local IPv6 address of the router that advertised the prefix.

  o  Link-layer (MAC) address of the router that advertised the prefix.

  o  One or more IPv6 addresses; for each address include:
      * flag to indicate whether the address was obtained through
        SLAAC or DHCPv6
      * preferred lifetime
      * valid lifetime
      * other configuration information if address was obtained
        through DHCPv6:
        - DUID
        - IA_ID
        - flag indicating IA_NA/IA_TA
        - other configuration information (DNS recursive servers, NTP
          servers, etc.)

  o One or more prefixes assigned to the link
      * preferred lifetime
      * valid lifetime
      * on-link flag

In section 4.2:

  o  Sending of neighbor discovery or DHCPv6 probes

is incorrect ("or").  The host always sends NS probes and RS requests;
it *may* send a DHCPv6 confirmation early as an optimization.

In section 4.4:

  For the purpose of sending neighbor solicitations to previous
  routers, the host first identifies the set of operable IPv6 addresses
  (candidate set) that it wishes to use.  If the addresses obtained
  from a previous router are no longer valid, the host does not include
  these addresses in the candidate set for NS based probing.

s/operable/valid/  At this point, the host does not know what link it
is attached to, so it cannot determine which addresses are operable.
Also, the second sentence in this paragraph is redundant assuming the
change to "valid" is made.

More abstractly, I would rewrite this paragraph and the following
paragraph to allow for multiple addresses on an interface:

  For the purpose of sending Neighbor Solicitation messages to
  previous routers, the host first identifies the set of candidate
  routers to probe.  Any router in the SDAT for which there is at
  least one valid address is in the set of candidate routers.

  For each router in the candidate set, the host obtains the
  link-local and MAC addresses of the router from the SDAT.  The host
  then sends a unicast Neighbor Solicitation to the router's
  link-local address.

In the next paragraph, make "Router Solicitations" singular.  The
first paragraph in this section has a MUST requirement that the host
only send one Router Solicitation.

In section 4.5.1, I am baffled by the last paragraph.  No DHCPv6
address is used anywhere else in the probe NS message and I can think
of no reason why "The probing node SHOULD include a Source link-layer
address option in the probe messages if the address was obtained using
DHCPv6".

Section 4.6 is somewhat problematic, in that a host is expected to use
a Confirm message if it already has assigned addresses and a Solicit
message if not.  Thinking about the problem a little, I would suggest
turning the solution around as follows:

* Send a Solicit message
* Compare the addresses in the Advertise message to the addresses in
  the SDAT
* If a match is found, assume connection to the corresponding link;
  otherwise
* Complete the DHCPv6 message exchange with a Request and wait for the
  Reply

Otherwise, the host will need to send a Confirm message for each of
candidate links and a Solicit message in case it is attached to a new
link.

In section 4.7, 2nd para, if the host receives an RA, why wouldn't it 
just use
the current info in the RA; why would it try to reuse any cached info
from a previous attachment?

Also in the same para, what does it mean to receive a "DHCPv6 message [...]
which contains prefixes that intersect with those previously
advertised by a known router"?  A DHCPv6 message contains assigned
addresses  and other configuration information, but no prefixes.  I'm
guessing the idea is to use the DHCPv6 response as an optimization, in
case it is received before any NA or RA messages.  If I have that
right, then the check would have to be that the set of addresses in
the DHCPv6 message matches the set of previously assigned addresses
associated with the probed router.

Comment:
[2009-11-19] The authors should take a pass over the entire document to 
confirm that all descriptions of the purpose of this mechanism is to 
determine if the host has reattached to *any* previously attached link, 
rather than determining if the host has reattached to the link the host 
just left.

For example:

4.  Host Operations

  When a host has an existing configuration for IP address prefixes and
  next hop routing, it may be disconnected from its link-layer, and
  then subsequently reconnect the link-layer on the same interface.

  When the link-layer becomes available again, it is important to
  determine whether the existing addressing and routing configuration
  are still valid.

  In order to determine this, the host performs the detecting network
  attachment procedure.

This document describes more than just detecting change; it describes 
how to find any link the host to which the host might have been 
previously connected.

In the Introduction:

Why do

  "Hosts require procedures to simply and reliably identify if they have
  moved to a different IP network"

I think all of the text in the first paragraph of the introduction is
more or less at odds with the rest of the document.  Moving to a
different IP network is not what this document is about.  The
machinery in this document identifies if a host reattaches to a link
to which it has been previously attached.  It accomplishes that result
by determining if it has reachability to a router it has previously
used as a default router.  If the host determines it has been
previously attached to its current link, it reuses the previously used
addresses and other configuration information.

Similarly, section 2.1 has several goals that mention "link change"
when, in fact, Simple DNA is all about determining link reattachment.

Section 2.2:

  When a host moves to a completely new link that
  is previously unknown, the performance of the Simple DNA protocol
  will be identical to that using standard neighbor discovery
  procedures [RFC4861].

But, section 4.6 suggests initiating DHCPv6 before receiving an RA,
which reduces latency in completing DHCPv6 transaction for address
assignment on a new link.

Section 2.4:

  Since simple DNA does not modify the
  DHCPv6 protocol or state machine, the operation of DHCPv6 is
  unchanged.

Not true.  Simple DNA hanges the timing of DHCPv6 transmission and
uses Solicit when Confirm would be appropriate.

In section 2.5, if assumption 1 does not hold, a host may make an
incorrect determination of which link it has attached to.

In section 4, the second paragraph describes reattaching to the same
link, while Simple DNA determines whether the host has reattached to
*any* link to which it has previously been attached.

In section 4.5.2, is there any difference between this RS message
contents and the RS message contents specified in RFC 4861?  If there
is no difference, just reference the appropriate section of RFC 4861.

There should be some text somewhere about when info is cached in the
SDAT and when info is flushed from the SDAT.