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

From: Cameron Byrne <[email-masked]>
Date: Wed, 22 Sep 2010 08:26:34 -0700

When you must translate between protocols, most service providers use
sip b2bua aka an sbc.

Cameron

On 9/22/10, Mosley, Leonard <[email-masked]> wrote:
> 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?
>
> 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.
>
> 3)      I'm curious about RTP performance under moderate to heavy call loads
> as well as NAT-PT interaction with IMS-ALG.  If anyone can share at a
> high-level that would be great.
>
> Tks,
>
> Len Mosley
> Time Warner Cable
>
> ________________________________
> 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.
>

-- 
Sent from my mobile device

---

From: "Mosley, Leonard" <[email-masked]>
Date: Wed, 22 Sep 2010 11:46:32 -0400

Yes sir Cameron, hence, my queries below. Most of the SIP-SDP-RTPv4 to SIP-SDP-RTPv6 lab evals I've seen have utilized the deprecated NAT-PT, so I was curious about anyone's experience yet with the Behave group's "newer" algorithms (yes, normally implemented in an SBC for RTP/UDP/IP-version translation) and its interaction with an IMS network (VoIP network) requesting translation services from it.

Tks,

Len...

-----Original Message-----
From: Cameron Byrne [mailto:[email-masked]]
Sent: Wednesday, September 22, 2010 11:27 AM
To: Mosley, Leonard; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v4tov6transition] Any Experience with Using Behave's Stateless NAT-PT for IMS-SIP VoIP Application...

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.

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Sep 2010 08:59:09 -0700

On Sep 22, 2010, at 7:23 AM, Mosley, Leonard wrote:

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

To my knowledge, behave isn't supporting 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. 

Xing Li can comment on whether SIP/IVI is in use in his network. I would expect that the biggest issue in SIP deployment is the use of native addressing in SDP, which is probably best handled by some form of gateway. This is of course true of any protocol that carries IP addresses in the application and expects them to be meaningful to a peer; SIP across an IPv4/IPv4 NAT similarly requires some form of proxy that can direct indicated traffic correctly.

> 3)      I’m curious about RTP performance under moderate to heavy call loads as well as NAT-PT interaction with IMS-ALG.  If anyone can share at a high-level that would be great.

NAT-PT hasn't been all that wonderful. That's why it was deprecated...

> _______________________________________________
> v4tov6transition mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v4tov6transition

---

From: "Mosley, Leonard" <[email-masked]>
Date: Wed, 22 Sep 2010 12:08:58 -0400

Ahh, my apologies Fred for referring to the stateless-portion of the v6v4-xlate-23 draft as "NAT-PT". I see in conversation there is a strict distinction between the two.

Tks,

Len...  

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Wednesday, September 22, 2010 11:59 AM
To: Mosley, Leonard
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v4tov6transition] Any Experience with Using Behave's Stateless NAT-PT for IMS-SIP VoIP Application...

On Sep 22, 2010, at 7:23 AM, Mosley, Leonard wrote:

> 1)      I was wondering what vendors currently are implementing the Behave WG's NAT-PT algorithms?

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

> 3)      I'm curious about RTP performance under moderate to heavy call loads as well as NAT-PT interaction with IMS-ALG.  If anyone can share at a high-level that would be great.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 22 Sep 2010 09:23:09 -0700

On Wed, Sep 22, 2010 at 9:01 AM, Hui Deng <[email-masked]> 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

---

From: "Mosley, Leonard" <[email-masked]>
Date: Wed, 22 Sep 2010 12:45:18 -0400

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:[email-masked]]
Sent: Wednesday, September 22, 2010 12:23 PM
To: Hui Deng
Cc: Mosley, Leonard; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v4tov6transition] Any Experience with Using Behave's StatelessNAT-PT for IMS-SIP VoIP Application...

Cameron

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Sep 2010 09:58:43 -0700

> From: [email-masked] [mailto:v4tov6transition-
> [email-masked]] On Behalf Of Mosley, Leonard
> Sent: Wednesday, September 22, 2010 7:24 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [v4tov6transition] Any Experience with Using Behave's
> Stateless NAT-PT for IMS-SIP VoIP Application...
> 

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

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

---

From: "Mosley, Leonard" <[email-masked]>
Date: Wed, 22 Sep 2010 13:05:52 -0400

Dan this was great! Tks,

Len...

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, September 22, 2010 12:59 PM
To: Mosley, Leonard; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [v4tov6transition] Any Experience with Using Behave's Stateless NAT-PT for IMS-SIP VoIP Application...

There are two answers:

-d

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Sep 2010 10:41:04 -0700

> To my knowledge, behave isn't supporting NAT-PT...

OK, if you're talking about http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate and http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful, I know Cisco has two implementations and http://datatracker.ietf.org/doc/draft-arkko-ipv6-only-experience talks about Jari's experience with Ericsson's. I don't know of others, but I would expect that there are several others.

>> 3)      I'm curious about RTP performance under moderate to heavy call loads as well as NAT-PT interaction with IMS-ALG.  If anyone can share at a high-level that would be great.

draft-ietf-behave-v6v4-xlate is only at the network layer; ALGs are required for some protocols, like SIP and FTP, but I would expect that RTP (voice traffic) is a matter of exchanging IPv4<->IPv6 headers. That's primarily a matter of read/write times...

---

From: "Mosley, Leonard" <[email-masked]>
Date: Wed, 22 Sep 2010 10:23:38 -0400

Tks,

Len Mosley
Time Warner Cable

---

From: "Hui Deng" <[email-masked]>
Date: Thu, 23 Sep 2010 00:01:30 +0800

Thanks

-Hui

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mosley, Leonard
> Sent: Wednesday, September 22, 2010 11:47 PM
> To: Cameron Byrne; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [v4tov6transition] Any Experience with Using Behave's
> StatelessNAT-PT for IMS-SIP VoIP Application...
> 
> Yes sir Cameron, hence, my queries below. Most of the SIP-SDP-RTPv4 to
> SIP-SDP-RTPv6 lab evals I've seen have utilized the deprecated NAT-PT, so
I was
> curious about anyone's experience yet with the Behave group's "newer"
> algorithms (yes, normally implemented in an SBC for RTP/UDP/IP-version
> translation) and its interaction with an IMS network (VoIP network)
requesting
> translation services from it.
> 
> Tks,
> 
> Len...
> 
> Subject: Re: [v4tov6transition] Any Experience with Using Behave's
Stateless
> NAT-PT for IMS-SIP VoIP Application...
> 
> stateless
> 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.

---

From: "Hui Deng" <[email-masked]>
Date: Thu, 23 Sep 2010 00:47:08 +0800

Inline please,

> Sent: Thursday, September 23, 2010 12:23 AM
> To: Hui Deng
> Subject: Re: [v4tov6transition] Any Experience with Using
> Behave'sStatelessNAT-PT for IMS-SIP VoIP Application...
> 
I think we are inline here, the reason I ask here is because I feel SIP is
not rely 
On NATPT for operator service, but he may ask about Internet SIP service.

> more complex logic deeper in the packet.
For Internet SIP, does NAT64 shows the same performance as NAT44, 
We are discussing here. Mosley may have testing experience about how
NATPT is weak about Internet SIP?

-Hui

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 22 Sep 2010 15:42:01 -0700 (PDT)

Cameron, NAT64 also requires ALGs. Behave is working on FTP ALG now. 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.

--b

----- Original Message ----
> From: Cameron Byrne <[email-masked]>
> To: Hui Deng <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; "Mosley, 
>Leonard" <[email-masked]>
> Sent: Wed, September 22, 2010 11:23:09 AM
> Subject: Re: [BEHAVE] [v4tov6transition] Any Experience with Using Behave's 
> Behave  mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Sep 2010 19:05:55 -0700

> 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

---

From: Fred Baker <[email-masked]>
Date: Thu, 23 Sep 2010 12:19:56 -0700

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

If we agree that some don't, then you are agreeing with each other. Protocols that do their own NAT traversal (anything that keeps application layer stuff at the application layer and network layer stuff at the network layer) are fine. Protocols that mix the two - FTP, SIP, perhaps SMTP, etc - require some form of ALG or proxy to fix up the application layer stuff. Simplest approach is an application that speaks IPv6 on one side and IPv4 on the other and terminates the sessions, such as an SMTP MTA; if relays don't exist, it gets messy, but then the NAT world has always been messy.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Sep 2010 10:04:47 +1200

> If we agree that some don't, then you are agreeing with each other. Protocols that do their own NAT traversal (anything that keeps application layer stuff at the application layer and network layer…

Shameless plug: there's another way to look at this topic:
draft-carpenter-referral-ps-01.txt

   Brian

---

From: Xing Li <[email-masked]>
Date: Sun, 26 Sep 2010 22:01:06 +0800

> Xing Li can comment on whether SIP/IVI is in use in his network. I would expect that the biggest issue in SIP deployment is the use of native addressing in SDP, which is probably best handled by so…

We are deploying IVI in 100 campus networks of CERNET2 (IPv6-only 
network). But we have not get reports concerning SIP/IVI. Some 
universities told us that they will do SIP related test later.

At this moment, some comments are:

(1) IVI (stateless translation) can support IPv6 and IPv4 initiated 
communications, while stateful translation can only support IPv6 
initiated communication. So stateless translation should support SIP better.
(2) IVI is stateless, there should be no performance issues for SIP/IVI.
(3) For any application embedding addresses, ALG is required. However, 
if double stateless translation (dIVI) is used, ALG is not required.

We will report the SIP/IVI testing results when it is available.

xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 26 Sep 2010 16:27:30 +0200

> initiated communication. So stateless translation should support SIP 
statefull translation is compatible with the NAT traversal techniques 
such as STUN, TURN and ICE, that should be taken into account i guess.

---

From: Tina TSOU <[email-masked]>
Date: Sun, 26 Sep 2010 22:39:55 +0800

B. R.
Tina
http://tinatsou.weebly.com

On Sep 26, 2010, at 10:27 PM, marcelo bagnulo braun wrote:

> statefull translation is compatible with the NAT traversal  
> techniques such as STUN, TURN and ICE, that should be taken into  
> account i guess.
Are there any two levels NAT traversal documents?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 26 Sep 2010 19:37:48 +0200

> Are there any two levels NAT traversal documents?
Not that i am aware of, actually, there is not a single level nat 
traversal document afaict.
But my point was that the same tools that are used to traverse NATs in 
IPv4 are useful to deal with NAT64.

Regards, marcelo