Subject: 169.254/16 IP addresses

From: "Martin Djernaes" <[email-masked]>
Date: Fri, 14 Apr 2000 08:55:55 +0200

Hi,

I have here been seeing some discussions about packages sourced from a
member of the IP group 169.254/16, should never leave the local network
- also not translated via NAT or an equal functionally.

I would like to know from you:
- Why?
- Where is this described?

-- 
Regards,
  Martin Djernæs

--------------------------------------------------------------
Martin Djernæs                    [email-masked]
Dipl.-Ing.                             
Alcatel Kommunikations-Elektronik GmbH Tel:+49 (0511) 6747 741
Postfach 3246                          Fax:+49 (0511) 6747 777
30032 Hannover, Germany                http://www.ke-online.de
--------------------------------------------------------------

---

From: Mark Thompson <[email-masked]>
Date: Fri, 14 Apr 2000 08:51:23 +0100

> I would like to know from you:

169.254/16 is the IPv4 "link-local" allocation (do a "whois
[email-masked]"), similar in use to IPv6'es fe80::/8 address
allocation.

> - Where is this described?

In draft-ietf-dhc-ipv4-autoconfig-05.txt at www.ietf.org/internet-drafts

"Yet another reverse-applied bolt-on to v4 to mimic the glory of v6?" *ducks*

Mark/

-- 
iam: networks and distributed systems

---

From: "Martin Djernaes" <[email-masked]>
Date: Fri, 14 Apr 2000 10:33:24 +0200

Hi Mark,

> [email-masked]"), similar in use to IPv6'es fe80::/8 address

That is also fine that the address group is link local, but why
shouldn't it be used as source for a outgoing connection via a NA(P)T
gateway?

Taken in mind that most ISPs only want to provide one IP address for
their end customers, and that the customers wants to connect more than
one computer/device to the internet, we have a problem. If a xDSL/ISDN
router provide NAT functionality the ISP would be happy, the customer
would be happy (and the "protocol people" are unhappy with the "broken"
addressing scheme). So the autoconfig functionality would be an ideal
way to supply the internal network with local addresses (router and
PCs), and the NAT functionality will make sure that the link local
addresses never  are seen outside the local network.

-- 
Regards,
  Martin Djernæs

---

From: Mark Thompson <[email-masked]>
Date: Fri, 14 Apr 2000 09:40:47 +0100

Hi Martin,

> shouldn't it be used as source for a outgoing connection via a NA(P)T

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.

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.

If Steve Deering is listening in on this, I'm sure he'll have valuable
input on the reasons the IPngwg work introduced the link-local strictly
scoped addresses.

Mark/

---

From: "Martin Djernaes" <[email-masked]>
Date: Fri, 14 Apr 2000 11:04:15 +0200

Hi Mark,

> route to the outside world" cases.
I can follow you on this one.

> is discovered, and then runs with it up until a DHCP server (or NAT gw)
That is were I can't see the idea any longer. I have a Win98 PC (or a
Mac) which supports the autoconf feature - the goal is that the user
really can plug an ethernet card into his/hers PC and then the network
runs. So we know now that the autoconf function is running pr. default,
and the machine will try to get an IP address in the link local range.
Now the user plug in his/hers xDSL/ISDN router, with a DHCP server. The
PC would have to get a new IP address, just as any other device on the
local network!
The PCs now have another IP address, and I can access the outside world,
but all "old" devices with a link local address (evtentually. manually
configured) is not reachable any longer!

My point is - why is a link local address range chosen for autoconfig,
when the place where the biggest need for the autoconfig option is at
the home user with little or no knowledge about network topology etc. ?

In this way the home user will see one IP address, and then another IP
address - I even fear that some users will turn off the xDSL/ISDN router
when it is not needed (everybody talks about standby power
consumption)!!!!

> (topological location, security, etc. etc.) that you can't otherwise.
For the knowledged user - I agree.

-- 
Regards,
  Martin Djernæs

---

From: Richard Johnson <[email-masked]>
Date: Fri, 14 Apr 2000 02:15:47 -0700 (PDT)

> is discovered, and then runs with it up until a DHCP server (or NAT gw)

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.

 > (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: Fri, 14 Apr 2000 02:21:21 -0700 (PDT)

> configured) is not reachable any longer!

Actually, I thought the ultimate idea was for the PC to have two
addresses associated with the same interface and thus it would use the 
link-local to talk to the link-local-only devices while still using
the Internet accessible one for communicating to the outside world.

 > the home user with little or no knowledge about network topology etc. ?

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.

/raj

---

From: Thomas Narten <[email-masked]>
Date: Fri, 14 Apr 2000 07:17:42 -0400

> NATing these addresses anyway simply because some customer will demand

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: "Martin Djernaes" <[email-masked]>
Date: Fri, 14 Apr 2000 14:02:04 +0200

Hi Thomas,

> has to deal with the problem of which interface a given link-local
Why?

I am so naive that I expect autoconfig mainly will be used in home (or
small) networks, where there is no knowledged "administrator" avalible.
When this is said, the majority of the "NAT gateways" will be internet
access devices like xDSL and ISDN routers. Here the internet access
interface should not use/support the autoconfig option, but use
DHCP/IPCP/"Static enty" to obtain a valid internet IP addreess. The only
interface with autoconfig is the local LAN (what ever technologi)
interface, and here addresses are unique.

Martin

---

From: Ralph Droms <[email-masked]>
Date: Fri, 14 Apr 2000 08:51:19 -0400

There is a small issue with DHCP server discovery related to zeroconf 
addresses - after a host chooses a link-local autoconfig address, should 
the host's DHCP client use 0.0.0.0 or the host's link-local address when 
broadcasting to find a DHCP server?

My guess would be 0.0.0.0 - either way, the choice ought to be documented 
somewhere...

- Ralph

---

From: "Ralph E. Droms" <[email-masked]>
Date: Fri, 14 Apr 2000 08:58:10 -0400 (EDT)

Or, I suppose, "don't care" is a viable choice, too.  In any event,
documenting the choice will preempt questions in the future...

---

From: Daniel Senie <[email-masked]>
Date: Fri, 14 Apr 2000 09:24:49 -0400

> My guess would be 0.0.0.0 - either way, the choice ought to be documented

Operational experience in a mixed datacenter: various platforms do a
variety of things. This is bad. If a host is running DHCP to get an
address, and has not received such an address from a DHCP server (any
DHCP server) then it should use 0.0.0.0. It didn't get the 169.254/16
address from a DHCP server, and thus the DHCP packets sent to a server
should be from 0.0.0.0.

There are good reasons: 

1. The DHCP server could have multiple interfaces on multiple networks.
In this case, a link-local address may be somewhat ambiguous. Depending
on how the DHCP software is implemented on the server, it may be
difficult to communicate back to the client.

2. Stronger reason: DHCP Relay. This is a function implemented in
routers. Since routers may well know that 169.254/16 is link local, the
DHCP packets are less likely to reach the DHCP Relay code in the router,
whereas the 0.0.0.0 sourced ones will be recognized.

I agree this should all be documented. I'm willing to write it up if an
appropriate WG is willing to sponsor it.

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 14 Apr 2000 10:00:21 -0700

> shouldn't it be used as source for a outgoing connection via a NA(P)T

The original purpose of auto-configuration was adhoc networks, not
networks with a router. I would note that linklocal behavior applies
not only to unicast but also to multicast; routers should not forward
packets from linklocal addresses off the link even if they are sent
to a global scope multicast address. This is useful in preventing
hosts with linklocal scope addresses from interacting globally.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 14 Apr 2000 10:04:19 -0700

>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: Thomas Narten <[email-masked]>
Date: Mon, 17 Apr 2000 12:33:36 -0400

> so it is effectively linklocal scope?

What do NATs do in general with multicast? One BIG problem I can see
is larger sites with multiple NAT/egress boxes. If the multicast
packet reaches more then one egress NAT, multicast packets get
replicated (incorrectly, since the packets are duplicates) out of
different points with different source addresses. Not good for the
Internet.

> then we'll lose the ability to have truly linklocal behavior

Agreed. But if we also talk about a mini-dhcp server that handles
multiple subnets, what prefix is it handing out addresses from? Net
10?

Thomas

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Mon, 17 Apr 2000 23:46:38 -0800 (GMT-0800)

> What do NATs do in general with multicast? 

I don't know that anyone has ever done a survey of behavior
or defined what should happen. There is a draft on IGMP
proxy that defines popularly implemented behavior for
home gateways but that draft does not discuss NAT.

> different points with different source addresses. Not good for the

And once that happens, reverse path forwarding checks won't
kill the dupes because they come from different source addresses.
Yuck. 

> multiple subnets, what prefix is it handing out addresses from? Net

Well, we need to talk about that. In the draft on mini-dhcp assignment
on multiple subnets, I assumed it was 192.168/16 because that seemed
like plenty of address space for a home network.The draft describes how
to hand out /24s from this prefix.  

By the way, I was recently asked how the first server on a
network should address itself. If this were a DHCP server then you
could say that it shouldn't use auto-conf addressing because it can
find a DHCP server (itself). Therefore it seemed to make sense to
do something like claiming and defending a persistent  address within
the 192.168/16 prefix. To provide persistence between reboots, the
network portion of the address might be a hash on the MAC address. 
Alternatively, the server might try 192.168.0.1 and if this were
occupied, then try the hashed MAC address.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 18 Apr 2000 08:11:45 -0400

> occupied, then try the hashed MAC address.

It might make sense for all nodes to (as a first guess) pick a
"random" address that is actually based on something like the MAC
address so that in the majority of cases (even in the absence of
stable storage), the generated address is the same. This would
simplify debugging and other operational things. If there is a
collision, then we want some real
randomness.

draft-cheshire-ipv4-linklocal-00.txt already seems to suggest that
this be done, but perhaps the wording could be made more explicit that
this is a desirable feature.

Thomas

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 18 Apr 2000 08:34:59 -0700

>this is a desirable feature.

I think this would be a desirable (optional) feature.