Subject: RE: 169.254/16 IP addresses

From: "Mike Borella" <[email-masked]>
Date: Tue, 18 Apr 2000 17:56:07 -0500

This is actually directed at an earlier message...

I agree with the comments about NAT/DHCP being a good thing
when it is available, and DHCP allocating private IPs.  But what about
when such a setup dials into a privately-addressed corporate network?
Forcing any particular space on a user has its drawbacks.  Hopefully,
the zeroconf space will be the exception.

-Mike

"Hattig, Myron" <[email-masked]> on 04/18/2000 05:45:06 PM

Sent by:  "Hattig, Myron" <[email-masked]>

To:   [email-masked]
cc:    (Mike Borella/MW/US/3Com)
Subject:  RE: 169.254/16 IP addresses

The only thing I wish us to agree on is that we don't
produce a spec that says link-local addresses are not
"NAT"able. See below comments only address this point.

> I disagree with both of you. Reasons:
>
> 1. NAT boxes are themselves routers. They may contain code to
> specifically guard against ingesting packets from link-local space.

Certainly a vendor could build
a NAT box that could have a LAN interface with a link-local address
and other devices on the LAN segment could communicate to the NAT
box through the LAN interface that is using a link local address.
This has no negative affects on other NAT boxes with DHCP servers
or the clients that connect to those other NAT boxes.

> 2. NAT Boxes often contain DHCP servers for dealing with the
> local LAN.
> DHCP servers specifically must not use link local addresses.

Agreeing or disagree that link-local address are "NAT"able has
no affect on this case because link-local addrs are not used.

> 3. Gateway/default route discovery: to use link-local
> addressing with a
> NAT, some means of gateway discovery must be employed to determine the
> IP address of the NAT box. This will have to be icmp router
> discovery or
> other mechanism. Otherwise, the end stations will not know
> where to send
> packets which are destined beyond the local network.

Router discovery would work quite nicely I think since the NAT box
is a router.

> 4. A large installed base of systems exists which treats 169.254/16 as
> link-local space only, namely Win98 and later. It's not clear changing
> the rules at this time can be done in a compatible fashion.

Win98 and later boxes communicate just fine with link-local addresses
today. How does agreeing or disagree that link-local address are "NAT"able
affect this?

> 5. Since nearly every NAT box on the market also supports
> DHCP, why are
> we trying to reinvent the wheel here? Why not just let that NAT box be
> the DHCP server and be done with it? I guess this all comes down to,
> "what problem is it that we're trying to solve?" Seems to me
> the proper
> and workable solutions are already in place, in proven, installed
> product.

Again, if someone uses DHCP in the NAT box then there are no questions
about link-local addresses.

So far, I don't see anything breaking if we allow link-local addrs to
be "NAT"able.

-myron

---

From: Daniel Senie <[email-masked]>
Date: Tue, 18 Apr 2000 23:06:20 -0400

> the zeroconf space will be the exception.

Until the network they're connecting into has decided to use this
address block.

Sooner or later, you get into trouble if you want to have one private
address space cascade off of another. This is where using NAT technology
gets evil, and where proper planning is required.

We've got 10/8, 172.16/12 and 192.168/16. That's a lot of space...
claiming we need to use 169.254/16 to solve earlier planning mistakes is
questionable... I understand the motivation, but I'm not sure it's a
good reason.

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