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

[<juha.wiljakka@nokia.com>]

Hi all!

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

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

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

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

Right?

Cheers,
	 -Juha-

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.

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