[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis-04: Automatic tunneling inside 3GPP operator's network [issue 9]
Hi, Pekka et co.!
This is an issue I need to get more wg discussion. If I have not missed any e-mails, no comments on this have been given, but there was quite a long e-mail rally (mostly by Pekka & Karim) before publishing 3GPP Analysis -04.
The main points are: Pekka does not like to see automatic tunneling mechanisms in 3GPP operators' backbones and recommends dual-stack based solution coupled with a couple of tunnels. Explicitely:
- removing 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
- discussing 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).
Can anybody (Karim??) provide suggested text on the redundancy requirements on the list?
So: more wg discussion on this issue, please! But: please have a look at the older thread "3gpp-analysis document and automatic tunneling" to avoid repeating the same comments again and again and making no conclusion at all (that is unfortunately very typical in the IETF).
Cheers,
-Juha-
-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 25 July, 2003 06:20
To: v6ops@ops.ietf.org
Subject: 3gpp-analysis-04: Automatic tunneling inside 3GPP operator's
network
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