Re: [v4v6interim] [BEHAVE] [46translation] Proposal for new BEHAVE charter

On Thursday 23 October 2008 19:06:52 ext Cullen Jennings, you wrote:
> If the mapping was purely and 1:1 mapping between internal and
> external IPs I would agree with you but unfortunately, I worry that
> meeting the requirement that drive section 4.4 of 4864 (privacy and
> topology hiding) really complicate trying to do it with 1:1 mapping at
> IP level.
>
> If you want to be able hide that two uncorrelated sessions are
> actually coming from the same internal host, well, I'm not sure I see
> how to do this with 1:1 mappings. One might argue that one should
> ignore these requirements but this is one of key areas where some
> people feel that 4864 has limitations that drive the deployment of
> NAT66. Two solutions I have seen for this are
> a) different external IP for every internal flow

This is unlikely to be deployed. It breaks to many applications that work fine 
with NATs (e.g. many web apps tie their "session" to the client IP address).

> b) doing port address translation similar to 
> NAPT in NAT44. Either of these choices has some pretty substantial
> impacts on how to make applications like VoIP work.

I don't think there's a strong requirement to hide correlation (or rather, 
lack thereof) between VoIP sessions - human user being the bottleneck in how 
many VoIP sessions a system can have.

But most importantly, I doubt that people who are this paranoid about topology 
hiding would tolerate using STUN, or any other server-reflexive address 
learning for that matter. But hey, you must know the SIP privacy work better 
than I do :) IIRC, it's proxy-based (TURN).

Therefore I am not convinced that 1:1 mapping would be a problem.
However, and to answer Alain's point, yes, some vendors will ship NAT66 boxes 
that work exactly like NAT44. But these will be no more BEHAVE-compliant than 
the NAT44 boxes. So it's kind of a non-issue from a standardization 
perspective - I tend to think that there is no problem if there is no 
solution.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim