Dynamic Configuration of IPv4 Link-Local Addresses
draft-ietf-zeroconf-ipv4-linklocal-17

[Note]: '2004-05-06: version -14 addressed concerns of IESG. But last minute
IPR disclosure from Apple needs to be considered by the WG. Detailed
info on document status can be found at:
http://www.drizzle.com/~aboba/ZEROCONF/issues.html.
' added by Thomas Narten

[Note]: '2004-03-23: IESG comments are being processed by WG; Erik has suggested updates and LC period on mailing list is ongoing. Then, revised ID and (hopefully!) IESG approval!' added by Thomas Narten

[Ballot discuss]
(1) In section 2.6.2 "Forwarding Rules", the document says:

  "Whichever interface is used, if the destination address is in the
  169.254/16 prefix (including the 169.254.255.255 broadcast address),
  then the sender MUST ARP for the destination address and then send
  its packet directly to the destination on the same physical link.
  This MUST be done whether the interface is configured with a Link-
  Local or a routable IPv4 address."

      I don't think that the above paragraph is intended to indicate
      that an ARP should be sent for every link-local packet, but
      it could be read that way.  In particular, it doesn't seem
      correct to ARP for a broadcast address.  Also, it should be
      okay (AFAIK) to use a normal ARP cache for these addresses,
      right?

    (2) This document says, at one point, that storing LL addresses
        in the DNS is not recommended.  But, later it says that
        you MUST NOT store LL addresses in the DNS.  Which is it?

    (3) The "Security Considerations" section contains the following
        band-aid that should have been included in the earlier text
        that describes how to handle address collision:

  "Implementations and users should also note that a node that gives up
  an address and reconfigures, as required by section 2.5, allows the
  possibility that another node can easily successfully hijack existing
  TCP connections. Before abandoning an address due to a conflict,
  hosts SHOULD actively attempt to reset any existing connections using
  that address."

[Ballot comment]
Watching the issue handling on the mailing list, I'd like to compliment Erik Guttman and Bernard Aboba (and the WG participants) for the approach they took.

[Ballot comment]
2.6.2 says

  ...if the destination address is in the
  169.254/16 prefix (including the 169.254.255.255 broadcast address),
  then the sender MUST ARP for the destination address and then send
  its packet directly to the destination on the same physical link.

This sounds like it's saying that 169.254.255.255 is not to be treated as a broadcast address, but it describes it as "the .. broadcast address".  Potentially confusing.

This is not a DISCUSS because this is a relatively minor issue in a document that I don't want to prevent from moving forward, but if it is going to be spun for something else (or even if this can be handled in AUTH48) I'd be happier.

[Ballot discuss]
I am much happier with this rev. The document addresses the concerns
I had before. I do have some comments though.

Editorial comment:

> 1.  Introduction
...
>    Microsoft Windows 98 (and later) and Mac OS 8.5 (and later) already
>    support this capability.  This document standardizes usage,
>    prescribing rules for how Link-Local IPv4 addresses MUST be treated
>    by hosts and routers.  In particular, it describes how routers MUST
>    behave when receiving packets with IPv4 Link-Local addresses in the
>    source or destination address.  With respect to hosts, it discusses
>    claiming and defending addresses, maintaining Link-Local and routable
>    IPv4 addresses on the same interface, and multihoming issues.
 
The two "MUST" above should be lower case.

More substantial comments on the new text:

> 2.6.2.  Forwarding Rules
...
>    In many network stacks, achieving this functionality may be as simple
>    as adding a routing table entry indicating that 169.254/16 is
>    directly reachable on the local link.

Mentioning that this won't work for multihomed hosts and routers and pointing
to the section discussing this would be useful.


> 3.2.  Address Ambiguity
>
>    This is a core problem with respect to Link-Local IPv4 addresses
>    configured on more than one interface. What should a host do when it
>    needs to send to Link-Local destination L and L can be resolved using
>    ARP on more than one link?

I would add that even if a given LL address is resolved using just one
link at a given moment, the choice will still be ambiguous without
interface specification, as a second later another host with the same
LL address may become available on another link.

>    One possibility is to support this only in the case where the
>    application specifically expresses which interface to send from.

>    There is no standard or obvious solution to this problem.  Existing
>    application software written for the Internet protocol suite is
>    largely incapable of dealing with address ambiguity. This does not
>    preclude an implementer from finding a solution, writing applications
>    which are able to use it, and providing a host which can support
>    dynamic configuration of Link-Local IPv4 addresses on more than one
>    interface.  This solution will almost surely not be generally
>    applicable to existing software and transparent to higher layers,
>    however.

The text reads as if we don't know how to work with scoped addresses
at all. This is not true. We know that:

  1. The IP stack must have the outbound interface associated with
    a packet that needs to be sent to a LL destination address

  2. The outbound interface cannot be derived from the packet's
    header parameters such as src or dst address (e.g. by using
    the forwarding table lookup), hence

  3. Outbound interface association MUST be done explicitly
    through other means. The specification does not stipulate
    those means, but examples include ...

[Ballot comment]
The draft has the following text in section 1.4:

  a. Routable addresses should be used within applications whenever
  they are available.

  b. Names that are globally resolvable to routable addresses should be
  used within applications whenever they are available.  Names that are
  resolvable only on the local link (such as through use of protocols
  such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be
  used in off-link communication.  IPV4 addresses and names which can
  only be resolved on the local link SHOULD NOT be forwarded, they
  SHOULD only be sent when a Link-Local address is used as the source
  address.  This strong advice should hinder limited scope addresses
  and names from leaving the context in which they apply.

  c. Link-Local IPv4 addresses MUST NOT be configured in the DNS.

A & B seem to contain contrary advice (Use routable addresses in applications vs.
use names resolvable to routable addresses in applciations); this is probably
because the authors see an "instead" in here that isn't stated.  I'd suggest rephrasing
A.  I'd also suggest reversing the order so that C is first (it is the MUST here),
B's advice is next (It is the SHOULD), and then the current A is "If names resolvable
to globally routable addresses are not available, but the globally routable addresses are,
they should be used instead of link-local addresses".

Section 2.9 says:

2.9.  Higher-Layer Protocol Considerations

  Similar considerations apply at layers above IP.

I think it would be valuable to say "Consideration similar to those in Section XX apply
at layers above IP", in case this text is excerpted or the Higher-layer protocol consideration
reader does not follow.  I'm also uneasy at the SHOULDs in this, and I have called out one
conflict in the text on the DNS front as a DISCUSS.  Basically, though, the APPs layer should
not need to know which interface is being used for a specific operation, and that may not
be the case here. There are  actually two risks here:  that a reference to a link-local address
by an application will break because the entity dereferencing it will not have access to that
link-local address and that an application will receive the wrong data because it can
dereference *something* at that address (possibly on a different interface), but it is not
the intended referent.  This is implied  in Sections 3.2 and 6.3, and forward references to
those section here would be useful in addition to the other references.

NIT:  IPv4ll used initially without expansion.  Style point:  it looks like "IP version four-one-one"
in a typical RFC font, which is confusing.

[Ballot comment]
The draft has the following text in section 1.4:

  a. Routable addresses should be used within applications whenever
  they are available.

  b. Names that are globally resolvable to routable addresses should be
  used within applications whenever they are available.  Names that are
  resolvable only on the local link (such as through use of protocols
  such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be
  used in off-link communication.  IPV4 addresses and names which can
  only be resolved on the local link SHOULD NOT be forwarded, they
  SHOULD only be sent when a Link-Local address is used as the source
  address.  This strong advice should hinder limited scope addresses
  and names from leaving the context in which they apply.

  c. Link-Local IPv4 addresses MUST NOT be configured in the DNS.

A & B seem to contain contrary advice (Use routable addresses in applications vs.
use names resolvable to routable addresses in applciations); this is probably
because the authors see an "instead" in here that isn't stated.  I'd suggest rephrasing
A.  I'd also suggest reversing the order so that C is first (it is the MUST here),
B's advice is next (It is the SHOULD), and then the current A is "If names resolvable
to globally routable addresses are not available, but the globally routable addresses are,
they should be used instead of link-local addresses".

Section 2.9 says:

2.9.  Higher-Layer Protocol Considerations

  Similar considerations apply at layers above IP.

I think it would be valuable to say "Consideration similar to those in Section XX apply
at layers above IP", in case this text is excerpted or the Higher-layer protocol consideration
reader does not follow.  I'm also uneasy at the SHOULDs in this, and I have called out one
conflict in the text on the DNS front as a DISCUSS.  Basically, though, the APPs layer should
not need to know which interface is being used for a specific operation, and that may not
be the case here. There are  actually two risks here:  that a reference to a link-local address
by an application will break because the entity dereferencing it will not have access to that
link-local address and that an application will receive the wrong data because it can
dereference *something* at that address (possibly on a different interface), but it is not
the intended referent.  This is implied  in Sections 3.2 and 6.3, and forward references to
those section here would be useful in addition to the other references.

[Ballot discuss]
Section 1.4 says :

  c. Link-Local IPv4 addresses MUST NOT be configured in the DNS.


Section 2.9 says:

  As Link-Local IPv4 addresses may change at any time and have limited
  scope, storing Link-Local IPv4 addresses in the DNS is not well
  understood and is NOT RECOMMENDED.

RFC 2119, Section 4, says "NOT RECOMMENDED" is the same strength
as "SHOULD NOT".  The authors and working group need to decide
whether this prohibition is a MUST or a SHOULD.

[Ballot comment]
The draft has the following text in section 1.4:

  a. Routable addresses should be used within applications whenever
  they are available.

  b. Names that are globally resolvable to routable addresses should be
  used within applications whenever they are available.  Names that are
  resolvable only on the local link (such as through use of protocols
  such as Link Local Multicast Name Resolution [LLMNR]) MUST NOT be
  used in off-link communication.  IPV4 addresses and names which can
  only be resolved on the local link SHOULD NOT be forwarded, they
  SHOULD only be sent when a Link-Local address is used as the source
  address.  This strong advice should hinder limited scope addresses
  and names from leaving the context in which they apply.

  c. Link-Local IPv4 addresses MUST NOT be configured in the DNS.

A & B seem to contain contrary advice (Use routable addresses in applications vs.
use names resolvable to routable addresses in applciations); this is probably
because the authors see an "instead" in here that isn't stated.  I'd suggest rephrasing
A.  I'd also suggest reversing the order so that C is first (it is the MUST here),
B's advice is next (It is the SHOULD), and then the current A is "If names resolvable
to globally routable addresses are not available, but the globally routable addresses are,
they should be used instead of link-local addresses".

[Ballot comment]
Section 2.2.  It seems that this technique should work for 802.11 ad hoc
  networking too.  An entry in the list that does not imply an infrastructure
  of any kind is desirable.
 
  The reference to RFC 2434 should be informative, or a reference should be
  added in the IANA Considerations section.

[Ballot comment]
It's good to see this document finished.
I'm happy with the document as written - it has addressed all the concerns I remember from the last time the IESG considered it.

[Ballot comment]
Section 2.2.  It seems that this technique should work for 802.11 ad hoc
  networking too.  An entry in the list that does not imply an infrastructure
  of any kind is desirable.
 
  The reference to RFC 2434 should be informative.

To: Internet Engineering Steering Group
From: IESG Secretary
Reply-To: IESG Secretary
Subject: Evaluation: draft-ietf-zeroconf-ipv4-linklocal - Dynamic
Configuration of IPv4 Link-Local addresses to Proposed
Standard
--------

Last Call to expire on: 2002-9-11

Please return the full line with your position.

                    Yes    No-Objection  Discuss *  Abstain 

Harald Alvestrand  [  ]    [  ]      [ X ]      [  ]
Steve Bellovin      [  ]    [  ]      [ X ]      [  ]
Bill Fenner        [  ]    [ X ]      [  ]      [  ]
Ned Freed          [  ]    [ X ]      [  ]      [  ]
Ted Hardie          [  ]    [  ]      [  ]      [  ]
Russ Housley        [  ]    [  ]      [  ]      [  ]
David Kessens      [  ]    [  ]      [  ]      [  ]
Allison Mankin      [  ]    [ X ]      [  ]      [  ]
Thomas Narten      [ X ]    [  ]      [  ]      [  ]
Jon Peterson        [  ]    [  ]      [  ]      [  ]
Margaret Wasserman  [  ]    [  ]      [  ]      [  ]
Bert Wijnen        [  ]    [ X ]      [  ]      [  ]
Alex Zinin          [  ]    [  ]      [ X ]      [  ]

Scott Bradner      [  ]    [ X ]      [  ]      [  ]
Randy Bush          [ X ]    [  ]      [  ]      [  ]
Patrik Faltstrom    [  ]    [ X ]      [  ]      [  ]
Erik Nordmark      [  ]    [  ]      [ X ]      [  ]
Jeff Schiller      [  ]    [ X ]      [  ]      [  ]


2/3 (9) Yes or No-Objection opinions needed to pass.

* Indicate reason if 'Discuss'.


DISCUSS:
========
Harald:

Three objections, based on a quick scan:

1)

The document gives no (zero) examples of applications that can
successfully and safely be used with link-local addresses. I think a
list of applications would serve two purposes:

- document the motivation for this feature
- serve as target for people arguing that this application has
serious failure modes when used with link-local addresses

2)

The following section:

> 2.10 Higher-Layer Protocol Considerations
>
> Similar considerations apply at layers above IP.
>
> For example, designers of Web pages (including 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.
>
> As link-local addresses may change at any time and have limited
> scope, storing link-layer addresses in the DNS is not well
> understood and it is NOT RECOMMENDED.

is not sufficiently draconian.

It should probably say something like:

The following set of protocols:

- FTP
- DNS
- NFS
- IPSEC using IPv4 as an identifier
- BGP
- OSPF
- RTP/RTCP
<<>>

will fail if applications use a link-local address instead of a
globally unique address when sending the address of its interface in
a protocol packet.

3)

Security consideration, section 2.8:

> The non-forwarding rule is important because it is expected that
> many link-local-only devices will be extremely simple devices of
> the kind that currently use X10 [X10], USB [USB] or FireWire [1394].
>
> The designers of these devices currently assume that they will
> communicate only with other local devices, and this allows them to
> produce cost-effective devices by implementing a degree of security
> appropriate for that expected environment. Any network gateway device
> that blindly forwards the contents of link-local IP packets off the
> local link (or onto the local link) exposes simple link-local-only
> devices to a much greater degree of risk than their designers may
> have planned for.

In the world of wireless LANs, this seems to be an extremely stupid
idea.  (not that it was a smart move before.....for kicks, try plugging
an X10 controller into your neighbour's outdoor electrical socket and
start playing....)
I would suggest to add a NOTE:

NOTE: The existence of local links without physical security, such as
LANs with attached wireless base stations, means that expecting all
local links to be secure enough that normal precautions can be dispensed
with is an extremely dangerous practice, which will expose users to
considerable risks.

Steve:
How do current hosts behave with respect to this:

All ARP packets (*replies* as well as requests) that contain a
      link-local 'sender IP address' MUST be sent using link-level
broadcast instead of link-level unicast. This aids timely
detection of duplicate addresses. An example illustrating how this
helps is given in Section 4. 

(I understand the necessity, but is it done? I suspect not. This
suggests that there be a warning that link-local addresses SHOULD NOT
be manually configured.) 

I have vague recollections of an RFC that permits hosts to ignore
spontaneous ARP replies, i.e., those not in response to a query, in an
effort to block connection hijacking. I think that some hosts actually
do this. That would interfere with the claim-and-defend mechanism, and
with renumbering, I believe.

What use is link-local security in a world of wireless bridges?

The Security Considerations section should note that address-based IKE
certificates [RFC2409, I think] MUST NOT be issued for link-local
addresses.

How does Windows XP behave?

Alex:
Seems to me that a "routing considerations" section is required.
  Some things that should be described:

    - should a route be installed in the routing table based
        on the link-local address on an interface?

    - should/can the 169.254/16 prefix be announced by dynamic
        routing protocols?

    - if received from a routing protocol, should the prefix
        be installed in the RT?

    - what the behavior should be if the prefix somehow
        made it to the RT (static route, old routing proto)?

Erik:
The abstract and first paragraph in the introduction can easily
be read as these addresses being a full-fledged replacement of
DHCP assigned addresses.
Having the text explicitly say that such addresses can not be used
for communication outside a single link would make sense.

In the applicability section it would make sense to add explicit
warnings about issues for applications. One issue is the addresses
are of limited scope which might cause problems for multi-party
applications that pass IP addresses between parties.
The other issue is that these addresses might have much shorter and
unpredictable lifetime, which would have an impact on applications
using them on the link. (This is true especially given the
suggestions in section 2.5 to pick a new address when a conflict is
detected after the address has been used for a while.)

The text in section 2.5 says that in some cases the host MUST cease
using the address. Since it is easy for an on-link attacker to spoof
the ARP packets it can cause the host to break all its connections by
switching to a new address. The document should at least warn against
this in section 2.5, and presumably also discuss it in the security
considerations section.

And here is a "bonus" I didn't mention on the call:
      The time values specified above are intended for use on
technologies such as Ethernet, where switches that implement
Spanning Tree [802.1d] often silently discard all packets for
several seconds. The time values specified above result in a
delay of 8-10 seconds before a chosen IP address may be used.
For a desktop machine on Ethernet,

FWIW when 802.1d is enabled on the port I plug in my laptop at the
office, the delay before the switch starts forwarding packets is 45
seconds. (I think the 802.1d spec indicates a default time of around
30 seconds.) So 10 seconds don't seem to do much good.

      If the destination address is the 255.255.255.255 broadcast
address or a multicast address, then the host may use either
its link-local source address or a routable address, as
appropriate.

OK for a link-local multicast destination. But for other multicast
destinations I assume it SHOULD use any routable address instead of
the link-local.

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.

Add warning that uses the same address on all interfaces makes the host
more suceptible to attacks and other reasons for duplicate addresses
being detected late, resulting in a shorter lifetime for the link-local
addresses. Using a separate address per interface limits the "damage"
in such a case to a single link.

section 3.3
      In addition, this kind of host should probe for, and defend, all
of its link-local addresses on all of its active interfaces that
are using link-local addresses.

      When bringing up a new interface, the host SHOULD first probe
for all of its existing link-local addresses on that new interface.
If any of the addresses are found to be already in use by some
other host on that new link, then the interfaces in question MUST
be reconfigured to select new unique link-local addresses. The
host should then select a link-local address for the new interface,
and probe on all of its active interfaces to verify that this new
address is unique on all the links that the host has connections to.

The above breaks if multiple interfaces on the host are connected
to the same link. It also isn't clear to me why this is needed;
presumably the interfaces can be managed indepdently as long as the host
ensures that it doesn't assign the same link-local address to more than
one interface.


COMMENT
-------
Scott: notes:
                references not split
                this can get fixed when Harald's discuss is delt with
Patrik:

This doesn't imply I don't have problems with the document, but that I
have read what others have for discuss...

[Note]: 'LC ends on Feb 20, but I''d like to flush out IESG comments and not lose momentum on finishing the doc and closing the WG.' added by Thomas Narten

[Note]: 'Sent back to WG after IESG review, WG is iterating on it. Will need a new IETF LC, then back to the IESG.' has been cleared by Thomas Narten

State Changes to Wait for Writeup                                  from New Version Needed (WG/Author)                    by narten

State Changes to New Version Needed (WG/Author)                    from Token@wg or Author                                by Thomas Narten

State Changes to Token@wg or Author                                from Wait for Writeup                                  by Thomas Narten