RE: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty for 3GPP]

[Suresh Satapati <satapati@cisco.com>]

Juha,

> I think there aren't any major open issues considering documenting this case in 3GPP Analysis
>
> - we state clearly, that "dual stack" based solution is not feasible and a translator is needed as a part of the solution
>
>     "As the IMS is exclusively IPv6 [3GPP 23.221], translators have to
>     be used in the communication between the IPv6 IMS and legacy IPv4
>     hosts, i.e. making a dual stack based solution is not feasible.
>     This section aims to give a brief overview on how that interworking
>     can be handled."

Agreed.

>
> - we document a higher level solution and refer to SIP(PING) wg to make a generic solution
>
>     "This section presents higher level details of a solution based on
>     the use of a translator and SIP ALG. [3GPPtr] provides additional
>     information and presents a bit different solution proposal based on
>     SIP Edge Proxy and IP Address/Port Mapper. The authors recommend to
>     solve the general SIP/SDP IPv4/IPv6 transition problem in the IETF
>     SIP wg(s)."

Consider a slight rewording here.

s/"general SIP/SDP IPv4/IPv6 transition"/"SIP/SDP signalling"/

And add:

  NAT-PT header translation mechanism may be used in conjunction with
  the [3GPPtr] mechanism. NAT(P)T-PT will perform header translation,
  using the binding supplied by [3GPPtr].

>
> - because NAT-PT is the closest possible (=PS RFC) solution to be used in this "Interworking Unit" as a translator, we state:
>
>    " We call the combined network element on
>     the edge of the IPv6-only IMS an "Interworking Unit" in this
>     document. A SIP-specific translation mechanism, which could e.g.
>     re-use limited subsets of NAT-PT [RFC2766], needs to be specified.
>     The problems related to NAT-PT are discussed in appendix A. "

Replace

      A SIP-specific translation mechanism, which could e.g.
     re-use limited subsets of NAT-PT [RFC2766], needs to be specified.

with

     A SIP-specific mechanism to handle signalling traffic, that would
     work in conjunction with NAT-PT [RFC2766], needs to be specified.

>
> - Finally, I think that documenting this case in 3GPP Analysis is important and details must not be dropped.
>
> Right?

Yep !
>
> P.S. I still can't understand what can be so horribly bad in NAT-PT, but let's not start that discussion using this mail thread, because it isn't a 3GPP-specific problem.

Same here..

Thanks
Suresh

>
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of ext Pekka Savola
> Sent: 18 November, 2003 00:22
> To: Suresh Satapati
> Cc: Karim El-Malki (HF/EAB); 'Randy Bush'; v6ops@ops.ietf.org
> Subject: Re: 3gpp-analysis: IMS/SIP transition [RE: NAT-PT Applicabilty
> for 3GPP]
>
>
> On Mon, 17 Nov 2003, Suresh Satapati wrote:
> > > Yes, but then again, you don't need DNS-ALG in the v4<->v4 NAT, because
> > > the destination address families are the same.  On the other hand, you
> >
> > I am afraid you are *wrong*.
> >
> > DNS-ALG is not used *merely* for translation between address families.
> > DNS-ALG is used to translate addresses contained in PTR queries and any addresses
> > in DNS responses (like Answer, Additional RRs). The translation could be
> > be replacing a private (rfc 1918) address w/ a public address.
>
> Again, it is not required.  Many NAT boxes do implement this, but many
> others do not.  IPv4 NAT is fully functional without a DNS ALG.
>
> > This has been extended to v6<->v4, where an IPv6 address is being
> > replaced w/ an IPv4 one.
>
> Right, but you cannot implement NAT-PT without DNS-ALG, or something to
> replace the functionality (whereas with v4 NAT, there is no need for the
> functionality).
>
> > > Instead, we should defer the problem to a SIP working group (SIPPING?) to
> > > figure out.. because *they* will be using SIP for interaction, and they
> > > know best which kind of solution they'd need (whether based on NAT-PT or
> >
> > No concerns on defering the problem to SIP folks, as long as we agree what
> > the problem is. If the problem is figuring out the bindings during SIP
> > signalling through an external mechanism, then yes I agree. That is all to
> > the problem.
> >
> > Defining a translator that uses those bindings to do header translation
> > has already been defined in RFC2766. SIP wg. should not invent another
> > one.
>
> I'm not sure actually what the problem is.  All it is that folks think
> that an optional mechanism for v6-only SIP <-> IPv4 SIP should be
> specified.  I don't personally care much for the details, but the SIP
> folks probably know better which kind of tool might solve the problem.  If
> it's sufficiently close to NAT-PT, why not reuse parts of it and specify
> something to create the mappings; if not, maybe it's worth doing something
> else.  I just don't think this WG is the right place to define that.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>