Subject: RE: TTL=255 on xmit, no check on receipt please

From: "Christian Huitema" <[email-masked]>
Date: Thu, 26 Dec 2002 16:41:50 -0800

> > One has to weigh the potential benefits (including security, if any)
> > when deciding whether the benefits of a TTL=255 check are high
enough
> > to out weight the negatives (like reduced interoperability).
> 
> While there are very few true security benefits, the ability to easily
> discard routed LL packets is an operational benefit that should be
> implemented. The interoperability issues with non 255 packets can be
fixed
> via update mechanisms easily enough.

I don't think so. I really believe that all this is a trade off. If what
you want is a properly architected link local "zeroconf" service, then
you should use IPv6. If you insist on IPv4, it must be for compatibility
with existing implementations etc. That means that the zeroconf IPv4
should be designed to maximize interoperability with existing IPv4
service that were not necessarily zeroconf aware. 

If you consider interoperability, the TTL 255 requirement for IPv4
addresses is not very productive. There is a wide body of deployed
implementations that use the auto-configured IPv4 address and set the
initial TTL to a value other than 255, which means that implementations
will not in practice require a check to the value 255 for a very long
time. So you will be left with a "set 255, don't check" implementation,
which means that you won't get any protection, and also means that if
your packet is somehow swallowed by a mis-configured router, it will
travel all the way to the Internet core.

On the other hand, if you set TTL=1, you will actually be able to
interoperate with existing IPv4 implementations, and also to be robust
in the presence of non-zeroconf aware router. You will not have a
guarantee that you will never receive a UDP packet, but TCP's 3-ways
handshake will effectively guarantee that you never set a connection
with an off-link node. That seems like a much better engineering
trade-off.

And you should use IPv6 anyhow.

-- Christian Huitema

---

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

> with an off-link node. That seems like a much better engineering

There is no guarantee that that TTL = 1 packet didn't come through 200 other
routers. The 255 doesn't guarantee that either, but it has a much higher
probability of correct behavior.

> And you should use IPv6 anyhow.

Yes, but we can't wait 7 years for this to be ubiquitous enough...some of
use need to get work done *now* as well.

john

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Dec 2002 14:38:27 -0500

> If you insist on IPv4, it must be for compatibility

Having compatibility with non-zeroconf-aware hosts is of little value if 
the applications on those hosts aren't zeroconf aware.  And the set of 
applications that can run transparently with link local addresses is 
relatively small.

However I agree that it would be better to use IPv6, because IPv4 
is becoming obsolete.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 27 Dec 2002 17:47:19 -0500

> However I agree that it would be better to use IPv6, because IPv4

Why yes, in only 5-7 years, it will be a dominantly IPv6 world, and in ten
or so, IPv4 will be almost entirely gone. Why couldn't I see before, We
should all just sit on our hands and wait for IPv6 to make it all better.
All you IPv4 people, stop coding now! IPv6 is coming.

There, now that we've gotten that out of our system, can we please get on
with the task at hand? Yes, IPv6 will fix many of the problems with
networking, but it isn't the panacea that some would like us to believe it
is. It is not in wide spread implementation yet, and there will, not may,
but will be bugs in it that will need to be dealt with. That is unless
someone has gotten that pragma invoke deity option to work.

Stopping all efforts to make IPv4 work better because <magical wonderful
future thing> is coming is just silly.

john

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