Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] 
> Sent: Tuesday, December 01, 2009 1:47 AM
> To: Dan Wing
> Cc: 'Simon Perreault'; 'Magnus Westerlund'; behave@ietf.org
> Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling
> 
> Dan Wing escribió:
> >  
> >
> >   
> >> -----Original Message-----
> >> From: behave-bounces@ietf.org 
> >> [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault
> >> Sent: Thursday, November 26, 2009 6:57 AM
> >> To: Magnus Westerlund
> >> Cc: behave@ietf.org
> >> Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling
> >>
> >> Magnus Westerlund wrote, on 2009-11-26 09:27:
> >>     
> >>> I think for that address dependent mapping may work if one 
> >>>       
> >> restrict it
> >>     
> >>> to cases where it is known that there is a strict client 
> >>>       
> >> server protocol
> >>     
> >>> on the port. I think the most gain for the least hassle 
> would be to
> >>> allow address dependent mappings for flows that has 
> destination that
> >>> matches TCP.port=80 or TCP.port=443. I don't know how that 
> >>>       
> >> would affect
> >>     
> >>> the more esoteric usages of HTTP.
> >>>       
> >> Something similar to this was proposed by Rémi Després on 
> >> 2008-05-22 with the
> >> name "Address-port sparing NATs".
> >>
> >> I would agree that this is a useful optimization.
> >>
> >>     
> >>> But, in general it is difficult to know what application 
> >>>       
> >> that runs on
> >>     
> >>> top of the transport protocol and what its need is. Thus 
> >>>       
> >> this should be
> >>     
> >>> done with significant care. I would recommend a minimal set of
> >>> identified applications where an operator may chose this option to
> >>> achieve a bit better address re-use.
> >>>       
> >> Agreed.
> >>
> >> Rémi Després suggested HTTP, HTTPS, DNS, POP3, IMAP, SNMP.
> >>
> >> I suggest that this list be interpreted as guidance for 
> >> operators, as in e.g.
> >> "these protocols fine with adddress and port-dependent 
> >> mappnig." Ultimately this
> >> is an operational issue and we can only provide guidance.
> >>
> >> However, address and port-dependent mapping is implemented 
> completely
> >> differently than what is described in the current draft. For 
> >> instance, there is
> >> no longer a need for separate binding and session tables. So 
> >> I would like to
> >> hear from authors what they think of this suggestion, and if 
> >> they'd like me to
> >> provide text.
> >>     
> >
> > This sort of optimization feels like an 
> informational/experimental-track
> > document and can be separate from 
> draft-ietf-behave-v6v4-xlate-stateful.
> >   
> 
> Yes, this seems to be common to any CGN,  nat64 and nat44.
> I understand that this is related to having bigger nat boxes and i 
> understand there is ongoing work to identify what of the behave 
> requirements can be lifted in the case of CGNs.
> 
> So, this has been discussed several tiems already and the 
> proposed way 
> forward was:
> - define nat64 as complying with the behave requirements
> - define another doc where the behave requirements are 
> contrasted witht 
> eh reality of CGNs and identify which requirements can be lifted.
> 
> makes sense?

Yes, makes sense.

It also allows us to keep stateful NAT64 on its current schedule
to be sent to IESG this month.

-d

> Regards, marcelo
> 
> 
> > -d
> >
> >
> >   
> >> Simon
> >> -- 
> >> DNS64 open-source   --> http://ecdysis.viagenie.ca
> >> STUN/TURN server    --> http://numb.viagenie.ca
> >> vCard 4.0           --> http://www.vcarddav.org
> >> _______________________________________________
> >> Behave mailing list
> >> Behave@ietf.org
> >> https://www.ietf.org/mailman/listinfo/behave
> >>     
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> >
> >   
> 