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

[Brian E Carpenter <brc@zurich.ibm.com>]

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

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

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

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

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK