[CUWiN-Dev] ipnat question + patch

David Young dyoung at pobox.com
Wed Apr 20 17:37:32 CDT 2005


On Wed, Apr 20, 2005 at 05:07:35PM -0500, Bill Comisky wrote:
> 
> The CUWiN gateway in our testbed (currently rev 3014) is mapping 
> 10.0.0.0/8 to the address received via DHCP from the LAN in the 
> /etc/ipnat.conf file.  Like:
> 
> map sip0 10.0.0.0/8 -> 192.168.2.104/32 portmap tcp/udp 10000:20000
> map sip0 10.0.0.0/8 -> 192.168.2.104/32
> 
> Should this be "169.254.0.0/16 -> ..." now?  We recently cannibalized our 

I should give some background on these 169.254 numbers, since they may
cause some confusion.

BTW, 169.254/16 contains the so-called "IPv4 link-local" numbers.
There is a draft RFC that describes these numbers and their uses.
The gist of it is that they are only guaranteed unique on a single "link"
or "broadcast domain," and no router should forward a packet with a
link-local source address.

I assign one number in 169.254/16 to each node's wireless interface.
I also assign a number 10.0.a.b/32---the /32 is important, since it keeps
ARP from running.  hslsd binds 169.254.x.y and sends its Hellos/LSUs
from that address.  hslsd also uses 169.254 numbers for (wireless)
nexthops.  I use the IPv4 link-local numbers to work around the issue
with the unified ARP/routing table that keeps NetBSD from storing both
a link-layer and IP nexthops for the same destination.

The upshot is that you can ping 169.254.255.255 to see who a router's
neighbors are, but you cannot ping arbitrary nodes on the network using
their 169.254 address.  Use a 10/8 address, instead.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933


More information about the CU-Wireless-Dev mailing list