Subject: 3gpp-analysis-04: Automatic tunneling inside 3GPP operator's network

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Jul 2003 06:20:22 +0300 (EEST)

Hi,

This is my last issue in the document.  This has already been discussed 
before, at least in the thread starting May 14, 2003, with subject 
"3gpp-analysis document and automatic tunneling", but without concrete 
resolution.  Perhaps rereading that discussion would be in order prior to 
starting the same debate again.

The text basically includes healthy disclaimers (based on my insistence I 
guess) why running automatic tunneling mechanisms in 3GPP operators' 
backbones is not a good idea, and dual-stack should be done instead, 
coupled with a couple of tunnels.  (Most of this is really ISP scenarios 
anyway.)

However, the text still, IMHO, uses too strong words in favor of automatic 
tunneling mechanisms, in particular in three paragraphs I've marked with a 
"*" in the text below.

I've also marked a section which might use some more description with "@":  
"if the number of IPv6 islands grow, the administrative burden of
maintaining tunnels also grows".  Correct: but isn't this a CLEAR signal 
that instead of building more tunnels you should be deploying dual stack 
between those islands?  We want an (IPv4/)IPv6 continent, not dozens of 
small islands connected with bridges!

What I want is to:
 - remove all references to the use of 6to4 (for the use of automatic 
tunneling in the 3GPP operator's core network) or IGP/BGP tunneling 
mechanisms from this document, and
 - discuss connection redundancy requirements (if any) and how they 
could be met with regular, already specified, simple methods (like running 
IPv6 routing protocols, using configured tunnneling and deploying 
dual-stack infrastructure).

=====
 3.2 IPv6 UE Connecting to an IPv6 Node through an IPv4 Network
[...]
    "IPv6 in IPv4" tunnels between IPv6 islands can be either static or
    dynamic. The selection of the type of tunneling mechanism is up to
    the operator / ISP deployment scenario and only generic
    recommendations can be given in this document.

    The following subsections are focused on the usage of different
    tunneling mechanisms when the peer node is in the operator's
    network or outside the operator's network. The authors note that
    where the actual 3GPP network ends and which parts of the network
    belong to the ISP(s) also depends on the deployment scenario. The
    authors are not commenting how many ISP functions the 3GPP operator
    should perform. However, many 3GPP operators are ISPs of some sort
    themselves. ISP transition scenarios are documented and analyzed in
    [ISP-scen], [ISP-analysis] and their future updates.

 3.2.1 Tunneling inside the 3GPP Operator's Network
                                                                                                                      
    Many GPRS operators already have IPv4 backbone networks deployed
    and they are gradually migrating them while introducing IPv6
    islands. IPv6 backbones can be considered quite rare in the first
    phases of the transition. If the 3GPP operator already has IPv6
    widely deployed in its network, this subsection is not so relevant.

    In initial, smaller scale IPv6 deployment, where a small number of
    IPv6 in IPv4 tunnels are required to connect the IPv6 islands over
    the 3GPP operator's IPv4 network, manually configured tunnels can
    be used. In a 3GPP network, one IPv6 island could contain the GGSN
    while another island contains the operator's IPv6 application
    servers. However, manually configured tunnels can be an
@   administrative burden when the number of islands and therefore
    tunnels rises. In that case, upgrading parts of the backbone to
    dual stack may be the simplest choice. The administrative burden
    could also be mitigated by using automated management tools which
    are typically necessary to manage large networks anyway.
                                                                                                                      
*   Even a dynamic tunneling mechanism, such as "6to4" [RFC3056] or an
    IGP/EGP routing protocol based tunneling mechanism [BGP][IGP],
    could be used if other methods are not suitable. Routing protocol
    based mechanisms such as [BGP] consist of running BGP between the
    neighboring router tunnel endpoints and using multi-protocol BGP
    extensions to exchange reachability information of IPv6 prefixes.

*   The routers use this information to create IPv6 in IPv4 tunnel
    interfaces and route IPv6 packets over the IPv4 network. It is
    possible to combine this with different types of tunnels.
                                                                                                                      
*   Connection redundancy should also be noted as an important
    requirement in 3GPP networks. Static tunnels on their own don't
    provide a routing recovery solution for all scenarios where an IPv6
    route goes down. However, they may provide an adequate solution
    depending on the design of the network and in presence of other
    router redundancy mechanisms. On the other hand, IGP/EGP based
    mechanisms can provide redundancy.

    "6to4" nodes use special IPv6 addresses with a "6to4" prefix
    containing the IPv4 address of the corresponding "IPv6 in IPv4"
    tunnel endpoint ("6to4" router) which performs encapsulation /
    decapsulation. When connecting two nodes with "6to4" addresses, the
    corresponding "6to4" routers use the IPv4 addresses specified in
    the "6to4" prefixes to tunnel IPv6 packets through the IPv4
    network. But if only one of them has a "6to4" address, a "6to4"
    relay must be present to perform the missing "6to4" router
    functionality for the native-IPv6 node. If we consider the "6to4"
    tunneling mechanism and the 3GPP addressing model (a unique /64
    prefix allocated for each primary PDP context), a /48 "6to4" prefix
    would only be enough for approximately 65000 UEs. Thus, a few
    public IPv4 addresses would be needed depending on the size of the
    operator.

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