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

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 18 Nov 2003 15:50:31 +0100

As you pointed out the 3gpp-analysis draft addresses these
issues and I have no problems with that. It points to the
work to be done in SIPPING and says that such a solution
could reuse parts of NAT-PT.

IMO this discussion concerns the nat-pt applicability draft.
The outstanding issue is the understanding behind the NAT-PT
applicability draft which contains different wording. I proposed
to solve it by putting in alternative wording (in the nat-pt draft)
referring to the work that will be done in SIPPING which, as you
write below, could reuse parts of NAT-PT. That would make the
IMS parts of the nat-pt applicability draft more similar to the
3gpp-analysis draft.

/Karim

 > 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: [email-masked] [mailto:[email-masked]]On
 > Behalf Of ext Pekka Savola
 > Sent: 18 November, 2003 00:22
 > To: Suresh Satapati
 > Cc: Karim El-Malki (HF/EAB); 'Randy Bush'; [email-masked]
 > 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
 > 
 >

---

From: Jasminko Mulahusic <[email-masked]>
Date: Tue, 18 Nov 2003 16:23:40 +0100

> could reuse parts of NAT-PT.

i have a question to the wg chairs and/or ad:s:

do you plan to deprecate nat-pt before the work (ims-translator) has 
been finished in the sipping wg?

thanx!

jasminko

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Nov 2003 14:35:15 +0200 (EET)

> been finished in the sipping wg?

I believe it's too early to plan either deprecating or embracing
NAT-PT.

HTH..