[no subject]

["Dan Wing" <dwing@cisco.com>]

<AANLkTin1gQhnS=w4+ehLyJOyO+mz0NNnz-4rD-N97ZEq@mail.gmail.com>
<EC91E98C3BC6A34B917F828067B9335C1535E733DE@PRVPEXVS07.corp.twcable.com>	<005301cb5a6f$75490320$5fdb0960$@com>
<AANLkTi=+Fx4c6UvcBi3GO2U2Cg9y7EkkTcmyO2q_YQ6t@mail.gmail.com>
<576604.55924.qm@web111407.mail.gq1.yahoo.com>
In-Reply-To: <576604.55924.qm@web111407.mail.gq1.yahoo.com>
Subject: RE: [BEHAVE] [v4tov6transition] Any Experience with Using
Behave's	StatelessNAT-PT for IMS-SIP VoIP Application...
Date: Wed, 22 Sep 2010 19:05:55 -0700
Message-ID: <179c01cb5ac3$db7a77b0$926f6710$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Actap2dXrifSCLwAQ1aDmrT+l97yegAGwuVg
Content-Language: en-us
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

> Cameron, NAT64 also requires ALGs.

No, only for protocols that don't do their own NAT traversal.

> Behave is working on FTP ALG now. 

FTP is a special case because EPSV, which was supposed to be how
IPv6 works with FTP, is improperly deployed on approximately 30% of
publicly-accessible FTP servers on the Internet.  The FTP64
specification (draft-ietf-behave-ftp64) describes how an ALG can
get around that deployment problem, and a separate document will
explain how an FTP client can do the same thing, and how IPv6-
friendly FTP servers are supposed to be deployed.  The FTP64 ALG
is also designed to be told avoid doing any ALG functions at
all ("ALGS DISABLE" command) in anticipation of IPv6-only
clients that support their own NAT traversal and dealing with
EPSV/PASV interworking (which is what the FTP64 ALG does).

draft-ietf-behave-ftp64 is in its second WGLC.  Reviews
welcome.

> I think IMS-ALG is also needed but you said B2BUA can be used. 
> In fact 3GPP standardized IMS-ALG already but it was for NATPT.

-d


> --b
> 
> 
> 
> ----- Original Message ----
> > From: Cameron Byrne <cb.list6@gmail.com>
> > To: Hui Deng <denghui@chinamobile.com>
> > Cc: v6ops@ops.ietf.org; behave@ietf.org; v4tov6transition@ietf.org;
> "Mosley,
> >Leonard" <len.mosley@twcable.com>
> > Sent: Wed, September 22, 2010 11:23:09 AM
> > Subject: Re: [BEHAVE] [v4tov6transition] Any Experience with Using
> Behave's
> >StatelessNAT-PT for IMS-SIP VoIP Application...
> >
> > On Wed, Sep 22, 2010 at 9:01 AM, Hui Deng <denghui@chinamobile.com>
> wrote:
> > > I guess that NATPT and B2BUA are different story?
> >
> > Right,  B2BUA is a proxy that terminates and re-initiates the call
> leg.
> >  B2BUA are  very specific to SIP and therefore can be very robust in
> > their handling of  SIP traffic.
> >
> > As where any form of NAT is fundamentally just a "network  layer"
> > function with some ALG to support.  And, ALGs are notoriously  poorly
> > implemented and seldom standardized.
> >
> > > What about ur opinion  about performance of deprecated NAT-PT
> regarding to
> > >  SIP-SDP-RTP?
> > >
> >
> > I do not recommend anyone to have a going forward  network strategy
> > based on a deprecated protocol, if it can be  avoided.
> >
> > VoIP is generally considered very important traffic (billable
> minutes,
> > emergency services, branded services) while Internet is considered
> not
> > very important (best effort,  ...).  That said, i believe most
> network
> > operators feel more comfortable keeping the protocol  translation
> > infrastructure for VoIP / IMS separate (use a B2BUA or  P-CSCF
> > functions) from the general use protocol translation (NAT64).   The
> > basic logic is that the NAT64, like NAT44 today, will have a lot  of
> > entropy from the various different types of protocols and
> > interactions,  as where the B2BUA will be much more focused functions
> > with stricter rules  and less entropy that can trigger "unforeseen
> > feature interactions", aka  bugs.
> >
> > Also, given my limited scope, i have not seen a strong use case,
> IMHO,
> > for stateless translation since it requires 1 to 1 mapping of IPv4
> to
> > IPv6, and thus does not solve the address exhaustion issue ....
> which
> > is why folks are doing IPv6 in the first place.
> >
> > Generally about  NAT64 performance, we expect it to be approximately
> > consistent with NAT44 CGN  performance, slightly less on some
> > platforms.  ALGs generally decrease  performance since they require
> > more complex logic deeper in the  packet.
> >
> > Cameron
> > _______________________________________________
> > 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