Subject: Re: 169.254/16 IP addresses

From: Stuart Cheshire <[email-masked]>
Date: Mon, 8 May 2000 18:04:18 -0700

>Of course, as others have pointed out, declaring that one MUST NOT NAT
>such addresses is probably out-of-scope and pointless (i.e., it will
>be ignored). What would be good of course, is to document the
>potential dangers that lurk when NATting such addresses.

Wow! I've been away, and it took me a while to catch up.

Here is the key question about whether you can use NAT with 169.254/16 IP 
addresses: Can a packet with a 169.254 source address *EVER* be sent to a 
non-169.254 destination address? As currently written, 
draft-cheshire-ipv4-linklocal-00.txt says not. It says:

>A host SHOULD NOT establish communications from a global source
>address to a link-local destination address, or vice versa.
>Link-local addresses should only be used for communication with
>other link-local addresses on the same link.

A host complying with this requirement would simply refuse to generate a 
packet with a 169.254 source address and a global destination address, so 
the NAT gateway would simply not get the opportunity to translate the 
packet, because the packet would never exist.

This is a tricky question. How does the host know that there's a NAT 
gateway out there? If a host sends out a packet from 169.254.1.2 to 
17.254.0.91, and there is no NAT gateway, then the host will never get a 
reply. On the other hand, does it really hurt to try?

On considering all the arguments, I think I'll revise 
draft-cheshire-ipv4-linklocal-00.txt to say that a multi-homed host 
should always *prefer* a non-169.254 source address when sending to a 
non-169.254 destination, but if a host *only* has a 169.254 address, then 
it MAY use ARP to resolve all addresses, and send packets with 169.254 
source addresses to any destination address for which it gets an ARP 
reply.

This means that a vendor could make a NAT gateway that issues proxy-ARP 
replies for all (non-169.254) addresses, and a host using self-configured 
link-local addresses would transparently work that that device.

It also means that a device which doesn't have a 169.254 address can 
still communicate with 169.254 devices on the same physical link, as long 
as it is prepared to answer ARP requests from 169.254 devices, and send 
IP packets to 169.254 destination addresses.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 8 May 2000 18:58:03 -0700

>There is a small issue with DHCP server discovery related to zeroconf 
>addresses - after a host chooses a link-local autoconfig address, should 
>the host's DHCP client use 0.0.0.0 or the host's link-local address when 
>broadcasting to find a DHCP server?
>
>My guess would be 0.0.0.0 - either way, the choice ought to be documented 
>somewhere...
>
>- Ralph

The problem here is not so much sending out the packet as it is receiving 
the reply. It is fairly easy with most IP stacks to spoof the outgoing 
source address, so that if the interface has address 169.254.1.2, you can 
nevertheless send out a packet that appears to come from source address 
0.0.0.0.

The problem is that when the DHCP server then unicasts a reply to address 
17.1.2.3, most IP implementations will discard the packet because the 
destination address in the packet does not match the interface address.

When the machine is booting and running DHCP and the interface has no 
address yet (i.e. the interface address is 0.0.0.0), the IP stack knows 
that 0.0.0.0 is "special", and it ought to be looking for DHCP replies 
even though they are apparently addressed to some other unknown 
destination address. When the machine trying to run DHCP on a "live" 
interface, this special hack in the IP code is no longer active.

The workaround that Mac OS currently uses is to set the "broadcast reply" 
bit in the request, because broadcasts are received no matter what the 
interface address is, but some DHCP servers and some BOOTP relay agents 
do not honour the "broadcast reply" bit.

I did try setting ciaddr in the DISCOVER packet to the current interface 
address, in the hope that the DHCP server might unicast its OFFER to that 
address instead, but to no avail.

The only workaround I can think of is that the core IP stack need to know 
that UDP port 68 is "special", and if there is a listening client (or 
clients) on UDP port 68, packets addressed to that port need to be 
received, no matter what the destination IP address says.