Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt

From: Erik Guttman <[email-masked]>
Date: Fri, 6 Dec 2002 14:24:32 +0100 (CET)

Erik,

While the debate continues on the TTL setting on send and handling on 
receive, I will try to make progress on your other issues.

For each of the suggested changes, I mark off a section with '-' bars
and show the original and modified text, with change bars in the left
column to aid in comparision.

I hope that I have also addressed some of Keith's concerns (in the
applicability statement and section 7).

-----------------------------------------------------------------------
On Fri, 29 Nov 2002, Erik Nordmark wrote:

> > > 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.)
> > 
> > Are Sections 7. 1 and 7.2 insufficient?
> 
> Three issues with those:
>  - They don't explicitly mention that the stability of the addresses is
>    affected by late collisions i.e. when the address has been in use for
>    a while

OK.  I clarify section 7.1 with this point.

From draft-ietf-zeroconf-ipv4-linklocal-07.txt:

7.1 Address Changes, Failure and Recovery

   IPv4 link-local addresses used by an application may change over
   time. Some application software encountering an address change
   will completely fail. For example, client TCP connections will fail,
   servers whose addresses change will have to be rediscovered, blocked
   reads and writes will exit with an error condition, and so on.

To:

7.1 Address Changes, Failure and Recovery

   IPv4 link-local addresses used by an application may change over
   time. Some application software encountering an address change
   will completely fail. For example, client TCP connections will fail,
   servers whose addresses change will have to be rediscovered, blocked
   reads and writes will exit with an error condition, and so on.

|  Note well that address changes may occur at any time.  A host
|  attempting to establish a TCP connection with a peer using an 
|  address which worked previously may not work subsequently, as
|  the peer's address may have changed.  An existing TCP connection
|  which has been in use for some time may fail, as one or both of
|  the communicating peers has been forced to change its address.

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

>  - They are written as "all applications SHOULD be fixed to be usable in
>    this environment" - it is more realistic for people deploying this
>    technology to turn this around and instead issue a warning that 
>    link-locals should not be used unless all applications used in the 
>    network are known to not depend on X, Y, Z.

Revise Section 7.

From draft-ietf-zeroconf-ipv4-linklocal-07.txt:

7. Application Programming Considerations

   Use of IPv4 link-local autoconfigured addresses presents additional
   challenges to writers of applications and may result in existing
   application software failing.

To:

7. Application Programming Considerations

   Use of IPv4 link-local autoconfigured addresses presents additional
   challenges to writers of applications and may result in existing
|  application software failing.  Operational problems will arise if 
|  the following considerations are not addressed by application
|  software.  It is therefore RECOMMENDED that IPv4 link-local
|  autoconfiguration support be deployed only with application software
|  which is robust to address changes, does not forward IPv4 link-local
|  addresses and avoids address ambiguity problems, as described below.

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

>  - Warnings about limitations of the applicability makes sense up
>    front in the document - not towards the end.

I agree.  I add a forward reference and applicability warning to Section
1.2.

From draft-ietf-zeroconf-ipv4-linklocal-07.txt:

1.2. Applicability

   The specifications in this document apply to any IEEE 802 media [802]
   including Ethernet [802.3], and other similar link-layer network
   technologies that operate at data rates of at least 1Mb/s, have a
   round-trip latency of at most one second, and support ARP [RFC 826].
   Wherever this document uses the term "Ethernet", the text applies
   equally to any of these network technologies.

To:

1.2. Applicability

|  IPv4 link-local addresses and their dynamic configuration have 
|  profound implications upon applications which use them.  This is
|  discussed in Section 7.  Existing applications fundamentally 
|  assume addresses of communicating peers are routable, relatively
|  unchanging and unique.  These assumptions no longer hold with IPv4
|  link-local addresses.  IPv4 link-local addresses are therefore 
|  applicable for those existing applications which can either
|  accomodate these differences or for those applications which are
|  modified to account for dynamic addresses, their limited scope and
|  their potential ambiguity.

   The specifications in this document apply to any IEEE 802 media [802]
   including Ethernet [802.3], and other similar link-layer network
   technologies that operate at data rates of at least 1Mb/s, have a
   round-trip latency of at most one second, and support ARP [RFC 826].
   Wherever this document uses the term "Ethernet", the text applies
   equally to any of these network technologies.

---------------------------------------------------------------------- 
> >    add ->
> > 
> >    It would also be possible for an on-link attacker to spoof ARP
> >    packets which would cause a host to break all its connections by
> >    switching to a new address.
>
> OK, but you need to point out that this is a new threat added
> by link-local - and not just bundle if with the current "arp is insecure"
> threats.
>
> > which use global addresses.  An on-link attacker could spoof ARP
> > packets which would cause a packets destined for a host to be
> > redirected to the attacker, who could discard them, etc.
> 
> That is a different threat - MiTM can be done with current ARP vs. the new
> "IP address invalidation" attack with is possible with this draft.
> RFC 826 isn't subject to a threat were an on-link attacker can get
> a host to change its address thereby, as a result of receiving a single ARP
> packet, will break all its existing communication.
> This distinction should be made clear.

A revised security considerations section follows:

From draft-ietf-zeroconf-ipv4-linklocal-07.txt:

5. Security Considerations

   The use of IPv4 Link-Local Addresses may open a network host to new
   attacks. In particular, a host that previously did not have an IP
   address, and no IP stack running, was not susceptible to IP-based
   attacks. By configuring a working address, the host may now be
   vulnerable to IP-based attacks.

   The ARP protocol [RFC 826] is insecure. A malicious host may send
   fraudulent ARP packets on the network, interfering with the correct
   operation of other hosts. For example, it is easy for a host to
   answer all ARP requests with replies giving its own hardware address,
   thereby claiming ownership of every address on the network.

   Implementers are advised that the Internet Protocol architecture
   expects every networked device or host must implement security
   which is adequate to protect the resources to which the device
   or host has access, including the network itself, against known
   or credible threats. Even though use of link-local addresses
   may reduce the number of threats to which a device is exposed,
   implementers of devices supporting the Internet Protocol must
   not assume that a customer's local network is free from security
   risks.

   While there may be particular kinds of devices, or particular
   environments, for which the security provided by the network is
   adequate to protect the resources that are accessible by the
   device, it would be misleading to make a general statement to
   the effect that the requirement to provide security is reduced
   for devices using link-local addresses as a sole means of access.

   In all cases, whether or not link-local addresses are used, it
   is necessary for implementers of devices supporting the Internet
   Protocol to analyze the known and credible threats to which a
   specific host or device might be subjected, and to the extent
   that it is feasible, to provide security mechanisms which
   ameliorate or reduce the risks associated with such threats.

To:

5. Security Considerations

   The use of IPv4 Link-Local Addresses may open a network host to new
   attacks. In particular, a host that previously did not have an IP
   address, and no IP stack running, was not susceptible to IP-based
   attacks. By configuring a working address, the host may now be
   vulnerable to IP-based attacks.

   The ARP protocol [RFC 826] is insecure. A malicious host may send
   fraudulent ARP packets on the network, interfering with the correct
   operation of other hosts. For example, it is easy for a host to
   answer all ARP requests with replies giving its own hardware address,
   thereby claiming ownership of every address on the network.

|  A host implementing IPv4 link-local configuration has the additional
|  vulnerability to selective reconfiguration and disruption.  It is
|  possible for an on-link attacker to issue ARP packets which would
|  cause a host to break all its connections by switching to a new 
|  address.  The attacker could force the host implementing IPv4 
|  link-local configuration to select certain addresses, or prevent it 
|  from ever completing address selection.  This is a distinct threat 
|  from that posed by fraudulent ARPs, described in the preceding 
|  paragraph.

   Implementers are advised that the Internet Protocol architecture
   expects every networked device or host must implement security
   which is adequate to protect the resources to which the device
   or host has access, including the network itself, against known
   or credible threats. Even though use of link-local addresses
   may reduce the number of threats to which a device is exposed,
   implementers of devices supporting the Internet Protocol must
   not assume that a customer's local network is free from security
   risks.

   While there may be particular kinds of devices, or particular
   environments, for which the security provided by the network is
   adequate to protect the resources that are accessible by the
   device, it would be misleading to make a general statement to
   the effect that the requirement to provide security is reduced
   for devices using link-local addresses as a sole means of access.

   In all cases, whether or not link-local addresses are used, it
   is necessary for implementers of devices supporting the Internet
   Protocol to analyze the known and credible threats to which a
   specific host or device might be subjected, and to the extent
   that it is feasible, to provide security mechanisms which
   ameliorate or reduce the risks associated with such threats.
 
---------------------------------------------------------------

> > >  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.
> > 
> > 2.3 Shorter Timeouts on Appropriate Network Technologies
> > 
> >    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. 
> > 
> >    add -->
> > 
> >    In some cases, the delay can be considerably longer due to other 
> >    networking infrastructure.
> > 
> > The purpose of this section is to give some guidance to implementors
> > to set appropriate values for their timers, not to definitively answer
> > what those settings should be.
> 
> Thanks for the attempt, but I think this addition is insufficient.
> 
> Deleting text might be a better approach.

Here is a revised section 2.3 which removes the questionable text and
adds an explanation of why shorter timeouts may not be such a great
idea.

From draft-ietf-zeroconf-ipv4-linklocal-07.txt:

2.3 Shorter Timeouts on Appropriate Network Technologies

   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,
   this may not be a great problem, but for other types of device,
   particularly portable hand-held wireless devices, a ten-second delay
   before networking services becomes available may not be acceptable.
   For this reason, shorter time values may be used on network
   technologies that allow the device to determine when the link has
   become active and can be reasonably trusted to deliver packets
   reliably. On these network technologies the recommended time values
   are: The host should first wait for a random time interval selected
   uniformly in the range 0-200 milliseconds, and then send four probe
   packets, waiting 200 milliseconds after each probe, making a total
   delay of 800-1000 milliseconds before a chosen IP address may be
   used.

   Should future versions of the IEEE Spanning Tree Protocol be enhanced
   to inform clients when the link is ready to begin forwarding packets,
   then the shorter time values may be used on these networks too.

To:

2.3 Shorter Timeouts on Appropriate Network Technologies

|  The time values specified above result in a delay of 8-10 seconds
|  before a chosen IP address may be used. 

   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. 

|  There may be additional delays before a host is able to send and
|  receive datagrams on a link.  Some switches may only forward packets
|  after several seconds.  Implementors should exercise some restraint, 
|  therefore, in setting timers to short, aggressive values.  If hosts 
|  configure IPv4 link-local addresses before these addresses can be
|  defended, there is an increased risk of collision once the host is 
|  able to send and receive datagrams on the link.

|  Shorter time values MAY be used on network
   technologies that allow the device to determine when the link has
   become active and can be reasonably trusted to deliver packets
   reliably. On these network technologies the recommended time values
   are: The host should first wait for a random time interval selected
   uniformly in the range 0-200 milliseconds, and then send four probe
   packets, waiting 200 milliseconds after each probe, making a total
   delay of 800-1000 milliseconds before a chosen IP address may be
   used.

|

---------------------------------------------------------
 
> > (a) The paragraph must be augmented with the following:
> >     Host must consider the case where more than one interface is 
> >     connected to the same link.  Say the list of link-layer addresses
> >     for a given host is L.  The claim-defend algorithm MUST consider
> >     the case when arp sender link-layer address is in L.  In this case, 
> >     the IP sender address field in the arp message *does not* constitute
> >     a conflict necessitating the host to select another address for any
> >     interface in the list L.
> 
> Wouldn't this result in the two (or more) interfaces attached to the same
> link on the node to have the same v4LL address? While it might be possible
> to get such a configuration to work, I suspect it requires additional things.
> 
> > 
> > (b) Each interface should be assigned a different v4LL address and
> >     can then operate independently. 
> >
> > (b)...
> Which of the two b's? :-)

Format error!  Shame on me.  (a) and (b) above are alternatives.  The
paragraph below is an assessment of the alternatives.

(b) is simpler, and as you state above, it is less instable due to
address reconfiguration events and has fewer security consequences.
Further, (a) relies upon all link-layer addresses being unique,
which is not necessarily true and not required for (b).

Proposal:  (b)

Until there is further discussion on this point, I will not suggest
text.

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

Erik

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 09:12:49 -0500

> |  addresses and avoids address ambiguity problems, as described below.

that sounds reasonable.  however, with the current proposal LL is enabled
by default on all platforms that support it, and there is no defined way 
to disable it.  how are users/networks to avoid deploying LL (say, if they're
running apps that don't meet the above conditions) without a mechanism to 
disable it?

Keith

---

From: Erik Guttman <[email-masked]>
Date: Fri, 6 Dec 2002 15:36:34 +0100 (CET)

> running apps that don't meet the above conditions) without a mechanism to 

First, This protocol is an elective standard.  No one has to implement
or deploy it.  

Should vendors choose to implement it, and customers choose to buy
their equipment, there are several ways in which the recommendation will
have an impact.

 a) Proper app support before inclusion of IPv4LL support - closed
    platform

    Example: A device vendor which offers, say, a print server or file
    server with no human interface.  Such devices already exist.  These
    servers are currently written in a fashion which is brittle wrt
    v4LL.  The vendor should harden the server code so that it will not
    break, panic, etc if its own address changes.  The vendor should
    think twice about supporting v4LL on more than one interface.  If
    the vendor does, the server will have to be sophisticated enough
    to keep address/interfaces separate so that if a request comes from
    interface A, address A it is distinct from a request which comes 
    from interface B, address A.  Finally, the server will have to be
    very carefully written so that it does not forward locators.  For
    example - a web server generating dynamic content will have to 
    use names instead of addresses in links if possible (where names
    can be resolved using LLMNR, etc).

 b) Proper platform support before inclusion of IPv4LL support

    Example:  I understand Microsoft includes a system level 'address
    changed' exception which IP services are supposed to catch.  This
    is part of their IPv6 developer environment.  Microsoft has 
    modified their own server software to accomodate address changes
    and has notified their developers to do the same.  This could be
    done for IPv4 LL as well.

    Example:  Pending new and improved APIs for dealing with address
    ambiguity on separate interfaces, vendors could include v4LL on
    only one interface.  This would eliminate one of the three 
    identified issues for applications using v4LL addresses.

    Example:  Platform can offer late binding service discovery and
    name resolution protocols (SLP, LLNMR, Rendezvous, UPnP, etc)
    so that clients can discover services even if the server's
    address changes.  Vendors can work hard to inform developers
    on their platforms of the problem and the solution.

    Example:  A vendor can offer an 'off switch', where users who
    are not getting results they want with v4LL can turn it off.

Erik

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 09:58:09 -0500

> First, This protocol is an elective standard.  No one has to implement

get real.  we both know that this is going to be deployed on both of the
general-purpose platforms that make up 99% of the installed base of those
platforms, and customers have little choice about whether to buy
one of those platforms.  saying it is an elective standard is meaningful for 
special-purpose devices, perhaps, but not for general purpose platforms.

so the "it's not our fault if it's broken because nobody has to implement
it argument" is pure hogwash.
 
>     done for IPv4 LL as well.

it doesn't solve the problem.  few application protocols are able to
recover from an unanticipated address change; this essentially requires
that (a) they implement acks at layer 7 (b) that each sender buffer every
message sent until it receives an ack for that messages (c) that there
be a uniform and stable naming system within the app to take the place of 
IP (and it's not reasonable to assume that DNS is used for this purpose)

>     identified issues for applications using v4LL addresses.

even the APIs don't solve the problem, as they require increased complexity
of applications which is not always feasible.

>     on their platforms of the problem and the solution.

those protocols don't solve the problem either - what they mainly serve
to do is to make life more complex and to increase the diversity of
operating environments that apps have to cope with.

>     are not getting results they want with v4LL can turn it off.

this is by far the simplest and most reliable solution.   there needs to be
a way to do this from the network (at least as much as for any other knob
that people want to control via DHCP) and it needs to be part of the standard.  

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 06 Dec 2002 10:02:34 -0500

> that people want to control via DHCP) and it needs to be part of the standard.

If you are going to advocate a new, easier way to remotely change
configuration on machines, then I personally will scream bloody murder
unless it's tied into a known, tested, and reliable, cross platform
authentication and encryption system *by default*. There are enough ways to
modify stuff remotely *now*, we do NOT need another method, and it is a
hideously *bad* idea to make one part of the standard

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 06 Dec 2002 10:04:22 -0500

> IP (and it's not reasonable to assume that DNS is used for this purpose)

Good point. But for now, DNS is all we have, so we should use it. Let's not
delay stuff for another decade waiting for YAMS. (yet another magic
standard).

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 6 Dec 2002 16:04:55 +0100 (CET)

> |  their potential ambiguity.

Instead of "for those existing applications ..." it might make more sense
to say "if it is either known that all applications that are used
can accomondate this change in the properties of the IP addresses,
or all applications that are used have been modified to account 
for dynamic addresses, their limited scope and their potential ambiguity.

> |  [802.1d] often silently discard all packets for several seconds. 

Still doesn't make sense if the discard time is 30-45 seconds.

If we talk about the protocol and not the text, I know of
two interesting cases on IEEE 802 media:
1. No spanning tree on the port to which you connect, or the port has been
   enabled for a long time before the address claim is done.
   In this case it probably makes sense to have slightly shorter timers i.e.
   a few packets over a few seconds might suffice. Thus 3 seconds instead of 8.
2. Spanning tree on the port to which you connect.
   If the address claim is done immediately after bringing up the link
   the host might as well wait for 45 seconds before sending any packet.

I don't know if the host can tell the difference between #1 and #2 - or
if it can "ask" (at the Ethernet layer) if the switch is running STP.

With RSTP I think the problem goes away and the approach used in #1 can be
used.

   Erik

---

From: Erik Guttman <[email-masked]>
Date: Fri, 6 Dec 2002 17:29:41 +0100 (CET)

> it argument" is pure hogwash.

Arguing about this is fruitless.  The protocol is out there.  We need to
publish a specification which explains how it works and how to use it
safely.
  
> IP (and it's not reasonable to assume that DNS is used for this purpose)

Applications can be made to recover from unanticipated address change
without protocol level support.  Stateful protocols will lose their
state and have to rebuild sessions.  That is not what I am suggesting.

> of applications which is not always feasible.

I am not suggesting we have this debate in the text above.

> operating environments that apps have to cope with.

Appletalk proves you are wrong.

> this is by far the simplest and most reliable solution.  there needs
> to be a way to do this from the network (at least as much as for any
> other knob that people want to control via DHCP) and it needs to be
> part of the standard. 

We have been through this in 3 WG last calls and 2 IETF last calls.
Your opinion is the rough part of the consensus here.

I bring up the off switch only because there is nothing preventing a
vendor from offering this.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n             
 Solaris Installation and Provisioning         phone: +49 6227 356 202
 Sun Microsystems                               cell: +49 172 865 5497 
                       (140 char max) pager: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 13:07:54 -0500

> publish a specification which explains how it works and how to use it

documenting existing practice is generally a good idea.
assessing the effect of an existing practice is also useful.
if the document were just a description of existing  practice,
I'd fully its publication as an Informational RFC.

but that's not what this document is trying to do.  it is trying to
recommend a variant of existing practice even though that variant
is obviously harmful to some networks and applications, and it's
trying to do so without recommending any effective measures for limiting
that harm.  and it's trying to get IETF's endorsement of these practices.

> without protocol level support.  

Wow.  that's an extraordinary statement.  would you care to explain how
that can be done?

> Appletalk proves you are wrong.

actually, appletalk is a good illustration of the phenomenon.  it results
in either having appletalk-only apps or having apps that try to deal with
a mixture of appletalk and DNS.  we either get different apps for the LAN
vs. the WAN or apps that work differently in different environments. 

> Your opinion is the rough part of the consensus here.

why do you keep trying to justify a lack of technical soundness
by appeals to consensus?  consensus within the working group 
does not make up for a failure of the document to meet the
basic standards of 2026.
 
Keith

---

From: Vincent Lubet <[email-masked]>
Date: Fri, 6 Dec 2002 10:14:26 -0800

> IP (and it's not reasonable to assume that DNS is used for this 

This problem of unanticipated address change is not new to the Internet 
and not specific to IPv4 LL. This has been a reality that we have faced 
for many years since the days DHCP and PPP have been used by ISPs.

The days of static IP address and permanent links are long gone. Now 
the majority of hosts on the Internet are either mobile or have 
addresses assigned temporarily.

My point is that platforms that support dynamic address assignment with 
DHCP or PPP should have no problem supporting IPv4 LL.

Vincent

---

From: Erik Guttman <[email-masked]>
Date: Fri, 6 Dec 2002 19:43:45 +0100 (MET)

> Wow.  that's an extraordinary statement.  would you care to explain how

A server can bind to its address, accept connections and process
requests as it does now.  If there is a socket failure of any kind, 
check to see if the address has changed.  If so start reading this
paragraph again.

A client can bind to its address, make a connection and send a request.
If for any reason it fails and the user wants to try again, start
reading this paragraph again.

This is of course easier if the OS can signal the client or server to
change its address.  In this case, the client or server knows exactly
what to do.

Sorry if this is turning into a pedantic thread.

> does not make up for a failure of the document to meet the

The output of the WG to the IESG is that link-level configuration 
is not dependent upon DHCP.  We make no mention of RFC 2563
intentionally, though a vendor is of course free to implement it.

The IESG understands this position by now, and your dissenting view.

Erik

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 14:03:44 -0500

> reading this paragraph again.

And how do the client and server know that they're connected to the same
parties as before?  How do they reconcile the fact that they don't know
how much of their previous transmissions got through?  How can they
efficiently recover from the loss of connection integrity?  

Say for the sake of example that this is a protocol that transfers 
potentially-large files over potentially-slow links.  Are you really 
claiming that an acceptable mode of recovery from a broken connection 
is to reconnect and start transfering those files over again?

> change its address.  In this case, the client or server knows exactly

That's simply false, and frankly I have a hard time believing that you 
don't have the technical expertise to understand that it's false.

> Sorry if this is turning into a pedantic thread.

It might be pedantic in tone, but it's not instructive.   And you haven't
justified your extraordinary statement in the slightest.   

> is not dependent upon DHCP.  

The specific mechanism is not at issue here.  The lack of any mechanism
to address the problem is.

Keith

---

From: Erik Guttman <[email-masked]>
Date: Fri, 6 Dec 2002 20:22:08 +0100 (MET)

On Fri, 6 Dec 2002, Keith Moore wrote:
> parties as before?  

Use a service discovery protocol, or LLMNR or appletalk to find the
party we want to talk to, not an address.

> How do they reconcile the fact that they don't know
> how much of their previous transmissions got through?  

I did not claim that it was easy to reconstruct session state, or even
possible. 

> How can they efficiently recover from the loss of connection integrity?  

Leaving efficency aside, most apps work fine if the connection goes down
and comes back up.  Just start a new session.  Services that I am
familiar with work fine in these environments, too.  Software can obtain
new addresses and start over, instead of crashing.

Erik

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 14:22:59 -0500

> for many years since the days DHCP and PPP have been used by ISPs.

False.  Properly-configured DHCP servers do not change addresses at a 
whim. PPP service can also be set up to use static IP, and users that
need that level of stability will buy it.

What you are trying to assert is that because some networks have 
misconfigured their DHCP servers and ISPs tend to provide dynamic IP
service by default for dialup connections, that all applications
running on all IP networks should already have to deal with transient 
addresses.  That's simply not the case.  In fact there are few 
applications that can operate reliably with transient addresses on 
both ends.
 
> The days of static IP address and permanent links are long gone. 

(why do so many people in this group make blatently false statements?)

essentially every service on the net relies on static IP and "permanent" links.

more and more ISPs are selling static IP addresses and always-on connections
for residential and small business use.  a few years ago I could find one
provider that would sell me service to my home with static IPs at a
reasonable price; when I recently started looking for a new ISP I was 
able to find a few large ISPs who specifically advertised this as a feature -
because more and more customers want it.

> Now the majority of hosts on the Internet are either mobile or have

perhaps, but "the majority of hosts" doesn't indicate anything about
the importance of the services that the net can support, nor does it
say anything about future trends.

> DHCP or PPP should have no problem supporting IPv4 LL.

that conclusion is not warranted.  DHCP doesn't break things if configured 
properly; and when it does break things, there's a way to fix it.  
dynamic assignment with PPP is generally only an issue when the connection
is inherently intermittent (as in a dialup line rather than a nailed-up
connection) - but people quite reasonably have lowered expectations in that 
environment and they don't expect as many applications to work.   

the same platform that is used with PPP on a dialup line is also used 
with Ethernet on a nailed-up line, but that doesn't mean that people have
the same expectations of each environment.

Keith

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 6 Dec 2002 11:24:59 -0800

> efficiently recover from the loss of connection integrity?

The client can use the same method as used originally to find the other 
party, whether it be DNS or a service discovery protocol. Any network 
protocol should be designed in such a way that recovery is possible in 
case connectivity breaks down. Leased lines go down, modems drop 
connections, people trip over power cords to switches, equipment fails. 
An application can not assume that a TCP session will not die, except 
in very special circumstances. Recovery may not be efficient, the 
important thing is that it is possible.

> is to reconnect and start transfering those files over again?

This is why FTP and HTTP have added extensions to effectively resume a 
file transfer. Many people still use modems. Those people lose their 
connections quite often and they end up with a different address. The 
applications they use must be able to recover when this happens. Many 
applications may contend with protocols that don't support an efficient 
way to recovery, but the application can usually work around this 
problem. This is not a problem that did not exist before IPv4LL and for 
the most part, this is not a problem that can only be solved in the 
protocol.

> don't have the technical expertise to understand that it's false.

This is not false. If an application knows when IP addresses changes, 
such as when I unplug my laptop from the wired network and connect to 
the wireless one, the application can be much quicker to respond 
instead of waiting for the TCP session to timeout.

-josh

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 14:29:33 -0500

> party we want to talk to, not an address.

a) existing apps don't do this, so you're not talking about existing apps
b) LLMNR at least doesn't solve the problem because it suffers from the
   same naming ambiguities that DNS does.  I can't speak for the other
   protocols.

> and comes back up.  Just start a new session.  

It's really odd to describe a failure condition as "working fine".

If a long email message is sent from point A to point B and the connection
dies after the client sends ".CRLF", and before the client receives a
2xx reply, the sender will resend the message and the recipient will get
a duplicate.  Would you really call that "working fine"?

> Services that I am familiar with work fine in these environments, too.  

it appears you aren't very familiar with many services.

> Software can obtain new addresses and start over, instead of crashing.

yes they can often start over.  some even do.   whether this is an 
acceptable means of recovering is highly dependent on the application.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 14:36:08 -0500

> party, whether it be DNS or a service discovery protocol. 

it doesn't work in general, because it doesn't guarantee that it reached
the same party as before.

> Any network 
> case connectivity breaks down. 

it's really kind of you to redefine the Internet architecture for us
in one blanket assertion.    don't be surprised if not everyone else
goes along with it.

indeed, IP is designed to allow recovery from those kinds of failures, 
and higher level apps make use of this.   but IP assumes that IP 
addresses are stable across those failures; that's fundamental to 
how IP works.  what you are asserting it's that it's okay to take away 
this property of IP and still expect applications to recover.

> in very special circumstances. 

no, but it's reasonable to assume that sessions of a particular duration
have a low probability of failure, and in many cases it's reasonable to
assume that it's okay to simply accept that failure rate.  zeroconf
is asserting that it's okay to increase that failure rate, and that 
any problems it causes by doing so are somebody else's to deal with.

> file transfer. 

right, but what you're saying is that even more apps will need to do this
in order to accomodate zeroconf's increased failures.

> instead of waiting for the TCP session to timeout.

a quick response isn't very helpful if the app doesn't have an effective
means of recovering from the response.

Keith

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 6 Dec 2002 13:01:19 -0800

> this property of IP and still expect applications to recover.

I'm not redefining anything, just observing that application and 
protocol developers have to contend with failure cases already. Modem 
connections are a common example of this. Anyone that is developing a 
protocol that may be used over a modem link should consider the 
possibility that the link may go down and a new address may be 
acquired. Yes, some people pay more for static IP addresses with 
dial-up. If you're designing a protocol for general use, you have to 
accept that not everyone does pay for a static address so you may not 
be able to rely on such a luxury.

> any problems it causes by doing so are somebody else's to deal with.

There is no evidence that link-local addresses increase the failure 
rate. AppleTalk uses a similar addressing scheme. AppleTalk addresses 
did not change often, only when conflicts arose. If the nodes on the 
network properly implement the protocol and the number of nodes does 
not exceed the number of addresses available, then the IPv4LL addresses 
will probably be very stable. Others have pointed out that DHCP can 
lead to addresses that change often. You have argued that only happens 
when something is misconfigured or not operating correctly. In the case 
of IPv4LL addresses, the same applies, only it there isn't any 
configuration (other than the number of nodes on a link), so IPv4LLs 
will only be unstable when the nodes are not operating correctly.

> in order to accomodate zeroconf's increased failures.

Why do you think that IPv4 will increase the number of failures? It's 
not like the spec requires the nodes to change addresses every 2 
minutes. The address only needs to change when there is a conflict.

> means of recovering from the response.

Your assertion that applications are incapable of dealing with failures 
on the network is one that I do not agree with. Your assertion that 
IPv4LL addresses are so unstable they will increase the incident of 
failures on the network is also something I disagree with.

-josh

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 06 Dec 2002 15:26:34 -0500

> And how do the client and server know that they're connected to the same

How do you know this now?

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Vincent Lubet <[email-masked]>
Date: Fri, 6 Dec 2002 14:13:50 -0800

> (why do so many people in this group make blatently false statements?)

Why are you making such an offensive statement and not concentrate on 
the technical merit of the commennt?

Vincent

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 20:03:59 -0500

> protocol developers have to contend with failure cases already. 

I think you're exaggerating the degree to which this happens.
Most apps that I'm aware of do not recover from these failures.
People are always challenging me for real world examples -
perhaps you'd like to name some apps that transparently recover 
from address changes?  (SMTP qualifies IMHO, so there's at least one)

> Modem connections are a common example of this. Anyone that is developing a
> acquired. 

Based on what assumption?  You can't rely on the DNS name being bound
to the thing you're talking to; a good deal of the time the DNS name
is either ambiguous or it's bound to the address rather than to the host.

> If you're designing a protocol for general use, you have to

Yes, sometimes this happens.  What this tends to mean is that these 
protocols need their own network infrastructure in the form of 
proxies and/or dedicated central servers, and the clients are expected
to connect "out" to those central servers.  

But not all protocols can be made to work this way, at least not
efficiently; and not all networks constrain protocols to work 
this way.  So you do have protocols that will only run in parts
of the network that provide stable addresses.  

But LL doesn't just cause problems for networks that are running 
misconfigured DHCP servers and users with temporary connections and 
dynamic IP assignment.  It will also cause problems for those networks
that have well-behaved DHCP servers and stable IP addresses.

> rate. 

actually it would be fairly easy to model the change rate of LL addresses - 
you could plot it on a graph of average # of hosts on one axis and churn 
rate (frequency at which a new host joins the network) on the other, and 
the plots would be lines showing the set of points on that graph with a
particular mean time between address change.

this would be a useful exercise.  I'll see if I can find time to work it up,
or perhaps someone else can do it.

> Others have pointed out that DHCP can

I believe v4LLs will be unstable under certain combinations of network 
population and churn.  But I suspect we would agree that real numbers 
would be better than intuitive speculation.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 06 Dec 2002 20:14:22 -0500

> the technical merit of the commennt?

Because I can't see the technical merit in the statement.

In most of the technical discussions in which I participate, when somebody
makes a statement that sounds bizarre or indefensible, usually I can at 
least guess at an interpretation of a statement that somebody else said, 
that makes sense according to my own experience.  

That's a lot rarer in this working group.   In this discussion there
are a large number of statements for which the best (and most 
charitable) interpretation I can come up with is "this person is in 
serious denial". and it's hard to not assume worse.

I get the strong impression that people are assuming that this stuff
will only affect small networks and corner cases, and that it will only
be used with a dozen or so applications with which most people are 
familiar, so there's no need to think about how it will work on large
networks or with a wide variety of apps.   But despite the fact that
we know it will break some networks and some apps, people are still 
insisting that it's okay for LL to be on every host on the network 
and that we don't need a way to turn it off.

Is there a better explanation of this than some combination of
"denial" and "irresponsibility"?

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 06 Dec 2002 20:17:28 -0500

> from address changes?  (SMTP qualifies IMHO, so there's at least one)

Anything with a stable name using DyDNS.

> is either ambiguous or it's bound to the address rather than to the host.

Um...based on the reality that Modem connections are unstable, and drop for
all sorts of reasons, including call - waiting. So modem connections are
unreliable for anything but *very* small transfers, and the *vast* majority
of PPP users *don't* have static IP addresses. That problem is real, and yet
it gets handled every day. Kind of detracts from "The sky will fall if your
address changes" theory.

People with laptops and wireless networks with DHCP have their address
change regularly. Mine does 5-6 times a day at MIT. Yet everything still
works.

> that have well-behaved DHCP servers and stable IP addresses.

Nonsense. LL and Rendezvous are in use *now* at MIT, every day, and it
causes zero problems, and the Netops folks there are *very* fast to clamp
down on problems. Not only that, we use a combination of static IPs,
(Ethernet) and DHCP (Wireless), yet no problems with Zeroconf
Implementations. So real world evidence indicates that that any problems are
quite minimal. Unnoticeable even.

> or perhaps someone else can do it.

Why yes...how about some real data. Because according to the spec, the only
time an existing address in use should change is when it has to defend
against another node trying to claim that address and the other node won't
change it's address. This is *not* going to happen often, unless you are
regularly joining subnets, or running defective equipment.

> would be better than intuitive speculation.

Um...yes.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 06 Dec 2002 20:20:28 -0500

> "denial" and "irresponsibility"?

I see no examples of deliberate attempts to lie by anyone. (Let's be
blunt...blatantly false equals lying, and that's what you are, by that
statement, accusing people of.) I see people *disagreeing* with your
baseless, (in the sense of having *no* supporting data) conclusions of
massive harm to existing infrastructure, and my real world experience
indicates that your conclusions are at best, exaggerated.

Just because someone disagrees with your conclusions and views does not make
them a liar.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Vincent Lubet <[email-masked]>
Date: Fri, 6 Dec 2002 18:56:02 -0800

> applications that can operate reliably with transient addresses on

Applications and protocols should be designed to adapt to change and be 
able to deal with unlikely events (see RFC 1122 and 1123). IP address 
change is such a low-probability events.

This does not mean that the applications are not be affected by change 
of IP address, rather that they have to be prepared to such events.

It's useful to remember that change of IP addresses is a low 
propability. This does not constantly happen from datagram to datagram.

> because more and more customers want it.

A lot of people pay for Dynamic DNS services so they are not tied to a 
particular IP address. This is especially valuable because many 
applications use the domain names to identify peers and not IP address.

> say anything about future trends.

We should not limit our reasoning to servers that can afford a static 
IP address.

If the Internet was not limited by NAT, more hosts would be directly 
reachable and those hosts would make their services available. What is 
important for those hosts with transient address is the services they 
make available can be reached. This is easily done by using DNS and 
very difficult with IP address -- see below.

> the same expectations of each environment.

The problem is an IPv4 address does not identify a host on the Internet 
-- let's hope we will get provider independent IPv6 addresses but I 
won't hold me breath for it. With IPv4, the address belongs to a 
network owned by an ISP, a company, an Internet cafe or other 
organization.

Even if DHCP is "properly configured" in each of the many networks the 
system gets attached to, a mobile system gets a different IP address 
from the network it is attached to.

This means the IP address is not a constant that a system can rely to 
make its services available. The DNS is a much better anchor to make 
services available.

Vincent

---

From: Vincent Lubet <[email-masked]>
Date: Fri, 6 Dec 2002 21:48:30 -0800

> "denial" and "irresponsibility"?

Yes, you should pay more consideration and attention to other people's 
point of view.

The point I was making is that many platforms already cope with change 
of IP addresses so IPv4 LL does add any special burden.

Vincent

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 02:16:40 -0500

> able to deal with unlikely events (see RFC 1122 and 1123). 

Please cite specific sections.  I don't find this in 1123 at all;
and 1122 is not about applications.

And frankly I don't believe that address change was ever anticipated
as an event that apps should deal with at the time 1123 was written.
The original purpose of the IP address was to provide an identifier 
for hosts which was stable across changes in the network topology.   
The idea that IP addresses could change without the underlying topology 
changing was never part of the architecture; it emerged as an unintended 
consequence of DHCP.

> of IP address, rather that they have to be prepared to such events.

What you suggest is technically unsound, and neither I nor anyone else
recognizes your authority or the authority of this WG to change the 
Internet architecture.  

> particular IP address. 

What kind of kool-aid are you drinking?  The only people who claim this
is a feature are marketing people - i.e. people who tell lies for a living. 
Even the casual users I know get pissed when their modem connection breaks,
the computer redials, and their applications either fail (conferencing,
games, telephony) or have to be restarted (file transfers).

> This is especially valuable because many 

Some apps use domain names; but these are not reliable peer identifiers.
They work for some use cases and with some configurations, not in general. 

> We should not limit our reasoning to servers that can afford a static 

And you should not pretend that all networks suffer the same limitations
as those which have misconfigured DHCP servers or dynamic IP assignment,
nor should you justify imposing similar limitations on every network
that has a host which supports LL.
 
> very difficult with IP address -- see below.

This working group is supposed to be solving problems related to ad hoc 
networks - trying to make hosts with transient addresses accessible
from elsewhere on the net is not in scope.

> network owned by an ISP, a company, an Internet cafe or other 

In practice a certain level of stability of the address-to-host binding
is always needed, because neither TCP or apps can deal with frequent changes
in those bindings.  Furthermore, we don't have a stable and unambiguous
identifier that can reliably replace an IP address.  At least an IP address
has a consistent meaning as an identifier for a location in the network
topology - DNS names can name almost anything. 

> make its services available. The DNS is a much better anchor to make 

DNS works better for some cases, worse for others.  It's not suitable
for all apps - it's too unreliable, too slow, and the names are too 
ambiguous.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 02:25:39 -0500

> Yes, you should pay more consideration and attention to other people's

I've tried really hard to do so.  The problem is that those people don't
give a damn about how many problems they are causing for others.
If apps break because of link locals, that's somebody else's problem.
Those apps will just have to adapt because we're going to insist
that this feature be imposed on all networks - not because it's 
technically sound to do so, just because we think it's a good idea,
and because we're already shipping it in product.  Never mind that
there are less disruptive ways of solving the problem that this
group was chartered to solve - we've got our own agenda here.  If this 
causes operational problems for networks or security problems for 
hosts, again, that's not our problem.  Screw everyone else, and we 
know what's good for everyone anyway.  

Yes, I've considered this point of view, and I don't believe it deserves
a shred of respect.

> of IP addresses so IPv4 LL does add any special burden.

And screw everything for which it does add a special burden - including 
large numbers of apps that don't run on dysfunctional networks.

Keith

---

From: Vincent Lubet <[email-masked]>
Date: Sat, 7 Dec 2002 10:15:12 -0800

> and 1122 is not about applications.

Here is the section for RFC 1122:

    1.2.2  Robustness Principle

          At every layer of the protocols, there is a general rule whose
          application can lead to enormous benefits in robustness and
          interoperability [IP:1]:

                 "Be liberal in what you accept, and
                  conservative in what you send"

          Software should be written to deal with every conceivable
          error, no matter how unlikely; sooner or later a packet will
          come in with that particular combination of errors and
          attributes, and unless the software is prepared, chaos can
          ensue.  In general, it is best to assume that the network is
          filled with malevolent entities that will send in packets
          designed to have the worst possible effect.  This assumption
          will lead to suitable protective design, although the most
          serious problems in the Internet have been caused by
          unenvisaged mechanisms triggered by low-probability events;
          mere human malice would never have taken so devious a course!

          Adaptability to change must be designed into all levels of
          Internet host software.  As a simple example, consider a
          protocol specification that contains an enumeration of values
          for a particular header field -- e.g., a type field, a port
          number, or an error code; this enumeration must be assumed to
          be incomplete.  Thus, if a protocol specification defines four
          possible error codes, the software must not break when a fifth
          code shows up.  An undefined code might be logged (see below),
          but it must not cause a failure.

          The second part of the principle is almost as important:
          software on other hosts may contain deficiencies that make it
          unwise to exploit legal but obscure protocol features.  It is
          unwise to stray far from the obvious and simple, lest untoward
          effects result elsewhere.  A corollary of this is "watch out
          for misbehaving hosts"; host software should be prepared, not
          just to survive other misbehaving hosts, but also to cooperate
          to limit the amount of disruption such hosts can cause to the
          shared communication facility.

---

From: Keith Moore <[email-masked]>
Date: Sat, 07 Dec 2002 13:45:21 -0500

> Here is the section for RFC 1122:

Maybe this group should apply the robustness principle to its own
output, rather than insisting that existing applications change to
accomodate zeroconf.  A reasonable interpretion of "be conservative
in what you send" would be "don't use IPv4 link local addresses
except when you are sure they will not cause problems."

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 07 Dec 2002 15:47:30 -0500

> except when you are sure they will not cause problems."

Ah...so now the WG needs to predict every possible action of every possible
packet before sending this packet. That should lead to really good
throughput and usablility.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM