Subject: RE: draft-ietf-zeroconf-ipv4-linklocal-03.txt

From: Jim Busse <[email-masked]>
Date: Tue, 10 Jul 2001 18:26:51 -0700

Sturart:  It' s too long, so I'll just put this at the top:

>   If the destination address is in the 169.254/16 prefix (including the
>   169.254.255.255 broadcast address), the host MUST use its link-local
>   source address.
>
>too strong?

In my opinion, is no reason to change the wording to "should".  I think the
concept that the169/254/16 prefix packets are coming from a "friendly"
link-local network, the use of some other address may look like an
"intruder".  I like the original wording best.  Maybe Thomas could give a
reason for the "too strong"?   

 -----Original Message-----
From: 	Stuart Cheshire [mailto:[email-masked]] 
Sent:	Tuesday, July 10, 2001 12:43 PM
To:	Thomas Narten; [email-masked]
Subject:	Re: draft-ietf-zeroconf-ipv4-linklocal-03.txt

Thanks for your quick response to our request for document review.

I have attempted to answer your comments below:

----

>   2.4 Source Address Selection
>
>The rules in this section seem overly strong to me. In particular,
>they make it a protocol violation to use certain combinations of
>addresses, when:
>
>a) it is not clear there is a need for such a restriction
>b) it makes it a protocol violation to use certain combinations when
>   it seems to be that little or no harm would come from it (i.e,
>   communication would work just fine).

The intention here was to limit accidental leakage of 169.254/16 packets 
into or out of the local link.

Leakage into the local link exposes link-local devices to potential 
attack from a larger set of hosts than their designer may have designed 
for.

Leakage out of the local link potentially annoys network operators, 
making them complain, "what are these 169.254/16 packets doing on my 
network?"

However, with the TTL=255 check advocated by Dave Thaler and others, 
link-local devices have a better way to protect against external packets 
leaking into the local link, and arguably, annoying network operators is 
not our concern -- they should filter out errant 169.254/16 packets if 
they are worried about them.

If no one makes strong arguments to the contrary, I am happy to relax 
these requirements. (See below.)

----

>   If the destination address is in the 169.254/16 prefix (including the
>   169.254.255.255 broadcast address), the host MUST use its link-local
>   source address.
>
>too strong?

Would the following be acceptable?

   If the destination address is in the 169.254/16 prefix (including the
   169.254.255.255 broadcast address), the host SHOULD use its link-local
   source address if it has one.

----

>   If the destination address is:
>   (a) a unicast address outside the 169.254/16 prefix, or
>   (b) a multicast address with scope larger than link-local and
>       the TTL in the IP header is greater than 1,
>   then the host MUST NOT use its link-local source address, and should
>   instead use an appropriate routable source address.

Would the following be acceptable?

   then the host SHOULD use an appropriate routable source address
   if it has one.

----

>   Any host receiving an IPv4 packet whose destination addresses is in
>   the 169.254/16 prefix MUST discard the packet if the source address
>   is not in the 169.254/16 prefix.

This can be deleted.

----

>   all zeroes. The 'target IP address' field MUST be set to the address
>   being probed. An ARP request constructed this way with an all-zero
>   'sender IP address' is referred to as an "ARP probe".
>
>terminology: what is 'target IP address'? ARP has "target protocol
>address". ditto for sender IP address? I think the terminology may
>need tweaking throughout the document on this point.

My experience with earlier drafts of this document is that many of its 
readers asked questions which made it clear they knew little about ARP.
My feeling was that the term 'sender IP address' is clear and unambiguous 
to more readers than the term 'sender protocol address', and I did not 
want to make this document unnecessarily obscure to the majority of 
readers.

Would the following introductory text in the "Conventions and 
Terminology" section be acceptable?

   Wherever this document uses the term "sender IP address" or
   "target IP address" it is referring to the fields of the ARP
   packet identified in the ARP specification [RFC 826] as "ar$spa"
   (Sender Protocol Address) and "ar$tpa" (Target Protocol Address)
   respectively. For the usage of ARP described in this document,
   these fields always contain an IP address.

----

>   In addition,
>   if during this period the host receives any ARP packet where the
>   packet's 'target IP address' is the address being probed for, and
>   the packet's 'sender hardware address' is not the hardware address
>   of any of the host's interfaces, then the host MUST similarly treat
>   this as an address collision and select a new address as above. This
>   can occur if two (or more) hosts attempt to configure the same link-
>   local address at the same time.
>
>They above text seems wrong. If a router is trying to ARP for my
>address, wouldn't it send out a packet that by the above rules
>indicate an address collision? Shouldn't the check be if the Sender
>Protocol address is IP address and is 0, and the hardware source
>address is not one of my own?

If a router is trying to ARP for my address, then it *cannot* be trying 
to talk to *me*, since I just picked this random number, and have not yet 
advertised that fact to the world. Hence if a router (or any host) is 
trying to ARP for this address, then that must mean that *someone else* 
is (or was recently) using this address. Hence it is safest if I don't 
use this address.

----

>   A host should maintain a counter of the number of address collisions
>   it has experienced in the process of trying to acquire an address,
>   and if the number of collisions exceeds ten then the host MUST limit
>   the rate at which it probes for new addresses to no more than one new
>   address per second. This is to prevent catastrophic ARP storms in
>   pathological failure cases, such as a rogue host that answers all
>   ARP probes, causing legitimate hosts to go into an infinite loop
>   attempting to select a usable address.
>
>Hmm. Seems to me that if you have ten collisions in a row, you've
>either got:
>
>1) bad algorithm for chosing addresses, in which case retrying at all
>   is a waste of time (or worse)...
>
>2) DOS attack in progress in which someone is claiming ownership of
>   all addresses. In this case, continuing on every second seems
>   useless too.

There are networks at Apple with 1000 active hosts and 1016 usable 
AppleTalk addresses. Hosts regularly AARP 60 times or more before getting 
a free AppleTalk address. I'm not saying this is good, just observing 
that it happens.

>I'd suggest in the name of network friendliness that after ten tries,
>one should either quit entirely (maybe too extreme) or at least back
>off *very* significantly, say no more than once every few minutes or
>so.

Is "no more than one new address per minute" acceptable?

----

>   (b) If a host currently has active TCP connections or other reasons
>   to prefer to keep the same IP address, and it has not seen any other
>   conflicting ARP packets recently (for Ethernet, within the last ten
>   seconds) then it MAY elect to attempt to defend its address, by
>   recording the time that the conflicting ARP packet was received, and
>   then broadcasting one single gratuitous ARP request, giving its own
>   IP and hardware addresses as the sender addresses of the ARP. Having
>   done this, the host can then continue to use the address normally
>   without any further special action. However, if this is not the first
>   conflicting ARP packet the host has seen, and the time recorded for
>   the previous conflicting ARP packet is recent (within ten seconds for
>   Ethernet) then the host MUST immediately cease using this address and
>   configure a new link-local IP address as described above. This is
>   necessary to ensure that two hosts do not get stuck in an endless
>   loop with both hosts trying to defend the same address.
>
>Once you've concluded that one of the nodes needs to give up its
>address, should you just pick one, rather than forcing both to pick a
>new one? I.e, let the lower numbered ethernet address win? At least
>that way only one gives up the address. This would be less disruptive
>on average.

This "defend once" behaviour usually provides this result. Collisions not 
detected during the probing phase are usually because someone booted up 
their laptop first, and then plugged it into an Ethernet hub. The first 
network operation they try to do on their laptop will almost always 
result in an ARP request being broadcast, which the other host sees, 
defends once, and then the laptop reconfigures.

----

>   All ARP packets (replies as well as requests) that contain a link-
>   local sender address SHOULD be sent using link-level broadcast
>   instead of link-level unicast. This aids timely detection of
>   duplicate addresses. An example illustrating how this helps is
>   given in Section 4.
>
>Seems like this should be a MUST. Why should this be an implementation
>choice?

Older Mac OS and Windows did not broadcast ARP *replies*, yet they still 
broadcast ARP *requests* frequently enough that collision detection was 
effective. Broadcasting ARP replies as well is certainly better, because 
it enables quicker collision detection?

I will change this to a MUST if no one makes strong arguments to the 
contrary.

----

>Since MS has a patent on technology related to this document (see the
>IETF IPR Web Page), the document needs to include text noting that
>there are possible IPR concerns. In particular, just include
>paragraphs (A) and (D) of Section 10.4 in RFC 2026. Don't mention the
>specific patent itself in the document.

Done.

----

>needs an iana considerations section that indicates that IANA has
>assigned the 169.254 address for this purpose.

Done:

6. IANA Considerations

   The IANA has allocated the network prefix 169.254/16 for the use
   described in this document. No other IANA services are required by
   this document.

----

Thanks for your comments. I await feedback from other Working Group 
members.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Thomas Narten <[email-masked]>
Date: Wed, 11 Jul 2001 09:28:17 -0400

> reason for the "too strong"?   

Stuart captured my concern precisely. Namely, if two nodes are on the
same link, and one uses a global address rather than a link local (it
might not even have a link-local address!), I don't think you want to
outlaw communication when there would seem to be no harm.

So, actually, I'm mostly OK with the above wording, since it basically
says if you can use a link-local address, you MUST. What I worry is
too strong, is saying you MUST drop packets if the src/dst addresses
are not both link-local. To make it absolutely clear, perhaps the text
"(if it has one)" could be added to the above text., i.e.:

   If the destination address is in the 169.254/16 prefix (including the
   169.254.255.255 broadcast address), the host MUST use its link-local
   source address (if it has one).

Thomas