[e2e] NAT traversal for src+dst routing

[Xiaoming Fu]

Jon,

Binding/Address-mapping state instantiation (as well as maintenance and 
deletion) for NAT devices is being discussed in IETF NSIS WG (previously 
also in MIDCOM); 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-04.txt 
describes a soft-state based approach. Is this a way you'd expect?

Cheers,
Xiaoming

Jon Crowcroft wrote:
> 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.