Subject: Re: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt

From: Stuart Cheshire <[email-masked]>
Date: Tue, 11 Sep 2001 00:57:51 -0700

Thanks for your comments Erik.

>The text in section 1.2 which attempts to define link seems to exclude
>all link layers that modify some part of the link-layer packet.
>This clearly excludes MPLS and might exclude source routing token ring
>as two examples.

The intention was to state that the link-layer *payload* (IP header and 
up) should not be modified, not the link-layer header.

>Why not just refer to or copy the definitions of "link" and the terms
>it depend on from RFC 2460?

I find the definition in RFC 2460 somewhat self-referential:

   link - a communication facility or medium over which nodes can
          communicate at the link layer, i.e., the layer
          immediately below IPv6.  Examples are Ethernets...

This defines "link" in terms of "link layer", but then leaves the term 
"link layer" undefined. It gives a list of examples, but a list of 
examples is not a definition.

I actually think that in the most precise definition of "on the same 
link" for the purposes of IP is the one the draft gives: two hosts are 
"on the same link" if and only if IP packets sent from one to the other 
arrive with no part of the IP packet modified. If the TTL is decremented 
en route, they are not on the same link. If the IP addresses are 
rewritten by a NAT box or TCP port numbers are changed or the IP packet 
is modified in any other way, then the hosts are not communicating 
directly on the same link.

The reason the draft defines this in terms of link-layer payload instead 
of IP packets is that ARP packets must also arrive unmodified, not just 
IP packets.

>And presumably the definitions belong in section 1.1 and not 1.2.

I propose putting the following modified text in Section 1.1:

   This document describes link-local addressing, for IP communication
   between two hosts on a single link. Two hosts are considered to be on
   the same link if, when one host sends packets to the other, the
   entire link-layer packet payload arrives unmodified. The link-layer
   *header* may be modified, such as in Token Ring Source Routing
   [IEEE8025], but not the link-layer *payload*. In particular, any
   device forwarding a packet whose source and/or destination address is
   in the 169.254/16 prefix MUST NOT modify any part of the IP header
   or IP packet body. This means that the packet may pass through
   devices such as Ethernet switches, bridges, hubs or repeaters, but
   not through devices like IP routers that modify the IP header.

I am aware that by this strict definition, a Token Ring and an Ethernet 
segment bridged together do not qualify as a single link, because the 
bridge modifies the contents of ARP packets. Bridges do this to work 
around the ubiquitous bug that Token Ring hosts typically put their 
six-byte IEEE MAC addresses into the ARP packet with the bit order 
reversed from the normal canonical order. When packets go to another 
Token Ring host this bug goes unnoticed, because receiving hosts 
misinterpret received ARP packets the same way, thereby nullifying the 
effect of the bug. For packets that cross the bridge, the bit order of 
the hardware addresses within the ARP packets has to be flipped, or the 
ARP packets from the Token Ring side would be invalid and meaningless on 
the Ethernet side of the bridge. This is an unreliable hack. Networks 
bridged this way to do not qualify to be called a single link. Do Token 
Ring-to-Ethernet bridges also flip the bit order of the chaddr field of 
DHCP packets? I think not. What about the Client ID option of DHCP 
packets, in the case where the Client ID option carries a six-byte MAC 
address (but not when the Client ID is a user-entered string)? What about 
all the other places where six-byte MAC addresses can be embedded in 
packets that the bridge doesn't know about? This kind of bridging is 
fragile and unreliable, and while it can certainly be made to work in 
some situations, this draft should not promise to support it.

>I don't understand what the text in section 2.1 about 
>   This means that even without using any other
>   persistent storage, a host will usually select the same link-local
>   address each time it is booted [...]
>relates to the fact the you refer to RFC 1750 which says "It recommends 
>the use of truly random hardware techniques ..."
>
>If you have truly random hardware techniques then you would *not* get the
>same random number on each boot. So what is the relationship really with
>RFC 1750?

The reference to RFC 1750 was put in at the request of Donald Eastlake on 
31st May this year. I do not have a strong opinion about it myself. Would 
you prefer to see that reference removed?

>Section 2.1 claims that 169.254/16 is assigned by the IANA for this
>purpose. I didn't think it had a reference to the draft so I went to
>look. Turns out it isn't explicitly listed in
>http://www.iana.org/assignments/ipv4-address-space
>
>We need to make sure we have the correct instructions for the IANA
>which might include transferring the ownership of the address block
>to refer to this spec.

# whois [email-masked]
[whois.arin.net]
IANA (NETBLK-LINKLOCAL)
   Internet Assigned Numbers Authority
   4676 Admiralty Way, Suite 330
   Marina del Rey, CA 90292-6695
   US

   Netname: LINKLOCAL
   Netblock: 169.254.0.0 - 169.254.255.255

   Coordinator:
      Internet Corporation for Assigned Names and Numbers
      (IANA-ARIN)  [email-masked]
      (310) 823-9358

   Domain System inverse mapping provided by:

   BLACKHOLE.ISI.EDU            128.9.64.26
   BLACKHOLE.EP.NET             198.32.1.116

   Record last updated on 30-Aug-2000.
   Database last updated on 8-Sep-2001 23:09:15 EDT.

The ARIN Registration Services Host contains ONLY Internet
Network Information: Networks, ASN's, and related POC's.
Please use the whois server at rs.internic.net for DOMAIN related
Information and whois.nic.mil for NIPRNET Information.

I have contacted [email-masked] to see what needs to be done to correct 
this.

>The algorithm in section 2.3 seems to force an unneeded IP address
>change if a single packet is lost.
>A is trying to use address X, which is already in use by B.
>A sends arp request. B sees it and responds with a gratuitus reponse.
>This response is lost.
>A sends the arp request again after 2 seconds. (It is supposed to do this 4 
>times). B sees it. Now the rules say that it MUST cease to use the address.
>This doesn't seem very robust.

I think you are confusing sections 2.2 and 2.3. The four ARP packets two 
seconds apart are in Section 2.2, "Claiming a Link-Local Address". Also, 
they are ARP probes, not ARP requests. ARP probes are benign. They have 
zero source address, and cause no harm to any other host on the network.

The forced reconfiguration in Section 2.3 only comes into effect if the 
ARP probing process failed, and two hosts are trying to use the same 
source IP address (for example when two separate network segments are 
later joined). Forced reconfiguration is rarely needed, and when it is 
needed, it is the quickest (and only) way to restore working 
communication. Two hosts cannot use the same IP address and have reliable 
communication. Whether or not an ARP packet may occasionally be lost 
makes no difference here. If two hosts are trying to use the same source 
IP address, reliable communication will not be restored until at least 
one of them stops using that address.

>Have both Apple and Microsoft implemented exactly this?

Apple has implemented exactly this. I can't speak for Microsoft.

>   If the destination address is the 255.255.255.255 broadcast address
>   or a multicast address, then the host may use either its link-local
>   source address or a routable address, as appropriate.
>Huh? Sending to a global multicast address with a link-local source
>is a good idea?
>How about allowing either for broadcast or multicasts to 224.0.0.0/24
>but mandating global source for other multicasts.

For example, hosts may want to use SSM addresses. There are no SSM 
addresses in the 224.0.0.0/24 prefix.

What if you have a MADCAP server on the network, but no DHCP server, so 
the hosts are using link-local addresses? Is the MADCAP server then 
restricted to assigning only multicast addresses in the 224.0.0.0/24 
prefix? Is a MADCAP server allowed to assign multicast addresses in the 
224.0.0.0/24 prefix?

What about the Zeroconf couterpart to MADCAP (ZMAAP). Can it also only 
assign multicast addresses in the 224.0.0.0/24 prefix?

I did consider saying that link-local source addresses may not send to 
multicast addresses outside 224.0.0.0/24, but I fear (though I don't know 
for certain) that this would be overly restrictive.

>Section 2.5 a few paragraphs that seem to endorse the construction of
>boxes that depend solely on the IP addresses being used for some notion
>of weak security. As we all know bridges to wireless media breaks
>any such assumptions. I don't think the IETF should be endorsing such
>weak security in standards track documents.
>How about making 2.5 state the protocol mechanisms and the
>in the security considerations section state that 
>1) the protocol prevents packets using link-local addresses from being 
>injected
>   outside the link through the use of a ttl 255 check, and 2) users of
>link-local addresses should be aware of the existence of
>   bridges e.g. to wireless media that make the use of ttl 255 a very
>   weak security mechanism.

I was very careful not to say that devices should have no security. I 
said that designers should implement a degree of security appropriate for 
the expected environment.

Security wording is always tricky. If you can propose specific wording I 
would welcome that.

>The way I view it section 3.2 talks about constraints when the APIs
>allow applications to specify and retrive interface information, and
>section 3.3 talks about issues when such APIs are not available.
>But the section titles doesn't match this so I'm confused about the
>intent.

Section 3 covers multi-homing issues.

Section 3.1 covers one choice for multi-homing -- don't do it.

Section 3.2 covers another option -- a single address shared between all 
interfaces -- and describes what is necessary to do this.

Section 3.3 covers an alternative option -- a different address on each 
interface.

Can you suggest better titles?

>Section 3.2 recommends using a single link-local address across
>multiple interfaces but it doesn't explain why this is better
>or simpler than using different ones. I think it can be worse
>in some cases. If a conflict appears on one interface forcing
>the host to pick a new link-local on that interface it would be
>nice if that didn't effect connections using link-local
>addresses on all interfaces.

1. Address collisions are rare, so in practice this is not an issue.

2. If it were to be an issue, the more addresses a host has, the greater 
its chance of experiencing a collision, so having fewer addresses to 
collide is arguably better.

>Section 3.3 seems to skip the issue about how to connect or
>send the first UDP to a link-local address in the absense of
>API support to identify interfaces. Using the source IP address
>to identify the interface works after the initial exchange e.g.
>after a tcp connection has been established. But making it work
>for UDP responders when the socket is bound to INADDR_ANY seems
>hard.

Application software has to do what any good application software (e.g. 
DNS server, NFS server, etc.) has to do today on a multi-homed host -- it 
enumerates the available interfaces, opens a socket per interface, and 
binds each socket to its interface.

>   In addition, this kind of host should probe for, and defend, all of
>   its link-local addresses on all of its active interfaces that are
>   using link-local addresses.
>I don't see why this is strictly needed. The host needs to
>ensure that its IP are unique across the interfaces but it
>should be able to handle having a local address X on interface
>#1 while address X is also assigned to a remote node on
>interface #2.

This case is discussed in 3.3.1, "Example Illustrating (Incorrect) 
Ambiguous Address Re-Use":

   When host A sends a UDP packet from source
   address P to destination address Q without specifying an explicit
   outgoing interface identifier, it is ambiguous whether A intends
   to talk to itself, or to host B.

Do you disagree with that example?

>And defending its addresses on all interfaces has the disadvantage of
>increasing the risk of having to pick a new address.

That is the benefit of using choice 3.2 (Single Shared Link-Local 
Address) on hosts where the OS and application software make that 
possible.
 
>The example in 3.3.1 doesn't seem to match what is said at the
>top of section 3.3: "[...] enable use of the source address as
>an unambiguous interface identifier". This means that in 3.3.1
>P identifies the interface and the only Q on that interface is
>assigned to B. If A wants to talk to itself it can use a source
>of 127.0.0.1 (indentifying the loopback interface) and the same
>as a destination, or a source of P and dest P, etc. Allowing a
>source of P and a destination Q for loopback traffic seems
>counter to using the strong end system model.

I believe that in most operating systems today, if a multi-homed host has 
addresses P and Q, and sends a packet addressed to Q, then that packet is 
looped back inside the network stack and redelivered locally. It is not 
sent out on the wire. It seemed wise not to mandate changing this 
behaviour for LL destination addresses, but I do not have a strong 
opinion about that.

Am I wrong about the current behaviour of today's multi-homed hosts?

>But I still don't understand the description in section 3.3 is
>supposed to handle what is common in the BSD API: a TCP socket
>is created and then connected to the destination address. In
>this case there is nothing which can be used to infer the interface.
>Is that intended to be outside the scope of section 3.3?

Section 3.3 does not propose a solution to applications that think that 
an IP address alone is sufficient to uniquely identify the desired 
destination. I believe that such a solution would require magic.

Section 3.3 explains how it is possible to produce a well-written 
application that can use link-local addresses on a multi-homed host.

We do everything possible to make current software work as well as it can 
with link-local addresses, but that doesn't mean that there aren't ways 
you could improve current software to make it work even better.

If we can run Zeroconf IP over a USB cable, then you can use today's ftp 
client software to transfer files over that cable. Perhaps you could 
improve today's ftp client software to work even better if you made it 
more aware of Zeroconf Considerations. Compare that with how much work 
you'd have to do to modify today's ftp client software to transfer files 
over a USB cable where IP is *not* available.

>The second paragraph in section 3.4 seems to conflict with the
>current model in section 3.1 - if you want to support multiple
>interfaces being bridged togther in the same link then the
>interfaces better have distinct link local addresses. Otherwise
>you don't know which interface packets will arrive on which
>means that the communication bound to an interface per the
>strong ES model will fail half the time (when the packets
>arrive on a different interface than were connection is sending
>packets).

This is a very good point.

I propose the following new text:

   If a host receives an ARP packet where the 'sender hardware address'
   is not the hardware address of the interface on which the packet was
   received, but *is* the hardware address of one of the host's other
   interfaces, then this indicates that the host has two or more
   interfaces connected to the same network link. This can happen if the
   user of a multi-homed host with two Ethernet interfaces connects both
   interfaces to the same Ethernet hub. It can also occur less
   obviously, such as a host with both wired and wireless Ethernet
   interfaces, in an environment where a wireless gateway is available,
   and (perhaps unknown to the user) happens to be bridged onto the same
   wired Ethernet.

   If a host implementing a single shared link-local address (Section
   3.2) receives such an ARP packet, it should cease using its link-
   local address on one of the two interfaces in question. If there is a
   performance difference between the two interfaces (e.g. Gigabit wired
   Ethernet and 11Mb/s wireless), then the host should generally cease
   using its link-local address on the lower performance interface.

   If a host implementing a different link-local address for each
   interface (Section 3.3) receives such an ARP packet, it should
   silently discard it and not treat it as a conflict. Such a host
   should not shut down either interface's link-local address, because
   to do so would break existing connections established to the
   discontinued IP address.

Thanks again for your comments.

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Sep 2001 07:17:05 -0700 (PDT)

> Is a MADCAP server allowed to assign multicast addresses in the 
> 224.0.0.0/24 prefix?
> 
Addresses in the 224.0.0.0/24 prefix are not dynamically assigned. So they
should not be assigned by MADCAP or ZMAAP.

> for certain) that this would be overly restrictive.

In general, there's no reason to use a linklocal address to send to a
global multicast address, since that packet could reach hosts multiple
hops away, and packets from a linklocal address should remain local to the
link.