RE: (ngtrans) draft-wiljakka-3gpp-ipv6-transition-00.txt

[Phil Roberts <[e-mail]>]

> 
> Phil,

Hi Jonne,

> 
>  
> > So what is to keep a handset from operating dual stack, contacting
> > a SIP server, finding out it's communicating partner is v4, 
> > and running v4
> > to it?
> > I mean the 3g specs say this shouldn't be done, but it's a 
> > far cry from
> > saying it couldn't be done.  You will have v4 connectivity 
> capability.
> > What's
> > to force a user to use the IMS SIP anyway?
> 
> GPRS provides a general IP connectivity. Thus, it is possible 
> to do anything you want over it. 
> 
> However, the discussion was about IMS. The IMS specs say that 
> it cannot be done. I tried to explain why it shouldn't be 
> done technically bellow. In addition, because the lack of 
> IPv4 addresses, use of dual stack would not be possible 
> without IPv4 NATs.

Yes, I *think* I understand what the specs say.  So the question
becomes for the purpose of this document, what's to keep an
enterprising user/vendor from setting things up this way, and if
it's possible, do we need a scenario to cover it?

The only concrete limit seems to be the presence of NAT, but it isn't
always the case that a NAT is used.  Is the scope of the work to
include the possible cases, and see what is missing?  Or to move
toward a spec that says this is the way this *should* be done?

> 
> Cheers,
> 
> Jonne.
> 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Tuesday, July 23, 2002 7:36 PM
> > > To: [e-mail]; 
> [e-mail]
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; 
> [e-mail];
> > > [e-mail]
> > > Subject: RE: (ngtrans) draft-wiljakka-3gpp-ipv6-transition-00.txt
> > > 
> > > 
> > > Hello Luc,
> > > 
> > > if you look at 3GPP TS23.221v5.5 (can be downloaded from 
> > > http://www.3gpp.org/) in section 5.1 it says
> > > 
> > > "-The IM CN subsystem shall exclusively support IPv6.
> > >  -The UE shall exclusively support IPv6 for the connection to 
> > > services provided by the IM CN subsystem."
> > > 
> > > This means that IPv4 is out of the question for the UE, and 
> > > for the network in the case of IMS. Thus, if, for a reason or 
> > > another, the UE wishes to connect to a SIP node that is IPv4, 
> > > an SIP ALG and a user traffic translator have to be used. 
> > > (Just as a reminder for people that are not that familiar 
> > > with SIP: In SIP, the SIP signaling goes through a series of 
> > > possible SIP proxies, and servers, where the user traffic 
> > > (e.g. IP/UDP/RTP/voice) goes directly between the two SIP 
> > end-nodes.) 
> > > 
> > > There were a number of reasons why IPv6 is the only IP 
> > > version chosen for IMS. One of those was to have a simplified 
> > > set of transition scenarios. (If IPv4 would have been an 
> > > option, you would not see two transition scenarios that are 
> > > both rather unlikely - you would se many more.) 
> > > 
> > > However, to answer your question why dual stack could not be 
> > > used in a more technical fashion: Every UE would have to 
> > > support IPv4 until there would be no potential IPv4 devices 
> > > in the world. I, at least personally, think that this would 
> > > be rather unnecessary.
> > > 
> > > I also personally dislike translators. However, in this case 
> > > I think they are rather justified, because they make this 
> > > quite a bit easier.
> > > 
> > > Cheers,
> > > 
> > > Jonne.
> > > 
> > > > -----Original Message-----
> > > > From: ext BELOEIL Luc FTRD/DMI/CAE
> > > > [mailto:[e-mail]]
> > > > Sent: Tuesday, July 23, 2002 2:10 AM
> > > > To: Karim El-Malki (EAB)
> > > > Cc: Wiljakka Juha (NMP/Tampere); [e-mail];
> > > > [e-mail]; MARTIQUET Nicolas 
> > FTRD/DMR/ISS; Brian E
> > > > Carpenter
> > > > Subject: TR: (ngtrans) 
> draft-wiljakka-3gpp-ipv6-transition-00.txt
> > > > 
> > > > 
> > > > Hi all, 
> > > > 
> > > > Thanks for you answers. I'm sorry but I'm till not 
> > convinced that a
> > > > translator is needed. 
> > > > 
> > > > > "Brian E Carpenter" wrote:
> > > > > 
> > > > > "Karim El-Malki (EAB)" wrote:
> > > > > > 
> > > > > >  > 1/ IMS is IPv6-only
> > > > > >  > As far as I know IMS will be used to managed SIP 
> > signalling.
> > > > > >  > If you installed a dual-stack SIP proxy at IMS 
> border,that
> > > > > >  > proxy will be able to contact external IPv4-only proxies.
> > > > > > 
> > > > > > The dual-stack SIP proxy would need to use a SIP 
> ALG to allow
> > > > > > communication between IMS IPv6 and non-IMS IPv4 hosts 
> > > > (more below).
> > > > > >
> > > > By dual-stack proxy I was thinking about a "real" dual-stack 
> > > > proxy like
> > > > a Web server or a FTP server that can answer to IPv4 or 
> > IPv6 queries
> > > > even at application level, not just at IP level (level 3).
> > > > 
> > > > > >  >
> > > > > >  > 2/ SIP can transport IPv4 and IPv6 addresses
> > > > > >  > Moreover SIP might be compared to a DNS service as 
> > far as it
> > > > > >  > can resolve name of correspondents in addresses. 
> So even if
> > > > > >  > you send a request (or an INVITE by using SIP) by 
> > using IPv6
> > > > > >  > transport, you may receive a reply (or an ACK by 
> using SIP)
> > > > > >  > by IPv6 transport but with an answer that 
> proposes you IPv4
> > > > > >  > addresses.
> > > > > > 
> > > > > > It can only involve IPv6 addresses, that's why you would use
> > > > > > a SIP ALG as above.
> > > > > > 
> > > > 
> > > > But SIP can involve IPv4 and IPv6, can't it?
> > > > 
> > > > > >  >
> > > > > >  > I mean :
> > > > > >  > A node sends "I want to contact [e-mail]" query 
> > > > using IPv6.
> > > > > >  > Same node receives "[e-mail] is 
> > 192.168.168.192" reply
> > > > > >  > using IPv6.
> > > > > >  > Same node use then its IPv4 stack to contact 
> > > [e-mail]...
> > > > > > 
> > > > > > This is not possible since all 3GPP IMS communication 
> > > (signalling
> > > > > > and traffic) runs over IPv6 (see below). Node A would get 
> > > > > back an IPv6
> > > > > > address (e.g. PREFIX::192.168.168.192) which can be 
> translated
> > > > > > to IPv4 by a translator box.
> > > > > 
> > > > > But is there any reason that IP packet translation is needed, 
> > > > > rather than
> > > > > an application level proxy running on a dual stack? 
> > > > > 
> > > > >    Brian
> > > > > 
> > > > 
> > > > I still believe that UE can use dual-stack SIP 
> > applications. Why not
> > > > using that feature? IMS is a way to transport signalling . 
> > > > Why to modify
> > > > IP addresses inside SIP messages if UE can manage any IP 
> > > address type?
> > > > > 
> > > > > > 
> > > > > >  >
> > > > > >  > I still think that if UEs and an IMS border 
> proxy are dual
> > > > > >  > stack, no translation mechanism is needed.
> > > > > >  >
> > > > > >  > 3/ SIP signalling and data traffic must be handled by
> > > > > >  > distinct PDP contexts
> > > > > >  > Whatever you have to activate another PDP 
> context for data
> > > > > >  > traffic, why not using IPv4 in this one?
> > > > > > 
> > > > > > The different PDP Contexts you are referring to are 
> > "secondary"
> > > > > > PDP Contexts to have different L2 QoS reservations, 
> > but they use
> > > > > > either the same IPv6 address or different IPv6 addresses on 
> > > > > the same link
> > > > > > (i.e. stateless autoconfig on a /64 prefix). Therefore 
> > > > the same IPv6
> > > > > > link is used for signalling and traffic. There is a good 
> > > > > description of how
> > > > > > to map an IPv6 link to 3GPP PDP Contexts in 
> > > > > draft-ietf-ipv6-3gpp-recommend-02.
> > > > > > 
> > > > > > /Karim
> > > > > 
> > > > As far as I know, the PDP Context for data is a secondary PDP 
> > > > Context in
> > > > R5 but this can still be changed in R6, which is not frozen 
> > > (and this
> > > > addressing issue concerns R6). Anyway, here, the purpose is 
> > > to find a
> > > > native solution. You are talking about a same IPv6-only 
> > > link. But that
> > > > does not simplify IP routing, and that introduces mandatory 
> > > > SIP ALG in a
> > > > translator, instead of using native IP comunication. SIP 
> > > allows native
> > > > communications, why not using that? I believe IETF should 
> > propose a
> > > > native solution and reject unusefull translators. 
> > > > 
> > > > Regards,
> > > > 
> > > > Luc
> > > > 
> > > > 
> > > 
> > 
>