Subject: Re: middleboxes and Re: [tcpm] TCPx2

From: Mark Allman <[email-masked]>
Date: Thu, 11 May 2006 13:48:14 -0400

> [email-masked] wrote:
> >> To me the critical issue is maintaining critical compatability and
> >> interoperability. If you are going to lose those, then it is no
> >> longer a minor modification. Further, it won't matter how useful it
> >> is, it won't get deployed anytime soon. And I don't think that
> >> calling it "TCPx2" or whatever will make it get required support
> >> anytime sooner. 
> > 
> > I read the above as indicating that you do not believe that
> > TCPx2 "maintains critical compatibility and
> > interoperability".  Is that a correct interpretation?  If so,
> > I'd like to hear the logic behind the statement, because from
> > my seat compatibility and interoperability are maintained
> > with the fallback to RFC793 TCP sketched in the i-d.  (The
> > clear case when that would break is when a stack supported
> > TCPx2 and not TCPx1.  But, since *it's (basically) the same
> > protocol* it would seem stupid to go to x2 and not continue
> > to grok x1.)
> > 
> 
> If fallback is required it adds either to the latency of the
> connection setup or places additional packets on the wire.

Absolutely, no question.  Latency and network traffic don't add up to
"critical compatibility and interoperability" issues.  *That* is my
point.

allman

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 May 2006 10:58:47 -0700

Mark Allman wrote:
...
> "critical compatibility and interoperability" issues.  *That* is my

Er, isn't that why nobody is using IPv6 right now? The lack of a
fallback that doesn't require dual-stack with parallel tests?

That seems like _the_ critical interoperability issue that will affect
deployment - as it already has.

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 11 May 2006 14:06:38 -0400

> deployment - as it already has.

You're beyond my reading level again.  I can't parse this at all.

allman

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 11 May 2006 10:31:10 -0700

What I was suggesting was a packet that would pass through 
"TCPx1"-only network elements unmolested but uninterpreted.
Then we only have to deal with the question of whether the
two endpoints understand the upgrade option.

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 May 2006 12:00:12 -0700

> You're beyond my reading level again.  I can't parse this at all.

Sorry - I need that second cup of coffee.

In full sentences:

IMO, "critical compatibility and interoperability" are defeated by
dual-stack. That's what has killed IPv6 - even those of us who want to
transition are hit by the dual-stack problem. Once I enable IPv6, my
apps need to try both versions in parallel to work; since they don't,
things silently fail when IPv6 isn't available.

I.e., simple, default backward compatibility is exactly what is needed
to get something out there right now. We tried dual-stack as a solution,
and IMO it ended up killing deployment. We don't need to try it again.

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 11 May 2006 15:07:56 -0400

> Sorry - I need that second cup of coffee.

Heh.

> to get something out there right now. We tried dual-stack as a
> solution, and IMO it ended up killing deployment. We don't need to try
> it again.

This is not as dual-stack as IP.  It's the same protocol.  Why even
bother to get the apps involved in TCPx1 vs. TCPx2 unless they want to
be inserted for whatever reason and do something explicit?  The service
provided to the app is the same.

allman

---

From: Ethan Blanton <[email-masked]>
Date: Thu, 11 May 2006 17:17:53 -0400

> fallback that doesn't require dual-stack with parallel tests?

Well, that and the fact that nobody else has an IPv6 address, either.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Tim Shepard <[email-masked]>
Date: Thu, 11 May 2006 18:02:27 -0400

> Well, that and the fact that nobody else has an IPv6 address, either.

Anyone who has a single globally routable IPv4 address has 2^80 IPv6 addresses.

Read rfc3056.txt and rfc3068.txt and be enlightened. 

Someone pointed those out rfc3068 to me when I was at the IETF in
Yokohama (4 years ago).  I already mostly understood rfc3056.txt.

Soon after I got home from that IETF I used this new found
enlightenment to get myself IPv6 service at home without the
cooperation of my ISP.  I typed a few lines on my Debian/Linux
machine and then had a look at http://www.kame.net/ in my web
browser and the turtle was dancing.

I then added an IPv6 address for a small web server I have running
at home to the DNS entry for it (maintained by zoneedit.com) and
that has been working fine ever since (over 3.5 years).

What's nice about this is it neatly solves the "My ISP will only
give me one routable address, but I have multiple machines on my LAN
at home that I want to be able to open ssh connections to."-problem.

I've also noticed that outside the US, people seem to be much more
aware of the reality of IPv6.

I would agree that in the US there's not yet any pressing need to
go IPv6 live.  But given how easy it is to do, if the slightest
need to be IPv6 live should surface, we could find that IPv6 is
turned on most everywhere almost overnight.

IPv4 is so 20th century.

			-Tim Shepard
			 [email-masked]

---

From: Ethan Blanton <[email-masked]>
Date: Thu, 11 May 2006 18:15:51 -0400

> Read rfc3056.txt and rfc3068.txt and be enlightened. 

I have read them, I have 6to4 addresses and have had them for some
years (and a dedicated tunnel before that).  That makes me one of the
few.  Now I can unreliably communicate with those few others via
tunnels through God-knows-where with horrible latency and loss ratio
compared to direct IPv4 connection, and with a much greater chance of
something systematically eating my packets along the way.  I can also
look forward to connections failing due to sites advertising IPv6
addresses which they toyed with at some point when they thought IPv6
might be going somewhere, and have subsequently abandoned.  Add to
this a half dozen other pitfalls, and...

But I suppose this is off-topic, aside from underscoring the
unfortunate difficulty of rolling out any sort of new protocol into
the entrenched Internet.

Ethan