FreeBSD eats 169.254.x.x addressed packets

[Stephen Clark]

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.

-- 

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)