Re: [lwip-users] OT: Is the AutoIP range a special case IP addressrange?

[David Empson]

----- Original Message ----- 
From: "Simon Goldschmidt" <address@hidden>
To: "Mailing list for lwIP users" <address@hidden>
Sent: Tuesday, November 16, 2010 8:01 PM
Subject: Re: [lwip-users] OT: Is the AutoIP range a special case IP 
addressrange?


> David Empson <address@hidden>
> > > OT: Is the AutoIP range a special case IP address range?Bill Auerbach
> > > wrote:
> > >   I just found out through testing that the PC with a NIC in the
> > > 192.168/16 subnet (netmask 255.255.255.0) will ping and connect to 
> > > devices on the
> > > physical network in the AutoIP range (169.254/16).  This is on a WinXP 
> > > PC.  I
> > > find the ARP table contains AutoIP addresses and I can ping and open
> > > connections to the device at the AutoIP address.
> > >
> > >   Is this something that is expected to occur?
>
> Yes, it's expected behaviour.
>
> > >  Is it specific to Windows?
>
> No, it's defined in RFC 3927.
>
> > >  I've not come across any RFC that mentions that this 'bridging' should 
> > > or
> > > can occur.
>
> As David said, no bridging required. Here's an excerpt from RFC 3927:
> > > > > snip >>>>
> 1.8.  Communication with Routable Addresses
>
>   There will be cases when devices with a configured Link-Local address
>   will need to communicate with a device with a routable address
>   configured on the same physical link, and vice versa.  The rules in
>   Section 2.6 allow this communication.
>
>   This allows, for example, a laptop computer with only a routable
>   address to communicate with web servers world-wide using its
>   globally-routable address while at the same time printing those web
>   pages on a local printer that has only an IPv4 Link-Local address.
> <<<< snap <<<<
>
> Windows might use a 2nd IP address in the AutoIP range, but that's not 
> necessary
> if AutoIP is implemented correctly in all devices: IP traffic to 
> Link-Local address
> should mainly always be sent directly by using a local ARP request.

I hadn't read that RFC in detail. It turns out I was wrong on that point.

I've now confirmed the behaviour, using my MacBook Pro running Mac OS X 
10.6.5, a PC running Windows XP SP3, and an old PowerMac running Mac OS 9.1.

1. If the Mac OS X computer is configured with a static IP address, it is 
able to communicate with any device using an AutoIP address. Network traffic 
is sent by Mac OS X using its static IP address. The computer does not need 
to allocate an AutoIP address. ARP requests look like "who has 169.254.x.y 
tell 192.168.z.w".

2. If the Mac OS X computer is configured with an AutoIP address, it is able 
to communicate with Windows XP using a static IP address.

3. Windows XP behaves exactly the same as Mac OS X. Communication works 
whether the computer is configured with a static IP address or AutoIP 
address.

4. If the Mac OS 9 computer is configured with a static IP address, it is 
unable to communicate with any computer that is using an AutoIP address. 
This appears to be a limitation of the Mac OS 9 TCP/IP stack, as Wireshark 
shows that pings are being sent by the other computers, but the Mac OS 9 
computer is not replying to them, and it doesn't send any pings.

5. If the Mac OS 9 computer is configured with an AutoIP address, everything 
works, but I noticed one oddity: ARP replies sent by the Mac OS 9 computer 
use an Ethernet broadcast. It doesn't do this if configured with a static IP 
address.

Mac OS 9 predates RFC3927 by several years, so I expect (4) and (5) are 
abnormal behaviour due to an old implementation of AutoIP.

> BTW: This does *not* work for me under Windows XP, where I have to 
> manually
> configure a 2nd address in the AutoIP range. Which version of windows were 
> you
> using, Bill and David?

Works for me on Windows XP SP3. Behaviour appears to be identical to Mac OS 
X.

The only issue I noticed with Windows XP is a delay when changing the 
network configuration, before it is able to communicate (in one case it was 
about 30 seconds). I waited until ipconfig /all showed valid IP addresses 
before I was able to test properly.