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

[Brian E Carpenter <brian@hursley.ibm.com>]

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 brc@zurich.ibm.com
Try that if you get failure messages.

Pekka Savola wrote:
> 
> 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