An idea: GxSE

["Paul Francis" <yoid2000@home.com>]

I've been tossing around the following basic approach to the
multihoming/renumbering problem, and am wondering if folks think it is worth
pursuing.

Like GSE, the basic idea is to isolate site numbering from global numbering
by allowing site border routers to rewrite prefixes as packets pass in and
out of a site.  Unlike GSE, however, the ID is not the sole identifier of
the host.  The full address is still the identifier, but multiple (full)
addresses are used to identify the host.  A packet received with any of the
set of addresses identifies the host.  In this sense, the idea is like
SCTP's use of multiple addresses.

I call this approach GxSE, to convey the idea that like GSE the address has
global, site, and end-system address elements, but unlike GSE, addresses
with multiple globals are used to identify a host (thus the 'x' after the G
conveys a multiplier).

There are multiple ways one could design GxSE.  Here are the primary aspects
of what I have in mind:

Every host knows at least one (and typically only one) address for itself,
called the self-known address (SK address).  The SK address may or may not
be globally routable, but must be globally unique.

In addition to the SK address (from here on I talk as though there is only a
single SK address---it should be understood that there can be multiple of
them), there is a set of one or more globally routable addresses (GR
addresses) for every host.  The host does not need to know its GR addresses
(nor do site-internal routers).  All of the addresses (GR and SK) for a host
have the same "site" and "ID" parts, but different "global" parts (aka
"prefix").  An SK address may also be a GR address.  The (publicly
reachable) DNS entry for a host will typically contain all of the hosts' GR
addresses.

Each of the GR address prefixes of course represents that assigned by an
ISP.  There is a site border router attached to that ISP with that GR
prefix.  The site border router knows the SK prefixes for the site.  (All
hosts in a site do not necessarily have the same SK prefix, but if they
don't then the site border router must know the SK prefix for every host.)
The site border router knows all of the GR prefixes for the site, not just
its own.  (Again, all hosts in a site do not necessarily "have" the same GR
prefixes, but if they don't then the site border router must know the GR
prefixes for every host.  Clearly it is better if all hosts have the same SK
and GR prefixes, and this should be normal operation.)

For every "connection" (where a connection is defined as a distinct
address/protocol/port 5-tuple), the host keeps a list of (globally unique)
addresses of the destination (or partner) host.  It knows which of these is
the SK address, and whether theSK address is routable or not.  This full
list identifies the host (not just the SK address).  Two connections with
partner hosts with different lists, even if they use the same SK address,
are considered to be different hosts.

Packets transmitted by a host contain its SK address as the source address,
and one of the GR addresses of the partner host as the destination address.
Typically the destination address will be that of the most recently received
source address, but not necessarily.  When the packet passes through the
site border router, the router replaces the global prefix part of the SK
address with that of the ISP to which it will route the packet.

When a packet is received by a site border router incoming, the site border
router replaces the GR prefix with the SK prefix of the destination host,
and forwards the packet into the site.

The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6
extension header---the address-list extension.  This header is typically
added by the site border router as the packet exits the site.  (It could
also be added by the source host, but this would require the host to know
its GR addresses which is the thing GxSE is trying to avoid.  Nevertheless,
a site could choose to operate this way.)  The header is added typically
only for the first packet sent in either direction (with the return header
indicating whether the forward header was received).  A GxSE-aware host
would tell the site border router to add the address-list extension by
attaching a different extension header (the "please add the address-list
extension" extension, or address-list-trigger extension).  Both extension
headers are of the "if unknown, skip over this option and continue
processing the header" type.

The typical exchange would go like this:

SH-->SSBR: |IPv6 head|ALT ext head|transport|
SSBR->DH:  |IPv6 head|ALT ext head|AL ext head|transport|
DH->DSBR:  |IPv6 head|ALT ext head (acks first ALT)|transport|
DSBR->SH:  |IPv6 head|ALT ext head|AL ext head|transport|
SH->DH:    |IPv6 head|transport|
DH->SH:    |IPv6 head|transport|

(where SH=source host, SSBR=source site border router, DH and DSBR are same
for destination, ALT=address-list-trigger, AL=address-list)


This is the basic idea.  Lots of unworked details....

For API, I imagine that the full list of addresses (GR+SK) gets handed up to
the upper layer, if it cares to know.

Pseudo-header checksums and IPsec would I suppose be based on the SK address
only (not the GR addresses).

Not sure how to deal with IPsec regarding the extension headers---due to
inadequate understanding of this stuff.

The extension header "handshake" needs to be worked through...might need to
be 3-way etc.

There are some destination address selection issues, to deal with the fact
that SK addresses work within a site but not necessarily outside the site.
Two hosts in the same site would want to use the SK address, not a GR
address, when talking to each other.  One approach is two-faced DNS.
Another might be to go ahead and have DNS return the GR addresses, but after
the address-list extension headers are exchanged, the hosts would recognize
that they share the same SK prefix and could start using that (and
subsequently bypassing the site border router).  Note that IPv6 with
site-local prefixes has the same sorts of issues.

As for transition, site border routers need to know which hosts are GxSE
aware and which aren't.  For those that aren't the baseline behaviour would
be for site border routers would agree to all use the same GR prefix on
outgoing packets for each host.  Obviously if the site border router with
that GR crashes, then communications breaks, but this is no different from
today's situation.  The site border routers could potentially also try to
proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the
partner host is GxSE aware).  In this case, the site border router would
need to keep enough state to know to attach the address-list extension on
the initial packet only. (An address-list extension minus the
address-list-trigger extension would convey to the destination host that the
source host is non-GxSE aware, but the site border router is.)

As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they
largely don't apply because GxSE uses fully overloaded addresses, just more
of them.  For instance, there is no ID-to-address mapping issue because the
ID is never used alone as the identifier.  A host cannot pretend to be
another host, in essence because the full set of addresses is what
"identifies" a host, not a single address (and certainly not an ID alone).
So, for instance, if a rogue host tries to pass itself off as having another
host's SK address but its own GR address, it won't matter because the
"identity" of the rogue host would be considered to be the whole list of
addresses, and so wouldn't be confused with the "true" host (with the same
SK address but the correct GR address).

Note that GSxE doesn't prevent renumbering altogether---it would still be
required when two sites merge.  But renumbering would not be necessary
because of changing providers.

Comments?

PF