Subject: 3gpp transition solutions, revision -02

From: <[email-masked]>
Date: Tue, 5 Nov 2002 13:02:31 +0200

Hi all,

a new version of the 3GPP (cellular) network design team solutions draft is available here:

http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-02.txt

All comments are appreciated a lot.

Cheers,
	-Juha W.-

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Tue, 5 Nov 2002 18:47:41 +0100

hi all, 

1- You'll find me boring but I'd prefer not to see in section 4.2 that a S-CSCF could be dual-stack. To my mind that would mean that IMS would not be IPv6-only anymore?! 

ref. section 4.2
"If the S-CSCF is dual stack capable, the ALG 
    specific functions can be done in the S-CSCF directly, i.e. 
    changing the SIP message headers, and the SDP payload. "

2- I'm till ill at ease will the fact that NAT-PT is till the only solution mentioned even if that solution is none to be not enough efficient. Is IETF allowed to propose 3GPP other solutions ? How to do that ?

Regards, 

Luc

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]]
> Envoyé : mardi 5 novembre 2002 12:03
> À : [email-masked]
> Objet : 3gpp transition solutions, revision -02
> 
> 
> 
>  Hi all,
>

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 5 Nov 2002 19:53:04 +0100

> 2- I'm till ill at ease will the fact that NAT-PT is till 
  > the only solution mentioned even if that solution is none 
  > to be not enough efficient. Is IETF allowed to propose 3GPP 
  > other solutions ? 

=> Sure.

  How to do that ?

=> You have to have a solution first :)
There were several discussions about taking the 
ALG out of NAT-PT, but we don't have a WG doc.

Hesham

---

From: <[email-masked]>
Date: Wed, 6 Nov 2002 13:34:19 +0200

Hi, Luc!

1) As 3GPP specification TS 23.221 v.5.5.0 says:

"The UMTS/GSM architecture shall support IPv4 / IPv6 based on the statements below.
- IP transport between network elements of the IP Connectivity services (between RNC, SGSN and GGSN) and IP transport for the CS Domain: both IPv4 / IPv6 are options for IP Connectivity
-IM CN subsystem elements (UE to CSCF and the other elements e.g. MRF):
	- The architecture shall make optimum use of IPv6.
	- 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.
..."

=> IMS *is* IPv6-only for both UE - CSCF and IMS internal interfaces. Yep, the text is just an "if" statement and in my opinion could be removed from the solutions doc.

2)

Well, can you suggest something? As Hesham pointed out, there should be a standardized solution to be proposed to the 3GPP. I would like also to remind that our design team aims not to specify new transition mechanisms or propose changes to 3GPP specs. We just make a "gap analysis" on the exisiting transition tools and their usability in 3GPP environment. And we will report our findings to the v6ops wg.

NAT-PT does have issues, the issues pointed out in section 3.4 are relevant in chapter 4 as well. The issues discussed in v6ops Interim meeting can be found in "3GPP breakout report"
http://www.6bone.net/v6ops/minutes/default.htm 

BR,
	-Juha-

-----Original Message-----
From: ext BELOEIL Luc FTRD/DMI/CAE
[mailto:[email-masked]]

ref. section 4.2

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Wed, 6 Nov 2002 17:52:55 +0100

> ALG out of NAT-PT, but we don't have a WG doc.
Alain Baudot reminds me that some have already outlined the possibility to use tunneling mechanisms (+ ROHC to optimize performances) so as to solve the issue:
-> dual-stack UE connecting to a node via an IPv4 network through IMS

That could be easily an IETF solution but I do not think that 3GPP proposes any mechanism to allocate IPv4 address when required, does it ?

Luc

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 6 Nov 2002 20:30:00 +0100

> Alain Baudot reminds me that some have already outlined the 
  > possibility to use tunneling mechanisms (+ ROHC to optimize 
  > performances) so as to solve the issue:

=> In theory, yes. But we need to get an IP n IP profile
for ROHC. Pretty easily done. 

  > -> dual-stack UE connecting to a node via an IPv4 network 

=> ok. That's what ISATAP gives us.

    I do not think 
  > that 3GPP proposes any mechanism to allocate IPv4 address 
  > when required, does it ?

=> Yes, it does. They're defined in TS.23060.
Ideally you don't want to run too many PDP contexts, 
they take time and add significant state to GGSNs and 
terminals. 

Hesham

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Thu, 7 Nov 2002 14:10:13 +0100

Thanks a lot for all our remarks,

> for ROHC. Pretty easily done. 

ok, and that sounds better than using translation mechanisms.
 
> => ok. That's what ISATAP gives us.

Yep, ISATAP is one of tunneling solutions.

> they take time and add significant state to GGSNs and 

I've just tried to check that big document (TS.23060). But I did not find your point. Anyway, if you say that is possible, I think that this case and solution (dual-stack UE connecting to a node via an IPv4 network through IMS) should be mentioned in:
draft-ietf-v6ops-3gpp-cases-00.txt and draft-wiljakka-3gpp-ipv6-transition-02.txt

Do you agree?

regards,
Luc

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 7 Nov 2002 17:52:02 +0100

> I'm sad now ;+)
  > 
  > Even if I will own a dual-stack UE, I won't be able to 
  > communicate with my IPv4 stack if that communication was 
  > initiated through IMS :+(. I'll be forced to use my IPv6 
  > stack and go through a surely less efficient translation 
  > mechanism (in comparison with native end-to-end IPv4).
  > 
  > I can not agree with that.

=> ok fair enough. But please understand that this decision
(IPv6 only in IMS) was taken by 3GPP about 2 years ago and 
the specs are frozen. We are working within 3GPP specs.

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 7 Nov 2002 17:58:47 +0100

> > => Sorry, I don't think this has anything to do with replacing
  > > translation. We're talking about two different cases. I was
  > > trying to explain that tunnelling overhead, over the air interface
  > > can be removed with ROHC. That doesn't mean that IPv6 UEs will
  > > not talk to IPv4 UEs.
  > 
  > What is the plan for apps that are broken by NAT? 

=> Broken by NATv4 or NAT-PT or both? If both, then 
there is no difference.

Won't the
  > supported apps be relatively few, and better handled by dual stack
  > application proxies than by NAT-PT?

=> I'm sure there will be application proxies for 
well-known and popular apps (HTTP, email ...etc), but not for 
every single one. 

I understood that the discussion was focused on IMS
signalling for p2p apps. 3GPP mandates that this
be done using IPv6. The good thing about that is 
that it encourages IPv6 deployment and thanks to this
decision every phone vendor will support v6, if they
haven't already. 

As for availability of apps on NAT-PT, this is probably
getting a bit speculative for me. I don't know if it's
too difficult to port the NATv4 ones to NAT-PT, but anyway
if I have to guess I would say that if there is enough demand, 
I'm sure it will be done. 

Hesham

---

From: <[email-masked]>
Date: Fri, 8 Nov 2002 14:17:56 +0100

> This means that IMS itself has no interworking problems, no 
> NATs, no NAT-PTs, and no IPv4 - it is only IPv6. Thus, there 
> are no problems inside the IMS. The NAT-PT would come to the 
> picture if, for instance, you have to place a call to another 
> "system" that does not support v6. (It may be that you have 
> to do another kind of translation as well, e.g. SIP to H.323, 
> or SIP to ISUP, or whatever.) 
> 
> (BC) And if that is the case, the IWU that does this 
> translation can be dual
> stacked, with its IPv6 stack talking to IMS and its IPv4 stack talking
> to the legacy system. If you do that, NAT-PT isn't needed.
> 

that will take care of the signalling part. you still need a box to translate the media flow, which is not going through the ims.

jasminko

---

From: <[email-masked]>
Date: Fri, 8 Nov 2002 14:44:32 +0100

> => IMS *is* IPv6-only for both UE - CSCF and IMS internal 
> interfaces. Yep, the text is just an "if" statement and in my 
> opinion could be removed from the solutions doc.

ims _is_ v6 only. i suggest you remove it. it's only confusing. thanx!

jasminko

---

From: <[email-masked]>
Date: Fri, 8 Nov 2002 14:24:09 -0800

> ims _is_ v6 only. i suggest you remove it. it's only confusing. thanx!

Yes, sorry about it.

Cheers,

Jonne.
--------
Jonne Soininen
Nokia

Tel. +1 650 864 6794
Cellular: +1 650 714 7733
Email: [email-masked]

---

From: <[email-masked]>
Date: Fri, 8 Nov 2002 17:55:47 -0800

Hi Brian,
> to the legacy system. If you do that, NAT-PT isn't needed.

OK, for the SIP signalling part you have to use an IWU (or a NAT-PT with a SIP ALG, which I guess would be the same thing, right?). As Jasminko pointed out there is also the "media stream" (SIP only negotiates the session e.g. VoIP - the data goes end-to-end). There NAT-PT (or a mutation of that) could be used.

> > In addition, you end up having a dual-stack in your phones 
> until the end of time or to the point where the last 
> _possible_ IPv4 device in the world would be extinct! These 
> are just some of the reasons why 3GPP decided to have IPv6 only IMS.
> 
> (BC) Which was an excellent decision.

I think so too!

> 
> Now, what's the answer to Keith's point below? 
> 

If I got it right, the question was if NAT-PT is sufficient. No, you need application level gateways in many cases (like in your IWU). But this is "business as usual" in NATed environments. Though, I hope the NAT-PT for the media stream can be pretty basic.

Cheers,

Jonne.

>   Brian
> > > From: ext Keith Moore [mailto:[email-masked]]
> > > Sent: Thursday, November 07, 2002 9:21 AM
> > > To: BELOEIL Luc FTRD/DMI/CAE
> > > Cc: Brian E Carpenter; Hesham Soliman (EAB); [email-masked]
> > > Subject: Re: 3gpp transition solutions, revision -02
> > >
> > >
> > > > For SIP-based services an application proxy is not sufficient.
> > >
> > > and NAT-PT is sufficient?  from my limited knowledge of SIP I
> > > find this
> > > surprising.
> > >
> > > however I don't see a huge problem with using NAT-PT only for
> > > a specific
> > > set of well-defined services on networks with known 
> characteristics;
> > > presumably it can be adapted as needed to accomodate 
> those services.
> > >
> > > the imposition of NAT-PT on other services is of course a
> > > separate question.
> > >
> > >
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter 
> Distinguished Engineer, Internet Standards & Technology, IBM 
> On assignment at the IBM Zurich Laboratory, Switzerland
> 
>

---

From: <[email-masked]>
Date: Fri, 8 Nov 2002 18:13:23 -0800

Hi Luc,

> Here is my last point, 
> IMS is IPv6-only ok, but IMS is a set of SIP servers.
> SIP is a control protocol that can initiate IPv4-based or 
> IPv6-based flows.
> But 3GPP specs have constrainted nodes, that use IMS SIP 
> server services, only to use IPv6 (signalling + communication 
> flows). The communications initiated by IMS (SIP) are not 
> intend to go through IMS (routing is different).
> 

IMS is not only the SIP server, etc. It comprises the whole system. That is why the media stream between the nodes is actually part of IMS as well.

> So, consider I'm using IMS services, even if:
> - I have a dual-stack node,
> - I have sufficient IPv4 public addresses (some areas are 
> still not constrainted)
> - I may just need private IPv4 address (its depends of your 
> architectures)
> - SIP protocol is efficient enough to allow you to open IPv4 
> and/or IPv6 communications,
> I can not use IPv4.
> 
> So why not using DSTM + ROHC ?

Because then you would be using IPv4 as well, and you would have to have IPv4 on your terminal. 

> Just a comment:
> A transition mechanism (whatever it is) would be necessary 
> until I wanna offer services towards other IPv4-only SIP-based system.

Yes.

> Moreover, I think that dual-stack phones are usefull to use 
> IPv4-only services not based on IMS, and those services may 
> not be disregarded. 

That is why we have the different scenarios (this is under the general scenarios). IMS is IPv6 only, but if you want to have, for example, a connection to your intranet that is IPv4 you can. However, the intranet is not part of the IMS.

Cheers,

Jonne.

> > De : [email-masked] [mailto:[email-masked]]
> > 
> > Hi,
> > 
> > sorry to step into the discussion so late. (I had computer 
> > trouble for a while!)
> > 
> > I would like to remind everybody that as IMS is _exclusively_ 
> > IPv6, and the NAT-PT (or a flavor of that) is just an 
> > interworking solution to a non-IMS network that supports IMS 
> > like services. (Confusing enough?;)
> > 
> > or SIP to ISUP, or whatever.) The NAT-PT would be an 
> > interworking function to an outside world - not an internal part!
> > 
> > People seem to write all the time that with dual-stack you 
> > can fix the interworking problems of IMS. That however is not 
> > true, because you end up with normal NAT for your IPv4 
> > connections. You cannot get (at least in certain areas of the 
> > world) enough IPv4 addresses to even support it as an 
> > interworking method and to have global addresses. In 
> > addition, you end up having a dual-stack in your phones until 
> > the end of time or to the point where the last _possible_ 
> > IPv4 device in the world would be extinct! These are just 
> > some of the reasons why 3GPP decided to have IPv6 only IMS.
> > 
> > Anyways, the 3GPP specifications (as Hesham pointed out) now 
> > say that this network/system, the IMS, is exclusively IPv6. 
> > We cannot change the specs, and there is no reason for 
> > changing them - the contrary. I would propose that we 
> > concentrate now on solving the problem instead of changing 
> > the problem.
> > 
> > Cheers,
> > 
> > Jonne.
> > 
> > 
> > 
> > > presumably it can be adapted as needed to accomodate those 
> > services.  
> > >