FreeBSD eats 169.254.x.x addressed packets

[Jeremy Chadwick]

On Tue, Jun 08, 2010 at 02:49:20PM -0400, Peter C. Lai wrote:
> On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote:
> > On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote:
> > > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote:
> > > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote:
> > > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when
> > > >>4.9 didn't?
> > > >
> > > >The following output would help:
> > > >
> > > >- ifconfig -a
> > > >- netstat -rn
> > > >- Contents of /etc/rc.conf
> > > >
> > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year:
> > > >http://security.freebsd.org/
> > > >
> > > Hi Jeremy,
> > > 
> > > I am not sure that information is relevant. We have two systems configured
> > > identically one using 4.9 the other 6.3.
> > 
> > My concern was that someone had botched something up in rc.conf or
> > during the OS upgrade/migration, resulting in there being no loopback
> > interface.  I also wanted to verify that your routing table looked
> > correct for what ifconfig showed.
> > 
> > Other users pointed you to RFC 3927.  Wikipedia has this to say:
> > 
> > http://en.wikipedia.org/wiki/Link-local_address
> > 
> > "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses.
> > However, the first and last /24 subnet (256 addresses each) in this
> > block have been excluded from use and are reserved by the standard.[1]"
> > 
> > I read this to mean 169.254.0.0/24 and 169.254.255.0/24.
> > 
> > Your previous ifconfig statement shows:
> > 
> > > $ ifconfig rl0
> > > rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > >         options=8<VLAN_MTU>
> > >         inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255
> > >         inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255
> > >         ether 00:30:18:ae:7c:77
> > >         media: Ethernet autoselect (100baseTX <full-duplex>)
> > >         status: active
> > 
> > With this configuration, you're using both the first and last /24
> > netblocks -- 169.254.0.0 for your network address, and 169.254.255.255
> > for your broadcast address.
> > 
> > You should be able to avoid this by using 169.254.1.0/24.
> > 
> 
> RFC 3927 also has complicated rules involving when one can or should not
> use a link-local address on the same interface as a routable IP, so at
> best your configuration may not be supported anyway. One should not use
> a link-local address as if it were under RFC 1918 rules, in particular
> because link-local involves self-assigned addresses and internal
> conflict mitigation.

Thanks for the addendum, Peter.  You're absolutely right.

Furthermore, I looked at the IN_LINKLOCAL() macro and relevant code:

include/netinet/in.h:#define IN_LINKLOCAL(i)	(((u_int32_t)(i) & 0xffff0000) == 0xa9fe0000)

-       if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) {
+       if (!ip_fwdlinklocal && IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) {

I assume ip->ip_dst.s_addr is the source address of a packet destined
somewhere (in the OP's case, this would be 169.254.1.1).  If my
assumption is correct, then the above macro filters out the last two
octets of the source address, leaving only the first two, comparing
those to 0xa9 and 0xfe respectively (decimal = 169 and 254).  If true,
then the if() statement applies, which I assume blackholes it.

Based on that, I don't think using a smaller block like 169.254.1.0/24
would work; seems FreeBSD does what it does against the entire /16.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |