Re: An idea: GxSE

["Jon (Taz) Mischo" <taz@tazlore.com>]

Mohan, Paul-

Unless I'm really misunderstanding something here, I was under the
impression we're talking about fixed-site multihoming and address space
change renumbering - the bane of every large site's existence.  As such, I
think we're not talking about mobility.  We're talking about the v4
equivalent of a site moving from one /?? to another.  Or, the BGP
equivalent of changing your AS Path completely.  Possibly millions of
connections simultaneously moving.  In this case, you really don't want a
whole bunch of superfluous packets if you can avoid them.

Now, this also happens to address transparent multihoming in the failover
case, similar to how SCTP handles it, except instead of failing over to a
new address, the GR prefix only changes.  In plain terms, you're binding a
socket between the SK addresses only, the rest is smoke and mirrors.  
Routing changes wouldn't really have a large impact, since the border
routers are essentially rewriting the headers.  Think of it as NAT with a
1:1 translation combined with the equivalent of a set of BGP announcements
via several different AS's.  If one route goes down, the GR prefix would
change on one end of a connection, but the SK address would stay the same,
and you're connected between SK's.  BGP for hosts :)

Again, that's how I'm reading this, I could very well be FAR off-base
here.  I was thinking about this, though...this could tie into BGP where
you're announcing valid GR and SK prefix pairs.  This sort of comes closer
to the idea of landmark routing, where you basically are routing to a
point closer to the destination without knowing where the destination
really is, and then letting the landmark routers (the SSBR and DSBR) route
you as it sees fit to go the rest of the way.

In the event of a routing mishap, a specific GR/SK pair of an active
connection would become invalid, forcing a change of GR mapping at the
SSBR on the packet on the way out, transparent to the host.  Furthermore,
if a host was experiencing high packet loss, latency, or jitter, it might
ask the SSBR to try a different GR prefix.  It might be useful to allow
the announcement of GR prefixes to declare certain QoS properties, so a
host could request a GR that's designed for low latency or low jitter, for
example.  I digress, though.

Just my $.02 and my interpretation.  Always interested to know if I'm
being silly.

-Taz

On Wed, 20 Jun 2001, Mohan Parthasarathy wrote:

> Date: Wed, 20 Jun 2001 11:55:15 -0700 (PDT)
> From: Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>
> To: Paul Francis <paul@francis.com>
> Cc: multi6@ops.ietf.org
> Subject: Re: An idea: GxSE
> 
> Paul,
> 
> TCP endpoint being associated with multiple addresses was
> discussed in draft-nikander-mobileip-homelessv6-01.txt.
> Isn't renumbering equivalent to a mobile node moving to
> a new foreign link ? In that case why can't renumbering
> event trigger all the TCP connections to generate a
> new secure message (known as binding update in mobile IPv6)
> to tell its peer about the new address ? After sending
> this message, TCP connections start using the new address.
> Why wouldn't this work ? 
> 
> If we are looking for a solution that would not change
> the end host's implementation, then the above is not
> suitable. So, is the requirement that the
> renumbering event should be completely transparent to
> the end hosts ?
> 
> -mohan
> > 
> > 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
> > 
> > 
> > 
> 
> 

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989