Subject: RE: 3gpp scenario 2

From: <[email-masked]>
Date: Tue, 17 Dec 2002 13:23:44 +0200

Anand,

I assume that this is a very common problem / environment in initial IPv6 deployment, i.e. two separate IPv6 islands connected by IPv4 network using "IPv6 in IPv4" tunneling and solutions have already been thought by several (DNS) experts.

What if we already have some static "IPv6 in IPv4" tunnels configured from the operator's network to, say, IPv6 internet / 6bone and there is IPv6 connection to node B? 

I am very happy to receive more comments on this issue.

Thanks,
	-Juha-

-----Original Message-----
From: ext Thakur, Anand [mailto:[email-masked]]
Sent: 17 December, 2002 13:01
To: Wiljakka Juha (NMP/Tampere)
Cc: V6ops (E-mail)
Subject: 3gpp scenario 2

hi huha,
i was just wondering about the scenario in which 2 IPV6 UEs communicate over
an IPV4 network. In this scenario won't initial DNS resolution be a very
difficult job (if not impossible)? 
If you have not understood my question read this example:
Let Host A be on IPV6 netork X and Host B on IPV6 network Y. Now, if A makes
a DNS query ("A") for B, none of the name resolvers in network X will have
an entry for B . How will this query finally reach network Y, assuming all
intermediate routers are IPV4 only? Will A have to explicitly tunnel this
request to network Y? I am also assuming that DNS servers in the IPV4
internet don't support "AAAA".

regards
Anand Thakur
HCL Perot Systems (A SEI CMM Level 5 Company)
Plot No 3, Sector 125, NOIDA (UP)-201301, India
* Tel  +91 120 4432755-79, X3348 (EPABX)
mobile:9811748512

---

From: "Thakur, Anand" <[email-masked]>
Date: Tue, 17 Dec 2002 17:13:54 +0530

Juha,
As of now this seems to be the only solution, but i wonder if this solution
is going to scale well when number of IPV6 islands shoots up. Especially in
the 3gpp case we could be dealing with hundreds of thousands of (may be even
millions) of V6 nodes. In addition we will have to mandate that every V6
island has to be connected to the 6bone.

Plus, what about the scenario where Host A is in a V4 network Z and
generates a "A" query for Host B?

regards
Anand Thakur

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, December 17, 2002 4:54 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	RE: 3gpp scenario 2
> 
> Anand,
> 
> I assume that this is a very common problem / environment in initial IPv6
> deployment, i.e. two separate IPv6 islands connected by IPv4 network using
> "IPv6 in IPv4" tunneling and solutions have already been thought by
> several (DNS) experts.
> 
> What if we already have some static "IPv6 in IPv4" tunnels configured from
> the operator's network to, say, IPv6 internet / 6bone and there is IPv6
> connection to node B? 
>

---

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Tue, 17 Dec 2002 12:51:35 +0100

Hi Juha and Anand,
 
Can you clarify: "What if we already have some static "IPv6 in IPv4" tunnels configured from the operator's network to, say, IPv6 internet / 6bone and there is IPv6 connection to node B?"

My small experience shows that configuring static tunnels becomes quickly boring. I would prefer a 6to4-based solution. But it seems that security issues are remaining... I have to check that.

Luc

	-------- Message d'origine-------- 
	De: [email-masked] [mailto:[email-masked]] 
	Date: mar. 17/12/2002 12:23 
	À: [email-masked] 
	Cc: [email-masked] 
	Objet: RE: 3gpp scenario 2

	Anand,

	
	
	Thanks,
	        -Juha-
	
	-----Original Message-----
	From: ext Thakur, Anand [mailto:[email-masked]]
	Sent: 17 December, 2002 13:01
	To: Wiljakka Juha (NMP/Tampere)
	Cc: V6ops (E-mail)
	Subject: 3gpp scenario 2

	hi huha,
	
	regards
	Anand Thakur

---

From: "Thakur, Anand" <[email-masked]>
Date: Tue, 17 Dec 2002 17:33:58 +0530

Hi Luc,
I totally agree that configured tunneling is very boring and time consuming
but in this case you will have to set up only one configured tunnel to the
6bone/v6 internet. From there on it will be the responsibility of the 6bone
to send you back a legitimate reply ;-)
But the question remains, how do you know that HOST B is V6 and not V4?
Being in a V6 island you should be able to maintain connectivity with the V4
world also. If you generate a dual query (one to the 6bone and one to the V4
internet) and get a blank from the V4 net, then what? Do you wait for the
6bone reply? But most clients would accept the answer that they get first.

regards
Anand Thakur

> From:	BELOEIL Luc FTRD/DMI/CAE [SMTP:[email-masked]]
> Sent:	Tuesday, December 17, 2002 5:22 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	RE : 3gpp scenario 2
> 
> Hi Juha and Anand,
>  
> Can you clarify: "What if we already have some static "IPv6 in IPv4"
> tunnels configured from the operator's network to, say, IPv6 internet /
> 6bone and there is IPv6 connection to node B?"
> 
> My small experience shows that configuring static tunnels becomes quickly
> boring. I would prefer a 6to4-based solution. But it seems that security
> issues are remaining... I have to check that.
> 
> Luc
> 
> 
> 	I assume that this is a very common problem / environment in initial
> IPv6 deployment, i.e. two separate IPv6 islands connected by IPv4 network
> using "IPv6 in IPv4" tunneling and solutions have already been thought by
> several (DNS) experts.
> 	
> 	What if we already have some static "IPv6 in IPv4" tunnels
> configured from the operator's network to, say, IPv6 internet / 6bone and
> there is IPv6 connection to node B?
> 	
> 	From: ext Thakur, Anand [ <mailto:[email-masked]>]

---

From: <[email-masked]>
Date: Tue, 17 Dec 2002 13:17:57 +0100

this is not an issue as long as you have a continuous name space.

and just because someone is deploying ipv6-only networks, doesn't mean the name space is automatically fragmented.

jasminko

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 17 december 2002 12:24
> I assume that this is a very common problem / environment in 
> initial IPv6 deployment, i.e. two separate IPv6 islands 
> connected by IPv4 network using "IPv6 in IPv4" tunneling and 
> solutions have already been thought by several (DNS) experts.
> 
> configured from the operator's network to, say, IPv6 internet 
> / 6bone and there is IPv6 connection to node B? 
>

---

From: "Thakur, Anand" <[email-masked]>
Date: Thu, 19 Dec 2002 09:54:55 +0530

on Thursday, December 19, 2002 3:20 AM Pekka Savola wrote:

>2) outside the GPRS network, between the operator's network and the 
>Internet IPv6 (islands): there is no doubt some tunneling over IPv4 will 
>be needed _somewhere_.  But where?

>a) if the 3GPP operator is connected natively to an v6-enabled ISP, the
>3GPP operator himself does not necessarily have to do anything: he can
>more or less assume someone else (e.g. his ISP) is doing the bridging
>between these IPv6 islands.

> b) if the 3GPP operator is connected to some IPv4 and IPv6 networks, it 
>may want to perform tunneling to some IPv6 islands over IPv4 itself.  This 
>is just a matter of routing and policy.

I think this is a very valid point and more or less summarizes a solution to
scenario2. Correct me if i am wrong, but 2a) seems to indicate the
following:

                                                       +--------------+
+--------------+
                  native IPV6 connectivity    |  X's ISP   |      V6 conn.
| Y's ISP    |  native IPV6 connectivity    
                                  _____________|
|______________|                |__________________
                               /                        +-------------+
+--------------+                               \
                              /
\
      +---------------------/-----+
+---------------------------+
+---------------------\-----+
       | IPV6 network  X    |___V4________ | IPV4 internet
|______V4_____________|   V6 island   Y       |
       | (3gpp operator)     |                        |
|                                      |                            |
       +--------------------------+
+--------------------------+
+---------------------------+

These diagrams are time consuming, but they say a picture is worth a
thousand words !!

So, basically a parallel IPV6 internet is existing with the IPV4 internet?

regards
Anand Thakur

> From:	Pekka Savola [SMTP:[email-masked]]
> Sent:	Thursday, December 19, 2002 3:20 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject:	RE: FW: 3gpp scenario 2
> 
> On Wed, 18 Dec 2002 [email-masked] wrote:
> > can you give more (specific) comments on the applicability of IGP/EGP
> > based tunneling mechanisms in scenario 2?  Scalability seems to be your
> > main concern?
> 
> Let's consider the possible cases here (perhaps it should be clarified 
> which is the case in the particular scenario):
> 
> 1) inside the GPRS network: if the 3GPP operator has a large backbone, it
> may not have native IPv6 everywhere.  Tunneling may have to be used there.
> 
> Personally I think this is a non-issue, because as 3GPP is so heavily 
> IPv6, I don't see why anyone would bother deploying it without all the 
> network infrastructure (or most of it so it doesn't really matter) being 
> IPv6-enabled.
> 
> But if this is important, here something like [BGP][IGP] could be usable.
> 
> Not required, really, or maybe not even optimal, but they could be used.
> 
> 2) outside the GPRS network, between the operator's network and the 
> Internet IPv6 (islands): there is no doubt some tunneling over IPv4 will 
> be needed _somewhere_.  But where?
> 
>  a) if the 3GPP operator is connected natively to an v6-enabled ISP, the
> 3GPP operator himself does not necessarily have to do anything: he can
> more or less assume someone else (e.g. his ISP) is doing the bridging
> between these IPv6 islands.
> 
>  b) if the 3GPP operator is connected to some IPv4 and IPv6 networks, it 
> may want to perform tunneling to some IPv6 islands over IPv4 itself.  This
> 
> is just a matter of routing and policy.
> 
> However, considering these two specific tools:
> 
> [IGP] is used in IGP only and IGP is not run across administrative 
> borders; so it's clearly useless.
> 
> [BGP] could theoretically be used, but its main area of applicability is
> to enable automatic tunneling over IPv4-enabled core using IPv4/6 edge
> routers (the typical case being an ISP's MPLS core network).  If this was
> applied to the general Internet, it would basically mean that
> participating islands would have to be have BGP sessions between them
> using some tunneling techinique like 6to4, IPv4 eBGP multihop, etc.
> 
> So it seems to me neither of these is applicable in the context 2).
> 
> Perhaps this clarifies my point?
> 
> > From: ext Pekka Savola [mailto:[email-masked]]
> > Sent: 17 December, 2002 21:10
> > 
> > On Tue, 17 Dec 2002 [email-masked] wrote:
> > > Our proposed solution concluding that "In most 3GPP scenarios it is
> > > preferred to use manually configured tunnels or EGP/IGP based
> tunneling
> > > mechanisms." is written in "3GPP analysis" chapter 3.2.
> > > 
> > > In my comment below I just refer to using "IPv6 in IPv4" tunnels from
> > > the operator's network to other IPv6 islands - configured tunneling
> > > makes sense, if there is a limited number of other IPV6 islands you
> need
> > > to connect to. Note that we also state
> > > 
> > >    "However, manually 
> > >     configured tunnels can be an administrative burden when the number
> 
> > >     of islands and therefore tunnels rises. Therefore it is also 
> > >     possible to use dynamic tunneling mechanisms such as "6to4" 
> > >     [RFC3056] and IGP/EGP routing protocol based tunneling mechanisms 
> > >     [BGP][IGP]."
> > > 
> > > in our analysis doc.
> > 
> > I think one should keep in mind that it's not necessary to reach every 
> > IPv6 island directly (a usual justification for e.g. IGP/EGP tunneling).
> > 
> > I think we can pretty much discard [BGP][IGP] from scenario 2 too -- 
> > they're applicable for smaller-than-Internet scopes, which scenario 2
> does 
> > not seem to be at all.
> > 
> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: <[email-masked]>
Date: Thu, 19 Dec 2002 10:15:54 +0200

Some more comments below:

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 19 December, 2002 00:47

On Wed, 18 Dec 2002, Karim El-Malki (EAB) wrote:

It also reads:

    Encapsulating node can be e.g. the GGSN or the edge router between
    the border of the operator's IPv6 network and the public Internet.

this makes it very apparent to me that main focus was tunneling in the 
internet -approach.

 JW: This is a thing I commented in my previous mail: we must more clearly separate those outside / inside operator's network cases in the next revision.

IMO there's something really wrong in the 3GPP operator's network if it
needs to have e.g. more than 10-15 isolated IPv6 islands there (~ reaching
one limit where in some cases configured tunneling could become more
difficult to maintain).

 JW: I also think that configured tunneling is fine when the number of tunnels can be kept limited. Around 10 configured tunnels may be sufficient for many 3GPP nws.

btw. the ridiculously long paragraph should be split in about 5.

 JW: Let's do that in January! I admit that the editor could click 'enter' more frequently...

BR,
	-Juha-

---

From: "Thakur, Anand" <[email-masked]>
Date: Thu, 19 Dec 2002 14:41:12 +0530

>I don't agree. Most operators already have IPv4 backbone networks and
>many would want to migrate them gradually while introducing IPv6
>islands. So it does not make sense to base our recommendations on
>native IPv6 operator backbones only. The IGP/EGP mechanism is for
>the case in which the operator is not ready to upgrade the
>backbone.

by IPV6 islands are we reffering to entire PLMNs being IPV6? if yes, then
will an IPV4 UE be able to perform GPRS attach to an IPV6 PLMN (island)?

Anand Thakur

> From:	Karim El-Malki (EAB) [SMTP:[email-masked]]
> Sent:	Thursday, December 19, 2002 3:59 AM
> To:	'Pekka Savola '; [email-masked] '
> Cc:	[email-masked] '; [email-masked] ';
> [email-masked] '; [email-masked] '; Karim El-Malki (EAB)
> Hi Pekka
> This is exactly the case. The tunnelling mechanisms paragraph
> mentions explicitly the case where it applies:
>     
>     In a 3GPP 
>     network, one IPv6 island could contain the GGSN while another 
>     island contains the operator's IPv6 application servers....
> 
> >
> I don't agree. Most operators already have IPv4 backbone networks and
> many would want to migrate them gradually while introducing IPv6
> islands. So it does not make sense to base our recommendations on
> native IPv6 operator backbones only. The IGP/EGP mechanism is for
> the case in which the operator is not ready to upgrade the
> backbone.
> 
> >
> OK, so I think we agree that this scenario makes sense.
> 
> Rgds
> /Karim

---

From: <[email-masked]>
Date: Thu, 19 Dec 2002 12:13:14 +0200

Hi, Pekka!

-----Original Message-----
From: ext Pekka Savola [mailto:[email-masked]]
Sent: 19 December, 2002 10:28

On Thu, 19 Dec 2002 [email-masked] wrote:
> Sent: 18 December, 2002 23:50
> 
>  JW: I agree with Karim's later comments that many GPRS operators already 
> have IPv4 backbone networks (gradually migrating them while introducing 
> IPv6 islands). And native v6 backbones are quite rare in the first phases 
> of the transition. We can write clearer 'applicability statement' for the use
> of [BGP] / [IGP]. 

Sure, but my thought is that dual-stack v4/v6 backbones already exist, and
are definitely on the rise.  It's not like 3GPP networks are deploying
today or tomorrow.  Often setting up the infrastructure required to
install something like BGP/IGP tunneling is greater than the pain of 
configured tunneling or dual-stack backbone.

JW: Yep, the development direction goes IPv4-only backbones ->
dual stack backbones (and finally in the future -> IPv6 backbones),
given recommendations depend on the status of IPv6 deployment
in particular operator's network.

In any case, I'm not sure how specific this discussion is to 3GPP.  
Depending on how you view the operator, seems pretty close to ISP (or 
enterprise) network.

JW: Maybe not so 3GPP specific at all, transition issues (like
where to use which tunneling mechanism) are general.

>  JW: Well, yes...this looks like an easy case and starts to be close to 
> the scope of the ISP design team..  :-)

Definitely...

If the 3GPP operator does tunneling over IPv4 Internet, IMO it should be 
considered 3GPP operator/ISP, and then ISP parts would apply.  Nothing 
really 3GPP-specific as I see it.

JW: OK, this is more or less a question of definition, I can discuss that 
with the other authors. Anyway, I do not want to concentrate only on 'operator's
network internal' cases in our document. Like our abstract says,
    In these scenarios, the 
    User Equipment (UE) connects to nodes in other networks, e.g. in 
    the Internet, and IPv6/IPv4 transition mechanisms are needed
 
>  JW: Thanks for your opinion, I can quite clearly see that your basic
> recommendation for this case 2b) is to use a couple of configured 
> tunnels?

Yes -- but it depends quite a bit on how many ISP functions the 3GPP
operator wants to perform (indeed, I believe most of them are ISP's of
some sort themselves) -- and then the issue about external connectivity
seems a bit moot.

My point is that I don't see anything 3GPP -specific in the Internet case.  
Either it gets connectivity to other IPv6 sites through its ISP's or
transits, or connects to some of them directly ("acting as ISP doing 
peering").  The latter is unscalable.

---

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Thu, 19 Dec 2002 18:15:23 +0100

> On Thu, 19 Dec 2002, Karim El-Malki (EAB) wrote:
 > >  > today or tomorrow.
 > > I think the issue was that 3GPP core networks have already 
 > been deployed
 > > and are running IPv4.
 > 
 > .. but v6 part of it isn't deployed today or tomorrow.  Prudent folks
 > would be preparing for enabling of IPv6 today -- so that when finally
 > viable 3GPP solutions are available, their network is 
 > already upgraded,
 > router software tested etc.

True you want to prepare as early as possible. However you may want to
do your initial deployment without risking to disrupt your live v4
network. You can do that without upgrading your backbone.
Of course the final aim is to upgrade the backbone, but I don't
think we should recommend that they must go dual-stack from day one
if they don't want to.

 > 
 > >  > Often setting up the infrastructure required to
 > > When an operator introduces v6 islands over an existing v4 backbone
 > > it doesn't have to modify the existing network. Both configured
 > > tunnelling and EGP/IGP would be the same from this point of view.
 > 
 > .. at the expense of possibly having to upgrade latest and greatest 
 > software in the islands to support these mechanisms.

The v6 islands haven't been deployed yet so that's ok.

 > 
 > > In certain cases upgrading the whole backbone at once is worse.
 > 
 > Who says the backbone must be upgraded at once?  Usually 
 > things like these
 > are done over a longer period, e.g. 6-12 months.

What I'm saying is that there may be operators that don't want to
risk disrupting a live network in the early stages of ipv6
deployment. They would do that when they have more experience with
running the v6 network. For those in this situation they can tunnel
between the v6 islands in the early stages. So it is a scenario we need
to consider IMO.

/Karim

---

From: "Thakur, Anand" <[email-masked]>
Date: Thu, 19 Dec 2002 14:07:05 +0530

>peering").  The latter is unscalable.

I agree. In fact in one of my earlier mails i had mentioned the same
thing(that the scenarios are not 3gpp specific). But the point here is that
some extra issues and points do arise in the 3gpp case. like the presence of
an extraordinary number of mobile nodes accessing the internet and blowing
up of NAT-PT - DNS_ALG issues.

Anand Thakur

> Sent:	Thursday, December 19, 2002 1:58 PM
> > Another thing we should do is to more clearly separate
> > 'inside the operator's network' and 'outside the operator's network'
> cases in
> > the next revision!
> 
> Definitely agree :-)
>

---

From: "Karim El-Malki (EAB)" <[email-masked]>
Date: Fri, 20 Dec 2002 16:01:58 +0100

> > If we can run something like MP-BGP over v4
 > > isn't that better? 
 > 
 > If that requires additional infrastructure, like upgrading 
 > your routers to
 > support the extension, configure full BGP mesh of peerings 
 > between all the
 > islands, or the like -- perhaps not.

It depends on the network of course. If you already have
a fully-meshed BGP network then you could introduce new
ipv6 islands with dual-stack edge routers and have them
talk MP-BGP. You'd introduce the same infrastructure as if
you were running configured tunnels.

 > 
 > But I'm not completely opposed to the idea: if, for some 
 > reason I couldn't 
 > fathom, the operator was running MPLS core network, MP-BGP 
 > over v4 just 
 > _might_ be a good solution if the number of the islands is high.

I only used MP-BGP over v4 as an example of v6 route advertisement.
I was in no way meaning to focus on the MPLS solution. Any
tunnelling mechanism can be used.

 > 
 > But I don't believe we should be designing to cope with 
 > every possible 
 > cornercase (whether this is one is another question) -- then 
 > we'd get 
 > nothing done, and would end up requiring all kinds of transition 
 > mechanisms -- I *don't* want, based on 3GPP analysis, that we end up 
 > requiring standardization of [BGP] or [IGP] because there's some 
 > perceived need for deployment.

If we're recommending too many mechanisms I would agree, but we're only
recommending two mechanisms: static configured and EGP/IGP. I think that's a
good balance for now and it gives implementers and network designers some
direction but also some flexibility. From my experience in mobile network
design I think a set of tools for different scenarios is what is needed
rather than a single option.
/Karim