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

[Mark Townsley <[e-mail]>]

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.

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