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

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 01 Dec 2009 10:46:41 +0100

Dan Wing escribió:
>  
>
>   
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Simon Perreault
>> Sent: Thursday, November 26, 2009 6:57 AM
>> To: Magnus Westerlund
>> Cc: [email-masked]
>> 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?

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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>>     
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 01 Dec 2009 05:38:01 -0500

> eh reality of CGNs and identify which requirements can be lifted.

Oh, good. I certainly remember the discussions, but I don't remember 
that a decision had been made.

> makes sense?

Certainly!

(But let's not talk about CGNs as if they were something completely 
different. They're not. It's just about scaling, which is a continuum.)

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 08:21:42 -0800

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Tuesday, December 01, 2009 1:47 AM
> To: Dan Wing
> Cc: 'Simon Perreault'; 'Magnus Westerlund'; [email-masked]

Yes, makes sense.

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

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Dec 2009 08:22:41 -0800

> From: Simon Perreault [mailto:[email-masked]] 
> Sent: Tuesday, December 01, 2009 2:38 AM
> To: marcelo bagnulo braun
> Cc: Dan Wing; 'Magnus Westerlund'; [email-masked]

"LSN" (large scale NAT) is perhaps the better term; afterall, you
don't necessarily need to be a "carrier" to want/need a large NAT.
You might be a University, a large company, etc.

-d