Subject: RE: 169.254/16 IP addresses

From: "Peter Ford" <[email-masked]>
Date: Wed, 19 Apr 2000 12:27:27 -0700

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:

    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.

 > 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

---

From: Richard Johnson <[email-masked]>
Date: Thu, 20 Apr 2000 17:59:54 -0700 (PDT)

> 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: Thomas Narten <[email-masked]>
Date: Fri, 21 Apr 2000 08:32:29 -0400

One reason why NATting link-local might not be so great is that some
would argue that link-local addresses provide a limited form of
security. I.e., devices with such address won't allow communication
with remote devices (i.e., those behind a router). While not providing
any sort of iron-clad security, it does raise the bar somewhat. If one
starts NATing such devices, that assumption is of course no longer
valid.

This would add an interesting twist to the "NATs provide security"
myth.

Of course, as others have pointed out, declaring that one MUST NOT NAT
such addresses is probably out-of-scope and pointless (i.e., it will
be ignored). What would be good of course, is to document the
potential dangers that lurk when NATting such addresses.

Thomas

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 21 Apr 2000 09:48:03 -0700

I've asked myself the question "Why is 169.254/16" a linklocal
prefix at all?" There are several reasons that occurred to me:

a. To prevent it from being used in private addressing so as to
   avoid conflicts with enterprise networks.
b. To provide some extra security as described by Thomas.
c. To enable a sufficiently large (unsubnetted) address space so as to
   reduce the probability of conflicts even with LOTS of devices.

There are also reasons why having 169.254/16 as linklocal is awkward:

d. having to switch addresses when a DHCP server comes up.
e. having to use private address space when a DHCP server comes up
   (creates possibility of conflict with enterprise private address
   space).

Is there some compromise which allows us to retain the advantages of
a-c while perhaps addressing problems d-e? Can we get this into a 
document that is sufficiently specific so that we all can implement the
required behavior consistently? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Thomas Narten
Sent: Friday, April 21, 2000 5:32 AM
To: [email-masked]
Subject: Re: 169.254/16 IP addresses 

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 21 Apr 2000 12:59:33 -0400

>    reduce the probability of conflicts even with LOTS of devices.

All good reasons. I might add, because addresses are generated
randomly, one needs to check for duplicate addresses. ARP is used, and
ARP only works on a single link. Hence, link-local scope. Also, I
think the original problem being solved was an isolated dentist office
that had no routers and no connection to the internet.

> d. having to switch addresses when a DHCP server comes up.

I don't know that this is in fact a requirement, though that is
certainly what the first implementations did. I.e, are we talking
about an implementation issue, or an issue with link-local addresses
per se?  Having 169.254 addresses be link-local address makes it
cleaner for such addresses to coexist with a second (i.e.,
DHCP-learned) address simultaneously. Why give up the link-local
address just because you have global address?  Of course, you probably
want to favor the global address when selecting addresses, so there
are some details here.

(Note that link-local addresses exist in IPv6 along with other
addresses and its fairly well understood how to make them coexist with
other addresses.)

>    (creates possibility of conflict with enterprise private address

Yes. I would imagine a great danger lies here. :-)

Thomas

---

From: Daniel Senie <[email-masked]>
Date: Fri, 21 Apr 2000 13:32:07 -0400

> that had no routers and no connection to the internet.

In order for older versions of Windows to talk between machines, the
systems would come up by default running netbios over Ethernet (netbeui
I think is the right term). With link-local scope, it's now possible to
have netbios function on a local network without having to have any
protocol other than IP (i.e. we lose the netbios over Ethernet traffic,
and instead get netbios over IP everywhere).

> want to favor the global address when selecting addresses, so there

Many IP stacks, especially the ones that are in smaller embedded
systems, have traditionally not had all of the extra code necessary to
handle multiple IP addresses on the one interface.

> addresses and its fairly well understood how to make them coexist with

IPv6 stacks, due to the inclusion of link-local addressing and other
features, necessarily handle multiple addresses on the same interface
from the get go. Of course there are also relatively few implementations
of IPv6 in embedded systems, but there's also been an increase in the
CPU power which can be purchased at a reasonable price for embedded
systems.

> Yes. I would imagine a great danger lies here. :-)

Depends on your target market. A while ago, folks were interested in
using the link-local addresses with gateways to simplify home networking
issues. I would hope most home networks don't have an excessive number
of private address blocks in simulatenous use...

Anyone firing up a DHCP server on a corporate/enterprise network will
either be involved in the infrastructure of that entity, or will be
receiving a knock on their door from the person(s) responsible once
they've destroyed a piece of the network.

I'm not convinced the issue of private space conflicts is any better or
worse with what's being discussed here than it was before. If the
argument is that more private space is needed, that's a separate matter
that could be addressed with the appropriate parties (but still isn't
related to zeroconf, unless zeroconf wants a block other than 169.254/16
or RFC 1918 space to play in).

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 23 Apr 2000 11:55:28 -0700

>Having 169.254 addresses be link-local address makes it
>DHCP-learned) address simultaneously. 

Well, they might coexist reasonably on hosts, but what about
on devices that only have linklocal scope addresses? I am
somewhat confused about how this is supposed to work in an
multi-segment environment. Are we saying that gateways will
function as brouters, bridging the 169.254/16 prefix and
routing other prefixes? So now we have broadcasts for the
linklocal prefix propagating throughout the enterprise? 

If it doesn't work this way, how are we to prevent address
conflicts among linklocal-only devices separated into
linklocal islands? And how would someone be able to access 
a printer that wasn't on their link?

And if this is supposed to only happen on small networks
only, how is the device supposed to tell the difference
if it doesn't look for a DHCP server any more before
auto-configuring itself? 

Inquiring minds want to know :)

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Apr 2000 09:07:29 -0400

Prompted by Bernard's recent questions...

Is the 169.254/16 prefix a linklocal prefix, or specifically an 
autoconfiguration linklocal prefix?   The answer to that question would 
help us decide whether a DHCP server ought or ought not hand out addresses 
with a 169.254/16 prefix.

- Ralph