[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis document and automatic tunneling
This does not bother me. But lets move this document forward and my
input to the authors is as follows. We need this doc out more than
anyother work in the IETF for v6ops. Just scale it back than fighting
this battle with Pekka or others here for 3 months. We can build a
white paper in the industry and say whatever we want about tunnels and
the ones we want to use including Teredo if we want. But for the doc
give them what they want and lets move forward. We will build use and
methods out of the IETF for deployment and 3GPP authors contact me
offline and I can explain how we drive this and get it done in 3GPP
implementor community.
/jim
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Wednesday, May 14, 2003 7:33 AM
> To: v6ops@ops.ietf.org
> Subject: 3gpp-analysis document and automatic tunneling
>
>
> Hi,
>
> I'd like to raise one issue in the 3gpp-analysis document
> which bothers me
> a lot.
>
> I'd like to either understand the reasoning for mentioning
> all the kinds of automatic tunneling mechanism in this draft,
> or remove the references. (the last paragraph of 2.2 quoted
> below, and some re-editing of the paragraphs in 3.2.1).
>
> In particular, I feel this is an issue about IGP/BGP
> tunneling. It is possible such methods could be used -- if
> the network is built just so -- but that's entirely different
> thing from whether they're a required or even a recommended
> solution ("we have a hammer, now let's go find the nails").
>
> I fail to see anything 3GPP specific in the description of
> the network in
> 3.2.1 and consequently, I'd rather not go down the rathole of
> describing
> how an ISP would run its network in the 3GPP
> scenarios/analysis document.
> Rather, I'd try to work out generic ISP scenarios in the ISP
> documents to avoid duplicating the work.
>
> Therefore, I'd like to either understand why this is in scope
> and what's
> 3GPP specific about it, or try to reword the text
> appropriately (I can
> try to help if needed).
>
> ====
> 2.2 Tunneling
>
> Tunneling is a transition mechanism that requires dual
> IPv4/IPv6
> stack functionality in the encapsulating and
> decapsulating nodes.
> Basic tunneling alternatives are IPv6-in-IPv4 and
> IPv4-in-IPv6.
> IPv6-in-IPv4 tunneling mechanisms perform as virtual IPv6
> links
> over IPv4, and they are implemented by virtual IPv6
> interfaces that
> are configured over one or more physical IPv4
> interfaces. Sending
> nodes encapsulate IPv6 packets in IPv4 packets when the IPv6
> routing table determines that the next hop toward the IPv6
> destination address is via a tunnel interface. Receiving nodes
> decapsulate IPv6 packets from IPv4 packets that arrive on tunnel
> interfaces. Tunneling can be static or dynamic.
>
> Static (configured) tunnels are fixed IPv6 links over
> IPv4. They
> require static configuration of the IPv6 source, IPv6
> next-hop and
> IPv4 destination addresses for IPv6-in-IPv4
> encapsulation. The IPv6
> destination address is specified by the application and
> is used to
> determine the IPv6 next-hop address via
> longest-prefix-match in the
> IPv6 routing table. Configured tunnels are specified in [RFC2893].
>
> Dynamic (automatic) tunnels enable stateless
> encapsulation of IPv6-
> in-IPv4. They are virtual IPv6 links over IPv4 where the tunnel
> endpoints are not configured, i.e. the links are created
> dynamically, and they only require static configuration
> of the IPv6
> source address. Like in static tunneling, the IPv6
> destination
> address is specified by the application and it is used
> to determine
> the IPv6 next-hop address via a longest-prefix-match
> lookup in the
> IPv6 routing table. But unlike static tunnels, the IPv4
> destination
> address is not configured (fixed); it is derived from the
> IPv6
> next-hop address in some way. For example, the IPv4
> destination
> address can be embedded in the IPv6 next-hop address.
> Examples of
> dynamic tunneling mechanisms are "6to4" [RFC3056],
> [ISATAP], [DSTM]
> and [TEREDO].
>
> [...]
>
> 3.2.1 Tunneling inside the 3GPP Operator's Network
>
> Many GPRS operators already have IPv4 backbone networks deployed
> and they are gradually migrating them while introducing IPv6
> islands. IPv6 backbones can be considered quite rare in
> the first
> phases of the transition. If the 3GPP operator already
> has IPv6
> widely deployed in its network, this subsection is not so
> relevant.
>
> In initial, smaller scale IPv6 deployment, where a small number of
> IPv6 in IPv4 tunnels are required to connect the IPv6 islands over
> the 3GPP operator's IPv4 network, manually configured tunnels can
> be used. In a 3GPP network, one IPv6 island could contain the GGSN
> while another island contains the operator's IPv6 application
> servers. However, manually configured tunnels can be an
> administrative burden when the number of islands and therefore
> tunnels rises.
>
> It is also possible to use dynamic tunneling mechanisms
> such as
> "6to4" [RFC3056] and IGP/EGP routing protocol based
> tunneling
> mechanisms [BGP][IGP]. Routing protocol based mechanisms
> such as
> [BGP] consist of running BGP between the neighboring
> router tunnel
> endpoints and using multi-protocol BGP extensions to
> exchange
> reachability information of IPv6 prefixes. The routers
> use this
> information to create IPv6 in IPv4 tunnel interfaces and
> route IPv6
> packets over the IPv4 network. It is possible to combine this with
> different types of tunnels.
> [...]
> The conclusion is that in most "internal" 3GPP scenarios it is
> preferred to use manually configured tunnels or EGP/IGP based
> tunneling mechanisms, if it is not feasible to enable
> IPv6 in the
> network infrastructure yet.
>
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>