Subject: RE: 169.254/16 IP addresses

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 10 May 2000 15:06:43 -0700

Hi Stuart,

I'm not sure your question below is the key question or not because it does
not provide any insight as to why we should or should not NAT link-local IP
addresses. Sorry but I don't see how your suggested mod to your draft ;-)
adds any weight (pro or con) to the debate. 

There has been no clearly stated reason to preclude NATing link-local
addresses. NATing link-local addresses does not harm end-points nor
end-to-end communication any more or less than any other NATed address.

-myron

> -----Original Message-----
> From: Stuart Cheshire [mailto:[email-masked]]
> Sent: Monday, May 08, 2000 6:04 PM
> To: [email-masked]
> Subject: Re: 169.254/16 IP addresses
> 
> 
> >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: Daniel Senie <[email-masked]>
Date: Thu, 11 May 2000 08:34:24 -0400

> adds any weight (pro or con) to the debate.

I'm not sure if it really does. But he raises one issue we've discussed
before... how to FIND the gateway. Stuart suggests the gateway could
proxy-arp for addresses off the local LAN. This could be rather hostile
to end-stations, I would think... the gateway would have to generate a
proxy-arp for EVERY address an end station tries to reach that's off
169.254/16. This could result in a fairly large amount of traffic, and
large ARP tables. It seems even uglier than using ICMP router
discovery...

> end-to-end communication any more or less than any other NATed address.

It does, however, prevent the gateway from giving the end node any
configuration information that may be required. This includes:

- no default gateway (which is why we're talking about proxy
      arp and ICMP router discovery)
- no name server information. It's going to be hard to browse
      the Internet with no DNS server. Some sort of service location
      protocol could, of course, help here.

DHCP or manual configuration can convey many other parameters as well.
The issue is that by trying to devise a method for using NAT on a block
of IP addresses which are self-assigned, we lose access to a great deal
of useful and needed information.

The question I would ask is whether doing NAT on 169.254/16 is
sufficiently important a function that we should also re-invent or
substantially alter other mechanisms to attain this goal? Given every
NAT box out there has DHCP server capabilities, it's not at all clear
why it's worth the re-engineering effort.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com