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

From: Stuart Cheshire <[email-masked]>
Date: Mon, 2 Apr 2001 23:22:09 -0700

>Find enclosed some comments on the IPv4 linklocal draft. Despite the
>length of the review, most of these represent minor changes in wording.
>
>http://www.drizzle.com/~aboba/zeroconf/stuart.txt

Thanks. For the purpose of the official IETF record, I'm attaching the 
document here. Comments will follow.

-----------

Here are my comments on draft-ietf-zeroconf-ipv4-linklocal-02.txt.

Section 1. 

"Hosts and routers using addresses in the 169.254/16 range MUST follow
the rules laid out in this document. This document will discuss
claiming and defending addresses, maintaining link-local and routable
addresses on the same interface, and multihoming issues."

The rules apply not only to hosts and routers with interface
addresses within the 169.254/16 prefix; they also describe how
routers and network address translators are to behave when
receiving packets with linklocal addresses in the source and
destination address. 

Suggested change:

"This document prescribes rules for how IPv4 linklocal addresses 
MUST be treated by hosts, routers and network address translators.
In particular, it describes how routers and network address translators
MUST behave when receiving packets with IPv4 linklocal addresses
in the source or destination address. With respects to hosts, it will 
discuss
claiming and defending addresses, maintaining link-local and routable
addresses on the same interface, and multihoming issues."

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

"Note that addresses in the 169.254/16 range SHOULD NOT be configured
manually or by a DHCP server, since doing so may cause a host to use
an address in the 169.254/16 range without awareness of the special
rules regarding duplicate detection and automatic configuration
that pertain to addresses in this range."

I think it's worthwile to describe the issue with DHCP assignment
in more detail. The language in RFC 2131 is as follows:

"As a consistency check, the allocating
server SHOULD probe the reused address before allocating the address,
e.g., with an ICMP echo request, and the client SHOULD probe the
newly received address, e.g., with ARP."

Suggested change:

"Note that addresses in the 169.254/16 range SHOULD NOT be configured
manually or by a DHCP server. Manual or DHCP configuration may cause a 
host
to use an address in the 169.254/16 range without awareness of the
special rules regarding duplicate detection and automatic configuration
that pertain to addresses in this range. While RFC 2131 indicates
that a DHCP client SHOULD probe a newly received address, this is
not mandatory.  

Since linklocal addresses are not routable, it is not possible for a
host on one segment to detect whether a host on another segment has
allocated an IPv4 linklocal address. For example, a host sending a
ping to a linklocal address will only receive a reply if that address is
in use on the local segment; the packet must not be forwarded off the
link.

As a result, a DHCP server not directly connected to a link 
will not be able to probe an IPv4 linklocal address 
before allocating it as recommended by [RFC 2131] and therefore
will not be able to guarantee uniqueness of the allocated address."

----------------------------------------------------------------------
General comment: 
The term "range" is used to describe 169.254/16 throughout the document.
I believe that the more correct term is "prefix".

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

Section 1.1

"This document uses the term "routable address" to refer to any
unicast address outside the 169.254/16 range, including global
addresses and private addresses such as Net 10/8 [RFC 1918]."

This is confusing. In other documents and drafts the term "routable
address" refers to addresses that are routable on the global Internet --
which does not include private address space. For consistency, it
would be better if the term "routable and private addresses" were
used instead.

Section 1.3

In this section you launch into issues with autoconfiguration in the
first paragraph. This seems a bit abrupt, because you haven't yet
talked much about what linklocal addresses are and how they should
behave. 

I recommend adding a brief introductory paragraph at the beginning
of this section, or moving text from section 2.1 & 2.5 here. Suggested
addition:

"In order to provide for automatic configuration, this document
describes IPv4 linklocal addressing. IANA has allocated the address 
prefix 
169.254/16 for IPv4 linklocal use. Within the 169.254/16 prefix, the 
169.254.0/24 and 169.254.255/24 prefixes are reserved for future use and 
are 
not used. 

Linklocal addresses,  by definition, are local to the link and are not to 
be 
forwarded off the link by network devices, including routers and network 
address translators. In order to ensure that hosts and routers
will always be able to reach these addresses on the local segment, 
addresses within prefix 169.254/16 MUST NOT be subnetted."

Section 2.1. 
 
I think that given the desire that the address survive a reboot, we don't
really want randomly chosen addresses, we want pseudo-random addresses 
that
are uniformly distributed across the range (so as to minimize 
collisions). 

My recommendation is to change the first paragraph as follows:

"When a host wishes to configure a link-local address, it selects an
address using a pseudo-random number generator with a uniform..."

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

"Recommendations for pseudo-random number generators can be found in
"Randomness Recommendations for Security" [RFC 1750]."

Actually, RFC 1750 is really more about issues with pseudo-random
number generators. Recommend change to:

"Issues wth pseudo-random number generators are discussed in
"Randomness Recommendations for Security" [RFC 1750]."

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

Section 2.2

"The appropriate number of ARP probes and the interval between them is
implementation-dependent."

Later on, you say:

"After successfully configuring a link-local address, a host on
Ethernet SHOULD broadcast two gratuitous ARPs, spaced two seconds
apart."

Why do you only provide advice on the number of ARP probes *after*
configuring the linklocal address and not before? Seems like you'd
want to make suggestions on both. 

Also, elsewhere in the document you discuss remotely bridged networks
(such as VPN scenarios). In such circumstances, it would seem that
you would want to increase the ARP spacing. Thus, either more
gratuitous ARPs or wider spacing might make sense.

-------------------------------------------------------------------
"On link-layer network technologies that do not support
ARP there may be equivalent mechanisms for determining whether a
particular IP address is currently in use, but these kinds of
networks are not discussed in this document."

Are we saying that linklocal addressing doesn't apply to NBMA
networks? I would suggest a change of language to:

"On link-layer network technologies that do not support
ARP other techniques may be available for determining whether a
particular IP address is currently in use. However, the 
the application of claim and defend mechanisms to such networks
is left to a future document."

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

There are a number of references to Ethernet in the document. In most
cases, Ethernet is not in fact a requirement, and other IEEE 802
media would work just as well. I recommend going through the document
and replacing "Ethernet" with "IEEE 802 media". References to these
documents are included below:

[1]  IEEE Standards for Local and Metropolitan Area Networks: Overview
     and Architecture, ANSI/IEEE Std 802, 1990.

[2]  ISO/IEC 10038 Information technology - Telecommunications and
     information exchange between systems - Local area networks - Media
     Access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D- 1993),
     1993.

[3]  ISO/IEC Final CD 15802-3 Information technology - Tele-
     communications and information exchange between systems - Local and
     metropolitan area networks - Common specifications - Part 3:Media
     Access Control (MAC) bridges, (current draft available as IEEE
     P802.1D/D15).

[4] IEEE Standards for Local and Metropolitan Area Networks: Draft
     Standard for Virtual Bridged Local Area Networks, P802.1Q/D8,
     January 1998.

[5] ISO/IEC 8802-3 Information technology - Telecommunications and
     information exchange between systems - Local and metropolitan area
     networks - Common specifications - Part 3:  Carrier Sense Multiple
     Access with Collision Detection (CSMA/CD) Access Method and
     Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996),
     1996.

[6] IEEE Standards for Local and Metropolitan Area Networks: Demand
     Priority Access Method, Physical Layer and Repeater Specification
     For 100 Mb/s Operation, IEEE Std 802.12-1995.

[7] IEEE Standards for Local and Metropolitan Area Networks: Port based
     Network Access Control, IEEE Draft 802.1X/D10, January 2001.

[8] Information technology - Telecommunications and information
     exchange between systems - Local and metropolitan area networks -
     Specific Requirements Part 11:  Wireless LAN Medium Access Control
     (MAC) and Physical Layer (PHY) Specifications, IEEE Std.
     802.11-1997, 1997.

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

"For Ethernet at 10Mb/s, 100Mb/s or 1Gb/s
(henceforth referred to simply as 'Ethernet'), four probes with a
two-second wait after each probe is recommended (making a total of
eight seconds)."

Does this requirement apply only to Ethernet framing, and not other
IEEE 802 media? Recommend change to:

"For links supporting ARP, four probes with a two-second
wait after each probe is recommended (making a total of eight seconds)."

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

"Hosts that are equipped with persistent storage MAY, for each
interface, record the IP address they have selected, and on the next
boot should use that address as their first candidate when probing."

Recommend breaking the sentence as follows:

Hosts that are equipped with persistent storage MAY, for each
interface, record the IP address they have selected. On booting, hosts
with a previously recorded address SHOULD use that address as their
first candidate when probing." 

------------------------------------------------------------------------
Section 2.4

"If the destination address is a unicast address outside the
169.254/16 range, or a multicast address with scope larger than link-
local, the host SHOULD NOT use its link-local source address, and
should instead use its appropriate routable interface address."

Recommend changing the SHOULD NOT to a MUST NOT, since such packets
will not arrive in a properly functioning network. Therefore there is 
no point in sending such packets. Keeping the existing language could
give license to send such packets in situations where the host will
re-transmit if it doesn't receive a reply. This could result in a
multicast storm.

-----------------------------------------------------------------------
Section 2.5

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

Recommend clarifying this paragraph so that bridging is ok, but that 
NAT'ing is not acceptable:

"An IPv4 datagram whose source and/or destination addresses is in the
169.254/16 range MUST NOT be sent to any router or NAT for forwarding. Any
router or NAT receiving such a datagram MUST NOT forward it or
translate the source and/or destination address, regardless of 
the TTL in the IP header."

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

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

Recommend modifying this as follows:

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

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

"This does not mean that link-local devices are forbidden from
communication 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."

Recommend adding language relating to privately-addressed networks:

"In adition, NAT devices may translate addresses of IP hosts that 
implement 
private addressing."

--------------------------------------------------------------------------
"Alternatively, a remote host could use a secure tunnelling protocol
to establish access to a 'virtual interface' on the local link, via
which it could then send and receive 'virtual' link-local packets
just like any other host directly connected to that link."

I would recommend deleting this paragraph. As described in
draft-ietf-ipsec-dhcp-09.txt, such virtual interfaces are
typically routed and not bridged. As noted in the Zeroconf WG
discussion, such bridged VPNs would unite two linklocal segments,
thereby potentially resulting in address conflicts that did not 
previously exist before the segments were connected via the VPN. 
Depending on how far apart the bridged segments are, the timers
recommended in this document might not be sufficient. So overall
I'm not convinced that this scenario will work very well. 

For example, in order to make such a scenario work,
the VPN protocol would need to support bridging. This can
be accomplished using L2TP using PPP BCP, or potentially by
tunneling Ethernet. The mechanisms for doing this, and the
methods for guaranteeing the IEEE 802 hard and soft
invariants have been the subject of considerable debate
within the L2TPEXT WG, so the subject is best avoided until
a definitive solution can be referenced.

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

Section 3

"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 in use
already on the new link, then the interfaces in question must be
reconfigured to select new unique link-local addresses."

Recommend capitalization of requirements, as follows:

"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 in use
already on the new link, then the interfaces in question MUST be
reconfigured to select new unique link-local addresses."

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

Section 3.2

Note the example in this section would NOT work if the host A were 
configured
as a bridge, as is required in Bluetooth Ethernet emulation, for example. 
However, in this case gratuitous ARPs from D and C would reach other, 
resulting
in address conflict resolution. 

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

Section 4

"When joining two large networks there is a greater chance of
collision, but large networks are not expected to rely heavily on
link-local addresses for normal communication. Large networks are
better managed by using existing mechanisms such as DHCP servers to
allocate addresses."

I think that this sentence doesn't apply to the new IPv4 linklocal
spec as much as to the old one. Presumably there will be devices that
will only support IPv4 linklocal addressing for security reasons and
these devices will not be able to determine whether they are on a small
or large network, since they won't be looking for a DHCP server.

Recommend changing this to:

"When joining two large networks (defined as networks with a substantial
number of hosts per segment) there is a greater chance of collision. In
such networks, it is likely that the re-joining of previously separated
segments will result in one or more hosts needing to change their 
IPv4 linklocal address, with subsequent loss of TCP connections. In 
cases where separation and re-joining is frequent, as in remotely
bridged networks, this could prove disruptive. Furthermore, in such
networks, the interal between gratuitous ARPs may need to be enlarged
in order to enable conflict detection. However, unless the
number of hosts on the re-joined segments is very large, the traffic
resulting from the re-join and subsequent address conflict resolution
will be small."

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

Is it worth making a statement about the status of the DHCP auto-config 
option?

Suggested text:

"Since this specification does not require DHCP server detection, use of
the DHCP AutoConfigure option would serve no useful purpose. 

No existing implementations send the DHCP AutoConfigure option, nor do 
they 
act upon this option if it is received in a DHCPOFFER or DHCPACK. Since 
this
document proposes that linklocal addresses be usable at all times, there 
is
no need for such an option, and hosts receiving this option MUST ignore 
it."

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

Appendix

"Having failed to contact a DHCP server, these implementations retry
once every five minutes. If the failure to contact a DHCP server was
a transient problem such as a loose Ethernet cable, after correcting
the error, it could take up to five minutes for the system to
reconfigure with a server-assigned address."

Actually this problem exists only on operating systems that do not
implement media sense. Where media sense is available, the loss of
interface connectivity can be detected, and auto-configuration
begun immediately after re-connection.

BTW, I am wondering if it might not make sense to enlarge the Appendix
with additional description of the behavior of existing systems. That
would allow us to completely eliminate the need for the older draft.
Some potential text is given below:

5.  Behavior of Legacy Implementations

5.1.  Microsoft Windows 98 and 98SE

Windows 98 and 98SE systems choose their IP address on a pseudo-random
basis. This ensures that systems rebooting will obtain the same auto-
configured address, unless a conflict is detected. The address selection
algorithm is based on computing a hash on the interface MAC address, so
that a large collection of hosts should obey the uniform probability
distribution in choosing addresses within the 169.254/16 address space.

The Windows 98 and 98SE DHCP Client sends out a total of 4 DHCPDISCOVERs, 
with an inter-packet interval of 6 seconds.  When no response is received 
after
all 4 packets (24 seconds), it will auto-configure an address.

The auto-configure retry count for Windows 98 and 98SE systems is 10.  
After 
trying 10 auto-configured IP addresses, and finding all are taken, the 
host 
will boot without an IP address. Auto-configured Windows 98 and 98SE 
systems 
check for the presence of a DHCP server every five minutes. If a DHCP 
server is
found and Windows 98 is not successful in obtaining a new lease, it
keeps the existing auto-configured IP address.

If Windows 98 and 98SE is successful at obtaining a new lease, it drops 
all
existing connections without warning. This may cause users to lose
connection to sessions in progress. Once a new lease is obtained,
Windows 98 and 98SE will not allocate further connections using the auto-
configured IP address.

Windows 98 and 98SE systems do not send packets addressed to a linklocal 
address to the default gateway if one is present; these addresses are 
always
resolved on the local segment.

Windows 98 and 98SE systems do not implement media sense. This means
that network connectivity issues (such as a loose cable) may prevent a
system from contacting the DHCP server, thereby causing it to auto-
configure. When the connectivity problem is fixed (such as when the
cable is re-connected) the situation will not immediately correct
itself. Since the system will not sense the re-connection, it will
remain in autoconf mode until an attempt is made to reach the DHCP
server.

The mini-DHCP server included with Windows 98 SE Internet Connection
Sharing (ICS), which functions as a NAT, allocates out of the 192.168/16
private address space [6] by default.  
However, it is possible to change the allocation prefix via a
registry key, and no checks are made to prevent allocation out of the
linklocal prefix. When configured to do so, Windows 98 SE ICS will NAT
packets from the linklocal prefix off the local link. Windows 98SE ICS
does not automatically route for the linklocal prefix, so that hosts
obtaining addresses via DHCP cannot communicate with auto-configured-
only devices.

Other home gateways exist that allocate addresses out of the linklocal
prefix by default. Windows 98 and 98SE systems can use a 169.254/16 
linklocal
address as the source address when communicating with non-linklocal
hosts. However, Windows 98 and 98SE do not support router
solicitation/advertisement as specified in [7]. This means that Windows
98 and 98SE systems will typically not be able to discover a default 
gateway 
when in autoconfig mode.

5.2.  Windows 2000 and Windows ME

5.2.1.  client behavior

The auto-configuration behavior of Windows 2000 and ME systems is
identical to Windows 98 and 98SE except in several respects:

Media Sense
Router Discovery
Silent RIP

Windows 2000 and ME implement media sense. This means that as soon as
network connectivity is detected, a DHCPDISCOVER will be sent on an
interface. This means that systems will immediately transition out of
autoconf mode as soon as connectivity is restored.

Windows 2000 and Windows ME also support router discovery [7], although
it is turned off by default. Windows 2000 also supports a RIP listener.
This means that it is possible to discover a default gateway while in
autoconfig mode.

Windows 2000 and ME ICS behaves identically to Windows 98 SE with
respect to address allocation and NATing of linklocal prefixes.

5.3.  Apple MacOS 8.5

MacOS 8.5 choose the IP address on a ?  basis. <Insert more on the
algorithm here. Is it truly random?  What happens when a system reboots?
Does it get the same address?>

MacOS 8.5 sends three DHCPDISCOVER packets, with timeouts of 4, 8, and
then 16 seconds.  When no response is received from all of these
requests (28 seconds), it will auto-configure.

The auto-configure retry count for MacOS 8.5 is 10.  After trying 10
auto-configured IP addresses, and finding all are taken, the host will
boot without an IP address. Auto-configured MacOS 8.5 systems check for
the presence of a DHCP server every five minutes.

If MacOS 8.5 is not successful in obtaining a new lease, it drops the
existing auto-configured IP address.  If MacOS 8.5 is successful at
obtaining a new lease, it drops all existing connections after posting a
warning. This may cause users to lose connection to sessions in
progress. Once a new lease is obtained, MacOS 8.5 will not allocate
further connections using the auto-configured IP address.  [Issue: check
with Stuart on this]

<Any comments on media sense behavior?> <Any comments on the behavior of
the Airport with respect to NATing of linklocal prefixes?>

---

From: Peter Johansson <[email-masked]>
Date: Wed, 04 Apr 2001 13:22:02 +0800

At 11:22 PM 4/2/01, Stuart Cheshire wrote:

>cases, Ethernet is not in fact a requirement, and other IEEE 802 media 
>would work just as well.

Why are we mentioning EITHER Ethernet or IEEE 802, specifically? Is there 
something unique to Draft-IETF-ZeroConf-LinkLocal that concerns itself 
solely with IEEE 802 networks?

What about the other media that support Internet protocol that will have 
link local usage? For example, IPv4 over IEEE 1394 (RFC 2734)?

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 04 Apr 2001 01:08:50 -0700

> link local usage? For example, IPv4 over IEEE 1394 (RFC 2734)?

We mention Ethernet to provide context. For example, the draft recommends an
interval of two seconds between ARPs. On what networks is this appropriate?
On *all* networks that support ARP? What about a network that supports ARP
but runs at a rate of one bit per second? Mentioning 10/100/1000Mb/s
Ethernet indicates the scope for which the recommendation was intended. For
networks outside this scope, implementers may want to adjust the timing
parameters (and issue a new RFC specifying IPv4 link-local for those
networks).

Stuart Cheshire <[email-masked]>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 4 Apr 2001 09:53:01 -0700

>but runs at a rate of one bit per second?

I don't think we're likely to see more ARP-supporting media at low data
rates. New media (1394, 802.11, etc.) are all high speed. So it's
probably fine for these parameters to apply to any media that
supports ARP. The recommendations can be a SHOULD in order to be
able to deal with exceptions.