headers
Xu Xiaohu | 1 Dec 2009 05:19
Favicon

Re: proprietary implementation v.s standardised protocols//re: draft-xu-behave-nat-state-sync-00


> -----邮件原件-----
> 发件人: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] 代表
> Cameron Byrne
> 发送时间: 2009年12月1日 1:19
> 收件人: mohamed.boucadair <at> orange-ftgroup.com
> 抄送: behave <at> ietf.org; Xu Xiaohu
> 主题: Re: [BEHAVE] proprietary implementation v.s standardised protocols//re:
> draft-xu-behave-nat-state-sync-00
> 
> On Mon, Nov 30, 2009 at 4:54 AM,  <mohamed.boucadair <at> orange-ftgroup.com>
> wrote:
> >
> > Dear Cameron,
> >
> > The issue you are describing is more about load distribution rather than NAT
> state sync.
> 
> Correct, i believe we can best provide service availability in the
> macro network with DNS64 controlled load distribution.  NAT sync in
> the macro network faces too many challenges to be useful

Do you want to use DNS64 to achieve NAT redundancy while realizing load-balancing? Do you mean offering the
IPv6 host another prefix64 by DNS64 if the NAT box for the previous prefix crashes?

Xiaohu

> > I agree with the requirement you have (BTW, similar solutions exist for the
> selection of the outbound proxy SIP) but this may be easy to implement with
> stateless NATxy rather than stateful one since the path MUST be symmetric (the
(Continue reading)

Permalink | Reply | 52 comments |
headers
mohamed.boucadair | 1 Dec 2009 08:18

Re: proprietary implementation v.s standardised protocols //re: draft-xu-behave-nat-state-sync-00


Dear Cameron, 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Cameron Byrne [mailto:cb.list6 <at> gmail.com] 
Envoyé : lundi 30 novembre 2009 18:19
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Xu Xiaohu; Brian E Carpenter; behave <at> ietf.org
Objet : Re: [BEHAVE] proprietary implementation v.s standardised protocols //re: draft-xu-behave-nat-state-sync-00

On Mon, Nov 30, 2009 at 4:54 AM,  <mohamed.boucadair <at> orange-ftgroup.com> wrote:
>
> Dear Cameron,
>
> The issue you are describing is more about load distribution rather than NAT state sync.

Correct, i believe we can best provide service availability in the
macro network with DNS64 controlled load distribution.  NAT sync in
the macro network faces too many challenges to be useful

>
> I agree with the requirement you have (BTW, similar solutions exist for the selection of the outbound
proxy SIP) but this may be easy to implement with stateless NATxy rather than stateful one since the path
MUST be symmetric (the same NAT device must be crossed) and appropriate routing actions should be
undertaken to redirect the traffic to the appropriate NATxy device. If you have a fully distributed NATxy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cameron Byrne | 1 Dec 2009 08:32
Picon

Re: proprietary implementation v.s standardised protocols//re: draft-xu-behave-nat-state-sync-00

On Mon, Nov 30, 2009 at 8:19 PM, Xu Xiaohu <xuxh <at> huawei.com> wrote:
>
>
>> -----邮件原件-----
>> 发件人: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] 代表
>> Cameron Byrne
>> 发送时间: 2009年12月1日 1:19
>> 收件人: mohamed.boucadair <at> orange-ftgroup.com
>> 抄送: behave <at> ietf.org; Xu Xiaohu
>> 主题: Re: [BEHAVE] proprietary implementation v.s standardised protocols//re:
>> draft-xu-behave-nat-state-sync-00
>>
>> On Mon, Nov 30, 2009 at 4:54 AM,  <mohamed.boucadair <at> orange-ftgroup.com>
>> wrote:
>> >
>> > Dear Cameron,
>> >
>> > The issue you are describing is more about load distribution rather than NAT
>> state sync.
>>
>> Correct, i believe we can best provide service availability in the
>> macro network with DNS64 controlled load distribution.  NAT sync in
>> the macro network faces too many challenges to be useful
>
> Do you want to use DNS64 to achieve NAT redundancy while realizing load-balancing? Do you mean offering
the IPv6 host another prefix64 by DNS64 if the NAT box for the previous prefix crashes?
>
> Xiaohu

Yes, I want DNS64 to facilitate NAT64 redundancy from a macro-network
(Continue reading)

Permalink | Reply | 51 comments |
headers
Xu Xiaohu | 1 Dec 2009 10:07
Favicon

Re: proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00


> -----邮件原件-----
> 发件人: Cameron Byrne [mailto:cb.list6 <at> gmail.com]
> 发送时间: 2009年12月1日 15:32
> 收件人: Xu Xiaohu
> 抄送: mohamed.boucadair <at> orange-ftgroup.com; behave <at> ietf.org
> 主题: Re: [BEHAVE] proprietary implementation v.s standardisedprotocols//re:
> draft-xu-behave-nat-state-sync-00
> 
> On Mon, Nov 30, 2009 at 8:19 PM, Xu Xiaohu <xuxh <at> huawei.com> wrote:
> >
> >
> >> -----邮件原件-----
> >> 发件人: behave-bounces <at> ietf.org [mailto:behave-bounces <at> ietf.org] 代表
> >> Cameron Byrne
> >> 发送时间: 2009年12月1日 1:19
> >> 收件人: mohamed.boucadair <at> orange-ftgroup.com
> >> 抄送: behave <at> ietf.org; Xu Xiaohu
> >> 主题: Re: [BEHAVE] proprietary implementation v.s standardised
> protocols//re:
> >> draft-xu-behave-nat-state-sync-00
> >>
> >> On Mon, Nov 30, 2009 at 4:54 AM,  <mohamed.boucadair <at> orange-ftgroup.com>
> >> wrote:
> >> >
> >> > Dear Cameron,
> >> >
> >> > The issue you are describing is more about load distribution rather than
> NAT
> >> state sync.
(Continue reading)

Permalink | Reply | 50 comments |
headers
marcelo bagnulo braun | 1 Dec 2009 10:41
Picon

Handling fragments in the stateful NAT64

Hi,

after the discussion in hiroshima, I have updated the draft.
The current 03 version reads:

   If the incoming IP packet contains a fragment, then more processing
   may be needed.  This specification leaves open the exact details of
   how a NAT64 handles incoming IP packets containing fragments, and
   simply requires that a NAT64 handle fragments arriving out-of-order.
   A NAT64 MAY elect to queue the fragments as they arrive and translate
   all fragments at the same time.  Alternatively, a NAT64 MAY translate
   the fragments as they arrive, by storing information that allows it
   to compute the 5-tuple for fragments other than the first.  In the
   latter case, the NAT64 will still need to handle the situation where
   subsequent fragments arrive before the first.

   Implementors of NAT64 should be aware that there are a number of
   well-known attacks against IP fragmentation; see [RFC1858] and
   [RFC3128].

   Assuming it otherwise has sufficient resources, a NAT64 MUST allow
   the fragments to arrive over a time interval of at least 10 seconds.
   A NAT64 MAY require that the UDP, TCP, or ICMP header be completely
   contained within the first fragment.

Let me know if you have issues witht eh current text. I hope it reflects 
the received feedback.

Regards, marcelo
(Continue reading)

Permalink | Reply | 4 comments |
headers
marcelo bagnulo braun | 1 Dec 2009 10:46
Picon

Re: NAT64 mapping behaviour w.r.t. scaling

Dan Wing escribió:
>  
>
>   
>> -----Original Message-----
>> From: behave-bounces <at> ietf.org 
>> [mailto:behave-bounces <at> ietf.org] On Behalf Of Simon Perreault
>> Sent: Thursday, November 26, 2009 6:57 AM
>> To: Magnus Westerlund
>> Cc: behave <at> 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.
>>>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Simon Perreault | 1 Dec 2009 11:38
Picon
Favicon

Re: NAT64 mapping behaviour w.r.t. scaling

On 12/01/2009 04:46 AM, marcelo bagnulo braun wrote:
> 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.

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

-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org
Permalink | Reply | 1 comment |
headers
Simon Perreault | 1 Dec 2009 11:42
Picon
Favicon

Re: proprietary implementation v.s standardisedprotocols//re: draft-xu-behave-nat-state-sync-00

On 12/01/2009 04:07 AM, Xu Xiaohu wrote:
> In order to use the correct prefix64 in synthesizing AAAA records, the DNS64 should be able to determine
which prefix64 is available by some means, e.g., exchanging messages with NAT64, or sending probe
packets to a given IPv4 host within the IPv4 Internet by using different prefix64s.
>
> BTW, once the NAT box for a given prefix fails, would the communications using that prefix be interrupted
till the corresponding AAAA records in the DNS caches of IPv6 hosts expire?

This is exactly why each "box" is in fact many boxes whose state is 
synchronized.

Handling the complete failure of a set of such boxes is really up to the 
operator and doesn't need to be standardized, in my opinion. Many custom 
actions would need to be taken in such a case.

Simon
--

-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org
Permalink | Reply | 1 comment |
headers
Dan Wing | 1 Dec 2009 17:21
Picon
Favicon

Re: NAT64 mapping behaviour w.r.t. scaling


> -----Original Message-----
> From: marcelo bagnulo braun [mailto:marcelo <at> it.uc3m.es] 
> Sent: Tuesday, December 01, 2009 1:47 AM
> To: Dan Wing
> Cc: 'Simon Perreault'; 'Magnus Westerlund'; behave <at> ietf.org
> Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling
> 
> Dan Wing escribió:
> >  
> >
> >   
> >> -----Original Message-----
> >> From: behave-bounces <at> ietf.org 
> >> [mailto:behave-bounces <at> ietf.org] On Behalf Of Simon Perreault
> >> Sent: Thursday, November 26, 2009 6:57 AM
> >> To: Magnus Westerlund
> >> Cc: behave <at> 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
> >>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 1 Dec 2009 17:22
Picon
Favicon

Re: NAT64 mapping behaviour w.r.t. scaling


> -----Original Message-----
> From: Simon Perreault [mailto:simon.perreault <at> viagenie.ca] 
> Sent: Tuesday, December 01, 2009 2:38 AM
> To: marcelo bagnulo braun
> Cc: Dan Wing; 'Magnus Westerlund'; behave <at> ietf.org
> Subject: Re: [BEHAVE] NAT64 mapping behaviour w.r.t. scaling
> 
> On 12/01/2009 04:46 AM, marcelo bagnulo braun wrote:
> > 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.
> 
> 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.)

"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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane