RE: on NAT-PT

["BELOEIL Luc FTRD/DMI/CAE" <luc.beloeil@rd.francetelecom.com>]

Hi Jonne and all,
> 
> Hi Margaret,
> 
> 
> 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?)
> 
...
> > 
> > 
> > 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!

I do not share your point. The question to use IPv6-only or dual-stack phone does not concern technical issues but business issues. I have the feeling its an operator issue, and to use NAT-PT may be worse (see below).

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

It depends on the service architecture. If I follow your point I could say that with NAT-PT, we are likely to have NAT-PT (or "SIP proxy+ media translator") on the IMS phone's operator's network, NAT on network of mobile operator's ISP, and NAT in the other non-IMS terminal's network. ;+(


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

NAT-PT does not solve interconnections issues with IPv4 non-IMS networks. From an IPv4-only external network, a NAT/PAT+STUN or a NAT-PT or a "SIP-proxy + media translator" behave in the same way (address advertised are not those handled by terminals).

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