[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