FreeBSD eats 169.254.x.x addressed packets

[Jeremy Chadwick]

On Wed, Jun 09, 2010 at 07:59:16AM -0400, Stephen Clark wrote:
> On 06/08/2010 03:00 PM, Stephen Clark wrote:
> >On 06/08/2010 02:49 PM, 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.
> >>
> >Again what happened we had a box in the field that was running 4.9 being
> >used as a router/nat/vpn/firewall device. It was handing out ip addresses
> >to the internal lan using the range 169.254.202.0/24, who knows why this
> >address range was picked. It worked great but
> >the hardware died, so we were replacing it with our current SW which is
> >based on 6.3 we duplicated the configuration and have been struggling
> >trying to
> >get it to work for the customer since Saturday with no luck. Today I
> >finally
> >tried to ping the internal address from the box itself and it wouldn't
> >ping,
> >so I started trying using other addresses on the internal interface and
> >they
> >worked but not 169.254.202.1. In googling I discovered that 169.254/16
> >was supposed to be assigned if a box couldn't obtain an ip but saw
> >nothing about
> >an OS dropping them.
> >
> >So anyway I know the reason behind the change now.
> >
> One final comment - I still don't understand why FreeBSD "won't" respond to pings
> when it has an address like 169.254.1.1. I can ssh to the unit but it won't
> respond to pings. I tried setting up a linux box with an address like
> 169.254.1.2 and it "would" respond to pings.

I tried to explain it as best as I could here:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057191.html

The IP stack (not a firewall, etc.) is basically blackholing the packet.

-- 
| 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 |