RE: 3gpp-analysis-04: tunnels out of 3GPP operator's network

[<juha.wiljakka@nokia.com>]

Hi,

yep - this is an area that is somewhat overlapping with the ISP documents (and that's why we refer to ISP scenarios and analysis (when it will be published)). 

=> In my opinion, it is fine to do your proposed changes. Let's make further changes, if somebody is not happy with that. Making these changes also means removing 6to4 references from this section.

Cheers,
	-Juha-

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 24 July, 2003 11:22
To: v6ops@ops.ietf.org
Subject: 3gpp-analysis-04: tunnels out of 3GPP operator's network


Hi,

In section 3.2.2, "Tunneling outside the 3GPP Operator's Network", 
describes the case where the 3GPP operator has to obtain Internet 
connectivity through a tunnel.

My concern comes from the second-to-last paragraph:

    Usage of manually configured "IPv6 in IPv4" tunneling is sensible
    if the number of the tunnels can be kept limited. It is assumed
    that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the
    3GPP network towards the ISP / Internet should be sufficient.

This seems to be mixing issues with tunneling inside the 3GPP operator's 
network.  Why on earth would 3GPP operator have more than 10-15 configured 
tunnels *out* of its network?  This and the last paragraph would seem to 
indicate some confusion or misunderstanding.

I also see little need for the text in the previous paragraph:

                            Defining the tunnel endpoint depends on the
    deployment scenario. The authors want to avoid duplicating work and
    note here that the ISP transition scenarios are analyzed in [ISP-
    scen] and [ISP-analysis].

(How many ways can you define a tunnel end-point??)  

I'd remove the last paragraph completely (as was already mentioned in some 
other issue), and reword the two last ones to like:

    If the ISP only provides IPv4 connectivity, then the IPv6 traffic
    initiated from the 3GPP network should be transported tunneled in
    IPv4 to the ISP.

    Usage of manually configured "IPv6 in IPv4" tunneling is the 
    best approach, as the number of the tunnels outside of the 3GPP 
    network is very limited; no more than a couple of tunnels should 
    be needed.

    ISP transition scenarios are described in [ISP-scen] and 
    [ISP-analysis].

(or leave the last one out completely; it should already be addresses in 
at the start of section 3.2)

====
 3.2.2 Tunneling outside the 3GPP Operator's Network
                                                                                                                  
    This subsection includes the case when the peer node is outside the
    operator's network. In that case the "IPv6 in IPv4" tunnel starting
    point can be in the operator's network - encapsulating node can be
    e.g. the GGSN or the edge router.

    The case is pretty straightforward if the upstream ISP provides
    native IPv6 connectivity to the Internet. If there is no native
    IPv6 connectivity available in the 3GPP network, an "IPv6 in IPv4"
    tunnel should be configured from e.g. the GGSN to the dual stack
    border gateway in order to access the upstream ISP.
                                                                                                                      
    If the ISP only provides IPv4 connectivity, then the IPv6 traffic
    initiated from the 3GPP network should be transported tunneled in
    IPv4 to the ISP. Defining the tunnel endpoint depends on the
    deployment scenario. The authors want to avoid duplicating work and
    note here that the ISP transition scenarios are analyzed in [ISP-
    scen] and [ISP-analysis].

    Usage of manually configured "IPv6 in IPv4" tunneling is sensible
    if the number of the tunnels can be kept limited. It is assumed
    that a maximum of 10-15 configured "IPv6 in IPv4" tunnels from the
    3GPP network towards the ISP / Internet should be sufficient.

    On the other hand, usage of dynamic tunneling, such as "6to4", can
    also be considered, but scalability problems arise when thinking
    about the great number of UEs in the 3GPP networks. The specific
    limitation when applying "6to4" in 3GPP networks should also be
    taken into account, as commented in 3.2.1. Other issues to keep in
    mind with respect to the "6to4" mechanism are that reverse DNS is
    not yet completely solved and there are some security
    considerations associated with the use of "6to4" relay routers (see
    [6to4SEC]). Moreover, in a later phase of the transition period,
    there will be a need for assigning new, native IPv6 addresses to
    all "6to4" nodes in order to enable native IPv6 connectivity.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings