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

[<juha.wiljakka@nokia.com>]

 Hi, Anand!

-----Original Message-----
From: ext Thakur, Anand [mailto:Anand.Thakur@hpsglobal.com]
Sent: 12 December, 2002 12:31

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:

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

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.

 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)

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

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

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

 JW: Alain, I think this comment is for you..  :-)
	    
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.

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