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

[Cullen Jennings <[e-mail]>]

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.

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.

Cullen



On Oct 23, 2008, at 8:50 AM, Mark Townsley wrote:

> Magnus Westerlund wrote:
>> Anyway,
>>
>> Are anyone that thinks that NAT66 is so important that it takes
>> precedence over the NAT46 translator work? If not, can we postpone  
>> this
>> until we are ready to publish something on address family  
>> translators?
>>
>> The reason I ask the above is that we will have enough work for all  
>> the
>> people in the translator work. Thus trying to avoid splitting the  
>> forces
>> to thinly.
>>
> The NAT66 should be relatively straightforward, and could actually  
> help highlight some of the reasons why 46 and 64 become problematic.  
> NAT66 is a question that comes up again and again when talking about  
> deploying IPv6, and I honestly think it would be useful to have a  
> document to point to that brought light to and articulated some of  
> the issues, gave strong warning where necessary, and described what  
> was relatively safe and what not.
>
> It doesn't really have to be part of behave though.  Magnus, I fully  
> understand if you are looking at this new behave charter and can't  
> imagine another thing on your plate. As Margaret and others  
> mentioned, this can go through int-area, 6man, or some such.
>
> - Mark
>> Magnus
>>
>> Iljitsch van Beijnum skrev:
>>
>>> On 21 okt 2008, at 11:50, Fred Baker wrote:
>>>
>>>
>>>> As to the rest of what you said, I'll agree with you that in a very
>>>> real sense that ship has sailed, and I'll point out that we run the
>>>> same protocols on IPv6 that we run on IPv4. If we have indeed  
>>>> made the
>>>> protocols NAT-accepting for IPv4, I'll bet they are NAT-accepting  
>>>> on
>>>> IPv6 as well.
>>>>
>>> If only things were this simple.
>>>
>>> Many apps that break with NAT do referrals by IP address. So they  
>>> must
>>> be updated to work with IPv6, and gain significant additional  
>>> logic to
>>> work in a dual stack world. Things like STUN and ICE and their
>>> proprietary counterparts thus need to be reinvented/implemented  
>>> for v6
>>> to make referrals work, and/or the UPnP/NAT-PMP protocols that  
>>> open up
>>> ports in NAT devices must be recreated for IPv6 if port overloading
>>> NAT66s happen.
>>>
>>> Today the routing people are complaining that the IPv6 builders  
>>> didn't
>>> fix routing. I wonder if in 10 years the apps people are going to
>>> complain that we didn't fix NAT but just let the same thing happen  
>>> as in
>>> IPv4 which BEHAVE has been trying to clean up.
>>> _______________________________________________
>>> Behave mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> v4v6interim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v4v6interim

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