Transportzilla backwards

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 5 Nov 2002, Iljitsch van Beijnum wrote:

> On Tue, 5 Nov 2002, Iljitsch van Beijnum wrote:

I must say I like this replying to myself thing! Much less confusion.

> On the other hand, the locator could belong to some intermediate box.
> This could be a box that is responsible for server load balancing or
> traffic engineering, or it could be a mobility home agent (one of
> several). The intermediate box would then negotiate replacement locators
> and after that the rest of the session establishment procedure can be
> executed.

Originally, I thought backward compatibility with TCP would be
problematic. However, I think it can be done in a way that isn't (too)
harmful, and backward compatibility is of course a very useful thing to
have.

The basic idea is that session establishment needs a lot of extra stuff.
However, the actual data transfer doesn't have to look different from
TCP. It can even be compatible with TCP if suitable 4 or 16 byte
identifiers are used rather than the real one (the host name). So if a
transportzilla-implementation wants to talk to a regular IPv6 or IPv4
TCP implementation, the only thing that's needed is a box or wedge that
handles the locator and options negotation. One of the options that are
negotiated would then be IPv6 or IPv4 compatible session identifiers. If
both hosts are in the possesion of the right type of address, this will
obviously used, but if they aren't, anything that looks like such an
address can be used as long as there are no clashes with other sessions.
(For instance, host A could assign host B an address from 10.0.0.0/8 and
host B host A another one.

When the session is established, the extra box or wedge simply swaps
around the identifiers/locators and the TCP protocol number vs the
transportzilla one and the old TCP implementation will never know the
difference. The packet format (including the way the checksum is
calculated) would have to match regular TCP. This also makes
implementing transportzilla extremely easy as all the hard stuff such as
congestion control can simply be reused from TCP.

When running transportzilla over the old IPv4/IPv6 APIs it makes no
sense to do all of the above. Rather, the IPv6 or IPv4 address is turned
into a hostname (could be in-addr.arpa or ip6.int or something else) and
this address is used as the TCPv6/v4 compatible identifier.

I'll have to do some more brooding about how to work UDP based stuff
into all of this but the idea should be pretty much like TCP: have a new
session establishment paradigm but keep actual data packets the same if
possible.