RE: on NAT-PT

[Margaret Wasserman <mrw@windriver.com>]

Hi Jonne,

Thanks for the response, but maybe I'm still not getting it...

> 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.
Alright, I am with you so far.  IMS is IPv6 only.

> 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.
Okay, this is where we start to diverge.  I understand that you can 
theoretically
use SIP to signal anything.  And, there may be reasons why someone would want
to use IMS/SIP to signal an FTP session between two IMS-capable nodes (I 
can't think
of one, but I'll take your word for it).  But why would you ever want to use
IMS/SIP to signal an FTP (or other) session between an IMS-capable node and a
non-IMS-capable IPv4-only node?  What makes you think that this would work?
I don't think that most non-IMS nodes will be capable of having their FTP 
sessions
signalled through SIP.

> 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.
Right, but it is also possible to establish an IPv4 end-to-end session without
IMS/SIP signalling, right?  So, can you explain why anyone would want to use
IMS/SIP signaling to establish an arbitrary application connection with an
IPv4-only node?

> 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?)
This smacks of religion to me...  Is there some technical reason why it 
wouldn't
work to tunnel IPv4 in IPv6 over the IMS parts of the infrastructure?  Or is
this just dogma -- "No IPv4 Allowed!"?

> >
> > 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:
I don't _think_ that I'm suggesting this.  I'm suggesting that, when you
need to set-up a session with a non-IMS, IPv4-only node or service, that
you shouldn't use IMS.

> 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?
Why do we need IPv6 here?  For a dual-stack node to communicate with an 
IPv4-only
node, no IPv6 is needed.

> 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!
Well, yes.  I am actually proposing that, for now at least, all phones 
should be
dual-stack.  Eventually, when the huge majority of nodes and services are
available via IPv6, it might make sense to use NAT-PT (in the other direction)
to allow IPv6 access to legacy IPv4 servers.  But, in the meantime, I think 
that
any node that wants to connect to both IPv4 and IPv6 nodes and services
should be dual-stack.

> 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!
In _reality_ IPv4 NAT works just fine for most purposes... I'm writing to 
you from
behind one right now.

That argument aside, however...  I agree that an IPv4 network is quite 
likely to
include NAT.  This is one of several reasons why IPv6 is needed.  However,
declaring the IMS system IPv6-only will not change the fact that 3GPP providers
will need to provide some sort of IPv4 services (perhaps native or perhaps 
via IPv4
over IPv6 tunnels), and that IPv4 network is likely to include NAT.

In fact, in your example, you have replaced the IMS network NAT with NAT-PT
(not necessarily an improvement) and haven't done anything that will remove
the NAT from the non-IMS phone's network.  So, there will still be two NATs
in the path, and there will still be no way to know where they are.  Why
is it better that one of the NATs is NAT-PT?

> 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!
Maybe I'm missing something, but I still don't understand.  How can it be
better to end-up with an IPv6 <-> IPv4 translated session than to end-up with
a native IPv4 session?

> It may be that for some applications, and for old software dual-stack may 
> be a cleaner solution, though - but not in this case.
Perhaps this is one of the places we are disconnecting.  I tend to think of
the 3G "phone" as a clever little modem that will allow my PC and PDA to
connect to the Internet.  And, my PC and PDA do run old software, for
which dual-stack would be a cleaner solution...

Margaret