Subject: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12

From: Erik Guttman <[email-masked]>
Date: Mon, 5 May 2003 11:07:29 +0200 (MEST)

It seems my consensus call was flawed.  After reading recent comments, I
believe the right thing to do would be to accept LL21 as Robert Elz
suggested.  I believe that we should add the following advice to
implementors:

  ''A sensible default for applications which are sending from a
    link-local address is to explicitely set the IP TTL to 1.  This
    is not appropriate in all cases as some applications may require
    that the IP TTL be set to other values.''

Please send comments by May 12.  If there is no further discussion on
this topic, LL21 will be accepted and LL29 rejected.

Erik

---

From: John Schnizlein <[email-masked]>
Date: Tue, 06 May 2003 11:16:27 -0400

Please explain the reasons for your reversal.
Statements like "was flawed" and "reading recent comments",
which were apparently after the previous discussion deadline,
do not seem adequate to reverse the formal process of the WG.

---

From: Aidan Williams <[email-masked]>
Date: Wed, 07 May 2003 16:06:44 +1000

> do not seem adequate to reverse the formal process of the WG.

I was surprised at the result of the consensus call, however
Erik did say that he thought the consensus was rather rough.

Since I agree with Christian's comment that there won't be any
consensus on a specific value for the TTL, I support Erik opening
up the discussion on LL21 again.

Given that there doesn't seem to be any knock-down argument for
TTL=1 vs TTL=255 vs TTL=anything_in_particular, and that we
aren't going to be able to agree on a specific value, I think
we're better off with a spec that documents the issues and
leaves it up to the implementer.

Hence, I continue to support LL21.

- aidan

---

From: Erik Guttman <[email-masked]>
Date: Fri, 9 May 2003 11:05:22 +0200 (CEST)

> >this topic, LL21 will be accepted and LL29 rejected.

John,

You are right, more context and specific information is required to
discuss this point.  Sorry I did not included it in the initial note.

The consensus call was extremely rough.  

  [LL3] Stuart Cheshire and some others are concerned to remain
        consistent with the earlier decision of WG.  This serves Apple
        customers and those who implemented the protocol based on an 
        earlier i-d.

        However:

        Many pointed out that checking the TTL of incoming datagrams &
        deciding whether to discard the packet on the basis of that
        would not interoperate with existing implementations.

        Christian Huitema pointed out that IP TTL is exposed to apps
        and under their control.  Different apps set IP TTL for their
        own purposes and we cannot disallow or overrule that.

        Ralph Droms argued that IP TTL is well defined already and
        we have no business redefining it here.

 [LL29] (as accepted) stated:

     Any host sending an IPv4 packet with a source and/or destination
     address in the 169.254/16 prefix SHOULD set the TTL in the IP
     header to 1 by default. This includes multicast and broadcast
     packets with a source address in the 169.254/16 prefix.  An
     application may set the TTL to any value, using established
     interfaces for this purpose, overriding the default.

     This suggested behavior enables the normal behavior of Internet
     routers to preclude leaking traffic that is supposed to be
     confined to a single link out into the Internet when the local
     link has an attachment to the Internet that it did not discover.
     Setting TTL to 1 precludes mistaken forwarding of link-local
     traffic even when proxy-ARP is used on a link.

Concerns which have been related to me:

  - To the extent that we are trying to preserve backwards compatibility
    we do not serve this by recommending ttl=1.  None of the existing
    implementations use this setting. (Bernard Aboba)

  - The whole point of this standard is to provide a standard which
    expresses what has been done by vendors and to give advice for how
    to make this interoperation as safe and non-disruptive to networks
    and higher level applications as possible.  We should not extend
    well beyond the current well understood practice except as advice
    unless absolutely necessary. (Christian Huitema)

 [LL21] Aidan Williams and Robert Elz argued persuasively that we do not
        have consensus on this point.

This conclusion, together with the cited 'advice' seems to be the best
we can do.  Please provide your input so we can close these issues for
good.

Best regards,

Erik

---

From: John Schnizlein <[email-masked]>
Date: Fri, 09 May 2003 07:47:38 -0400

Thanks, the context helps us focus on the important issues.

The compatibility the WG should seek for a standards-track 
specification should be with Internet standards, such as the 
existing meaning of TTL, rather than installed base of a 
proprietary (pre-standards draft) implementation.
LL3  redefines TTL, and has reported interoperability problems,
     but maintains compatibility with deployed Rendezvous.
LL21 advocates that we ignore this problem and say nothing.
LL29 includes accommodation for applications to interoperate
     with the proprietary implementation as a technical compromise.

The way to publish an RFC to support interoperation with an already
deployed implementation (even if it happens to re-interpret TTL)
is as Informational, not standards-track. Why not do that?

How does an argument that there is no consensus among three 
alternatives become an argument for selecting a particular one?
The "advice" seems to shift compliance with the existing meaning
of TTL from an official SHOULD to easily-ignored advice.

Especially when consensus is "rough", the right course is the one
that deviates least from existing standards rather than one that
sets a particular point of the standard aside in favor of a
particular novel implementation.

After the formal process has concluded with a rough consensus is
not a good time to argue for a different outcome. That practice
calls into question the entire process of limited-duration debate
on specific issues.

It is worth noting that the discussion of LLMNR (in DNS-EXT) has
recognized the incompatibility of redefining TTL and settled,
after some debate there, on TTL=1 for both unicast and multicast.
My impression is that this decision followed the rough consensus
in Zero-Conf; reversing the TTL position in Zero-Conf threatens
to keep this issue cycling for a long time.

John

At 05:05 AM 5/9/2003, Erik Guttman wrote:
>... more context and specific information is required to discuss 
>this point.  Sorry I did not included it in the initial note.
>
> [LL21] Aidan Williams and Robert Elz argued persuasively that we do 
>        not have consensus on this point.
>

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 9 May 2003 13:54:29 -0700

I prefer LL3, the modifications to not require TTL 255 checks. This is 
the least amount of change from the previous IPv4LL drafts. It's time 
to stop churning on the same issues and get this thing out.

If there can be no agreement, then I think LL21 is an acceptable 
alternative. I don't think any mention of the TTL should be made, 
including the recommended text below.

-josh

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 May 2003 17:08:39 +0700

Date:        Fri, 09 May 2003 07:47:38 -0400
    From:        John Schnizlein <[email-masked]>
    Message-ID:  <[email-masked]>

  | How does an argument that there is no consensus among three 
  | alternatives become an argument for selecting a particular one?

I don't think that's quite what was intended.   More along the lines of
"there's no consensus about which particular TTL should be specified,
so perhaps the best thing to do is to specify none".   The "particular
one" was just that - that is, I looked at the arguments for TTL=1
and TTL=255, and couldn't see any reason to prefer one over the other,
so I suggested just not specifying either.

The way this group is attempting to make actual progress is by making
every suggestion become an "issue" - so to allow for the possibility
of specifying nothing, that had to be one of the issues.  Even though
the TTL=255 case is an issue with a higher number, the 1 vs 255
choice had been around for a long time, and was going nowhere.

LL21 is just what you get when you reject both LL3 and LL29 for lack
of consensus for either of those, it is kind of the default case,
not something new of itself.

  | Especially when consensus is "rough", the right course is the one
  | that deviates least from existing standards

There is no existing "standard" - there are two (maybe 3 now) existing
implementations, one of which used TTL=255 (and the other original one,
if I recall what I have read correctly, and I may not, so apologies if
this is wrong, picked 128).   That is, there isn't even an existing
common implementation.   This doc is intended to become the first
standard in this area.

  | It is worth noting that the discussion of LLMNR (in DNS-EXT) has
  | recognized the incompatibility of redefining TTL and settled,
  | after some debate there, on TTL=1 for both unicast and multicast.

That makes sense (multicast really wants TTL=1 for good reason,
unicast doesn't much care, but using the same value for both simplifies
things).

On the other hand, Rendezvous seems to want TTL=255, which is also fine.

  | My impression is that this decision followed the rough consensus
  | in Zero-Conf; reversing the TTL position in Zero-Conf threatens
  | to keep this issue cycling for a long time.

Are you sure it wasn't just that they no longer felt obliged by zeroconf
to use TTL=255 for the unicast case?

kre

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 10 May 2003 15:41:30 -0400

> choice had been around for a long time, and was going nowhere.

I say, Erik should write the number 1 on the heads side of a coin, and the
number 255 on the other. Flip the coin. Let it land on the ground. Whatever
number is not facing the ground is the TTL value. The only time there will
be a second flip is if the coin lands on edge.

This seems to be the only way that a number will ever be picked, and it's
about as valid as any other reason to pick one at this point, and it's for
sure a lot faster.

john

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