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

[Fred Baker <[e-mail]>]

Very much agree.

On Oct 24, 2008, at 12:58 AM, Alain Durand wrote:

> I'm going to jump into this and probably not make friends...
>
> IPv6 is just like IPv4 with longer addresses. This is where deployment
> reality trumps architectural purity.
>
> What I've seen in the last 3 years is that it is much, much easier  
> to deploy
> IPv6 if you keep the exact same operational model as in IPv4. This  
> is one
> (among many) reason why we pushed for DHCPv6.
>
> Many folks are considering NAT44 as a simple solution where they  
> just have
> to put a box in front of their network to make whatever problem they  
> think
> they have go away. I can easily see that the same people would like  
> to do
> the same thing with IPv6. Which exact problem they were solving is
> irrelevant to this discussion, the point is about preserving the same
> operational model.
>
> That, and Cullen Jennings point #2 argue for defining NAT66 exactly  
> the same
> way as NAT44, ie with (optional) port translation. We have the  
> opportunity
> to explain why some choices are less worse than others in doing so  
> and put
> all the caveats in place. That is, make sure all the behave work  
> done for
> NAT44 is immediately integrated in NAT66, or in  other words, lets  
> define
> NAT66 in behave. Now, we may argue about the urgency of doing  
> this... Ie
> should this be done in parallel as NAT64 & NAT46 or after.
>
>   - Alain.
>
>
> On 10/23/08 12:06 PM, "Cullen Jennings" <[e-mail]> wrote:
>
>>
>>
>> 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
>
> _______________________________________________
> v4v6interim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v4v6interim

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