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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:v4tov6transition-
> [e-mail]] On Behalf Of Mosley, Leonard
> Sent: Wednesday, September 22, 2010 7:24 AM
> To: [e-mail]; [e-mail]; [e-mail]
> 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