Subject: Re: 169.254/16 IP addresses

From: "Mike Borella" <[email-masked]>
Date: Fri, 14 Apr 2000 10:53:07 -0500

In the 3 interface case, the NAT can map on the MAC.  Some NATs allow this.
It is a poor way of configuring a network, however, I wouldn't be surprised to
see it happen.

-Mike

Thomas Narten <[email-masked]> on 04/14/2000 06:17:42 AM

Sent by:  Thomas Narten <[email-masked]>

To:   Richard Johnson <[email-masked]>
cc:   Mark Thompson <[email-masked]>, [email-masked] (Mike
      Borella/MW/US/3Com)
Subject:  Re: 169.254/16 IP addresses

>     Addresses allocated by this mechanism MUST NOT be routed by any net-
>     work device.  The addresses are designed to be link local addresses.
>     Link local address are to be, by definition, restricted to the local
>     network segment.  Allocation of link-local addresses in an IPv6 net-
>     work is described in [IPv6SAC].

> It's quite obvious why one would not want these addresses routed, but
> there are very good reasons why someone may want to NAT these
> addresses and there's no mention of whether NATing them is looked upon
> as "good" or "bad".  I see no reason why it should be mandated that
> NATing these addresses shouldn't be done.  I would bet that regardless
> of what any document says, someone will end up allowing an option of
> NATing these addresses anyway simply because some customer will demand
> it.

I suspect that one can certainly get away with NATing link-local
addresses in some circumstances. However, there are also new problems
in the more general case that don't occur when net 10 addresses are
used. For example, if a NAT box has 3 interfaces, one to the Internet
and two internal (with link-local addresses being used), then you have
the potential problems that link-local addresses on the two internal
links are not unique. Thus, a NAT implementation would have to do even
more tricks to keep track of which interface a specific NAT state
entry belongs to. But one might argue that this is a scenario where
the exclusive use of link-local addresses is a bad idea anyway, as the
nodes on the two links would have trouble talking to each other
anyway.

Even in the simple case of 2 interfaces (internal plus Internet) one
has to deal with the problem of which interface a given link-local
address belongs to.

Thomas

---

From: "Mike Borella" <[email-masked]>
Date: Fri, 14 Apr 2000 17:48:20 -0500

Out of curiousity, what is the proper way for a NAT to handle global
multicasts when only the private IP space is used?  I don't see this
as being very different, except that the private space may have multiple
routers and a more complex configuration.

Since the group's charter doesn't specifically forbid NATing, somebody
is going to do it. I think that it can be done in a reasonably clean fashion,
without impacting the special properties of linklocal addresses.

-Mike

"Bernard Aboba" <[email-masked]> on 04/14/2000 12:04:19 PM

Please respond to [email-masked]

Sent by:  "Bernard Aboba" <[email-masked]>

To:   "'Thomas Narten'" <[email-masked]>, "'Richard Johnson'"
      <[email-masked]>
cc:   "'Mark Thompson'" <[email-masked]>, [email-masked] (Mike
      Borella/MW/US/3Com)
Subject:  RE: 169.254/16 IP addresses

>addresses in some circumstances.

This can lead to undefined behavior in some circumstances.
Suppose I sent to a global multicast address from a linklocal
address. What is the expected behavior? Does the router NAT
the source address and forward it so that the multicast now
has global scope? Or does the router not forward the multicast
so it is effectively linklocal scope?

One of the reasons we created a linklocal prefix was so that
we could get behavior different from private addressing for
situations where this made sense. If we blur the distinction
then we'll lose the ability to have truly linklocal behavior
when we need it.

---

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 18 Apr 2000 10:17:29 -0700

Thomas,

I understand the reasoning behind restricting link-local addrs from 
being routed. I think that's commonly understood. There is a 
difference with routing through a NAT box though. A NAT box 
translates the link-local address before routing. I'm trying to 
understand the problem with translating a link-local 
address and why we should only translate private addresses.

-myron

---

From: Peter Ford <[email-masked]>
Date: Tue, 18 Apr 2000 13:20:35 -0700

Just like 169.254/16, I would recommend getting another subnet assigned
(probably a class B that could be subnetted).  Using existing private
subnetworks is a bad idea given that corporations have already deployed them
(this is something Microsoft learned when we beta tested the 169.254/16
feature for Windows 98 using net 10.   The biggest complaints came from ISPs
who assign their customers net 10 addresses!)

(to be clear, I am not sure it is worth investing in such networks given
IPv6 is beginning to happen.)

cheers, peterf

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, April 18, 2000 5:06 AM
To: Hattig, Myron
Cc: [email-masked]
Subject: Re: 169.254/16 IP addresses 

> Please clarify exactly what gets blurred and exactly what is lost.
> From the context of a host traversing a NAT box, I see link-local
> addresses as logically equal to private addresses (RFC 1918).

One difference is that by declaring 169.254/16 to be link-local, we
are giving nodes license to simply declare all destinations covered by
169.254/16 as being on-link and directly reachable. I.e., folks will
wire that knowledge into implementations.  If someone then comes along
later and says that some of the subnets of 169.254 are actually on
other links and only reachable via a router, that router will probably
have to do something like proxy ARP to properly handle all devices
that assumed link-local really meant link-local.

It might well make sense to just use one of the already-reserved
private address ranges (e.g. net 10) for doing multi-link
autoconfiguration. Is it reasonable to asume that this technique
(numbering multiple links automatically) will take place ONLY on
isolated networks? I.e., there will be no conflict with net 10? I.e,
are we willing to state definitively that a node will not have both
global addresses and these autoconfigured site-local (to borrow a name
from IPv6) addresses simultaneiously?  I.e., the direction being taken
with link-local addresses is that a node can have both link-local and
global address simultaneously. I'm not sure we want to do the same for
site-local addresses.

Thomas

---

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 19 Apr 2000 08:52:58 -0700

> Research question: Will a Win98 box using a 169.254/16 
> address send out
> an ICMP router discovery message? Will it respond to one? If 
> not, you're
> back to figuring out how to get that NAT box's IP address in as the
> default route in the Win98 box.

Now I understand your point. I'll look into this.

> You haven't answered my question, being "why are we reinventing?"

I didn't answer your question on purpose ... we all have different 
assumptions that we believe. In this case, it's not really worth 
our time to try and convince each other about which assumptions
are correct or not. For now, however, I would like us to keep 
169.254/16 as a NATable address space.

As far as your claim that by doing this it makes link-local (aka 169.254/16)
more like private addresses (aka RFC 1918 addrs), I disagree. The
distinction 
between link-local and private is that one is routable, the other is not.
The
similarity is that neither should be accessible from the public Internet.
Making
private or link-local addrs "NAT"able does not change the distinction or the

similarities between the two address spaces.

Bernard was the one that originally made the claim that link-local should
not
be NATable. Bernard, what are your reasons?

-myron

---

From: "Mike Borella" <[email-masked]>
Date: Wed, 19 Apr 2000 11:18:41 -0500

RFC1918 and 169.254 addresses are treated very differently.
That treatment is orthogonal to whether you can or should NAT
them.

This discussion isn't off topic because it may influence the wording
of the draft(s).  This discussion isn't academic because its a real
problem.

Just because the marketplace has accepted a reasonably
but non-robust solution doesn't mean that this is the only way or
even the prefered way of doing things.

-Mike

Daniel Senie <[email-masked]> on 04/19/2000 10:09:48 AM

Sent by:  Daniel Senie <[email-masked]>

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

Mike Borella wrote:
>
> If the RAS is handing out Zeroconf addresses, how is that different
> from DHCP handing the same addresses (which seems to be a bad thing)?

No different. I'm arguing that in both cases, we're turning 169.254/16
into another RFC 1918-type block. I'm not sure that's a good idea.

> The system is no longer zeroconf, and we're back to the problem that
> forcing private address spaces on users decreases the robustness of
> the overall solution.

>
> I don't think that there's a strong enough argument for prohibiting
> NATing of this space.

I'm not sure it's within the zeroconf charter to decide one way or the
other. The link local address space came out of work outside this group.
I'd sure like to see those who did that work consulted, before we go
changing the way it's used.

>  While NAT/DHCP with net 10 may be preferable in
> some situations, it does require configuration or administrative knowledge,
> at least to avoid collisions.

Net 10 isn't the only space. But this is WAY off topic.

The underlying question, which I still don't see a good answer to, is
why we're reinventing mechanisms which work (NAT with DHCP in one box)
and which are selling rapidly in the marketplace. WHAT PROBLEM is this
supposed to solve?

If it's just an academic exercise, can we please put this idea aside and
get back to the work of this WG?

>
> -Mike
>
> Daniel Senie <[email-masked]> on 04/19/2000 07:21:01 AM
>
> Sent by:  Daniel Senie <[email-masked]>
>
> To:   Mike Borella/MW/US/3Com
> cc:   [email-masked]
> Mike Borella wrote:
> > Who would set up a zeroconf network for RAS?  RAS is
> > always administered if only because you choose an IP to
> > give to dial in clients, and your RAS router needs a static IP.
> > I doubt that there are any RAS products on the market that
> > currently or are planning on using 169.154/16.  That would be
> > a mess.
>
> I agree completely it'd be a mess. My point is that moving 169.254/16
> closer to being usable as another block of private address space may
> well lead to a result like that.
>
> RAS/NAS boxes, if not specifically programmed to avoid using this block,
> will happily use that range for dialup users. The IP address of the
> RAS/NAS doesn't necessarily have any bearing on the IP addresses handed
> out to dialup users (at least with some NAS vendors).
>
> >
> > -Mike
> >
> > Daniel Senie <[email-masked]> on 04/18/2000 10:06:20 PM
> >
> > Sent by:  Daniel Senie <[email-masked]>
> >
> > To:   Mike Borella/MW/US/3Com
> > cc:   [email-masked]
> > Mike Borella wrote:
> > > 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.
> >
> > 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.
> >
> > > "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)
> > > 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
> >
> > --
> > -----------------------------------------------------------------
> > Daniel Senie                                        [email-masked]
> > Amaranth Networks Inc.                    http://www.amaranth.com
>
> --
> -----------------------------------------------------------------
> Daniel Senie                                        [email-masked]
> Amaranth Networks Inc.                    http://www.amaranth.com

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

---

From: Peter Johansson <[email-masked]>
Date: Wed, 19 Apr 2000 12:11:07 -0700

In a message dated 00-04-18 18:46:14 EDT, [email-masked] writes:

<<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.>>

I concur with Myron. There may be devices on the home network that obtain a
link-local address but also need to communicate with the larger
Internet---and may not be designed to accommodate two IP addresses.

Whatever the obstacles, real or suspected, to this solution, they need to
be resolved by this group.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Tony Flores <[email-masked]>
Date: Thu, 20 Apr 2000 09:54:15 -0500

well....there you have it, and quite eloquently put. 

Tony Flores

-----Original Message-----
From:	Peter Ford [SMTP:[email-masked]]
Sent:	Wednesday, April 19, 2000 2:27 PM
To:	Richard Johnson; Mark Thompson
Cc:	[email-masked]
Subject:	RE: 169.254/16 IP addresses

The core scenario for the 169.254/16 addresses is when two machines
appear on a subnetwork that IS NOT connected to the Internet.  When we
designed and built 169.254/16 behaviour for Windows 98, we assumed that
if a NAT box appeared on the subnetwork then it would also be a DHCP
server and the DHCP server would feed the host its gateway address.  The
Windows 98 second edition (SE) Internet Connection Sharing feature  does
this.  

There is a decision made if the DHCP server serves up 169.254/16
addresses or some other private network range.  I personally feel that
hosts and their applications should be able to cope with address
changes. (easy to say, much harder to implement, and even harder to
implement really well).  I feel that in general the simplest approach is
to keep the original address that the autoconfigured host gave to
itself.  Others argue that it is a good end user experience that the
address changes (the address is an indicator of address configuration
state).

I vote with Myron in that such addresses should be NATable as it is a
derivative of the theory that ALL addresses should be NATable.

cheers, peterf

-----Original Message-----
From: Richard Johnson [mailto:[email-masked]]
Sent: Friday, April 14, 2000 2:16 AM
To: Mark Thompson
Cc: [email-masked]
Subject: Re: 169.254/16 IP addresses

Mark Thompson writes:
 > I think the idea is that link-local addresses are used to communicate
 > *only* with devices on the local link, and that global addresses (or,
 > IYL, NATable addresses from Net10 etc.) are used for the "I want to
 > route to the outside world" cases.
 > 
 > Actually, the draft does imply that IPv4 link-local autoconf is used
to
 > "hunt" DHCP servers that appear after the local host comes up
(Section
 > 4, "Ongoing checks for a DHCP server"). The idea is that your device
 > gets a link-local address when no globally-routable one (or NATed
one)
 > is discovered, and then runs with it up until a DHCP server (or NAT
gw)
 > becomes available.

Unless there's some more recent version of the draft than what I've
seen, there's no mention of NAT in the draft at all.  It says:

 > If you know by *specification* that the link-local addresses are only
ever
 > going to be seen by local devices, and that routers by
*specification*
 > MUST NOT route/munge/forward packets destined to those addresses, I
can
 > see cases where you can make certain assumptions about the
communication
 > (topological location, security, etc. etc.) that you can't otherwise.

I think the strongest reason here would probably be security, but even
that somewhat fails when one starts thinking of wireless networks.
Sounds like a false sense of security to me.

/raj
 << File: ATT00001.html >>

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 21 Apr 2000 09:57:55 -0700

Daniel, 

Thanks for pointing out the references. I assumed those active 
in the discussion new about them. You have good points below.
I would like to add one more point. It is possible to specify
a protocol that only utilizes parts of RFC 1256, thus your 
statements that:

> 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.

and
 
> I don't know if there's an understanding that finding the gateway also
> requires multicast. 

may not be accurate. I'd call this recycling the spokes instead of
reinventing the wheel.

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 21 Apr 2000 10:14:34 -0700

> b. To provide some extra security as described by Thomas.

I could argue either way that the extra security is a bug or a feature.

-myron

---

From: Tony Flores <[email-masked]>
Date: Sun, 23 Apr 2000 16:05:46 -0500

agreed

Tony Flores
-----Original Message-----
From:	Richard Johnson [SMTP:[email-masked]]
Sent:	Thursday, April 20, 2000 8:00 PM
To:	Peter Ford
Cc:	Mark Thompson; [email-masked]
Subject:	RE: 169.254/16 IP addresses

 > derivative of the theory that ALL addresses should be NATable.

I agree for that reason and also because I can guarantee you that such 
address WILL be NATed by someone somewhere anyway, and no one on the
Internet will know or care.

/raj

---

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 24 Apr 2000 11:52:23 -0700

I agree that it would be a bad idea for a DHCP server to distribute address
from 169.254/16. 

-myron

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Apr 2000 15:08:41 -0400

At 11:24 AM 4/24/00 -0700, Peter Ford wrote:
>What problem are people trying to solve here?

I was mostly trying to solve the problem of this particular behavior not 
being written down.  I can imagine individuals with opposing viewpoints 
getting into a pissing match - perhaps every six months or so? - about 
"DHCP and 169.254/16: Threat or Menace?"

>What breaks when DHCP configures a 169.254/16 address for an end system?

I don't know - if there is something that breaks, we ought to come to 
agreement and document the decision somewhere...

- Ralph