Subject: comments : draft-ietf-v6ops-3gpp-analysis-00.txt

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Fri, 13 Dec 2002 09:58:20 +0100

Hi Juha, 

Thanks to have update the draft !

I still have the same comments on 4.2 paragraph. 

1- a UE that uses IMS services must contact IMS devices over IPv6
(because IMS is IPv6-only). I agree.
2- Nevertheless a UE that uses IMS services could also be dual-stack
(even if it does not use its IPv4 stack to contact IMS devices)
3- As pointed out in section 2.2 and 3.1, DSTM could also be used so as
to send IPv4 datagrams over IPv6 in IPv6 PDP Contexts.
4- when that dual-stack UE is connecting to an IPv4-only node in a
IPv4-only network through IMS, I argue that NAT-PT can be avoided by
using DSTM.

I understand that DSTM might not be easy to set-up inside 3GPP networks
but that is an alternative to NAT-PT. 

Perhaps that 3GPP does not want that such transition mechanisms involve
UE but only network ?

Regards,

Luc

---

From: <[email-masked]>
Date: Fri, 13 Dec 2002 12:20:59 +0200

Hi, Luc!

Thanks for your comments!  However, the UE really must be IPv6-only to the IMS direction. IMS case 1 can not be solved using DSTM - that solution would be "dual stacked" to the IMS direction.

Of course, otherwise the mobile can be dual stack. IPv4 stack can be used for e.g. Internet access / web surfing (using a separate IPv4 PDP context), i.e. for non-IMS-related traffic.

Best Regards,
	           -Juha-

-----Original Message-----
From: ext BELOEIL Luc FTRD/DMI/CAE
[mailto:[email-masked]]
Sent: 13 December, 2002 10:58
To: Wiljakka Juha (NMP/Tampere)
Cc: V6ops (E-mail)
Subject: comments : draft-ietf-v6ops-3gpp-analysis-00.txt

Hi Juha, 

Regards,

Luc

---

From: <[email-masked]>
Date: Sun, 15 Dec 2002 16:17:34 +0200

Hi, Anand!

-----Original Message-----
From: ext Thakur, Anand [mailto:[email-masked]]
Sent: 13 December, 2002 06:01

>One thing is that the selection of the type of tunneling mechanism is up to
the operator/ISP     >deployment scenario and we can only give generic
recommendations in our draft. 

Yes,i agree that we are not authorized to mandate a particular
tunneling/translation mechanism to the operator. But still don't you think
that if different operators have faith in different transition mechanisms
then compatibility may be a major issue?

 JW: I can see your point.. I also think that there are all too many alternatives available at the moment - at least I would be confused as an operator if I had to select from all the currently available alternatives. This is why I see this scenario / analysis work important. I think that a compact transition toolbox (including a couple of basic mechanisms) is needed to solve the transition scenarios - compatibility / interoperability must not be forgotten.

>A counter question: what kind of tunneling mechanims would you recommend?

I still insist that we need to come up with a tunneling mechanism that is
perfect. Whether that means rectification/modification of an existing method
or introduction of a new method. Since transition mechanisms have not yet
been deployed at a large scale, i don't think it is too late to introduce
(if required i.e.)a new tunneling mechanism. Anyway, i feel that if can do
away with NA(P)T-PT problems, atleast 80% of the job will be done.

 JW: Yep, we are in an early phase and can not clearly see yet which mechanisms are going to win. A good thing to be remembered is that the v6ops charter does not currently include specifying new transition mechanisms, at least not before the design team studies are completed.

Cheers,
	 -Juha-