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

From: <[email-masked]>
Date: Fri, 22 Aug 2003 15:55:18 +0300

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:[email-masked]]
Sent: 23 July, 2003 12:37
To: [email-masked]
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

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Aug 2003 08:35:37 +0300 (EEST)

On Fri, 22 Aug 2003 [email-masked] wrote:
> 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.

OK.
 
> 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?

I think my original comment was aimed at 3GPP operators specifically (the 
doc had a lot of text describing how a 3GPP _operator_ itself could run 
on top of 6to4).  

Brian's comment may be valid ("transition mechanisms at UEs discussion"),
but in different context.  Sorry for picking overly generic term for this.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Aug 2003 15:30:05 +0200

> but in different context.  Sorry for picking overly generic term for this.

I agree. There is no special reason to go into details. I certainly never
thought of 6to4 as something to be installed in telephones.

  Brian

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

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK