Request to reopen LL18
Bernard Aboba <[email protected]>
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
On April 11, 2003 Issue LL18 was rejected because the issue never had text submitted for it. In the following post, it was noted that "At such time as an issue comes to mind - we will take the submission and open it for discussion." See: http://www.merit.edu/mail.archives/zeroconf/2003-04/msg00029.html On June 4, 2003 Stuart Cheshire posted a message suggesting that LL18 be revisited: http://www.merit.edu/mail.archives/zeroconf/2003-06/msg00007.html However, since no formal request was made, LL18 was not reopened at that time, and as a result, no WG consensus was reached as to whether to allow the proposed change. At this point, I'd like to make a formal request that LL18 be reopened. The proposed change is as follows: In Section 2.6 Change: "If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable IPv4 source address, if it has one. If the host does not have a routable source address, then it MAY choose to ARP for the destination address and then send its packet, with a Link-Local IPv4 source address and a routable destination IPv4 address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding." To: "If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable source address, if it has one. If the host has no appropriate routable source address, then it MUST ARP for the destination address and then send its packet, with a link-local source IP address and a routable destination IP address, directly to the destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. In the case of a device with only a link-local address, this requirement can be paraphrased as "ARP for everything". In many network stacks, achieving this "ARP for everything" behaviour may be as simple as having no primary IP router configured, having the primary IP router address configured to 0.0.0.0, or having the primary IP router address set to be the same as the host's own link-local IP address."