Subject: (ngtrans) RE: draft-wiljakka-3gpp-ipv6-transition-00.txt

From: [email-masked]
Date: Tue, 25 Jun 2002 20:09:55 +0300

Pekka,

thanks for your good comments! Some initial comments from me below:

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 25 June, 2002 13:03

General comment, applicable to most transition schemes:

IPv6 connectivity in Internet is currently usually more unstable, has
longer latencies, lower bandwidth, networks built using abandoned routers.  
I fear "if destination supports IPv4/6, use IPv6" is probably usually
worse than using IPv4, and thus may be impractical especially if you
require high quality connections.

 JW: this is an interesting comment - we shall discuss this in the transition draft design team. In your comment, do you assume that public IPv4 addresses are available? If not, doesn't use of private v4 addresses + NAT change this in some degree?

And then for some more significant comments on the draft:

 4.1 Dual Stack UE connecting to IPv4 and IPv6 nodes

    However, if the GGSN does not support IPv6 Access Points and IPv6
    PDP contexts, and an application on the UE needs to communicate  
    with an IPv6 node, the UE may tunnel IPv6 packets in IPv4 packets,
    using a variety of methods. This requires dual stack capability in
    the UE and also a public IPv4 address allocated to the UE. 

==> You seem to be making an unstated assumption about the publicity 
requirements.  Public IPv4 address on the UE would only be necessary IF 
the tunnel endpoint is not in the GPRS network, e.g. some device there.

 JW: Yep. We could clarify this and mention that in this case we assume that the tunnel endpoint is outside the GPRS network.

 4.2 IPv6 UE connecting to an IPv6 node through an IPv4 network      

    In this scenario, the UE is IPv6 capable, and the GPRS network is
    also IPv6 capable (it has an IPv6 capable GGSN). It is also assumed
    that the UE is not capable of tunneling. The UE will be 
    communicating with an IPv6 node that could be, for example, an 
    application server. There is no end-to-end IPv6 connectivity
    between the UE and the IPv6 node, and this is why the IPv4
    infrastructure has to be used. 

==> I think it's wrong to say there is no IPv6 connectivity between two 
IPv6 nodes even if there is connectivity through IPv4 tunneling.

Perhaps s/IPv6 connectivity/IPv6 infrastructure/ ?

 JW: This is a good point. So we could say  "IPv6 connectivity" / "IPv6 infrastructure" / "native IPv6 connectivity" instead of "end-to-end IPv6 connectivity". Which one is the best?

 4.4 IPv6 UE connecting to an IPv4 node

    NAPT-PT introduces a number of limitations that are expected to be
    magnified within the 3GPP architecture. Some of these limitations
    are listed here:

==> You don't list possibly the most important of all, NAPT-PT does not 
work (without application specific translation algorithms) for packets 
that embed the address or port in the payload of the packets.

 JW: Agreed, we will mention this in -01 revision.

    In addition, IPv6 users are expected to use delay-sensitive 
    applications provided by IMS. Hence, there is a need to minimize
    forwarding delays within the IP backbone.

==> I'm sad to state that using IPv6 as a transport in IP backbone is 
usually very unoptimal and it does not meet the requirements of the users.

 JW: any suggestions for good wording in this case?

    To perform DNS resolution in the IMS, the UE can be configured as a
    stub resolver pointing to a recursive DNS resolver. This 
    communication can happen over IPv6. However, in the process to find
    the IPv6 address of a SIP server, the recursive DNS resolver  
    may need to access data that is available only on some IPv4 DNS
    servers, see [v6namespace] and [DNSreq]. One way to achieve this is
    to make the DNS resolver be dual stack. This may work in the early 
    days of deployment, but this will be a restrictive factor in the   
    future, and thus, is not a valid assumption for the IMS.

==> Is it a restrictive factor that a network operator has to have at 
least one IPv4 address and IPv4 connectivity?  In many transition 
scenarios in sections 4.x you already require connectivity and addresses!

 JW: Maybe not a severe one...but remembering that the IMS is IPv6-only...

Before stating that as a restriction, there must be some more discussion 
on the topic.  I'm confident that this is very much of a non-issue for the 
many years.

 JW: ok.

 5.2 UE connecting to a node in an IPv4 network through IMS
          
    This scenario occurs when an IMS UE (IPv6) connects to a node in
    the IPv4 Internet through the IMS, or vice versa. This happens when
    the other node is a part of a different system than 3GPP, e.g. a   
    fixed PC, with only IPv4 capabilities. 

==> Is there something in the 3GPP infrastructure that requires that this 
has to be supported?

 JW: This is just considered as one possible scenario. At this point, I can't answer how probable this scenario might be.

==> You do not address the scalability etc. problems of this technique (as
you discussed those of v6-v4 NAPT).

 JW: Yep - we should add some text on that. As you can see, this -00 version is not yet perfect.  :-)

 5.3 Two IPv6 IMS UEs connected via an IPv4 network 

   Static "IPv6 in IPv4" tunnels configured between different IMS
    domains would also be a solution. Note that this bears some 
    similarity to the problems that 6bone users face [6BONE]. 

==> These (larger scale) problems are left unspecified, reference does not
help any.

 JW: Well, I'm not sure that we want to address 6bone problems here, so the wording is not the best possible. What I meant, was to say that the situation is similar / comparable to 6bone network.
 
More editorial ones:

1
    GPRS scenarios are the following: Dual Stack UE connecting to IPv4 
    network, IPv4 UE connecting to an IPv4 node through an IPv6
    network, IPv6 UE connecting to an IPv4 node and IPv4 UE connecting
    to an IPv6 node. Two IMS scenarios are: UE connecting to a node in
	an IPv4 network through IMS and two IPv6 IMS islands connected via
	an IPv4 network. 
	 
==> this is better written as a list like in section 4 IMO.

 JW: Agreed. The current format is not so clear to read...

 3. Brief introduction to the 3GPP network model

==> you show SGSN in the picture but do not mention it at all in the text?

 JW: this was already addressed by a private comment by Phil Roberts. What I decided to do, was to drop SGSN from this picture. It is not so relevant for "user IP layer" traffic. The UE and its default router GGSN are the most relevant ones in this case.

 4.1 Dual Stack UE connecting to IPv4 and IPv6 nodes
         
    Introduction to dual stack
 
==> I believe these should have been subparagraphs?

 JW: So you mean 4.1.X?   Why not, I try to do that, if my draft template works ok.. :-)

Thanks once more for your comments!

	-Juha Wiljakka-