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

From: "Thakur, Anand" <[email-masked]>
Date: Thu, 12 Dec 2002 16:00:39 +0530

Hi juha,
	First of all congratulations on a well compiled draft. The draft is
very close to completeness and covers all mobile IPv6 transaction scenarios.
We (Mr. Ajay Jain and myself) have gone through your draft and have the
following (general) comments:

	1)
	 Apart from the fact that na(p)t-pt issues are magnified in a 3gpp
network, the cases dealt  with here  would exist anywhere and   everywhere
when deployment of v6 gathers momentum.

	2)
	 > In most 3GPP scenarios it is preferred to use manually configured
tunnels or EGP/IGP based tunneling mechanisms.

	I am not sure if manually configured tunnels will provide a good
solution
	in the years to come .  Especially when ipv6 ONLY  sites start to
mushroom 
	all over the place,  it will be extremely difficult (and probably
not 
	worthwhile) to manage such a great number of manually configured
tunnels. In
	fact the earlier part of this section does state that manually
configured tunnels may not provide a 
	long term solution. Then, why is it later on mentioned that such
tunnels are preffered?
	Personall,  i don't think we should go for short term solutions.

	3) (3.3)
	>Therefore, overall, the transition scenario involving an IPv4 UE
communicating 
	>with an IPv4 peer through an IPv6 network is not considered very 
	>likely in 3GPP networks. 
	     
	 I  totally agree to this .

	4)
	> (3.4) IPv6 UE connecting to an IPv4 node

	   This will probably be the most prevalent scenario in the initial
stages and yet we don't have a concrete solution to deal with this.
na(p)t-pt is far far from perfect.
	I  strongly recommend (as in 3.4) the usage of application proxies,
especially considering the fact that a user will mostly be concerned with
services like http,ftp,telnet and mail related protocols, the proxies for
which can be easily implemented at the Gi interface.
	As far as na(p)t-pt is concerned,
	this section basically is trying to say that na(P)t-pt has a lot of
drawbacks. so basically progress will be done 
	only when a solution to these problems (especially concerning nat-pt
dns-alg ) are found.
	    
	5)
	>the NAT-PT issues should be clearly 
	>documented in an RFC in the v6ops Working Group
	     
	I agree and it is a matter that requires immediate attention i.e if
we want v6 to be deployed soon.
	   
	6)
	> An alternative solution could be a general network address 
	> translation mechanisms such as NAT46 [NAT64].
	    
	 I  think a little more work should be done on NAT46 to sort out any
drawbacks that it might have because as  I  see it ,  nat46 may be the only
solution to issues concerning na(p)t-pt v4->v6.
	    
	7)
	This draft clearly (may be that is not the main purpose) points out
that all tunneling and/or translating mechanisms in existence today are far
from perfect. The most difficult part is when neither of the hosts is dual
stack. so, it would be only logical to first find a transition mechanism
(whether it's tunneling or translation) that:
	    1) scales well 
	    2) practicable whether there are small islands of v6 in a v4
ocean or vice-versa  and,  
	    3) preferably can be implemented in all or atleast most of the
scenarios mentioned in this draft.

	best regards

Anand Thakur
HCL Perot Systems
A-14 Sector-57,Noida
tel ext. - 3257
mobile:9811748512

---

From: <[email-masked]>
Date: Thu, 12 Dec 2002 14:05:01 +0200

Hi, Anand!

-----Original Message-----
From: ext Thakur, Anand [mailto:[email-masked]]
Sent: 12 December, 2002 12:31

 JW: Thanks! Good comments are always useful! :-)

1)

 JW: Yep, I also think that those issues are universal, not depending on the access network type etc. One thing is that 3GPP networks will have a very big number of nodes (terminals).

2)

I am not sure if manually configured tunnels will provide a good
solution in the years to come .  Especially when ipv6 ONLY  sites start to
mushroom all over the place,  it will be extremely difficult (and probably
not worthwhile) to manage such a great number of manually configured
tunnels. In fact the earlier part of this section does state that manually
configured tunnels may not provide a long term solution. Then, why is it later on mentioned that such
tunnels are preffered? Personall,  i don't think we should go for short term solutions.

 JW: I agree that we should use solutions that are future proof. 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. A basic question is how many tunnels we need to set up - if the number is not so big (e.g. one tunnel to IPv6 Internet, etc.), it is no problem setting up manually configured tunnels in the network. It is good to remember that use of automatic tunneling (e.g. 6to4) in very big networks is not trouble-free either. Anyway, text in this section may need some edits. A counter question: what kind of tunneling mechanims would you recommend?

4)
> (3.4) IPv6 UE connecting to an IPv4 node

his will probably be the most prevalent scenario in the initial

 JW: Use of application proxies (when possible) is not a bad idea at all. But in the cases like IMS scenario 1 we need also IP level protocol translation. As commented in our draft, NAT-PT problems should be well understood & documented. After that we should see what can be done to those problems. 
	   
6)

 JW: Alain, I think this comment is for you..  :-)
	    
7)

 JW: Yep, one main goal in this exercise is to see what existing tr. mechanisms are usable for 3GPP scenarios and document any gaps. Pointing out possible problems in the existing mechanisms also includes in this work. However, we are not going to specify any new mechanisms. We don't need just one or two mechanisms that would fit in all cases, but it would be nice to have a compact set of solutions (let's call it transition toolbox) that the operators could use making IPv6 to go full speed ahead.  

 Thanks again for your comments!

	-Juha W.-

---

From: "Thakur, Anand" <[email-masked]>
Date: Fri, 13 Dec 2002 09:30:53 +0530

Hi Juha,

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

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

Anand Thakur
HCL Perot Systems
A-14 Sector-57,Noida
tel ext. - 3257
mobile:9811748512