link-local IPs (Was "Re: 169.254.x.x (Dramatic increase in UDP Port 137 (NetBIOS Name Service) probe activity)")

[rdump () RIVER COM (Richard Johnson)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At 02:09 -0700 on 3/29/00, Pavel Kankovsky wrote:
> On Sat, 25 Mar 2000, Jeffrey D. Carter wrote:
>
> > There is one other anomoly in the data below: 4 of the probe clumps
> > include an interleaved series of a remote address and an address in the
> > 169.254.0.0 netblock....
>
> 169.254.0.0/16 is the netblock of choice for another silly Windows feature
> called "IP autoconfiguration". Windows pick up a more or less random
> address from this range and start using it if they fail to get an
> IP address by DHCP...or when they have a bad day or something.

169.254.0.0/16 is the IPv4 range reserved for link-local connectivity.  It's
not just Windows that uses it.  (Link-local address autoconfiguration is a
core part of IPv6.)

A DHCP client that cannot reach its DHCP server doesn't know whether the
server doesn't exist, or whether the server exists but doesn't want to talk to
that particular client (perhaps it doesn't like the client's MAC address).

In such a case, DHCP clients fall back on selecting an unused address in the
link-local range.  Having this happen with IPv4 is a natural move as well.
This allows the host to communicate with other hosts in the same predicament,
but it can't talk beyond a router.

There's an RFC dedicated to the option of turning off this behavior in cases
where the client should not have an IP address, even a link-local one:  RFC
2563.  See <http://www.cis.ohio-state.edu/rfc/rfc2563.txt>.

If you see link-local addresses in your firewall logs, you're probably seeing
stray traffic from a lost DHCP client.

Richard

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.2
Comment: www.europarl.eu.int/dg4/stoa/en/publi/166499/execsum.htm

iQA/AwUBOOQrA2KSuJuuNAZUEQJfMwCfb6rxISwBMY3bj2L+NqvteyRYmrQAoKtK
0OmeYXOMK0jbh+3+8dHdbJZj
=ysNw
-----END PGP SIGNATURE-----