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

From: Stuart Cheshire <[email-masked]>
Date: Mon, 2 Apr 2001 23:23:48 -0700

>Find enclosed some comments on the IPv4 linklocal draft. Despite the
>length of the review, most of these represent minor changes in wording.

Thanks. I liked almost all of the comments. Let me address the few I have 
comments about:

>This is confusing. In other documents and drafts the term "routable
>address" refers to addresses that are routable on the global Internet --
>which does not include private address space. For consistency, it
>would be better if the term "routable and private addresses" were
>used instead.

I was trying to pick a concise term that did not make the text clumsy, 
since clumsy text is less clear.

I would argue that other documents and drafts are wrong -- you can have a 
large private routed network without it being connected to the global 
Internet. I feel that the draft uses the term "routable" accurately, and 
it also defines the term to further reduce confusion. Even if some people 
misinterpret the word "routable" to mean "global", then that does not 
result in those people misunderstanding any significant aspects of how to 
handle link-local addresses.

>There are a number of references to Ethernet in the document. In most
>cases, Ethernet is not in fact a requirement, and other IEEE 802
>media would work just as well. I recommend going through the document
>and replacing "Ethernet" with "IEEE 802 media". References to these
>documents are included below:

Good point. But do you want me to list *all* eight references?

>"If the destination address is a unicast address outside the
>169.254/16 range, or a multicast address with scope larger than link-
>local, the host SHOULD NOT use its link-local source address, and
>should instead use its appropriate routable interface address."
>
>Recommend changing the SHOULD NOT to a MUST NOT, since such packets
>will not arrive in a properly functioning network. Therefore there is 
>no point in sending such packets. Keeping the existing language could
>give license to send such packets in situations where the host will
>re-transmit if it doesn't receive a reply. This could result in a
>multicast storm.

Agreed. And I'll also correspondingly change:
>   If the destination address is in the 169.254/16 range, the host
>   SHOULD use its link-local source address.
to:
>   If the destination address is in the 169.254/16 range, the host
>   MUST use its link-local source address.

However, for multicast destinations I'll keep the "SHOULD NOT use its 
link-local source address", since almost all IPv4 multicast addresses 
have scope larger than link-local, and saying "MUST NOT" would prohibit 
LL sources from using almost all multicast addresses. As long as TTL of 
1, I think sending to general multicast addresses is safe. 

>Is it worth making a statement about the status of the DHCP auto-config 
>option?

I'd rather say nothing about it at all, and simply let that RFC be 
reclassified as historic. It was a mistake that it got published at all 
-- I'd rather not draw further attention to it now.

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

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 2 Apr 2001 23:31:26 -0700

>=> As far as I understood the draft, that situation was just to enable
>remote connection to a specified link-local subnet (the remote client
>accesses it specified home network through its "gateway" between link-local
>subnet and internet, for example). Thus the purpose of this sentence is NOT
>"bridging two segments", is it ? But the draft is perhaps not enough clear
>here ? In that situation we are in the same situation that in the example
>"3.2 Example Illustrating Acceptable Address Re-Use" : the remote client
>behave as the host A of the example. So that implies some constraints on the
>"gateway" and on the remote client. Here the remote client MUST NOT behave
>as a bridge. Or did I miss something ?

The point is that this can get very complicated very quickly.

If the tunnel server performs the ARPing to allocate a unique address on 
the local link, when it informs the tunnel client at the other end, the 
address may not be acceptable to the tunnel client, perhaps because the 
tunnel client already has another interface with that address, or a peer 
(or peers) on its other local links that have that same address. Thus the 
tunnel client needs to be able to decline the address and tell the tunnel 
server to choose another.

Also, a conflict on the local link at the tunnel server end may force a 
reconfiguration. That requires the tunnel server to inform the tunnel 
client that the address it was allocated has been forcibly revoked, which 
is not handled very well by current tunneling protocols.