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

[Cullen Jennings <[e-mail]>]

On Oct 23, 2008, at 9:47 AM, Mark Townsley wrote:

>
>
> Cullen Jennings wrote:
>>
>> I'm not worked up one way or the other about if we should specify  
>> NAT66 or not - however, if we do specify it, I am very concerned  
>> about how we do that. I see one good reason not to specify NAT66  
>> and two good reasons to.
>
> Since saying nothing and hoping folks will abstain doesn't work very  
> well in practice, I'd rather we go in and describe safe NAT66 the  
> best we can. I agree that we have to be careful to do a good job, as  
> teaching bad NAT66 could be worse than not teaching it at all.
>
>>
>> Reasons not to do NAT 66:
>> 1) All the reasons explained in RFC 4864
>>
>> Reason to do it:
>> 1) Limitations of RFC 4864 as explained in 4864
>> 2) Large vendors are building nat66 today and they are doing it in  
>> a way that breaks applications and leaves the application designers  
>> with no idea about what they can count on working and what they  
>> can't count on.
>>
>> If #2 does not remind you of how we got into so much trouble nat44,  
>> well it should. Because of the impact on NAT66 on applications, if  
>> IETF does decide to do NAT66 specifications, I think it is very  
>> important that the specification is developed not only in the  
>> context of v6ops people but is also developed with input of folks  
>> from applications that need to use it. Today that would roughly  
>> mean behave.
> I think that something that operates only at the IP layer could stay  
> in the int-area.

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 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.





_______________________________________________
v4v6interim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v4v6interim