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

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Margaret Wasserman
> Sent: Thursday, October 23, 2008 8:28 AM
> To: Mark Townsley
> Cc: [e-mail]; 46Translation; Behave WG
> Subject: Re: [v4v6interim] [BEHAVE] [46translation] Proposal 
> for new BEHAVEcharter
> 
> 
> 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.  

BEHAVE is being re-chartered, so if the community wants BEHAVE to
do NAT66, now is a good time to tell the IESG to include NAT66 in 
BEHAVE's charter.  (as you all know.)  The new charter, at this
time, does not include NAT66.

And I only stated my desire to avoid the 'third rail'; the IESG can 
certainly decide they want NAT66 standardized.  Based on my 
understanding of how NAT66 would work, it would belong in BEHAVE.

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

Yes, makes sense.

-d

> 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

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