Subject: RE: 169.254/16 IP addresses

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 17 Apr 2000 17:26:09 -0700

> This is why I think zeroconf needs to allow for autoconfigured
> addresses in ranges other than just link-local.  Given that there are
> ways to discover the local network number and mask, a device 
> should be 
> able to do "claim and defend" autoconfiguration in that range as well.

I agree. The autoconf protocol should use any range of addresses. 
By using router discovery ICMP packets, the host can learn the appropriate 
subnet from which to choose an IP address. If there are no routers
then it can step back to link-local addresses.

-myron

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Apr 2000 22:18:29 -0700 (PDT)

> subnet from which to choose an IP address.

The ICMP router discovery protocol I know of doesn't carry subnet information -
it just carries the IP addresses of the routers. So you must be talking about
a different/extended protocol here.

I hope your are not assuming /24 subnetmasks.

   Erik

---

From: Daniel Senie <[email-masked]>
Date: Fri, 21 Apr 2000 08:14:08 -0400

> a different/extended protocol here.

As you point out, the above statement is incorrect.I recommend a reading
of RFC1256 to those who have not been there.

A mechanism does exist for finding the subnet mask over ICMP. Reading in
RFC950, there are two messages added to ICMP to handle this: "Address
Mask Request" and "Address Mask Reply".

It should be noted that if the NAT isn't present to indicate the ICMP
Mask Reply, not much will work.

> I hope your are not assuming /24 subnetmasks.

No need... 169.254/16 should not be subnetted. The last 16 bits of the
address are chosen by either hash or randomness, then tested for
duplication. So, a mask of /16 could probably be assumed.

Other comments

For those who are so convinced NATing 169.254/16 is such a great idea,
consider the additional code required in EVERY end station on such a
network. The tradeoff is to remove DHCP Client, and instead implement IP
Multicast, since ICMP Router Discovery requires that (local multicast).

On the NAT box side, the saving is not implementing DHCP, something
which is already in nearly all of the NAT implementations, is quite
small code-size-wise, and rather simple to implement, and instead
implement 169.254/16 address allocation. The NAT would also have to
implement ICMP Router Discovery protocol, something not all routers and
NAT boxes presently do. This requires multicast support in the NAT box's
LAN drivers, as well as its IP stack.

Indeed, RFC1812 (router requirements) indicates ICMP Router Discovery
MUST be implemented on interfaces which support IP Multicast. In cases
where IP Multicast isn't supported, ICMP Router Discovery is not either.

So, go ahead if you wish and define this as required for zeroconf, just
be sure you know what you're defining. From the discussions to date, it
is clear that at least some who are championing this cause really didn't
understand about the need to find a default gateway, or an address mask.
I don't know if there's an understanding that finding the gateway also
requires multicast. I still believe you're reinventing the wheel, and
doing it in a way that's harder/more costly than what we already have.
I'm also not convinced this is worth the time and effort we've spent
discussing it, let alone the extra effort small embedded IP stacks will
have to go through to implement it, but if necessary the marketplace can
decide those matters.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com