Re: [v4tov6transition] Any Experience with Using Behave's Stateless NAT-PT for IMS-SIP VoIP Application...
"Mosley, Leonard" <len.mosley@twcable.com> Wed, 22 September 2010 17:05 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 6D1173A685B; Wed, 22 Sep 2010 10:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.138
X-Spam-Level:
X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=0.325, 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 lhWqd+53hqY8; Wed, 22 Sep 2010 10:05:26 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by core3.amsl.com (Postfix) with ESMTP id 35A3D3A695C; Wed, 22 Sep 2010 10:05:26 -0700 (PDT)
X-SENDER-IP: 10.136.163.10
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.57,218,1283745600"; d="scan'208";a="132422799"
Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Sep 2010 13:05:53 -0400
Received: from PRVPEXVS07.corp.twcable.com ([10.136.163.35]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 22 Sep 2010 13:05:53 -0400
From: "Mosley, Leonard" <len.mosley@twcable.com>
To: Dan Wing <dwing@cisco.com>, "behave@ietf.org" <behave@ietf.org>, "v4tov6transition@ietf.org" <v4tov6transition@ietf.org>, "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Date: Wed, 22 Sep 2010 13:05:52 -0400
Thread-Topic: [v4tov6transition] Any Experience with Using Behave's Stateless NAT-PT for IMS-SIP VoIP Application...
Thread-Index: ActaYb+OEE/JbbIPTbyTOd1qpiQXrwAEanCwAAE7UcA=
Message-ID: <EC91E98C3BC6A34B917F828067B9335C1535E73563@PRVPEXVS07.corp.twcable.com>
References: <EC91E98C3BC6A34B917F828067B9335C1535E73180@PRVPEXVS07.corp.twcable.com> <152d01cb5a77$6a25eeb0$3e71cc10$@com>
In-Reply-To: <152d01cb5a77$6a25eeb0$3e71cc10$@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
Subject: Re: [v4tov6transition] Any Experience with Using Behave's Stateless NAT-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 17:05:27 -0000
Dan this was great! Tks, Len... -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Wednesday, September 22, 2010 12:59 PM To: Mosley, Leonard; behave@ietf.org; v4tov6transition@ietf.org; v6ops@ops.ietf.org Subject: RE: [v4tov6transition] Any Experience with Using Behave's Stateless NAT-PT for IMS-SIP VoIP Application... > -----Original Message----- > From: v4tov6transition-bounces@ietf.org [mailto:v4tov6transition- > bounces@ietf.org] On Behalf Of Mosley, Leonard > Sent: Wednesday, September 22, 2010 7:24 AM > To: behave@ietf.org; v4tov6transition@ietf.org; v6ops@ops.ietf.org > Subject: [v4tov6transition] Any Experience with Using Behave's > Stateless NAT-PT for IMS-SIP VoIP Application... > > Greetings Fred et al, I had a couple of inquiries concerning use of the > Behave WG NAT-PT algorithms: > > > > 1) I was wondering what vendors currently are implementing the > Behave WG's NAT-PT algorithms? I am aware of products from Juniper and Cisco that implement NAT-PT. > 2) Has anyone had any experience testing or implementing the > stateless algorithm for use cases involving IMS SIPv4 VoIP clients > calling SIPv6 clients and vice versa. Such use cases assume an > architecture where there is a co-existence period in the network > consisting of both "legacy" SIPv4 clients and "newer" SIPv6 (dual-stack > and/or v6-only) clients. There are two answers: 1. use an SBC to interwork between IPv6-only and IPv4-only nodes 2. require IPv6 nodes (both dual-stack and IPv6-only) to follow http://tools.ietf.org/html/draft-ietf-sipping-v6-transition which is RAI's recommendation for SIP IPv6 transition. That spec requires IPv6 hosts implement ICE, and requires IPv6 nodes to include an IPv4 address in their SDP. For an IPv6-only node to include an IPv4 address in its SDP, the IPv6-only host would need to figure out an IPv4 address for itself (because it cannot walk its interface table, like a dual-stack node could do). This problem is described in http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server-01 and BEHAVE spent 20 minutes at our last meeting analyzing techniques to solve that problem, and BEHAVE has a milestone to resolve that problem. (draft-ietf-sipping-v6-transition has been fully approved to become an RFC, but has been tied up in the RFC editor's queue. Reference http://www.rfc-editor.org/queue2.html#draft-ietf-sipping-v6-transition) Without one or the other, IPv4-only hosts will see c=/m= lines containing IPv6 addresses -- which they cannot do anything with. This all gets more complex with things like call transfers between IPv4-only, dual-stack, and IPv6-only, combined with firewalls and NATs which may (or may not) block media flows from 'new' peers, and so on. You asked an IETF mailing list, so I will say that ICE provides the best standards-based mechanism to solve the problem, but the dearth of ICE implementations in endpoints has caused many to consider using an SBC to interwork between IPv4 and IPv6. You might be interested in the first section of "Happy Eyeballs", http://tools.ietf.org/html/draft-wing-dispatch-v6-migration, although the Happy Eyeballs proposal itself has been rejected in favor of doing ICE. (Which is a good decision, IMHO). > 3) I'm curious about RTP performance under moderate to heavy call > loads UDP performance through a NAT (delay, jitter, loss) is going to be specific to vendor equipment. > as well as NAT-PT interaction with IMS-ALG. If anyone can share > at a high-level that would be great. -d
- [v4tov6transition] Any Experience with Using Beha… Mosley, Leonard
- Re: [v4tov6transition] Any Experience with Using … Cameron Byrne
- Re: [v4tov6transition] Any Experience with Using … Mosley, Leonard
- Re: [v4tov6transition] Any Experience with Using … Fred Baker
- Re: [v4tov6transition] Any Experience with Using … Hui Deng
- Re: [v4tov6transition] Any Experience with Using … Mosley, Leonard
- Re: [v4tov6transition] Any Experience with Using … Cameron Byrne
- Re: [v4tov6transition] Any Experience with Using … Hui Deng
- Re: [v4tov6transition] Any Experience with Using … Mosley, Leonard
- Re: [v4tov6transition] Any Experience with Using … Dan Wing
- Re: [v4tov6transition] Any Experience with Using … Mosley, Leonard
- Re: [v4tov6transition] Any Experience with Using … Fred Baker
- Re: [v4tov6transition] Any Experience with Using … Francis Dupont
- Re: [v4tov6transition] [BEHAVE] Any Experience wi… Xing Li
- Re: [v4tov6transition] [BEHAVE] Any Experience wi… Tina TSOU
- Re: [v4tov6transition] [BEHAVE] Any Experience wi… marcelo bagnulo braun