Re: [BEHAVE] Scalability of endpoint independent mapping

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch@gmail.com] 
> Sent: Wednesday, May 14, 2008 1:51 AM
> To: Dan Wing; Philip Matthews
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] Scalability of endpoint independent mapping
> 
> On 13 mei 2008, at 21:41, Dan Wing wrote:
> 
> >> Unless I'm missing something this should actually be fairly
> >> straightforward: just STUN for TCP + endpoint independent mapping.
> 
> > STUN for TCP exists (draft-ietf-behave-rfc3489bis now specifies how
> > STUN-over-TCP works).
> 
> Excellent.
> 
> > Of course with NAT64 we could specify exactly how a NAT64 
> is supposed
> > to work and maybe bypass much of the problem that STUNT found with
> > existing NATs.
> 
> Right. The good thing here is that we're not constrained by hundreds  
> of existing implementations that all behave differently. And 
> existing  
> CPEs can't work on the v6 side of a NAT64 universe anyway, so those  
> aren't an issue at all.
> 
> I was thinking:
> 
> If an application wants to make use of endpoint independent mapping  
> behavior by the NAT, wouldn't its first packets be towards a STUN(T)  
> server? If we can detect this, providing endpoint independent 
> behavior  
> where it's needed and using endpoint dependent mappings everywhere  
> else is easy.

Someone else (Rémi Després, I believe) had proposed doing that using
port numbers.  Doing it with port numbers would also be the first time 
that TCP behavior is different for different port numbers (the port 
1024 restriction does not change the behavior of TCP itself).  But
I see (below) that you are considering DPI rather than TCP port
numbers.

Another idea floating in my head is to use STUN-over-TCP to the 
NAT64's public IP address itself, which is trivial for the NAT64
to notice.  Essentially that is what is described in 
<http://tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-05>,
which is an expired draft.

> For TCP, another option would be a TCP option in the SYN from 
> the host to the STUNT server, or in the SYN/ACK from the STUNT 
> server back to the host, this is probably easier to do than deep 
> packet inspection to determine whether a random TCP session is 
> used for STUNT.

If the NAT64-aware box at the customer premise could make the decision
(somehow; I'm not sure how it could do that yet), the NAT64-aware box
could communicate the decision to the ISP's big NAT64-box-in-the-sky
using a simple-to-see trigger like that.

Unfortunately the application and host OS (Windows, OSX) couldn't set 
that TCP bit without changes to the TCP API and the TCP stack itself 
- which means an OS upgrade or, at minimum (if the vendors are 
motivated) an OS patch.

-d

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave