Re: An idea: GxSE

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

Going back a bit...

On Wed, 20 Jun 2001, Paul Francis wrote:

> But yes, the requirement here is that the renumbering event be transparent
> to end hosts (and also to internal routers).  I think this is important for
> the same reasons that O'Dell expresses in GSE.  I think that sites will not
> want to renumber, and will look for cheaper alternatives, of which there are
> two:

> 1.  Convince the ISPs to advertise its prefix across the default-free
> routing zone (i.e., what we do today with IPv4)
> 2.  Use NAT (also what we do with IPv4 today).

Renumbering is a pain, but running BGP or NAT is too. I'm not convinced
people are as desperate to avoid renumbering as you say. And this is in IPv4.
In IPv6 it somewhat unlikely that workstations that do not run any services
will be configured manually, and both prefix advertising and DHCP can handle
renumbering without too much of a hassle.

The only systems that are hard to renumber are those that others frequently
connect to. Since you wouldn't want your web server to magically get a new IP
address and become unreachable when it gets a new MAC address or someone else
uses the same MAC address these are configured manually. But how many web
servers do most organizations run?

> The goal of GxSE is to provide a solution that is about as easy as NAT, but
> provides better functionality (mainly, connections survive in the face of
> the site border routing crashing).

Ok, but why try to do both at the same time?

There are quite a few things we can do to improve NAT:

- make it stateless so there is no longer a single point of failure and
  scalability is improved
- add a "NAT control protocol" so applications can instruct the NAT box to
  enable/disable certain features and find out what their "real" address is

There is one thing that NAT has going for it that will kind of break in GxSE:
the hosts don't need to do or know anything special. But both the host and
the router have to support GxSE. Obviously, when every host runs GxSE this is
no longer a problem, but this is not something that is going to happen any
time soon.

And the same thing goes for using multiple addresses concurrently: if we can
implement this without requiring cooperation from the router, it becomes much
more usable. Many organizations have their routers supplied by a service
provider and are not in the position to update the software or even change
the configuration. If they can get a second router from a second ISP and the
hosts can use both connections at the same time and use each as a fallback
for the other, this would be a very good thing.

I've looked at the SCTP RFC some people mentioned, but this is a completely
new transport protocol. I don't think this is the way to go: this
functionality should be added to TCP or to IP.

A good all-purpose solution would be to implement a protocol in IP that
monitors connections (yes, even UDP "connections") and negotiates fallback IP
addresses with the other host when it detects that the connections stay up
for more than a certain time. (It makes no sense to do this for short DNS or
HTTP transactions: these benefit more from trying the different addresses
for a hostname and caching the unreachability information.) Then if an ICMP
unreachable message comes in the destination address for every connection is
changed to one of the fallback addresses.

The protocol for negotiating more addresses could be fairly simple: the
receiving system sends a challenge with a simple one time identifier and the
sending system responds to the challenge by returning the identifier and the
addresses to be used along with an indication of which is preferred. More
complex authentication schemes can be implemented as options.

Of course there should be an API so applications can see and control which
addresses are used.

The next stage would be to adapt TCP to use multiple addresses at the same
time. This way it is possible to optimize for delay, packet loss or bandwidth
or to use the full bandwidth of the combined connections.

A "source addresses a:b:c::/d are now unreachable" broadcast from the routers
might also help but is not really necessary.

Iljitsch van Beijnum