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

From: [email-masked]
Date: Wed, 17 Jul 2002 08:12:37 +0300

Hi all!

I also think that the issue is in wording and we are happy to clarify that in the next revision. :-)

We are no way prefering NAT over tunneling. Just because tunneling remains the end-to-end nature of the communication. However, translation may be needed in some cases, like in IMS scenario 1.

And about tunneling: what I meant was that if you consider GPRS scenario 2 (or actually scenario 1, where the UE has dual stack capability), I prefer doing "IPv6 in IPv4" tunneling in the network (the encapsulating node could be e.g. GGSN or edge router), not in the UE. If you make tunneling in the network, you can just activate IPv6 PDP context.

What Karim commented about the case that if a dual stack UE is connecting to a network in which the GGSN does not support IPv6, it is a relevant thing to make "IPv6 in IPv4" tunneling in the UE and just activate IPv4 PDP context. That scenario is also very shortly documented in GPRS scenario 1. 

Best Regards,
		-Juha W.-

-----Original Message-----
From: ext Erik Nordmark [mailto:[email-masked]]
Sent: 17 July, 2002 12:32
To: Karim El-Malki (EAB)
Cc: 'Erik Nordmark '; [email-masked] '
Subject: RE: (ngtrans) draft-wiljakka-3gpp-ipv6-transition-00.txt

> Maybe we need to look at the doc again to clarify this
> but we do have cases where tunnelling from the UE is preferred
> e.g. accessing IPv6-only services (i.e. IMS) when you're roaming
> into a network which only supports IPv4 connections (PDP Contexts).
> There are also cases where translation looks like the way to go
> e.g. Communicating with an IPv4 node when using an IPv6-only
> service (IMS) which mandates IPv6-only connections.
> The recommendations probably need clarifying if they give
> that impression, but regarding the tunnelling I think it was
> meant to prefer the native connection (without tunnelling or
> translation) rather than always recommending against tunnelling
> and for translation.

Thanks. In that case I think the issue is with the wording in the document.

  Erik

---

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Sun, 21 Jul 2002 03:46:06 +0200

We do need to support 3GPP IMS/SIP IPv6 hosts communicating
with, for example, IPv4 SIP hosts which are not 3GPP devices.
I agree that the solution doesn't have to be complex, but we
need to include it in the document and make sure we're
not forgetting anything. SIP ALG makes sense to me too and
that was something I was assuming.
/Karim

-----Original Message-----
From: Pekka Savola
To: Karim El-Malki (EAB)
Cc: 'BELOEIL Luc FTRD/DMI/CAE '; [email-masked] '; [email-masked] '; [email-masked] '; 'MARTIQUET Nicolas FTRD/DMR/ISS '
Sent: 2002-07-19 13:41
Subject: RE: (ngtrans) draft-wiljakka-3gpp-ipv6-transition-00.txt

On Fri, 19 Jul 2002, Karim El-Malki (EAB) wrote:
> IMS only allows IPv6 connectivity (PDP Contexts).
> It's not possible to activate an IMS IPv4 PDP Context,
> therefore we need translation for the case where an
> IMS (SIP-based) IPv6 host communicates with an IPv4 host.

Why does a **SIP-based** IPv6 host need to communicate with an IPv4
host?

You'll just open a huge can of worms wrt. NAT, etc.

Wouldn't it be much simpler to either:
 1) just add a SIP-only ALG, or
 2) (preferably) require that SIP terminals IMS talks with support IPv6?

Some people have also expressed the interest to enable being able to
call 
from IPv4-only SIP phones to IPv6 3GPP equipment.  Is this _really_ a 
problem we want to spend much time on solving?  I think the solution 
should be blindingly obvious here.

> From: BELOEIL Luc FTRD/DMI/CAE
> To: [email-masked]; [email-masked];
[email-masked]
> Cc: [email-masked]; MARTIQUET Nicolas FTRD/DMR/ISS
> Sent: 2002-07-19 01:58
> Hi all, 
> I'm happy to see a draft that proposes the use of native connection
each
> time needed.
> 
> Moreover I totally agree that UE must be dual-stack (in first phases)
> and that IPv4 connectivity (IPv4 PDP context) should not be always-on.
> 
> But, I do not feel at ease with section 4.1 (dual-stack UE) in
addition
> with section 5.2. (UE connecting to a node in an IPv4 network through
> IMS). I see a case which seems not to be addressed in the draft.
> 
> Consider a dual-stack UE with IPv6-only connectivity (because of IPv4
> addresses scarcity) that initiates a communication through IMS (with
> SIP) towards another node named C. Consider C is IPv4-only and outside
> the operator network. Don't you think that an IPv4 PDP context should
be
> initiated (by UE or network) so as to allow a native end-to-end
> connection ?
> 
> Could you help me ?
> 
> Luc
> 
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : mercredi 17 juillet 2002 07:13
> À : [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : RE: (ngtrans) draft-wiljakka-3gpp-ipv6-transition-00.txt
> 
> 
> Hi all!
> 
> We are no way prefering NAT over tunneling. Just because tunneling
> remains the end-to-end nature of the communication. However,
translation
> may be needed in some cases, like in IMS scenario 1.
> 
> And about tunneling: what I meant was that if you consider GPRS
scenario
> 2 (or actually scenario 1, where the UE has dual stack capability), I
> prefer doing "IPv6 in IPv4" tunneling in the network (the
encapsulating
> node could be e.g. GGSN or edge router), not in the UE. If you make
> tunneling in the network, you can just activate IPv6 PDP context.
> 
> What Karim commented about the case that if a dual stack UE is
> connecting to a network in which the GGSN does not support IPv6, it is
a
> relevant thing to make "IPv6 in IPv4" tunneling in the UE and just
> activate IPv4 PDP context. That scenario is also very shortly
documented
> in GPRS scenario 1. 

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Mon, 22 Jul 2002 17:45:20 +0200

> >  > >  > I mean :
 > >  > >  > A node sends "I want to contact [email-masked]" query
 > >  > using IPv6.
 > >  > >  > Same node receives "[email-masked] is 
 > 192.168.168.192" reply
 > >  > >  > using IPv6.
 > >  > >  > Same node use then its IPv4 stack to contact 
 > [email-masked]...
 > >  > >
 > >  > > 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?
 > >  >
 > > 
 > > In the answer above I was talking about translation for 
 > the traffic part as opposed
 > > to the SIP Signalling (for which a dual stack SIP ALG 
 > makes sense). For example,
 > > the 3GPP host would be sending RTP/UDP/IPv6 packets and 
 > these need to be
 > > translated to RTP/UDP/IPv4. A Translator would do this. 
 > Note that the 3GPP host
 > > can only send and receive IPv6 packets for IMS. A 
 > dual-stack RTP/UDP proxy would
 > > work but I can't see the advantages with respect to a more 
 > generic translator.
 > 
 > The advantage is that it avoids any flavour of NAT, which we 
 > want to avoid unless
 > we are absolutely forced into it. 

It also has disadvantages. For example, you need a proxy per
application and the application proxy address needs to be
configured in the 3GPP terminal. That may not be the easiest thing
to do in some terminals. I agree that translators have problems
but they do work transparently from the hosts which is an advantage
in this case. Hopefully the new work on improving NAT-PT can solve
some of them. Anyway you have a point and some text needs to be added
to the draft to discuss this.

/Karim

---

From: [email-masked]
Date: Tue, 23 Jul 2002 07:57:37 +0300

Hi,

availability of public IPv4 addresses most probably is a big issue for (at least European and Asian) mobile operators. I couldn't easily imagine a large number of "always-on" IPv4 PDP contexts.. The point is that in the longer run we really need IPv6. Use of private IPv4 addresses and NATs is not a good solution.

Let's think about an operator to put up a mobile network with, say, 50 million subscribers. There can easily be more than one primary PDP context activated per user => what would be the reply, if the operator was asking for 50 million public IPv4 addresses to be allocated for its mobile network from the authorities? And imagine 10 operators simultaneously doing the same thing.

Availability of public IPv4 addresses is also one limitation, why "IPv6 in IPv4" tunneling done in the UEs is not always so feasible - that would need a public IPv4 address allocated for each UE that makes the tunneling (assuming that the tunnel endpoint is outside the GPRS network, which often is the case).

BR,
	-Juha W.-

-----Original Message-----
From: ext Keith Moore [mailto:[email-masked]]
Sent: 22 July, 2002 21:57
To: Karim El-Malki (EAB)
Cc: 'Brian E Carpenter'; NGTRANS List
Subject: Re: (ngtrans) draft-wiljakka-3gpp-ipv6-transition-00.txt 

> If you're talking about IMS, then it's only SIP so a SIP ALG
> would suffice. If instead you mean the general case, 3GPP
> terminals will be dual-stack so they should talk IPv4
> to IPv4 peers and the same for IPv6. 

I'm confused...  how are you going to be able to get enough IPv4 
addresses for 3GPP terminals to let them use IPv4 when talking 
to IPv4 peers?

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Tue, 23 Jul 2002 11:09:57 +0200

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 [email-masked]" query using IPv6.
> >  > Same node receives "[email-masked] is 192.168.168.192" reply
> >  > using IPv6.
> >  > Same node use then its IPv4 stack to contact [email-masked]...
> > 
> > This is not possible since all 3GPP IMS communication (signalling
> But is there any reason that IP packet translation is needed, 
> rather than
>    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

---

From: [email-masked]
Date: Tue, 23 Jul 2002 16:36:16 -0700

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.

> From: ext BELOEIL Luc FTRD/DMI/CAE
> [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 2:10 AM
> To: Karim El-Malki (EAB)
> Cc: Wiljakka Juha (NMP/Tampere); [email-masked];
> [email-masked]; MARTIQUET Nicolas FTRD/DMR/ISS; Brian E
> Carpenter
> Subject: TR: (ngtrans) draft-wiljakka-3gpp-ipv6-transition-00.txt
> 
> 
> Hi all, 
>

---

From: Phil Roberts <[email-masked]>
Date: Tue, 23 Jul 2002 19:40:03 -0400

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?

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 7:36 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> if you look at 3GPP TS23.221v5.5 (can be downloaded from 
> http://www.3gpp.org/) in section 5.1 it says
> 
>  -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.
>

---

From: [email-masked]
Date: Tue, 23 Jul 2002 16:53:57 -0700

Phil,

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

Cheers,

Jonne.

---

From: Phil Roberts <[email-masked]>
Date: Tue, 23 Jul 2002 19:57:46 -0400

> Phil,

Hi Jonne,

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

> > > > Subject: TR: (ngtrans) 
> draft-wiljakka-3gpp-ipv6-transition-00.txt
> > > > 
> > > > 
> > > > Hi all, 
> > > >

---

From: [email-masked]
Date: Tue, 23 Jul 2002 17:17:32 -0700

Hi Phil,

there is something in the document that causes misunderstandings: The division between general GPRS cases, and the IMS cases. 

As the documents (both the scenarios document, and the solutions document), are specific to 3GPP we thought that in addition to the general cases (that are totally application independent), we would add the IMS case what is a bit special as it only allows the usage of IPv6. 

Though, the general GPRS scenarios do not list any specific applications (e.g. HTTP/HTML, mail, or even SIP), I think the general cases still should cover your concern - I hope. The IMS scenarios only concentrate to IMS. Thus, anything SIP that is not IMS is not there, but seen as a part of the general cases.

I hope this helps to understand the division of the document a bit better, and answers your concerns.

Cheers,

Jonne.

> From: ext Phil Roberts [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 4:58 PM
> To: Soininen Jonne (NET/MtView); Phil Roberts;
> [email-masked]; [email-masked]
> > > > Subject: RE: (ngtrans)

---

From: [email-masked]
Date: Tue, 23 Jul 2002 07:57:37 +0300

Hi,

BR,
	-Juha W.-

---

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Thu, 25 Jul 2002 17:39:22 +0200

> addresses for 3GPP terminals to let them use IPv4 when talking 

Sorry I should not have written v4 peer-to-peer since I was considering
private addresses and assumed that peer-to-peer was preferably IPv6.
That was the best case which assumed that there would be enough public
v4 addresses combined with the use of private v4 addresses for
general web-browsing etc. You and Juha are right in pointing out that
this can sooner or later be a problem too. You may also want to use the
v6 connection to communicate to non-IMS v4. So this scenario would require
more ALGs and/or app proxies. We should clarify this in the doc.

Rgds
/Karim

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Fri, 26 Jul 2002 13:23:13 +0200

Hi Jonne,

> De : [email-masked] [mailto:[email-masked]]
> 
> 
> Hello Luc,
> 
A "shall" is not a "MUST", but 3GPP might not think the same?

> (e.g. IP/UDP/RTP/voice) goes directly between the two SIP end-nodes.) 
A UE may be dual-stack. Moreover SIP can manage IPv4 and IPv6 so that just a question of architecture. IMHO there is efficient solutions for smooth IPv6 integration that IETF should propose to 3GPP. I can not accept a draft that accepts translator just because that seems more 3GPP friendly. 

> both rather unlikely - you would se many more.) 
I totally agree that UE-to-IMS relation MUST be IPv6-only, I'm just telling that:
- IMS-to-"external networks" relation SHOULD be dual-stack,
- It is possible to support native IPv4 traffic for UE-to-"external IPv4-only SIP node" user traffic.

> in the world. I, at least personally, think that this would 

My customers don't! Unfortunately, at least for Europe, I do not think that my customers are ready to turn off all their IPv4-only devices and start to use widely IPv6, even if that would simplify UMTS-base. Therefore I have to propose efficient solutions to integrate IPv6 and IPv4 in my services so as to follow my customers' requirements. 

> 
> I also personally dislike translators.
me too ;+) !

> However, in this case 
I don't ;+(
 
Regards, 
Luc

---

From: [email-masked]
Date: Fri, 26 Jul 2002 11:51:12 -0700

Hello Luc,

> A "shall" is not a "MUST", but 3GPP might not think the same?

In 3GPP "shall" is the same as "MUST" in the IETF. Thus, shall=MUST. The extract was from a 3GPP document. 

> >
> A UE may be dual-stack. Moreover SIP can manage IPv4 and IPv6 
> so that just a question of architecture. IMHO there is 
> efficient solutions for smooth IPv6 integration that IETF 
> should propose to 3GPP. I can not accept a draft that accepts 
> translator just because that seems more 3GPP friendly. 

This document is about 3GPP transition scenarios, and as such a document it is 3GPP specific. The scope of the document is not to change anything in 3GPP but to show what are the proposed transition scenarios in the 3GPP environment (which includes the IPv6 only IMS). 

> - It is possible to support native IPv4 traffic for 
> UE-to-"external IPv4-only SIP node" user traffic.

If UE-to-IMS is IPv6 only, how can it be at the same time dual-stack? 

> My customers don't! Unfortunately, at least for Europe, I do 
> not think that my customers are ready to turn off all their 
> IPv4-only devices and start to use widely IPv6, even if that 
> would simplify UMTS-base. Therefore I have to propose 
> efficient solutions to integrate IPv6 and IPv4 in my services 
> so as to follow my customers' requirements. 

I think nobody has proposed that your customers would turn off their IPv4 networks or devices. However, I would believe that those devices are not IMS capable at the moment (or actually they cannot be, because they are IPv4!) Maybe there is a misunderstanding in this discussion. Though, that the access to IMS has to be IPv6 only (which means using translators to IPv4 nodes when talking to those via the IMS). However, for other applications/services e.g. Web surfing, the UE can use IPv4. These cases are covered in the general GPRS cases of the document.

There were a lot of reasons for having IPv6 only in 3GPP when this issue was decided. One reason for it was to make the transition time shorter, and the transition itself simpler. I repeat my previous comment: If you would use dual-stack for the transition mechanism, you would have to support IPv4 virtually for ever on the terminals. As long as there is even one potential SIP IPv4 node in the world, all UEs would have to support IPv4 also. This would mean that IPv4 networks would have to be supported also. This does not really make the transition easier, does it. I agree that in many other cases NATs are not very good (especially when the both nodes have the same IP version). However, translators are a powerful, and a necessary transition mechanism when two hosts do not share the same IP version. In this case, translators are the only possible solution.

However, I would propose that the SIP device in the IPv4 network would have dual stack. To my knowledge, there are not many SIP capable IPv4 devices out there. Thus, to give a recommendation (in some other document, because it is outside of the scope of this document) that new SIP devices should have dual-stack, and some tunneling capabilities (e.g. ISATAP, DSTM, 6to4). I think this would be more achievable compared to what you are proposing.

Cheers,

Jonne.

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Mon, 29 Jul 2002 11:46:07 +0200

Hello Jonne,

> In 3GPP "shall" is the same as "MUST" in the IETF. Thus, 
> shall=MUST. The extract was from a 3GPP document. 
> 
ok thanks
> This document is about 3GPP transition scenarios, and as such 
> a document it is 3GPP specific. The scope of the document is 
> not to change anything in 3GPP but to show what are the 
> proposed transition scenarios in the 3GPP environment (which 
> includes the IPv6 only IMS). 
>
ok... It was not so clear for me, thanks. I had the feeling that IETF could give some kind of recommendations to 3GPP as in section 6 "Recommendations for transition methods in 3GPP networks and terminals", or by the draft draft-ietf-ipv6-3gpp-recommend-02.txt.
> If UE-to-IMS is IPv6 only, how can it be at the same time dual-stack? 
I am speaking about dual stack on the traffic path whereas IMS only concerns signalling. So it is not incompatible at all to imagine IPv6 only within the IMS (which solves the problem of IPv4 address exhaustion, as the users register with IPv6) with the possibility to use IPv4 when the end host requires it.
To focus on an example, in the same way as some "operating systems" acts: DNS queries can only be send over IPv4 but if DNS replies include IPv6 addresses, applications can use IPv6 transport. In a 3GPP environnement, SIP messages could be transported over IPv6, and data (media) traffic could be transported over IPv4.
> I think nobody has proposed that your customers would turn 
> off their IPv4 networks or devices.

thanks ;+)

> However, I would believe 
> that those devices are not IMS capable at the moment (or 
> actually they cannot be, because they are IPv4! Maybe there 
> is a misunderstanding in this discussion. Though, that the 
> access to IMS has to be IPv6 only (which means using 
> translators to IPv4 nodes when talking to those via the IMS). 

Here is the point I'm discussing (see above).

> However, for other applications/services e.g. Web surfing, 
> the UE can use IPv4. These cases are covered in the general 
> GPRS cases of the document.
> 

ok I 've always been agreeing with that.

> There were a lot of reasons for having IPv6 only in 3GPP when 
> this issue was decided. One reason for it was to make the 
> transition time shorter, and the transition itself simpler. I 
> repeat my previous comment: If you would use dual-stack for 
> the transition mechanism, you would have to support IPv4 
> virtually for ever on the terminals. As long as there is even 
> one potential SIP IPv4 node in the world, all UEs would have 
> to support IPv4 also. This would mean that IPv4 networks 
> would have to be supported also. This does not really make 
> the transition easier, does it.

I do not think that all UE should have to support IPv4, only those who need to access external IPv4 networks. By that way transition would be smooth. Anyway I think that it depends on business cases and deployment choices. IMHO it is a operator issue.

> I agree that in many other 
> cases NATs are not very good (especially when the both nodes 
> have the same IP version). However, translators are a 
> powerful, and a necessary transition mechanism when two hosts 
> do not share the same IP version. In this case, translators 
> are the only possible solution.
> 

As you said above, a lot of non-IMS services should be supported by 3GPP UEs, and it is likely that they will be supported on IPv4 for quite a long time. So anyway, as long as there is potential IPv4 services usefull for UE, lots of UEs will have to support IPv4 also.

> However, I would propose that the SIP device in the IPv4 
> network would have dual stack. To my knowledge, there are not 
> many SIP capable IPv4 devices out there. Thus, to give a 
> recommendation (in some other document, because it is outside 
> of the scope of this document) that new SIP devices should 
> have dual-stack, and some tunneling capabilities (e.g. 
> ISATAP, DSTM, 6to4). I think this would be more achievable 
> compared to what you are proposing.
> 

I am not sure if it is more achievable or not, but I share that point of view!

Cheers,

Luc

---

From: [email-masked]
Date: Mon, 29 Jul 2002 18:45:14 -0700

Hi Luc,

> I am speaking about dual stack on the traffic path whereas 
> IMS only concerns signalling. So it is not incompatible at 
> all to imagine IPv6 only within the IMS (which solves the 
> problem of IPv4 address exhaustion, as the users register 
> with IPv6) with the possibility to use IPv4 when the end host 
> requires it.
> To focus on an example, in the same way as some "operating 
> systems" acts: DNS queries can only be send over IPv4 but if 
> DNS replies include IPv6 addresses, applications can use IPv6 
> transport. In a 3GPP environnement, SIP messages could be 
> transported over IPv6, and data (media) traffic could be 
> transported over IPv4.

This is common misunderstanding. However, IMS is not only the signaling, but also the actual user traffic has to be IPv6. Thus, dual stack does not apply. 

> I do not think that all UE should have to support IPv4, only 
> those who need to access external IPv4 networks. By that way 
> transition would be smooth. Anyway I think that it depends on 
> business cases and deployment choices. IMHO it is a operator issue.

This discussion is a bit out of the scope of this list, but anyways. The one of the reasons why IPv6 was taken as the only version of IP was for this reason. You cannot say beforehand which terminals will need to talk to IPv4 nodes and which not! Thus, every node would have to support IPv4 because there might be the *possibility* that someone would like to contact somebody in the external IPv4 networks. Thus, it is not a deployment issue but an interoperability issue. 

Cheers,

Jonne.