RE: 3gpp-analysis-04: The use of 6to4 [issue 4]

[<juha.wiljakka@nokia.com>]

Hi again,

yep... I have cut quite a lot text introducing "6to4" in the previous version, and I could actually remove the rest of that text in the beginning of section 3.2.1.

Furthermore, I will consider rewording based on your proposals. This issue is also related to issue 7, and I agreed to (initially) remove 6to4 from chapter 3.2.2.

Brian Carpenter also commented that "...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."

Of course, that kind of situation is possible, but can we consider it as a special case that needs not be included in this document trying to find general solutions?

BR,
	-Juha-

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 23 July, 2003 12:37
To: v6ops@ops.ietf.org
Subject: 3gpp-analysis-04: The use of 6to4


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