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

["Thakur, Anand" <Anand.Thakur@hpsglobal.com>]

	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