Subject: Oppose: LL29 Link-local sources should specify TTL=1

From: Stuart Cheshire <[email-masked]>
Date: Mon, 3 Mar 2003 22:32:08 -0800

John Schnizlein wrote:

>Specifying that hosts must not send LL traffic to routers, which 
>appears to be the basis of the assumption that LL traffic does 
>not go to routers, makes them responsible for something they
>do not actually control. Since proxy-ARP gives the host a reply 
>that appears to be that of the ultimate host, but is a router,
>the originating host cannot enforce the requirement.

Sorry John, but this is a HUGE red herring.

Any router doing indiscriminate proxy-ARP for addresses of which it has 
no knowledge or authority is going to completely sabotage IPv4LL anyway.

For a start, the IPv4LL hosts will be unable to obtain any address 
because every ARP probe will be answered by the proxy-ARP router, giving 
the impression that every address is in use.

Even supposing that a host does manage to acquire an IPv4LL address, it 
will be unable to communicate reliably, because every time a peer host 
sends an ARP request, the indiscriminate proxy-ARP router will answer, 
thereby stealing the packets away so that they do not go to the right 
host.

If we were having this conversation five years ago, it might have
been argued that we could not risk shipping IPv4LL at all, because
of the potentially disastrous network meltdown it could cause.
(This reminds me of the NASA scientist who claimed -- rightly --
that there was a risk that the Apollo 11 fuel *might* react
with the moon rocks, thereby "setting the moon on fire". See
<http://spaceflight.nasa.gov/history/shuttle-mir/people/p-t-dye.htm>.)
As luck would have it, we didn't have this conversation five years ago,
we did ship IPv4LL, and the moon actually did not catch fire and explode.

Even if there were a scenario where IPv4LL hosts are tricked into sending 
their packets to a device that forwards them, it is unlikely to be a 
large volume of traffic -- typically just a few unanswered TCP SYNs. Note 
that since day one, Windows and Mac OS have sent packets with TTLs of 128 
and 255 respectively. If this leakage is already happening, are there any 
reliable figures reporting the scale of the problem? I suspect the volume 
of IPv4LL leakage is vanishingly insignificant compared to the other 
"elephants in the room" -- like PTR lookups for Net 10 addresses.

Even if there were a real problem, when we have five years of deployed 
hosts already using TTLs of 128 and 255, trying to change the TTL to 1 
for new hosts seems like slamming the door long after the horse has 
bolted.

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

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Mar 2003 14:39:38 +0700

Date:        Mon, 3 Mar 2003 22:32:08 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | Even if there were a real problem, when we have five years of deployed 
  | hosts already using TTLs of 128 and 255, trying to change the TTL to 1 
  | for new hosts seems like slamming the door long after the horse has 
  | bolted.

One can, of course, make the same statement about trying to force the
TTL to always be 255.   There is evidence out there (apparently) that
everything works OK using 128 (no great demonstrations of problems being
avoided by the hosts that use 255).   I can't think of a reason that
64, or 32, or 16, or 192 would be any different (as a general default for
the host for apps or protocols that don't specify otherwise).

Just allow the implementations to use whatever they like.

kre

---

From: "Partha, K V B" <[email-masked]>
Date: Tue, 4 Mar 2003 14:03:36 +0530

Link local source sending to a link local destination SHOULD specify TTL=1;
otherwise, leave it to implementations to specify their own TTLs. - Was this
option considered? Any drawbacks in this approach?

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Mar 2003 16:17:54 +0700

Date:        Tue, 4 Mar 2003 14:03:36 +0530
    From:        "Partha, K V B" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Link local source sending to a link local destination SHOULD specify TTL=1;
  | otherwise, leave it to implementations to specify their own TTLs. - Was this
  | option considered? Any drawbacks in this approach?

That option is issue LL21.   And no, no drawbacks (just two different sets
of imagined pseudo-benefits ignored).

kre

---

From: Erik Guttman <[email-masked]>
Date: Tue, 4 Mar 2003 10:57:00 +0100 (CET)

On Tue, 4 Mar 2003, Robert Elz wrote:
> Date: Tue, 04 Mar 2003 16:17:54 +0700
> From: Robert Elz <[email-masked]>
> To: "Partha, K V B" <[email-masked]>

Robert,

That is a misleading statement.  Here is my summary of the options
available at the moment.

          TTL on SEND              TTL on RECEIVE

LL3       MUST be 255              in the future, SHOULD discard if !255

LL21      Silent on TTL            Silent on TTL processing
          setting

LL21 +    MAY be 1 (unicast)       Silent on TTL processing
Robert*   MUST be 1 (multicast)
          otherwise, as per app.
          setting.

LL29      MUST be 1                Silent on TTL processing

LL29 +    SHOULD be 1 unless an    Silent on TTL processing      
Christian  app sets the TTL
**        Includes broadcast
          and multicast packets.

* = 
Date: Fri, 28 Feb 2003 17:49:09 +0700
Message-Id: <[email-masked]>

** = 
Date: Thu, 27 Feb 2003 12:00:50 -0800
Message-Id:
<[email-masked]
osoft.com>

Partha,

If you wish to suggest an alternative, please read the problem statement
at www.spybeam.org/ll3.html and subsequent discussion.  If you believe
that an additional alternative is useful, please state exactly what 
problems it solves that the others (given above) do not solve and post
this to the list.

Regards,

Erik

---

From: Robert Elz <[email-masked]>
Date: Tue, 04 Mar 2003 17:40:06 +0700

Date:        Tue, 4 Mar 2003 10:57:00 +0100 (CET)
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <Pine.SOL.3.96.1030304103219.29645F-100000@field>

  | That is a misleading statement.  Here is my summary of the options
  | available at the moment.

Oh yes, sorry, I misread the suggestion (treating it as two different
ones, split at the "otherwise" - because I didn't look at what came
before that closely enough).

  | LL21 +    MAY be 1 (unicast)       Silent on TTL processing
  | Robert*   MUST be 1 (multicast)
  |           otherwise, as per app.
  |           setting.

For what it is worth, even though I suggested that as a possibility,
I don't support adding it to this doc, LL21 as it exists on the web
page is what I'd prefer (ie: no occurrence of TTL at all in the doc,
with the possible exception of mention of current implementations that
actually check that TTL==255 on receive).

Just saying "MAY be 1" or "MAY be 255" or "MAY be any other value" is
meaningless, and doesn't help at all.  The MAY magic word is often overused,
its only real value is to point out a plausible reasonable exception
to a SHOULD or conditional MUST  (as in, "vehicles SHOULD be red, but MAY
be black if intended as hearses").

kre

---

From: Ralph Droms <[email-masked]>
Date: Tue, 04 Mar 2003 19:31:47 -0500

I support LL29.  Setting TTL to 255 and checking the TTL on receipt amounts 
to redefining the TTL field to be a "on this link" field for IP packets 
that have IPv4LL source and/or destination addresses.  This redefinition 
makes use of the behavior of existing routers but is not conveying the 
information intended in the original definition of the TTL 
field.  Redefining the TTL field in this way is beyond the scope of the 
zeroconf WG.

Requiring that the TTL be set to 1 is compliant with the definition and use 
of the TTL field in all other IP packets.

- Ralph