Detecting Network Attachment in IPv4 (DNAv4)
draft-ietf-dhc-dna-ipv4-18

[Ballot comment]
Comment/question from Jari Arrko's Mobility Directorate review:

>    [c] If secure detection of network attachment is required.
>        The reachability test utilizes ARP which is insecure.

What, specifically, is your model of "secure detection of network attachment"? How do I implement this requirement in a host i.e. what feature must be on for me to skip DNAv4?
Do you mean that if DHCP authentication is on then we skip DNAv4?

Also, some forms of secure ARP (e.g. Cisco's DHCP-secured
ARP) appear to work without host involvement and would appear to be compatible with DNAv4.

[Ballot comment]
Comment/question from Jari Arrko's Mobility Directorate review:

>    [c] If secure detection of network attachment is required.
>        The reachability test utilizes ARP which is insecure.

What, specifically, is your model of "secure detection of network attachment"? How do I implement this requirement in a host i.e. what feature must be on for me to skip DNAv4?
Do you mean that if DHCP authentication is on then we skip DNAv4?

Also, some forms of secure ARP (e.g. Cisco's DHCP-secured
ARP) appear to work without host involvement and would appear to be compatible with DNAv4.

[Note]: 'This document has changed substantially since the IESG reviewed version -12 based on post-LC comments. Back for a re-review before sending to the RFC Editor.' added by Margaret Wasserman

[Note]: 'This document has changed substantially since the IESG reviewed version -12 based on post-LC comments.  Back for a re-review before sending to the RFC Editor.' added by Margaret Wasserman

[Note]: 'This document has changed substantially since the IESG review version -12 based on post-LC comments.  Back for a re-review before sending to the RFC Editor.' added by Margaret Wasserman

Issues raised by Stuart Cheshire...


Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-13.txt
From: Ralph Droms
To: Undisclosed-Recipient:;
Cc: Stig Venaas
Date: Wed, 27 Jul 2005 00:10:51 -0400
X-Spam: [F=0.0001020200; B=0.500(0); S=0.010(2005070601); MH=0.500(2005072613); R=0.010(s287/n31069)]

Margaret - Stuart's comments raise a process issue, in that this
document has gone through IETF last call, and the -13 rev includes
changes to the document based on comments received during the IETF last
call. 

Considering the diffs between the -12 and -13 revs of the doc
(http://tools.ietf.org/wg/dhc/draft-ietf-dhc-dna-ipv4/draft-ietf-dhc-
dna-ipv4-13-from-12.diff.html), another IETF last call on this doc might
be in order.

I think Stuart's comments can be dealt with quickly - in fact, John
Schnizlein has already responded to Stuart's point 3 - in an IETF last
call.  I note that Stuart says he has "a long list of comments" that
perhaps should be reveiwed during a last call.

- Ralph

On Tue, 2005-07-12 at 16:47 +0100, Stuart Cheshire wrote:
> I just read draft-ietf-dhc-dna-ipv4-13.txt.
>
> I support the goals, but I think the current document misses the target.
> I have a long list of comments, but these are the three major ones:
>
> 1. Hints and heuristics
>
> It seems to me that the reliance on hints and heuristics is vastly
> overstated. The biggest and best heuristic of network attachment is the
> MAC address of the default gateway, which can be verified with a trivial
> ARP request (i.e. the proposed DNA mechanism itself), thereby negating
> much of the usefulness of all the other hints. The document even has a
> section for IP-layer hints, and then says they're pointless and shouldn't
> be used. Given than an ARP request can be answered in under 1ms, any hint
> or heuristic has to be significantly faster than that, or it's
> self-defeating.
>
> The argument in Appendix A that you don't want to delay the normal DHCP
> INIT-REBOOT process while waiting for DNA is bogus. There's no reason why
> a host that wants rapid attachment to the network (which is, after all,
> the whole point of DNA) wouldn't do both simultaneously, and then just
> wait and see which approach yields a fruitful result quickest.
>
> 2. Why only one MLN candidate?
>
> Why limit a host to picking just one candidate network to verify?
>
> The drafts says, "In the absence of other information, the MLN defaults
> to the network to which the host was most recently attached." Consider a
> laptop computer that moves daily between Ethernet at work and Ethernet at
> home. If each time it picks its most recently attached as its best guess,
> it's going to be wrong 100% of the time.
>
> It would be much better if a device simply sent ten ARP Requests for the
> last ten default gateway addresses it has seen, and then sees which, if
> any, are answered.
>
> If you don't want to hit the network with ten back-to-back wire-rate ARP
> Requests, then they can be staggered 100ms apart, starting with the most
> recently seen network, then the previous, and so on.
>
> Most network gateways should be able to answer an ARP Request almost
> instantaneously, since answering ARP Requests is something they have to
> do all the time anyway, and if they're slow at that, then that would
> adversely impact the performance of pretty much all IP traffic flowing
> through the gateway.
>
> This stream of ARP Requests would of course be going on concurrently with
> DHCP INIT-REBOOT processing, and as soon as one of them yields a fruitful
> result, the device should stop.
>
> It's simple, it's fast, and it yields the desired result.
>
> 3. Probe packets
>
> The document struggles with its incompatibility with the existing
> widespread use of a zero-sender ARP as an ARP Probe, which means, "I want
> to know if this address is in use, AND IF NOT I INTEND TO USE IT MYSELF."
> This is the issue James Carlson pointed out.
>
> This document needs an ARP Request with these semantics: "I just want to
> know if this address is in use, and I have no intention of claiming it as
> my own address; I may believe I already have an address of my own, but
> I'm not yet willing to reveal what that is."
>
> What could that packet be?
>
> Given that the host does not want to announce its address until it is
> certain of it, it can't put that address in ar$spa.
>
> The host can't put zero in ar$spa, because that implies, "I intend to use
> ar$tpa as my own."
>
> Therefore, it has to put something else. It just has to be a non-zero
> value that can't be an actual IP address already in use by a host on that
> link.
>
> There are many possibilities:
>
> 0.0.0.1
> 127.0.0.1
> 255.255.255.255
>
> Any of those values would work. They are not zero, so the packet doesn't
> look like a probe, and they're not any IP address that could be in use by
> any other host on that link, so they can't inadvertently stomp over
> someone else's ARP cache entry.
>
> Fixing this would eliminate much of the specification that's currently
> awkward, clumsy, self-contradictory and unimplementable. For example:
>
>      Note: Some routers may refuse to answer an ARP Probe, in which
>      case the reachability test will fail.  A host also may encounter a
>      router that utilizes ARP Probes for DAD, as described in [ACD].
>      Such routers will not interpret ARP Probes as an indication of an
>      address conflict, except where they are themselves doing Duplicate
>      Address Detection (DAD).  To avoid triggering conflict detection
>      on these routers, a host implementing DNAv4 that receives ARP
>      Probe from a router SHOULD NOT send ARP Probes to that router as
>      part of the DNAv4 reachability test.
>
> A host "that receives ARP Probe from a router SHOULD NOT..."
>
> How does a host KNOW it will receive ARP Probes from a router? How long
> should it wait to see? DNA is supposed to be fast, right, so how long do
> we want it to wait? Even after it's waited, how does it know the router
> is not booting up and, at that very instant, is about to send its own ARP
> Probes? How does a host know it's a router sending ARP Probes, and not
> some other host on the network performing DNA? What does it mean by,
> "SHOULD NOT send ARP Probes to that router as part of the DNAv4
> reachability test"? I thought that sending ARPs was ALL of the DNAv4
> reachability test. What other parts are there?
>
> Using ARP Requests with a 0.0.0.1 source address would eliminate all of
> these self-contradictions and awkward special cases.
>
> Stuart Cheshire
>  * Wizard Without Portfolio, Apple Computer, Inc.
>  * www.stuartcheshire.org
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

[Ballot comment]
The document says:

Experience has shown that IPv4 Link-Local
addresses are often assigned inappropriately, compromising both
performance and connectivity.

Is there a citation for this, or was this experience shared with the working group?

[Ballot discuss]
Section 2.1 of the document discusses implementations of DNAV4 using
snooping versions of OSPF and RIP to understand what prefixes are on a
subnet without fully participating in a routing protocol.  While this
practice is encouraged by this specification, no reference to how to
do it is provided.  If such a reference exists it needs to be
included.  If no such reference exists, please confirm that sufficient
detail is provided that implementations are unlikely to break the
routing infrastructure by misimplementing this feature.

Submission Questionnaire:


draft-ietf-dhc-dna-ipv4-09.txt is ready for IESG review; here is the chairs' questionnaire:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes and yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes and no.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No concerns.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

WG has expressed strong concurrence of a few individuals with no
objections.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

This draft uses RFC 2026 IPR boilerplate.  idnits also found a couple
of examples of hyphenation and wierd spacing.

8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

  (Abstract from "Detection of Network Attachment (DNA) in IPv4")
  The time required to detect movement (or lack of movement) between
  subnets, and to obtain (or continue to use) a valid IPv4 address may
  be significant as a fraction of the total delay in moving between
  points of attachment.  This document synthesizes experience garnered
  over the years in the deployment of hosts supporting ARP, DHCP and
  IPv4 Link-Local addresses.  A procedure is specified for detection of
  network attachment in order to better accommodate mobile hosts.

  The document addresses a need for compilation of experiences with
  various protocol specifications and formal description of protocol
  operation based on those experiences.  Members of the dhc WG
  provided significant expert input based on experience with DHCP
  client/server deployment and operation.

  - Working Group Summary

  The dhc WG was actively involved in the development of this
  document and provided significant input.  The consensus of the WG
  is to submit the document for publication.  The issues raised
  during discussion of this document, including the WG last call, are
  listed at http://www.drizzle.com/~aboba/DNA/dnaissues.html

  - Protocol Quality

  This document does not define a protocol; rather, it provides a
  formal description of procedures for host movement that are useful
  in protocols like DHCP and IPv4 link-local addresses.  The quality
  of the document is excellent.

  Please provide such a writeup. (We will hopefully use it as is, but
  may make some changes.) For recent examples, have a look at the
  "protocol action" announcements for approved documents.

AD review comments sent to the author and the WG:

To: Bernard Aboba
From: Margaret Wasserman
Subject: AD Review Comments On:  draft-ietf-dhc-dna-ipv4-09.txt
Cc: Mark Townsley , dhcwg@ietf.org

Hi Bernard,

I have two questions about draft-ietf-dhc-dna-ipv4-09.txt that I would like to discuss before I send this document to IETF LC.

(1) Could you explain why sending an ARP request to the default gateway(s) of the MLPA (as described in section 2.2)  is a better mechanism to confirm what IPv4 configuration parameters should be used than re-initiating DHCPv4 and/or attempting to renew the DHCPv4 lease (as described in section 2.3)?

The only text in the document that might explain this seems to be:

  In contrast to a DHCP exchange, which may be between a DHCP client
  and an off-link DHCP server, the reachability test is designed to
  verify bi-directional connectivity to the default gateway(s) on the
  MLPA.

But, I'm not sure why this is better than using DHCP and/or how this compensates for the possibility that the mechanisms described in this document may result in a two step process:  an ARP exchange (with a 200ms timeout) followed by a DHCP exchange.  Has there been some analysis and/or empirical testing that shows that this mechanism produces superior results?

(2) Is it assumed that the host would not send any non-DNA-related IPv4 traffic using its presumed address on the MPLA during the reachability test and address acquisition phases?  If so, would it make sense to state that restriction here?  Do you expect that packets would be queued until the address status is resolved?  Or that upper layers would receive errors consistent with an interface that has not addresses configured?

Thanks,
Margaret