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

From: Thomas Narten <[email-masked]>
Date: Mon, 09 Jul 2001 13:42:22 -0400

The WG has reqested this document be advanced as a Proposed
Standard. In anticipation of starting the Last Call, I reviewed the
document and have the following questions/comments. I'm sending this
to the WG rather than just the authors as some if the issues go beyond
just editorial clarification.

Thomas

   2.4 Source Address Selection

   Since each interface on a host may have a link-local address in
   addition to zero or more other addresses configured by other means
   (e.g. manually or via a DHCP server), a host may have to make a
   choice about what source address to use when it sends a packet or
   initiates a TCP connection.

   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.

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

I'll also note that the decision here is different than the approach
taken in IPv6, where the issue of addresses having different scopes is
much more prevalent.

Is this really needed?

Also, do these rules mean that a node can't just swap src/dest
addresses when responding to a packet? If so, this would seem to be an
extra check stacks must do, and it would also prevent certain types of
communication where there would appear to be no harm in allowing it.

   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?

   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.

why?

   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.

   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.

   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?

   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.

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.

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

   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?

Nits:

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.

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

   the special rules regarding duplicate detection and automatic conf-
   iguration that pertain to addresses in this prefix. While RFC 2131

don't split words across lines...

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