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

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 22 Aug 2003 juha.wiljakka@nokia.com 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.
 
> 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?

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.

> -----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