Subject: RE: on NAT-PT

From: <[email-masked]>
Date: Tue, 21 Jan 2003 23:03:01 -0800

Hi Margaret,

> Why would you run IPv6 apps to talk to IPv4?  It would make much more
> sense to open an IPv4 PDP context to talk to a remote IPv4 
> host than to
> communicate over IPv6 with either proxies or translation.

I believe I have explained this very thing on this very mailing list already a couple of times. However, repeating never hurts... ;)
As said before (by Juha, and Karim, and myself) IMS is v6 only. This means that the only version of IP that can be used is the version 6. IMS consists of both the SIP signaling (SIP messages to the SIP proxies, and SIP servers), and the "media stream" either between two mobiles, or between a mobile and an IMS service. This media stream (according SIP specifications) can be virtually anything. Theoretically, you can signal with SIP a session of FTP between two nodes. In this case, the media stream would be the FTP session. The media stream is end-to-end - not hopping through proxies and servers like the SIP signaling.

These two things combined it means that the IMS mobile has to be IPv6 only when it is using the IMS to set up a session (with another mobile, a fixed node, or a server). This means that no IPv4 is permitted in any form or another. (No, not even on top of v6 as then it is still v4, right?)

> 
> >It's only for a limited
> >amount of traffic, so it's not like the plan is to have 
> millions of users 
> >sending
> >all their data through the NAT-PT. The bottom line is that IMS is 
> >IPv6-only but it
> >does not exclude other v6 applications. An IMS IPv6 PDP 
> Context can carry 
> >IPv6 SIP
> >and IPv6 non-SIP traffic but no IPv4 traffic. Since you 
> cannot send IPv4 
> >traffic,
> >some of the IPv6 non-SIP traffic needs to go through a 
> NAT-PT to talk to v4.
> >Hope it makes more sense although it's not easy to explain.
> 
> No IPv6 PDP context can carry IPv4 traffic -- IMS PDP 
> contexts are not special
> in this regard.  To send IPv4 traffic, you need to open an 
> IPv4 PDP context.
> 
> >If I'm running e.g. web browsing over an IPv6 IMS PDP Context
> >(which has a good reason as mentioned above) my 
> understanding is that you 
> >shouldn't
> >use IPv4. The reason is the good old "IMS is IPv6-only" 
> story. So there 
> >would be
> >a need for some form of translation/app. proxying 
> (dual-stack http proxy 
> >in this case).
> >Other services which are not mainstream like http would 
> require a translator
> >such as a NAT-PT. You can also use a separate IPv4 PDP 
> Context to access 
> >non-IMS
> >services such as web browsing, but if the user already has 
> an active IMS IPv6
> >PDP Context we can't and shouldn't prevent this other 
> scenario which has its
> >advantages as mentioned above.
> 
> I don't see any advantages that would outweigh the serious 
> disadvantages
> of using NAT-PT...  Why do you consider it such a problem to 
> open an IPv4
> PDP context to communicate to IPv4-only nodes and services?
> 

Let's assume for a second that what you say is true, and we start to use v4 with IMS as well. So, how would that work:

If an IPv4 node is on the other side of the communication, the IMS mobile would get the non-IMS phone's IPv4 address in the SIP signaling. You say that the IMS mobile would then get an IPv4 address and submit that to the non-IMS phone via SIP. First, where is the IPv6 here? 
Secondly, what does this mean technically for the IMS phone? It means that there has to be an IPv4 stack on the phone in case this phone calls at some point of its life to somebody that has an IPv4 phone. Thus, as long as there is a single potential node in an IPv4 network that could be contacted, all the IMS phones in the world (new or old) have to have support for IPv4!
Thirdly, there may or actually most probably will be NAT in the media path. This NAT can be either on the IMS phone's operator's network, or in the non-IMS phone's network. Most probably there will be NAT in both. The problem in v4 nat is that you don't know where it is! This means that this does not work in reality at all!

OK, the next question is how does the IMS (or better the interworking unit on the border of IMS and IPv4 world) know there is need for NAT-PT in a session. It knows as all the IMS phones are IPv6, and if there comes an invite from the IPv4 side with an IPv4 address in the SDP. It then can understand that there is a need for IPv4/IPv6 translation. How this is done, you can check from the analysis document in detail. (I guess this mail is long enough anyways).

After this I really have to conclude that NAT-PT (or actually a translator that is not NAT-PT but a subset of it) is lesser evil in dual-stack!

It may be that for some applications, and for old software dual-stack may be a cleaner solution, though - but not in this case.

Sorry about the long answer...

Jonne.

> Margaret

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Jan 2003 11:41:38 +0200 (EET)

Hello,

I think there is confusion here; let me try to clarify.

IMS is IPv6-only.  That's not up for debate.  IMS will require some
translation services (sounds like a case for ALG to me!) to access IPv4
services like VoIP (as these can't be ruled out, as I have suggested),
using IMS-specific primitives.

However, the issue I believe Margaret (and others) are trying to get to 
is, is translation (=NAT-PT) really required for _other_ services than the 
IPv6-only IMS.

That is, say, web browsing on a 3GPP device.  Or running IMAP to check
mails.  Connecting your laptop to the 3GPP device.  Or whatever.

For these, I believe, the answer is "no, you could get an IPv4 PDP context
for them without problem and avoid translation".  Right?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings