Re: [v4tov6transition] Any Experience with Using Behave's StatelessNAT-PT for IMS-SIP VoIP Application...

"Mosley, Leonard" <len.mosley@twcable.com> Wed, 22 September 2010 16:51 UTC

Return-Path: <len.mosley@twcable.com>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD55C3A6978; Wed, 22 Sep 2010 09:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.03
X-Spam-Level:
X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLgleXieXhGl; Wed, 22 Sep 2010 09:50:54 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by core3.amsl.com (Postfix) with ESMTP id 804E93A6964; Wed, 22 Sep 2010 09:50:52 -0700 (PDT)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.57,218,1283745600"; d="scan'208";a="125337492"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Sep 2010 12:45:19 -0400
Received: from PRVPEXVS07.corp.twcable.com ([10.136.163.35]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 22 Sep 2010 12:45:19 -0400
From: "Mosley, Leonard" <len.mosley@twcable.com>
To: Cameron Byrne <cb.list6@gmail.com>, Hui Deng <denghui@chinamobile.com>
Date: Wed, 22 Sep 2010 12:45:18 -0400
Thread-Topic: [v4tov6transition] Any Experience with Using Behave's StatelessNAT-PT for IMS-SIP VoIP Application...
Thread-Index: ActacnJVu5Vz1gAYSMynEqOZx+QzMAAAbO3w
Message-ID: <EC91E98C3BC6A34B917F828067B9335C1535E73504@PRVPEXVS07.corp.twcable.com>
References: <AANLkTin1gQhnS=w4+ehLyJOyO+mz0NNnz-4rD-N97ZEq@mail.gmail.com> <EC91E98C3BC6A34B917F828067B9335C1535E733DE@PRVPEXVS07.corp.twcable.com> <005301cb5a6f$75490320$5fdb0960$@com> <AANLkTi=+Fx4c6UvcBi3GO2U2Cg9y7EkkTcmyO2q_YQ6t@mail.gmail.com>
In-Reply-To: <AANLkTi=+Fx4c6UvcBi3GO2U2Cg9y7EkkTcmyO2q_YQ6t@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>, "behave@ietf.org" <behave@ietf.org>, "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>
Subject: Re: [v4tov6transition] Any Experience with Using Behave's StatelessNAT-PT for IMS-SIP VoIP Application...
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Sep 2010 16:51:02 -0000

Tks Cameron, I concur with your comments below and was just curious if the Behave's IP/ICMP Algorithm/Stateful NAT64 had been evaluated in an SBC (IMS VoIP) environment yet and any "unexpected" impacts.  Maybe Xing Li can shed some light as Fred indicated.

Tks again,

Len...

-----Original Message-----
From: Cameron Byrne [mailto:cb.list6@gmail.com]
Sent: Wednesday, September 22, 2010 12:23 PM
To: Hui Deng
Cc: Mosley, Leonard; behave@ietf.org; v4tov6transition@ietf.org; v6ops@ops.ietf.org
Subject: Re: [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

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.