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

[Margaret Wasserman <[e-mail]>]

I'm getting mixed messages here, but I have a proposal...

Perhaps I could finish the NAT66 draft I've already started, and  
submit it before the -00 cut-off (on Monday).

I think we all agree that NAT66 is not part of the 46translation  
effort and the chair of behave has indicated that it is not in scope  
for behave, so I'll stop cc:ing those groups on my messages about it.   
When the draft comes out, I will send a pointer to intarea and ask for  
feedback.

If Jari and Mark are willing to give me a slot, we could talk about  
the draft at the intarea meeting in Minneapolis.  If there is enough  
interest in NAT66 that it makes sense to continue working on the  
draft, I will.

Even if it takes a while for us to get the NAT66 document published as  
an RFC, we'll have a reasonably well-reviewed draft available in the  
meantime that may help people who start working on NAT66  
implementations to make good design choices.

Does that make sense?

Margaret


On Oct 23, 2008, at 10: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