Subject: 3gpp-analysis-04: The use of 6to4

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Jul 2003 12:36:57 +0300 (EEST)

The first issue of today.

--8<--

In the document, the use of 6to4 is mentioned several times.  However, 
this method needs some scoping: IMHO, it is clear that 6to4 is not a 
useful approach for ISP-like networks, so it is not useful to recommend 
that 3GPP networks use it for example for Internet connectivity.  It is 
just so much easier to get a configured tunnel or native IPv6 from the 
upstream providers.  You just can't build a service like 3GPP networks 
intend to using 6to4; for some internal piloting, etc. it may be possible, 
yes, but that's mostly outside of the scope of the document (but could be 
mentioned for completeness if enough folks feel like it).

The text in the document is already healthily skeptical of 6to4's 
usefulness in this context, but I fail to see:

 - clear need for the existance of 6to4 here at all, and
 - sufficiently clear disclaimers why 6to4 is *NOT* the right solution for 
3GPP networks.

Note: this issue does not specifically address the document's suggestion
to use 6to4 in the UE's, independent of the 3GPP operator.  That'll be
dealt with in the next issues.

The text snippets below are the important ones:
-----
 3.2.1 Tunneling inside the 3GPP Operator's Network
[...]                                                                                                       
    "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. 

[note: could split to two paragraphs around here, the paragraph is both 
the 6to4 introduction and 3GPP application]

                                             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.

 3.2.2 Tunneling outside the 3GPP Operator's Network
[...]                                                                                                       
    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.
-----

At least, add a new paragraph at the end of 3.2.2:

    In consequence, the use of 6to4 to enable IPv6 connectivity to a part 
    or parts of the 3GPP network is strongly discouraged; configured 
    tunneling or preferably native IPv6 connectivity is preferred.

The end of the paragraph of 3.2.1 is also confusing things: tunneling 
inside the operator's network ("replacement for BGP tunneling"; as 
described in section 2.4.3 of draft-savola-v6ops-6to4-security-02.txt but 
IMHO a bit bad practice) -- and addressing the needs of the 3GPP UE's 
(pun intended).  If you want to only use 6to4 internally, you can't deploy 
6to4 addresses on the UE's.  If you wan to use it externally, the 
considerations in the next section step out.

So, I think at least the end of the last paragraph of section 3.2.1 should 
be removed/reworded.

I also fail to see a strict need for the 6to4 introduction (the first part 
of the paragraph in 3.2.1) here, at least at this point.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jul 2003 09:18:33 +0200

6to4 was designed as a technique to ride over the networks
of ISPs who don't support IPv6 natively, so I have to agree
with Pekka *except* perhaps in the case of a 3G operator who
decides not support IPv6 (such operators are rumoured to exist).
In that case, host-based 6to4 might just have some applicability,
but the scenario would need to be described very precisely.

    Brian
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NOTE: My email will soon change to [email-masked]
Try that if you get failure messages.