[e2e] NAT traversal for src+dst routing

[Jon Crowcroft]

File this under
Truly Horrible Idea/Concept/Kludge (T.H.I.C.K.)

reading some stuff recently about how MPLS can be used to do various
traffic engineering hacks that "cannot" be done  with normal IP
forwarding as it would need source+destination, which we "know" doesnt
scale (if there's an algorithm for labels, i dont quite see why an
algorithm for fast longest prefix packet classification doesnt just
double in time/space for src+dst given both are in the FIB anyhow, but 
hey...)

so i was also reading about various cute NAT traversal hacks (many
aimed at allowing incoming SIP signaling for end-customer VOIP calls
etc....

so one can combine these - if a provider has a set of destination 
prefixes that are used to share out load over various paths, then one 
can achieve src+dst routing by looking at the _source_ of the call at the
application layer hack that triggers the nat traversal, and put in a
NAT globally reachable address on the public  side from the
appropriate _destination_ prefix in - then the src is irrelevant - but
different sources or potentially the same source with different calls
are going to different "destinations" 

i.e. a NAT is a label switch - it operates in a nice part of the
architecture where we (the end users, not the router and swithc
vendors) can still play...

the statefulness of the NAT is no different (in terms of being yucky)
from the statefulness of forwarding equivalence classes - there are
several _different_ ways one might implement the state instantiation
(but all are just slight enhancements to NAT traversal stuff)

the really neat thing is that this works _inter-domain_ (albeit
potentially making the multi-homing pressure on BGP and use of all the
BGP wunderkind hacks of path prepending and MEDs and whatever even
more stressful...:-)

In fact, if implemented AT the border, we might call this
Border Address Translation

even better than getting fingerprinted

j.