Subject: 3gpp-analysis document and automatic tunneling

From: Pekka Savola <[email-masked]>
Date: Wed, 14 May 2003 14:33:05 +0300 (EEST)

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

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 16 May 2003 18:39:01 -0400

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:[email-masked]] 
> Sent: Wednesday, May 14, 2003 7:33 AM
> To: [email-masked]
> Subject: 3gpp-analysis document and automatic tunneling
> 
> 
> Hi,
> 
> 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").
>

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 16 May 2003 18:39:03 -0400

Juha,

We need this for deployment as you have it.  I don't agree with Pekka.
But lets just build a deployment paper out of here.  There are going to
many of them rolling out soon.

/jim

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, May 15, 2003 8:43 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: 3gpp-analysis document and automatic tunneling
> 
> 
> 
>  Hi, Pekka!
> 
> Trying to briefly answer your questions considering the issue.
> 
> From: ext Pekka Savola [mailto:[email-masked]]
> Sent: 14 May, 2003 14:33
> 
>   JW: What comes to the tunneling text in 2.2, I am fine with 
> shortening it. There actually isn't anything 3GPP-specific, 
> it is more like general tunneling description that is already 
> described elsewhere (RFC 2893, etc...). As you see, the 
> references to DSTM, ISATAP and TEREDO are informational 
> references and thus not vital in this document. They are just 
> mentioned as examples of tunneling mechanisms. Would making 
> the tunneling text shorter (e.g. one paragraph) and removing 
> the references to mechanisms (that are not used in this 
> document) be a good thing to do in your opinion?
> 
>   JW: Well, I don't think we can give unambiguous 
> recommendations. It is much better to discuss different 
> solution alternatives. Anyway, we can't require any solutions 
> to be used by operators. We had some discussion with other 
> authors (especially Karim) how to edit the text. One point 
> that was brough up in the discussion was redundancy. Static 
> tunnels on their own don't give a solution if a route goes 
> down. Instead, EGP/IGP mechanisms support this. Say that I 
> have multiple tunnels to two router endpoints connected to 
> the same network. If one goes down I would like to start 
> tunnelling to the other. Do you have any comments on this?
> 
>   JW: I fully agree with you that we should not do work that 
> actually belongs to the ISP design team. What kind of text 
> would you suggest in our document? 
> 
>   JW: Certainly, your help is appreciated!
> 
>  Thanks for your comments,
> 
> 		-Juha W.-
> 
>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 22 May 2003 10:41:22 -0400

> > => That words between brackets above are not relevant
 > > to this tunnelling mechanism, this is more relevant
 > > to a 6-to-4 relay model, which is not what is being 
 > > discussed. Routing protocols can be secured. 
 > 
 > It's not as bad as 6to4 but any mechanism implementing any kind of
 > automatic tunneling requires very careful review.  The spec 
 > is very weak
 > on security considerations.  For example, there is no 
 > description how the
 > route advertisements in practice build and tear down the tunnel.
 > 
 > My fear is that implementations doing this would implement something
 > similar to "automatic tunneling interface with compatible 
 > addresses", 
 > which is inherently insecure.

=> That can be clarified of course. But I don't see
a fundamental security issue with this approach.
You advertise reachability as you do today.

 > 
 > Well, there has been general discussion of NAT-PT (or 
 > translation) too --
 > but that's something that's applicable in all scenarios.  
 > This is really
 > only an option in the ISP networks, so I think examining it 
 > in the ISP
 > context only, in those documents, seems the most useful approach.

=> It's applicable to anyone running a large IP network.
There is a complete overlap in some cases between the 
different scenarios being considered.

Hesham

---

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Tue, 27 May 2003 21:06:29 +0200

> Pekka Savola wrote:
 > > On Tue, 27 May 2003, Karim El-Malki (EAB) wrote:
 > >>I have used ISATAP in 2.5 & 3G mobile networks and think it
 > >>is a very relevant mechanism. What is your experience of
 > >>these mechanisms in mobile networks that makes you say this?
 > > 
 > > 
 > > ISATAP doesn't allow you you to connect more than a single 
 > host.  It
 > > doesn't allow routers or networks (e.g. a /64 as 
 > recommended to the 3GPP).  
 > > Thus, I see it being of little use at least in the 
 > 3GPP-specific part.
 > 
 > I don't know exactly the scenarios Karim is referring to, and I don't
 > quite understand Pekka's comment. But, I do see a use case for ISATAP
 > in the text of section 3.1 of "Analysis on IPv6 Transition in 3GPP
 > Networks".

That's exactly what I was talking about. I tried it in our lab and in
trials over 3G and it worked just fine. 

 > 
 > Whether/not the case described in this section will be 
 > common is a point
 > which can't be proven until significant 3G deployment has 
 > occurred, but
 > ISATAP does seem to provide a good fit.

We have to make it easy for people to start using IPv6 now that
some 3G networks have been deployed and launched commercially.
So I agree with Fred that in the above case ISATAP is a good fit.

/Karim

---

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Wed, 28 May 2003 12:06:04 +0200

> >  > I haven't read the analysis in detail, but the latest 
 > >  > Scenarios draft at
 > >  > least *seems* to very explicitly mention that GGSN supports 
 > >  > both IPv4 and
 > >  > IPv6.
 > > 
 > > I am pretty certain that's not what the doc says.
 > > First, the fact that the GGSN can support IPv6 and IPv4 
 > routing does
 > > not mean that it has support for IPv6 native connectivity 
 > to mobile hosts.
 > > Secondly we cannot guarantee that all GGSNs from all operators
 > > will support IPv6 at the same time. Some GGSNs will only support
 > > IPv4 as they do today.
 > 
 > It seems to that the clear implication from the draft is:
 > 
 > "If you want IPv4, use an IPv4 GGSN"
 > "If you want IPv6, use an IPv6 GGSN"
 > 
 > These do not need to be the same.  This seems clearly stated 
 > in Scenarios 
 > sect 3.1

You can't really choose to use one or the other GGSN. You request
an IPv6 connection and if it doesn't work you revert to using IPv4
and some automated tunnelling like ISATAP. There are other mechanisms
also that I don't think we can exclude yet, which is why at least
mentioning the few applicable mechanisms in the draft is important.

 > 
 > PDP contexts could be opened to different service boxes in a service
 > provider's network (whichever support IPv6); and if the 
 > service provider
 > does not support *any* IPv6, the user is on its own *anyway*.
 > 
 > (of course, the UE could support a transition mechanism 
 > itself but I find 
 > that a bit questionable approach -- the goal is to make 3GPP devices 
 > simple not complex.)

My view is very different as you have realised already. I think we need
to have transition mechanisms for early v6 introduction stages and special
roaming cases which allow the user to access those v6 e.g. peer2peer
services even when a v6 pdp context is not available. I've tried it in
real networks and a simple mechanism like ISATAP works fine. Anyway we
seem not to be taking steps forward with this discussion so I'll
stop here.

/Karim

---

From: <[email-masked]>
Date: Wed, 28 May 2003 13:55:05 +0300

Hi, Karim and Pekka!

In my opinion, the simplest (and most straightforward) way is to use IPv6 PDP context, if you use IPv6 services and use IPv4 PDP context, if you use IPv4 (legacy) services. And that should be the main way, how things are handled.

However, it is possible that in the early phases of IPv6 deployment, there is no IPv6-capable GGSN (or SGSN/HLR) in the network (in the home or visited 3gpp network as Karim explained below) and the user still wants to use IPv6 - that's the special case we document in 3.1. I think that the current text "...the UE may activate an IPv4 PDP context and tunnel IPv6 packets in IPv4 packets using a tunneling mechanism. Tunneling in the UE requires dual stack capability in the UE. ..." is quite good. We can mention some tunneling mechanisms that can be used in that case (informative references), or just mention some dynamic tunneling mechanism alternatives in 2.2, as we do in the current document. Anyway, I feel that we cannot explicitely state, which tunneling mechanism should be used.

Cheers,
	-Juha W.-

-----Original Message-----
From: ext Karim El-Malki (EAB) [mailto:[email-masked]]
Sent: 28 May, 2003 13:06
To: 'Pekka Savola'
Cc: Fred L. Templin; Wiljakka Juha (NMP/Tampere); Soininen Jonne
(NET/MtView); [email-masked]
Subject: RE: 3gpp-analysis document and automatic tunneling

/Karim