Subject: Comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt

From: Stuart Cheshire <[email-masked]>
Date: Thu, 6 Sep 2001 12:08:46 -0700

Keith Moore previously sent the message below. Because the mailing list 
software is currently configured to only accept mail from subscribed 
members of the list, the mail was rejected. We are working on having 
Merit modify the mailing list configuration to forward rejected mail to 
the WG chairs, but in the meantime, I enclose a copy of Keith's mail 
below. I am preparing a reply to the points he raises, and should have it 
ready shortly.

------------------------------------------------------------------------

Subject: comments on draft-ietf-zeroconf-ipv4-linklocal-04.txt
From: Keith Moore <[email-masked]>
Date: Thu, 26 Jul 2001 19:10:40 -0400

These comments are in response to the Last Call request.

(This is a bad time for a Last Call, as folks are typically quite busy
now.  So I hope the Last Call deadline is extended for a couple of weeks 
past the London IETF meeting.)

1. Applicability

1.1. Intended Purpose

My first set of comments have to do with the intended purpose of 
IPv4 link-local addresses.  (Some of them apply to IPv6 link-local
addresses also, but obviously those cannot be addressed in the 
context of this document.)

Link-local addresses are obviously valuable, for reasons implied
in the Introduction and Abstract.   They allow hosts on an isolated
network to begin communicating (assuming their applications can 
discover one anothers' addresses) without explicit setup and without 
support (e.g. DHCP, DNS) that would be present in a more sophisticated 
network.  However, there are some limitations also that should be 
mentioned:

- poor scalability - This technique works well only for small,
  isolated networks, and connections of short duration.  As the
  number of ad hoc network participants gets larger the network
  overhead due to address defense gets higher, and the liklihood 
  of address collisions gets higher. Along with that the liklihood 
  of having connections torn down due to address collisions also 
  increases.  networks of up to 100 hosts are probably okay, but
  after 1000 hosts the address collisions start becoming a 
  significant factor in reliability.

  (actually, having an explicit design parameter upper bound on # hosts 
  per link using link-local addresses would be a very good idea - it 
  would let us analyze the probability of various kinds of undesirable
  situations - broadcast storms, broken connections, etc - 
  and it might be that there is a need to discourage hosts from using
  link-local addresses if they find they're on a large network.)

- reduced reliability - The need to cease using addresses when
  collisions occur means that applications using link-local addresses 
  will generally be less reliable than applications using stable
  addresses.  

- limited applicability - Link-local addresses are inherntly only
  usable on the local link, and are not a solution for anything
  that needs to be accessable from outside that link, or to access
  outside devices.

Consequently, link-local addresses should be used sparingly, or
for special purposes by applications that are aware of them.
However this document offers no guidance to application authors 
regarding appropriate (or inappropriate) use of link-local addresses.

I believe this document needs to expand its Applicability section
to include not only link-level considerations, but also to
specify reasonable expectations for use of link-local addresses
by applications.

1.2. Security claims

In a couple of places this document makes claims that use of link-local 
addresses provides a security benefit.  Such claims cannot be supported 
in general, and we should not encourage the use of locally-scoped
addresses as a security mechanism.  (actually, we should actively 
discourage such notions)

- It's unrealistic to assume that chosen security boundaries and
  network topology will conveniently coincide.  A home network user
  will still want to print from a PDA that is connected to a 
  wide area wireless network (whether he is at home or not), and 
  he'll want to be able to view the image from his home babycam 
  from that same PDA whether he's at home or not.
 
- Link-local addresses *will* be routed from one network to
  another even if we prohibit this.  Some people will find this
  useful and ignore our prohibitions; others will fail to configure 
  their routers appropriately (admittedly, the TTL rules help a 
  lot here).

- It's fairly obvious that this mechanism is being designed
  for use in ad hoc networks of moderate size (say 100 or even
  1000 hosts).  Under those conditions, the threat potential is 
  sufficiently large that it's not reasonable for a network-
  accessible device to ignore security issues.  Even a single
  host on a wireless link (or bridged to a wireless link)
  has to cope with myriad security threats.  The idea that 
  a simple host can avoid addressing security is just a dream. 

- Even if the addresses will not be routed, experience indicates 
  that most general-purpose hosts are easily compromised.  A
  single Windows box on a home network that is attached to the
  Internet will suffice to give an attacker connectivity with all 
  devices on that local network, even if they only use link-local 
  addresses.  (and such devices are easily autodiscovered by
  watching for their ARP requests...)

- The End-to-End principle argues that hosts need to be responsible
  for their own security just as they need to be responsible for
  recovery of data loss, end-to-end message integrity, etc.

Device and application vendors will want to claim that link-local
addresss give them a justification to ignore security issues in their
products.  We should not lend support to such claims.  

Even if you argue that simple end devices shouldn't have to implement
strong authentication (I do not agree but IMHO it's reasonable to have 
that discussion) and that such security should be provided by the 
network, link-local addresses are neither a sufficiently robust nor 
a sufficiently flexible security mechanism for this purpose.

The problem with the document can be fixed by removing the security claims
from this document, and by adding some disclaimers about link-local 
addresses NOT being a security mechanism to the Security Considerations 
section.  

I don't know how to solve the problem of naive implementors 
(or for that matter, naive consumers)

1.3. Missing pieces

It seems unlikely that link-local addresses by themselves will
significantly enable existing applications, for instance, that
expect to look up the names of their peers using DNS.  (yes,
applications can often be configured to use IP addresses, but
applications that are looking for named services will have a 
hard time finding them.)  

If link-local addresses are being proposed in the context of
a broader solution with other pieces, it might help to state
those assumptions.  If nothing else, it might help to state
that there are missing pieces (even if they're for further
study).

2. Impact on Applications

The document says little or nothing about the impact of link-local
addresses on applications.  It's important to consider both the
effect on applications that aren't aware of link-local addresses,
and on those that are aware of them.

One can argue that without link-local addresses there would be no
communications at all under certain circumstances, and that a
somewhat-less-reliable communications capability is preferable to
no communications capability at all.  This is true - provided that
link-local addresses do not decrease the reliability of communications
when better capabilities would otherwise be available.

So one principle might be that the existence of a communications
capability using link-local addresses should not impair operations 
when other capabilities are available.

2.1 Non-aware Applications

A non-aware application that uses a link-local address as a source
or destination address may have problems for any of several reasons:

1. the address gets changed without warning, perhaps in mid-connection

2. the address is only usable in local contexts, even after the
   network has (re)joined the rest of the Internet

For example, 

- A non-aware host may see multiple DNS A records for a service and 
  (not knowing any better) choose a link-local address, even though
  that address is less stable/reliable than one of the alternatives.  
  (that address might even "look" better to a clever application,
  since the host will have a local interface to the same network)

  I don't have a good solution for this.  But I'll note that 
  there are numerous issues associated with putting link-local 
  addresses in DNS; it's not at all clear that this is doable
  in a reasonable fashion.  If you can solve the problems assocaited
  with putting link-local addresses in DNS you can probably 
  set up a DHCP server and assign more stable addresses.

- A distributed application may advertise its link-local address to 
  its peers as a rendezvous point.  But that address may be changed 
  without warning, and that address may not be usable from other 
  points in the network.

  I don't have a good solution for this.
 
- Another problem is that for a host with multiple interfaces, there may 
  be multiple, reachable, destinations with the same link-local address.
  Non-aware applications are likely to assume that all reachable 
destinations 
  can be uniquely distinguished by destination address alone (this is
  generally true even for NAT-aware applications).  Few existing 
applications
  bother to look at the source address assigned by the operating system,
  or to distinguish their peers by both source and destination address.

  I'm not sure how to fix this either, but it should at least be 
documented.  
  The best fix I can think of is that hosts with multiple interfaces 
  would only allow non-aware applications to use link-local addresses 
  on a single, designated interface.   Another fix is for hosts
  with multiple interfaces to relay link-local claim/defend messages
  to other interfaces, in order to ensure that such addresses are unique.

2.2 Aware applications

Applications that are aware of link-local addresses can presumably
choose if and when to use them as either source or destination
addresses.  However, to do this effectively probably requires some 
support from the socket API which is currently missing.  An application
can distinguish link-local addresses from other addresses, and it can
explicitly choose a source address using bind(), but it has no way 
to say "use the best non-link-local address that is available", or for 
that matter "use the best link-local address that is available".

It would be bad if different OS vendors were to implement this in 
different ways.

3. Impact on Operations

3.1  Timer hazards

The claim/defend protocol appears to have a flaw which will cause 
it to work very suboptimally, or not at all, for a large number of
hosts on a single Ethernet which are started at the same time (as
in after a power failure).  If the hosts all send their probes
at the same time, numerous collisions will result, causing requests
and responses to get dropped due to too much contention for the medium.
Since those hosts will retry at fixed intervals, the collisions
will with high probability happen again at the retry interval.

Even if the hosts don't quite start at the same time, if they start
their retry timers *after* failure of a transmission to produce a 
response, they will tend to "sync up" - because all hosts see more
or less the same periods during which the Ethernet cannot be accessed,
if they restart their timers after their responses are not heard,
they will all end up restarting those times are approximately the 
same time.

This could be addressed by varying the retry interval from one host
to another, and by starting retry timers *before* sending an ARP 
request.  For instance, the host's chosen address could be used as 
the seed of a pseudo-random number generator, the output of which
would determine the delay to the next retry.  The retries would not 
be uniformly spaced apart, but would be spread out over time.
This could be combined with exponential decay if that were considered
desirable.

3.2 When to use link-local addresses

Since link-local addresses do impact the network (significantly if
they are a lot of hosts using them), perhaps there should be some
well-defined conditions under which link-local addresses should 
NOT be claimed or used?

for instance, a host with a statically assigned address doesn't
need a link-local address unless it's talking to a host that only
has a link-local address.  similarly for a host that can get
an address with DHCP.  maybe hosts shouldn't claim a link-local
address until they find out that they need one.

4. overall impact

This is just one of many proposals that can (depending on how you
look at it) change fundamental assumptions in the Internet architecture,
or reflect changes in those assumptions that have already been made.
Some will argue that DHCP has already caused applications and 
to assume that addresses are volatile, and that NATs have already 
caused applications to assume that addresses are not gloablly usable.
To some extent this might be true, and yet if we were to insist that
all applications adopt these assumptions the network would be much
less useful than we have come to expect.

At a minimum when we make changes like this it seems important to 
consider what long-held assumptions are being challeged, and what 
effects these changes might cause for current and future applications.  
It also seems important to consider whether such changes can be made 
in a way that is less disruptive both to applications and to Internet 
flexibility.

The Internet was designed 30 years ago for very different conditions,
so some amount of change is inevitable.  The danger is that these
changes will be made in a piecemeal fashion and without considering
the global effects of apparently localized changes.

So if it seems like I've gone over this with a fine-toothed comb, that's 
why.
I think ad hoc networks are incredibly useful, but I am not sure that
we understand how to build them without affecting existing applications,
or that we know how to make ad hoc networks coexist in the same address
and protocol space with the global Internet. 

--------------------------------------------------------------------------
comments on specific portions of the text follow:

section 1.0:  

   A host need not implement a DHCP client in order to use
   a link-local address.  

True, but that host might not be able to communicate with other hosts 
on the same network unless those hosts also use link-local addresses.

section 1.2:

   Two hosts are considered to be
   on the same link if, when one host sends packets to the other, the
   entire link-layer packet payload arrives unmodified. In particular,
   any device forwarding a packet whose source and/or destination
   address is in the 169.254/16 prefix MUST NOT modify any part of the
   IP header.

This starts out being a definition of "on the same link" and ends up
making what looks like a (retroactive) requirement on packet forwarders.  

It's not clear whether the latter statement is meant to be a clarification
of the definition of "on the same link" or if it's really meant to 
impose a new requirement on devices that aren't aware of, and don't 
implement, this protocol.  I think it's the former, but if that's true,
it needs to be reworded, and use of MUST NOT is not appropriate.  

If the latter is intended, it needs wider review.  I don't think the
zeroconf group can unilaterally impose requirements on routers and
bridges.

What I might say is that this is a fundamental assumption behind the
v4 link-local address mechanism; and unless this condition is met, 
link-layer addressing cannot be expected to work correctly.

section 1.3:

   Implementations of IPv4 link-local address autoconfiguration MUST
   expect address collisions, and MUST be prepared to handle them
   gracefully by automatically selecting a new address whenever a
   collision is detected, as described in Section 2.

Unless you very carefully work out the details so as not to interfere
with existing applications, this requirement on "implementations of
IPv4 link-local address autoconfiguration" appears to also extend to
applications.  In other words, applications that expect to work in
an environment using link-local  addresses MUST be able to survive
address changes.  (but how to do so without some other naming system?)

section 1.5:

   Another example of why it is beneficial for hosts to maintain a link-
   local address in addition to other addresses is that there may be
   networks where some of the hosts have only a link-local address.

true so far, but...

   For example, a user with a wireless home network may have a laptop
   computer and an IP printer. The laptop computer may have both a
   self-configured link-local address and a DHCP-configured global
   address. The printer, in contrast, may have only a link-local
   address, because the user does not need (or want) the printer to be
   globally addressable.

this is a poor example, because it suggests using link-local addresses
(and the absence of global addresses) as a security mechanism.
also, it's perfectly reasonable to want a printer to be globally
accessible - after all, that's what a fax machine is.

to clarify, a host that only needs a link-local address to do its job
need not be assigned a global address. but we don't want to encourage
this as a mechanism for enforcing security or access policy.

(whether it's reasonable for certain appliances to use only link-local
addresses, and have no provision for other kinds of addresses, is a
different question.  I don't think we should assume a priori that this is
reasonable)

section 2.1:

if a link-local address is (usually) derived from some persistent
per-host identifier then this can serve as a (coarse) identifier
for the host, and perhaps (if the host is assigned to a user) for
that user.  this is not a problem if link-local addresses never
escape the local net - after all, the MAC address is also visible
from the local link.  however, it might be a good idea to recommend
that applications that are aware of link-local addresses do not 
expose them to the outside.  

this might just be a nit, but it's one of the issues that comes to
mind every time someone suggests using a persistent identifier. 

section 2.2:

see my comments above.  fixed-length timers between broadcasts
are an invitation to broadcast storms.

section 2.4:

this section is worded as if a 'host' decides the source address,
but sometimes the application decides.  

   If the destination address is in the 169.254/16 prefix (including the
   169.254.255.255 broadcast address), the host SHOULD use its link-
   local source address, if it has one. If the host does not have a
   link-local source address, then it MAY choose to ARP for the
   destination address and then send its packet, with a routable source
   IP address and a link-local destination IP address, directly to its
   destination on the same physical link.

is there any way that a host with only a link-local IP address would 
know how to reply to that routable IP address?  is it just expected
to treat the entire link as a /32 and ARP for it?  what if it has more
than one interface?

section 2.5:

okay, here we have several cases where zeroconf is trying to dictate
the behavior of things that don't know about link-layer addresses, 
and don't need to conform to this spec.  

   Any host sending an IPv4 packet with a source and/or destination
   address in the 169.254/16 prefix MUST set the TTL in the IP header
   to 255.

   Any host receiving an IPv4 packet whose source and/or destination
   address is in the 169.254/16 prefix MUST discard the packet if the
   TTL in the IP header is not 255.

   An IPv4 packet whose source and/or destination address is in the
   169.254/16 prefix MUST NOT be sent to any router for forwarding, and
   any network device receiving such a packet MUST NOT forward it,
   regardless of the TTL in the IP header.

these appear to be intended to apply to all hosts, whether they implement 
link-local addresses or not.  it's reasonable to require this of hosts 
that implement this spec, maybe not so reasonable (or realistic) to 
require
this of all hosts.  

if nothing else,  if you're imposing new requirements on hosts, they
need to be made very visible - not buried within a spec about link-local
addresses.

   This restriction also applies to multicast packets. IP packets with
   a link-local source address MUST NOT be forwarded off the local link
   even if they have a multicast destination address.

again, quite reasonable to apply to hosts that implement this protocol.
not reasonable to apply to every multicast router.

   Similar considerations apply at layers above IP. For example, DNS
   Resource Records containing link-local addresses SHOULD NOT be sent
   to hosts outside the link to which those link-local addresses apply.

now you appear to be imposing constraints on DNS implementations.

   Automatically generated web pages SHOULD NOT contain links with
   embedded link-local addresses if those pages are viewable from hosts
   outside the local link where the addresses are valid.

now you appear to be imposing constraints on HTTP servers.

I think it would be better if as many of these as possible were re-stated 
as operational recommendations, rather than, or in addition to, 
constraints 
on implementations.

e.g. rather than saying that all IPv4 hosts should discard packets
from 169.254/16 with TTL != 255, you might recommend that border 
routers be configured to discard such packets.  and rather than
saying that hosts should not send packets with destination addresses
in 169.254/16 to routers, maybe you should say that routers should
be configured to black-hole them.  rather than saying that DNS servers
should not expose 169.254/16 addresses, say that people should not
put those address into DNS servers if they can be exposed to the outside
(probably they shouldn't do it at all!).  similarly for web servers.

the last thing we need is to require all layers of the protocol
stack to be aware of link-local addresses.

   (bottom page 9 - top of page 10)
   The designers of these devices assume that they will communicate
   only with other local devices, and implement a degree of security
   appropriate for that expected environment.

they may indeed assume this. but that doesn't mean it's reasonable to 
assign a link-local address to such devices and expect that this 
provides security, and we shouldn't support their claims if they do this.

realistically, the scope of a link is large enough that you cannot
ignore security issues or (especially in wireless networks) assume that 
adequate security is provided by the medium.  a USB mouse or SCSI disk
that doesn't require authentication might be one thing; an insecure 
device on 802.11 or even wired Ethernet is quite another.

   This does not mean that link-local devices are forbidden from
   communicating outside the local link. IP hosts that implement both
   link-local and conventional routable IP addresses may still use
   their routable addresses without restriction as they do today.
   Extremely simple IP devices that implement only a link-local address
   may also communicate with hosts outside the local link, provided that
   such communication is mediated through a device capable of enforcing
   appropriate security controls. For example, a home heating system
   could be controlled via a Web server on the local network, where the
   Web server uses cryptographic methods to verify the authority of the
   remote user, and then uses link-local communication on the local
   network to communicate commands to the heating system's thermostat.

while there's nothing incorrect about what is said here, the implication
is that it's acceptable for devices with only link-local addresses
to not have security - and that's simply not correct.

   It should be understood that this mediated communication is not
   mandatory; it is an option afforded to designers of very simple
   devices who wish to implement only a link-local address and thereby
   simplify their security assumptions.

and this makes the incorrect assumption even more explicit.

section 3.2:

   Some operating systems have networking APIs that allow applications
   to specify network interfaces by name, index value, or other local
   identifier, and to identify interfaces this way both for incoming
   and outgoing packets/connections. For operating systems that have
   this capability (and have application software that makes use of it)
   it is sufficient to configure all interfaces with a single common
   IPv4 link-local address, and defend that address on all interfaces.

this fails if multiple interfaces are connected to the same link.
(and there are valid reasons for doing this)

however as long as the host has the capability to assign different
addresses to the different interfaces, it can start out assuming that
they're the same, and  respond to its own ARP messages, as long as
it ends up with different addresses :)

a host for which it's impossible for multiple interfaces to connect
to the same link (because they're inherently different types of link
that cannot reasonably be bridged together) can get away with this.

section 3.3.2:

   Networking implementations that only
   allow the destination address to be specified should limit themselves
   to configuring only one interface for link-local addressing

this might apply equally to non-aware applications, since the 
application doesn't know that it needs to bind the source address.

section 8:

this section is missing a great deal, and needs a lot of work.

Keith

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 10 Sep 2001 02:16:07 -0700

>These comments are in response to the Last Call request.

Thank you for your detailed comments. I will attempt to answer them here.

>  significant factor in reliability.

I disagree.

In the normal case, once a host has selected an address, it will keep 
that address indefinitely. This is at least as reliable as today's 
hard-wired Ethernet networks using manual or DHCP-assigned addresses.

Any new host joining the network will probe an address before using it, 
thereby ensuring that it does not interfere with existing hosts.

The only time when undetected conflicts have to be resolved is when two 
previously separate segments are bridged together. I would argue that 
this is (a) rare, and (b) even on a conventional managed network, 
bridging previously separate networks together while hosts are running 
usually entails some degree of chaos. The difference here is that when 
two hosts find they inadvertently have the same IP address, instead of 
failing silently and causing all kinds of confusion to the users, the 
hosts automatically recover and continue working.

>  link-local addresses if they find they're on a large network.)

I agree that the draft could make a specific statement in this regard.

I propose adding the following new text to the draft:

   This protocol is designed for links of no more than 1300 hosts. A
   host connecting to a link that already has 1300 hosts, selecting
   a link-local address at random, has a 98% chance of selecting an
   unused link-local address on the first try. A host has a 99.96%
   chance of selecting an unused link-local address within two
   tries. The probability that it will have to try more than ten
   times is about 1 in 10^17. This does not mean that a host should
   attempt to count the number of other hosts on the link and refuse
   to operate if it finds there are more than 1300. It does mean
   that network operators with more than 1300 hosts on a single link
   may want to consider dividing that single link into two or more
   subnets.

>  will generally be less reliable than applications using stable

I disagree.

When two hosts on the same link are using the same IP address, no 
applications work reliably, no matter how the addresses were assigned. 
The requirement in this draft to automatically select a new address as 
soon as the conflict is detected restores working operation as soon as 
possible. In contrast, two hosts with the same manually-assigned address 
will fail to work until a human intervenes to correct the situation. In 
the case of a device like the Apple AirPort Base Station, which has no 
screen or keyboard, the only way for a human to intervene to correct the 
misconfigured address is via the network, which is difficult if the 
network is not working. Having the device automatically select a new 
address automatically automatically restores its ability to communicate 
on the local link.

>  that needs to be accessable from outside that link, or to access

I agree, but I feel that the title of the draft, "Link-Local Addresses", 
and numerous comments about ignoring packets from outside the local link, 
non-forwarding, etc., make this very clear to the reader. Is there 
specific additional text you would like to see in the draft?

>regarding appropriate (or inappropriate) use of link-local addresses.

I believe that Section 2.4, "Source Address Selection", gives guidance in 
this respect:

   If the destination address is a unicast address outside the
   169.254/16 prefix, then the host SHOULD use an appropriate
   routable source address, if it has one.

   In the case where two hosts on the same link each have both a link-
   local address and another address configured via some other means,
   the host may use either its link-local source address or a routable
   address, depending on which is expected to be more likely to remain
   stable for the expected lifetime of the connection. Note that link-
   local addresses may be forced to change over time, as described in
   Section 2.3.

>specify reasonable expectations for use of link-local addresses

Can you suggest specific text?

I believe most applications can use link-local addresses without any 
special awareness. If I type "epson.local.arpa" into my Web browser to 
access the configuration page for my Zeroconf Epson ink-jet printer, and 
multicast DNS correctly looks up a link-local address for the printer, 
the Web browser has no reason to (and SHOULD NOT) treat that address any 
differently to any other address.

I would say the same is true of just about any application.

How many current applications give special treatment to Net 10 addresses?
I suspect most do not, and do not need to. Perhaps a few specialized 
applications should -- a tool that generates externally visible web pages 
should try to avoid putting links on those pages that aren't usable from 
outside the company's internal network.

>addresses as a security mechanism.  (actually, we should actively 

I tried to be very careful about how this was worded. Evidently not 
careful enough. I did not say that link-local devices should have *no* 
security, just that link-local devices should "implement a degree of 
security appropriate for that expected environment."

If you can suggest specific text I'd be grateful.

One of the goals of Zeroconf IP is to provide a viable replacement for 
all the USB protocols, FireWire protocols, IrDA protocols, BlueTooth 
protocols, etc., and help us escape that Tower of Babel move closer to an 
all-IP world. Vendors of USB printers currently implement little or no 
security, because they assume that the number of devices that can launch 
an attack against those printers is very small, and physically localized.

If we could achieve a world where every $49 ink-jet printer supports 
link-local Zeroconf IP, then it becomes a smaller step to enhance those 
printers to include global IP and security as well. If we erect 
unreasonable barriers to printer vendors considering supporting 
link-local Zeroconf IP, then they will continue to use only serial ports, 
parallel ports, USB, BlueTooth, etc.

>- A home network user
>  wide area wireless network (whether he is at home or not)

I agree. I'd love to have a $49 ink-jet printer that supports secure 
printing over IP from anywhere in the world, but the truth is that 
today's $49 ink-jet printers don't support IP at all. They only use USB, 
they have no security, and if you're not at home you can't use them.

How do we get from today's world to our common goal of ubiquitous secure 
worldwide IP everywhere?

>  their routers appropriately (admittedly, the TTL rules help a 

Some people accidentally turn on Windows printer sharing with no 
password, thereby giving the world access to their local USB printer. Is 
this any different?

If devices choose to implement the TTL=255 check, they are pretty safe 
from external packets brought in by a conventional IP router.

If the router is correctly configured to not forward inbound 169.254/16 
packets, they are pretty safe.

With sufficient misconfiguration, even the most secure system can be made 
insecure, so it is unsurprising that link-local addressing can be 
similarly subverted.

>  a simple host can avoid addressing security is just a dream.

The mechanism is also designed for one PC connected to one printer, using 
a crossover Ethernet cable instead of a USB cable.

The difference is that with the Ethernet printer, you *can* connect it to 
a network of a thousand hosts if you want, at which point you probably 
start bugging the printer vendor for some security. With the USB printer 
you don't have that choice.

>  watching for their ARP requests...)

The same thing applies to all the devices on the USB bus. I argue that we 
have more hope of preaching the doctrine of end-to-end security in the IP 
world than we do in the USB world.

>  recovery of data loss, end-to-end message integrity, etc.

No argument. Hence the recommended TTL=255 check, which is reduces 
dependence on other devices to do the right thing. (Note: The language in 
the draft may have to be modifed somewhat for compatibility with older 
Windows systems, but the principle remains.)

>products.  We should not lend support to such claims.  

No argument. No one should ignore security issues, but can we provide 
them with an environment where the security threats are a little less 
daunting? If every product has to withstand arbitrary attack from the 
whole world, many products are simply not viable on IP, and will continue 
to use their current Tower of Babel protocols.

>applications that are looking for named services will have a 

In fact, with self-assigned randomly-chosen addresses, hand-configuring 
devices with dotted-decimal IP addresses ceases to be viable. Link-local 
addresses absolutely require a naming protocol (or shouting 
dotted-decimal IP addresses across the room).

Currently on Mac OS, name lookup is done with AppleTalk NBP. (You find a 
file server in the Chooser using AppleTalk NBP, but then connect to it 
using a TCP connection to its IP address, which may be a self-assigned 
link-local address.)

Currently on Windows, name lookup is done with NetBIOS.

Ideally, we want to replace both with Multicast DNS.

SLP can also allow hosts to learn useful address information in this 
situation.

Name-to-address mapping is one of the four Zeroconf Requirements, as 
specified in draft-ietf-zeroconf-reqts-09.txt.

I don't believe that a standards-track RFC at this time should discuss 
Multicast DNS when Multicast DNS is in its infancy and it is not at all 
clear how things will eventually work out.

Can you suggest specific text?

>when better capabilities would otherwise be available.

The primary purpose of link-local addresses is to provide communication 
where otherwise there would be none. Is there specific wording you would 
like to see in the draft?

>1. the address gets changed without warning, perhaps in mid-connection

This is as likely with a link-local address as it is with a manual or 
DHCP-assigned address. That is to say, it can happen, but usually does 
not. Good applications should cope with this. Some applications do not 
cope well.

>   network has (re)joined the rest of the Internet

The same thing applies with DHCP, if I move my laptop from a private 
network using Net 10 addresses, to a public network using global 
addresses.

>  since the host will have a local interface to the same network)

Providing better name service APIs is a problem that is already being 
tackled, to solve the IPv6 "source address selection problem", which is 
essentially the same problem.

>  set up a DHCP server and assign more stable addresses.

Multicast DNS doesn't use a centralized server.

>  without warning, and that address may not be usable from other 

Repeating previous comments: This is as likely with a link-local address 
as it is with a manual or DHCP-assigned address. That is to say, it can 
happen, but usually does not. Good applications should cope with this. 
Some applications do not cope well.

>- Another problem is that for a host with multiple interfaces,
>  there may be multiple, reachable, destinations with the same
>  link-local address. Non-aware applications are likely to
>  assume that all reachable destinations can be uniquely
>  distinguished by destination address alone (this is generally
>  true even for NAT-aware applications).  Few existing
>  applications bother to look at the source address assigned by
>  the operating system, or to distinguish their peers by both
>  source and destination address.

The same problem applies for Net 10 addresses today, where a multi-homed 
host can have connections into multiple different Net 10 address spaces. 
The same problem also applies for IPv6 hosts using link-local or 
site-local addresses. My preferred solution here is that the networking 
stack should provide a "connect-by-name" API, which allows the OS to 
handle all these address selection and interface selection problems 
transparently on the application's behalf.

>  I'm not sure how to fix this either, but it should at least
>  be documented. The best fix I can think of is that hosts with
>  multiple interfaces would only allow non-aware applications
>  to use link-local addresses on a single, designated
>  interface.

I agree that the draft could make a specific statement in this regard.

I propose adding the following new text to the draft:

   For applications that send packets (or initiate outgoing
   connections) without identifying a desired source interface, by
   interface identifier, source IP address, or any other means, an
   operating system that configures link-local addresses on multiple
   interfaces has two choices. It can either restrict such
   applications to using link-local addresses on only one default
   interface, or it can ARP for the given destination address on all
   interfaces, and use the first response it gets. While clearly sub-
   optimal, in most cases this heuristic approach will successfully
   establish communication with the desired correspondent host.

>  Another fix is for hosts with multiple
>  interfaces to relay link-local claim/defend messages to other
>  interfaces, in order to ensure that such addresses are unique.

I believe the transitive closure of this behaviour would be for every ARP 
packet to spread to every reachable network. Any topological loop would 
result in an infinite broadcast storm.

>that matter "use the best link-local address that is available".

I would be disappointed if application writers need to care about this.
I would feel that we have failed in our goal of providing local IP that 
provides communications functionality which is, at the API level, 
equivalent to today's global IP.

Applications should simply specify a name to connect to, and the OS 
should automatically provide the best quality connection possible in the 
current environment.

>will with high probability happen again at the retry interval.

This is a good suggestion.

I propose adding the following new text to the draft:

   When ready to begin probing, the host should then wait for a
   random time interval selected uniformly in the range zero to two
   seconds, and should then send four probe packets, spaced two
   seconds apart. This initial random delay helps ensure that a
   large number of hosts powered on at the same time do not all send
   their initial probe packets simultaneously.

>well-defined conditions under which link-local addresses should 

The volume of ARP traffic generated by hosts using link-local addresses 
is not significantly different to the volume of ARP traffic generated by 
hosts using any other kind of address.

A host that starts up and then is fortunate enough to never need to use 
its link-local address sends six ARP packets on startup. It is likely to 
send many more ARPs than that in the course of just one hour using its 
other address.

>address until they find out that they need one.

That assumes that the host's statically assigned address is correct.

One of the purposes of link-local addresses is that you can absolutely 
rely on them. No matter how badly configured a host's networking stack 
is, you should at least be able to rely on link-local addressing working 
sufficiently well for you to communicate with the host to correct its 
misconfigured networking settings. If hosts stop using link-local 
addresses when their configuration indicates they don't need them, you 
can lose this benefit in precisely the case where you need it.

>to assume that addresses are volatile

DHCP is a really a symptom, not a cause.

It is the mobility of laptop computers and PDAs that have invalidated the 
assumption that every host needs only one fixed IP address. Sure, at the 
London IETF meeting we *could* all have continued using our home IP 
addresses using Mobile IP, but that wouldn't have been a necessary or 
efficient way to communicate with the local printers in the IETF terminal 
room.

For most applications, having an IP address that is topologically 
appropriate for the current location is more important than every piece 
of hardware being branded at birth with a fixed globally unique IP 
address.

With laptop computers and PDAs it is also no longer appropriate to assume 
that you shut down your device and reboot it every time you change 
location. My Palm V PDA hasn't been rebooted since the day I took it out 
of its box.

>in a way that is less disruptive both to applications and to Internet 

I agree with this sentiment.

Where I disagree is the notion that it is a backward step to provide 
(limited) communication where otherwise there would be no communication 
at all.

>So if it seems like I've gone over this with a fine-toothed
>comb, that's why. I think ad hoc networks are incredibly
>useful, but I am not sure that we understand how to build them
>without affecting existing applications

I am grateful for your fine-toothed comb analysis.

However, both Mac OS and Windows have had some flavour of link-local IP 
addressing for several years, and to my knowledge no existing application 
has ever had to be rewritten before it could make use of link-local IP 
networking.

I agree that there are challenges, but not insurmountable ones.

>on the same network unless those hosts also use link-local addresses.

Not necessarily true. Link-local-to-routable address communication is 
both possible and encouraged.

>of the definition of "on the same link"

It is trying to define the possibly slippery concept of "same link".

If the IP header (or any other IP packet content) is modified before 
forwarding (e.g. decrementing TTL), then the packet is (by this 
definition) not on the same link any more.

If you can provide a clearer definition of "same link", we will happily 
consider it.

>or if it's really meant to 

Like any standard, this one only asserts requirements on those devices 
that choose to implement the standard. A router that claims to conform to 
this standard MUST NOT forward link local packets. A router that does not 
claim to conform to this standard is not bound by it. Customers are free 
to purchase whichever kind of router they prefer.

>link-layer addressing cannot be expected to work correctly.

What do you mean by "work correctly"?

Link-local, site-local, and other variants of local addressing have been 
"working correctly" for years. Routers that forward these packets may be 
annoying and a waste of bandwidth, but how do they make it not "work 
correctly"?

>address changes.  (but how to do so without some other naming system?)

The requirement to handle address changes comes from mobility, from DHCP, 
and from the fact that if they want to, the user can even change their 
manual address without having to reboot the machine.

The naming system is NBP, NetBIOS, mDNS, SLP, or shouting dotted decimal 
IP addresses across the room, just as with manual or DHCP addresses :-)

>accessible - after all, that's what a fax machine is.

We've covered this already, but to answer the point: Link-local addresses 
are one step on the road from insecure USB to global addresses and 
security.

We can't get to the destination if we can't take the first step.

>mind every time someone suggests using a persistent identifier. 

Would the following new text address this concern?

   Another reason to restrict leakage of link-local addresses
   outside the local link is privacy concerns. If link-local
   addresses are derived from a hash of the hardware address, some
   argue that they could be indirectly associated with an
   individual, and thereby used to track that individual's
   activities. Within the local link the hardware addresses in the
   packets are all directly observable, so as long as link-local
   addresses don't leave the local link they provide no more
   information to an intruder than could be gained by direct
   observation of hardware addresses.

>but sometimes the application decides.  

Except in very specialized cases, no normal application should ever have 
to make this kind of decision.

>to treat the entire link as a /32 and ARP for it?

Yes. This is what current implementations do.

>what if it has more than one interface?

Then it needs a RIP listener, or some other way to build a rudimentary 
routing table, just like any multi-homed host.

>that implement this spec, maybe not so reasonable (or realistic) to require
>this of all hosts.  
>

I don't understand the problem. Hosts that don't claim to conform to this 
specification don't have to implement this. However, such hosts will not 
interoperate well with hosts that do conform to this specification.

A host implementer could choose to ignore the fact that Class D IP 
addresses are conventionally used for multicast, or the fact that 
224.0.0/24 is conventionally used for link-local multicast, but market 
forces dictate that people don't want to buy hosts that do that. There is 
a market for products that *do* implement the specifications published in 
standards-track RFCs.

>not reasonable to apply to every multicast router.

Well, where *are* requirements on multicast routers specified, if not in 
standards-track RFCs?

>now you appear to be imposing constraints on DNS implementations.

No more than currently imposed by use of Net 10 or IPv6 link local 
addresses.

Would it be better to not mention this in the draft, and leave 
implementers to work it out for themselves?

Whenever you have private name spaces, it is helpful if names from one 
name space do leak across the boundary into a different name space where 
they are not valid.

I believe it is helpful for the document to point out this inevitable 
fact so that all implementers are aware of it.

It would be intellectually dishonest to pretend that the issue did not 
exist.

>now you appear to be imposing constraints on HTTP servers.

No more than currently imposed by use of Net 10 or IPv6 link local 
addresses.

>be configured to black-hole them.

You previously argued end-to-end principles. Now you say that the two end 
systems should not implement their own protection against packets leaking 
in from outside the link, but should instead rely on the correct 
operation of all routers on the network to implement this protection.

You previously argued that this draft could not impose requirements on 
routers. Now you are arguing that it should.

I'm confused.

>rather than saying that DNS servers

You're assuming that a person put the addresses into a DNS server. The 
whole point of Zeroconf is that no person is required to configure 
anything. The software is entirely self-configuring, so requirements on 
what a person does have no place here.

Likewise, you're assuming that a person typed in link-local addresses 
into some HTML text. This is not useful if the host doesn't have a fixed 
address, (and embedding IP addresses in HTML text is questionable at the 
best of times anyway, because few hosts have an IP address that is truly 
fixed over time periods of years or decades). The draft specifically says

   Automatically generated web pages SHOULD NOT contain links with
   embedded link-local addresses if those pages are viewable from
   hosts outside the local link where the addresses are valid.

There are three salient points here:

1. Automatically generated web pages (not manually typed ones)
2. should not contain embedded IP addresses (host names are better)
3. and ESPECIALLY not embedded IP addresses that are not useful to
   the person (or device) reading the page.

I don't see much to disagree with in that statement.

>provides security, and we shouldn't support their claims if they do

I argue that different levels of security *are* appropriate in different 
contexts. From the draft:

   For example, a typical
   USB mouse does not have a password, nor does it encrypt its mouse-
   movement data, and in most environments this is acceptable.

The last thing I need is a mouse that costs $100 and doesn't work because 
I lost the crypto key that my computer needs to talk to it.

>(and there are valid reasons for doing this)

Why?

From the draft:

   If a host receives an ARP packet where the 'sender hardware address'
   in the ARP packet is equal to *any* of the host's active interfaces,
   then this is not a conflicting ARP packet, and should be silently
   discarded. This is because a user of a multi-homed host with two
   Ethernet interfaces may connect both interfaces to the same Ethernet
   hub, in which case the two interfaces will see each other's packets,
   and if it did not check and realize that the apparently conflicting
   ARP packets were coming from itself the host could erroneously
   conclude that all its addresses were in conflict. Another common
   example is a host with both wired and wireless Ethernet interfaces,
   in an environment where a wireless gateway is available, but (perhaps
   unknown to the user) is bridged onto the same wired Ethernet.

>this section is missing a great deal, and needs a lot of work.

8. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification
   can be obtained from the IETF Secretariat."

   The IETF has been notified of intellectual property rights claimed
   in regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

Can you elaborate on what needs to be added?

Thanks.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 11 Sep 2001 20:13:47 -0700

>Addresses in the 224.0.0.0/24 prefix are not dynamically assigned.
>So they should not be assigned by MADCAP or ZMAAP.

Agreed. This was my point.

>In general, there's no reason to use a linklocal address to send
>to a global multicast address, since that packet could reach hosts
>multiple hops away, and packets from a linklocal address should
>remain local to the link. 

So, if a host with a link-local address that needs a dynamic multicast 
address cannot use addresses in the 224.0.0.0/24 prefix, and it cannot 
use a global multicast address, what can it use?

While it may seem natural at first to say that a host with a link-local 
address should only use link-local multicast, I think that in practice 
this would leave the host with no multicast at all.

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 12 Sep 2001 16:51:05 -0700

I'd like to request that people who have comments on the draft try to 
phrase them in terms of what *specific* text they'd like to see in the 
draft.

Right now I no longer remember who is advocating that DNS is required, 
and who is advocating that DNS is optional. I can't keep straight who is 
saying, "we need to retain the option of implementing other 
name-to-address lookup services without making them dependent on DNS" and 
who is saying, "we're talking about DNS specifically here."

I think we need to get back to focussing on what needs to be in the draft.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Sep 2001 15:37:07 +0200 (CEST)

> I actually think that in the most precise definition of "on the same 
> link" for the purposes of IP is the one the draft gives: two hosts are 
> "on the same link" if and only if IP packets sent from one to the other 
> arrive with no part of the IP packet modified. If the TTL is decremented 
> en route, they are not on the same link. If the IP addresses are 
> rewritten by a NAT box or TCP port numbers are changed or the IP packet 
> is modified in any other way, then the hosts are not communicating 
> directly on the same link.

I suspect people will agree with this, but there is a slight 
risk that we'd end up discussion "transparent" vs. "non-transparent"
links - links that don't decrement ttl but do e.g. NAT type operations.
Let's hope we don't end up in those discussions.

> The reason the draft defines this in terms of link-layer payload instead 
> of IP packets is that ARP packets must also arrive unmodified, not just 
> IP packets.

OK, but your proposed text below mentions IP which I think distracts
from the ARP part.

> >And presumably the definitions belong in section 1.1 and not 1.2.
> 
> I propose putting the following modified text in Section 1.1:
> 
>    This document describes link-local addressing, for IP communication
>    between two hosts on a single link. Two hosts are considered to be on
>    the same link if, when one host sends packets to the other, the
>    entire link-layer packet payload arrives unmodified. The link-layer
>    *header* may be modified, such as in Token Ring Source Routing
>    [IEEE8025], but not the link-layer *payload*. In particular, any
>    device forwarding a packet whose source and/or destination address is
>    in the 169.254/16 prefix MUST NOT modify any part of the IP header
>    or IP packet body. This means that the packet may pass through
>    devices such as Ethernet switches, bridges, hubs or repeaters, but
>    not through devices like IP routers that modify the IP header.

As I said above the "In particular ..." sentence might muddle things.
And also seem to suggest that there might be link layers that would
not modify packets with link-local addresses but modify other IP packets.
Thus I think the "doesn't modify link-layer packet payload" is sufficient.

> I am aware that by this strict definition, a Token Ring and an Ethernet 
> segment bridged together do not qualify as a single link, because the 
> bridge modifies the contents of ARP packets. [...]

Presumably you also exclude the FDDI to Ethernet bridges that end up
fragmenting IP packets without decrementing ttl etc.

> Networks 
> bridged this way to do not qualify to be called a single link. [...]
> This kind of bridging is 
> fragile and unreliable, and while it can certainly be made to work in 
> some situations, this draft should not promise to support it.

While I agree that such things are flaky I see two issues:
1) The link definition in RFC 2460 isn't this strict and there would be
   less confusion if there was a single definition across IETF standards.
2) It is up to the WG to decide whether or not such links are in scope
   or out of scope for the linklocal spec.

> >I don't understand what the text in section 2.1 about 
> >   This means that even without using any other
> >   persistent storage, a host will usually select the same link-local
> >   address each time it is booted [...]
> >relates to the fact the you refer to RFC 1750 which says "It recommends 
> >the use of truly random hardware techniques ..."
> >
> >If you have truly random hardware techniques then you would *not* get the
> >same random number on each boot. So what is the relationship really with
> >RFC 1750?
> 
> The reference to RFC 1750 was put in at the request of Donald Eastlake on 
> 31st May this year. I do not have a strong opinion about it myself. Would 
> you prefer to see that reference removed?

I'd like the WG to decide whether they want randomness or non-randomness
first. At the moment the spec is inconsistent since it says strong randomness
in one place and assumes non-randomness elsewhere.

> >The algorithm in section 2.3 seems to force an unneeded IP address
> >change if a single packet is lost.
> >A is trying to use address X, which is already in use by B.
> >A sends arp request. B sees it and responds with a gratuitus reponse.
> >This response is lost.
> >A sends the arp request again after 2 seconds. (It is supposed to do this 4 
> >times). B sees it. Now the rules say that it MUST cease to use the address.
> >This doesn't seem very robust.
> 
> I think you are confusing sections 2.2 and 2.3. The four ARP packets two 
> seconds apart are in Section 2.2, "Claiming a Link-Local Address". Also, 
> they are ARP probes, not ARP requests. ARP probes are benign. They have 
> zero source address, and cause no harm to any other host on the network.
> 
> The forced reconfiguration in Section 2.3 only comes into effect if the 
> ARP probing process failed, and two hosts are trying to use the same 
> source IP address (for example when two separate network segments are 
> later joined). Forced reconfiguration is rarely needed, and when it is 
> needed, it is the quickest (and only) way to restore working 
> communication. Two hosts cannot use the same IP address and have reliable 
> communication. Whether or not an ARP packet may occasionally be lost 
> makes no difference here. If two hosts are trying to use the same source 
> IP address, reliable communication will not be restored until at least 
> one of them stops using that address.

Hmm - perhaps the text should be made more clear by
 - using "ARP request or response packet" instead of "ARP packet"
 - a section explicitly listing the differences agaist ARP as specified in the
   old RFC.

> >Huh? Sending to a global multicast address with a link-local source
> >is a good idea?
> >How about allowing either for broadcast or multicasts to 224.0.0.0/24
> >but mandating global source for other multicasts.
> 
> For example, hosts may want to use SSM addresses. There are no SSM 
> addresses in the 224.0.0.0/24 prefix.

What is the utility of using SSM for packets that can not leave the link?
SSM deals with scalaing issues for large scope multicast routing, and
there are no scaling issues of that nature for link-local multicast.

> What if you have a MADCAP server on the network, but no DHCP server, so 
> the hosts are using link-local addresses? Is the MADCAP server then 
> restricted to assigning only multicast addresses in the 224.0.0.0/24 
> prefix? Is a MADCAP server allowed to assign multicast addresses in the 
> 224.0.0.0/24 prefix?

Good questions that should be answered by somebody (else).
But the questions don't directly address my concerns about using a 
link-local source address for non-link local multicast destinations.
Note that IPv6 allows this with the requirement that routers
not forward packets (out a different link) that have a link local source.
I don't think that requirement exists in theory or in current router deployment
for IPv4 link-locals, but I'd love to be corrected.

   Erik

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 24 Sep 2001 10:15:15 -0700

> there are no scaling issues of that nature for link-local multicast.

The utility is that one can allocate an address with 0 messages on the
wire,
and 0 extra delay due to network latency.

> Good questions that should be answered by somebody (else).

Normally MADCAP would never allocate link-local addresses, one would use
ZMAAP for that, except if you have a huge number of hosts on the link.

In theory, the MADCAP server can assign non-link-local addresses, but if
a 
link-local address is used as a source address, the packets really 
shouldn't be routed off the local link (same as if TTL=1 were used)
but see below...

> for IPv4 link-locals, but I'd love to be corrected.

I believe you are correct, this isn't explicitly stated anywhere.
So in practice, it's best that a MADCAP server not allocate from
larger multicast scopes if the admin knows equivalent unicast
addresses are not available.

-Dave