Subject: RE: 3gpp-analysis document and automatic tunneling

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

> >  > Examples of
 > >  >     dynamic tunneling mechanisms are "6to4" [RFC3056], 
 > >  > [ISATAP], [DSTM]
 > >  >     and [TEREDO].
 > >  > 
 > >  > ==> replace with:
 > >  > 
 > >  >  An example of dynamic tunneling mechanism is "6to4" [RFC3056].
 > > 
 > > That removes some useful info for 3gpp people.
 > > What did you not like about pointing out the main mechanisms
 > > which 3gpp should be aware of? IMO we should keep all the above.
 > 
 > I fail to see how those techniques would be useful for 3GPP people.  
 > Well, maybe DSTM could be leveraged, a bit, but it's not 
 > really even an
 > automatic tunneling mechanism.  It's all just irrelevant 
 > information in 
 > this context.

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?

..cut some text
 > >  >     However, manually configured tunnels can be an
 > >  >     administrative burden when the number of islands 
 > and therefore
 > >  >     tunnels rises.  In that case, upgrading parts of 
 > the backbone
 > >  >     to dual stack may be the simplest choice.
 > > 
 > > I don't think this is a viable or simple choice in many cases. The
 > > operator should be free to upgrade the backbone 
 > independently of the
 > > number of sites. Some may want to delay that upgrade.
 > 
 > The operator can, of course, do however he/she wants to.  
 > IETF cannot 
 > and should not mandate it.  But we can document some ways which seem 
 > preferable.

What reasons would it be preferable for? Cost? Ease of deployment?
I have talked to some who don't think it is cheaper or easier
so I don't think we should make this preference. We could say that
if the operator finds that the risk/cost allows the backbone
to be upgraded then this could avoid tunnelling. But I guess this
is quite obvious.

 > I've been been there when IPv6 coexistance has been planned and 
 > implemented for at least 3 ISP networks (each with 
 > gigabit-level traffic 
 > levels).  In all of those cases, dual stack has been *by 
 > far* the simplest 
 > choice, augmented by a tunnel here and there.  There may be 
 > other cases, 
 > of course, too -- to be identified in the ISP scenarios if necessary.

In my experience (mobile operators) it is not favoured by many.

 > > Also there is no discussion about reliability of connections.
 > > Doing this with static tunnels (manually configuring a mesh of
 > > static tunnels) and relying on v4 routing protocols does not
 > > seem like something we can recommend above everything else.
 > > It's an option but using a routing protocol you would achieve
 > > the same thing without the mesh of static routes.
 > 
 > There isn't because that discussion is not specific to 3GPP. 

But there is a requirement of high reliability in general
in mobile networks which isn't always there in other scenarios.

 >  We could 
 > tail down the section more if that'd be closer what you expect?

No! I want it to say more. This document is supposed to help
3gpp deploy these networks.

 >  
 > > Most importantly there are some routing scenarios in which you
 > > will not detect a route failure if you are using static routes.
 > > I have been involved in several mobile network designs and
 > > these cases are quite common, just like in any other network.
 > > So I would not recommend static tunnels as the first choice.
 > 
 > Static tunnels include routing protocols, as above.

Above I talked about running v4 routing protocols while tunnelling
v6-in-v4. That doesn't solve all the v6 route failure cases.

 > 
 > Or maybe it should be spelled out that in case of configured 
 > tunnels, it
 > may be desirable to have redundancy and run a routing protocol.

Run a routing protocol where? Inside the tunnel (v6 routing protocol)
and a v4 routing protocol as well? In that case I would simplify things
by running a single routing protocol that can exchange both v6 and
v4 routes.

 >  
 > > Putting the technical aspect aside, you brought up the patent
 > > issue with one of the routing protocol mechanisms. Although
 > > we should favour non-patented solutions, are we cutting out
 > > all routing protocol based solutions because of this patent?
 > 
 > Not explicitly.

I hope not implicitly either ;-)

 > I think there is a need to identify the 
 > real scenarios
 > and which approaches seem to make the most sense.  I'm 
 > unconvinced there's
 > anything 3GPP-specific here.  This doesn't exclude some 
 > (future) findings
 > in the ISP scenarios.

We don't need to cover what is in the ISP scenarios.
However we need to give a guideline doc for 3gpp networks.
I don't see why we should go and put 3gpp reliability or
tunnelling transition mechanism requirements on the ISP doc.
Also I've had a look at the ISP work and I thought the 3gpp doc
and the ISP doc were pretty much in line when it came to the
overlap regions.

 >  
 > >   The administrative
 > >  >     burden could also be mitigated by using automated management
 > >  >     tools which are typically necessary to manage large networks
 > >  >     anyway.  Even a dynamic tunneling mechanism could be used
 > >  >     if other methods are not suitable.
 > > 
 > > Do you mean automated management tools for configuring 
 > static tunnels?
 > 
 > Yes.
 > 
 > > Seems like you want us to clearly say we prefer static instead
 > > of dynamic tunnelling but I don't think we have an agreement here.
 > 
 > Yes.
 > 
 > > Maybe we should pose this issue to routing folks?
 > 
 > This seems more like an operational issue, not a protocol 
 > issue.  And this 
 > happens to be an ops working group :-).

If we have routing experts in this wg I think their input would
be helpful.

/Karim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 May 2003 21:20:34 +0300 (EEST)

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

> to be upgraded then this could avoid tunnelling. But I guess this

Well, we (as the working group) should document cases how to deploy IPv6
in the common case, using widely applicable mechanisms.  Obviously, some
approaches are more preferable (without defining the metric, as it isn't a
single one) than others.  One point to look at might be RFC3439, "Some
Internet Architectural Guidelines and Philosophy".

I'm not quite convinced that based on 3GPP analysis this yet fulfils the 
criteria for this.
 
> In my experience (mobile operators) it is not favoured by many.

That may be due to real or wrong reasons.  That's something to be found
out by better analysis of it in the ISP context.
 
> in mobile networks which isn't always there in other scenarios.

.. but in most cases, is.
 
> 3gpp deploy these networks.

It's supposed to help in 3GPP environment, not (IMO) in how 3GPP operators 
could act as ISP's, and how to build their ISP-grade backbone networks.  
These are two separate issues.

> v6-in-v4. That doesn't solve all the v6 route failure cases.

Routing protocols can be run in both v4 and v6.  Whichever combination 
seems useful for the operator. Together, they address all concerns.

> by running a single routing protocol that can exchange both v6 and

Yes -- if you want a simple network, you can do this quite easily by
running, for example, IS-IS on a dual-stack backbone.

For example, we run OSPF for IPv4 and IS-IS for IPv6 only.  That's not a 
problem for us.  It's better that way, for now -- we could introduce a new 
IPv6 routing protocol without disturbing the existing one at all, as 
they're completely separate.

So there are tradeoffs both ways.

> and the ISP doc were pretty much in line when it came to the

I think we have different concepts of the scope of the 3GPP case.  I think
it's focus is, and should be, on how the 3GPP-specified part operates
(like SIP interactions, providing v4/v6 connectivity to the 3GPP devices,
etc.), and how we most fluently merge it with IPv6.

*NOT* how to implement backbone networks.  (Which is certainly an 
interesting topic, but really something which is best fit under ISP 
context because that's where backbone networks of such grade are 
deployed.)

> If we have routing experts in this wg I think their input would

Agree.

I meddle with routing every day, but you already know my opinion *).  I'd
like to hear others' as well.

*)  How do you think big operators handle issues like:
 - updating a piece of configuration (e.g. access-lists, route-maps, 
policies) on dozens or hundreds of routers
 - configuring iBGP meshes between routers
 - update their eBGP filters on their border routers

.. other than by (advanced) management tools, or by a lot of manual work?
The former would help with tunnels too, but in the latter case the NOC 
folks are so used to it it doesn't matter anyway.  Pick your poison :-).

-- 
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: "Fred L. Templin" <[email-masked]>
Date: Tue, 27 May 2003 10:54:35 -0700

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

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.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 May 2003 22:26:53 +0300 (EEST)

> ISATAP does seem to provide a good fit.

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.

So what appears to be in the analysis document appears to branch into a 
very questionable direction.

---

From: Fred Templin <[email-masked]>
Date: Wed, 28 May 2003 12:38:26 -0700

Pekka,

Fred L. Templin wrote:

> Pekka Savola wrote:
>
>> ISATAP doesn't allow you you to connect more than a single host.
>
I think I know now why I was confused by your point on isatap not
allowing more than a single host. It is not strictly the case that nodes
on an isatap link must use isatap addresses as the source/destination
addresses in packets. If there is a way for the isatap router to discover
host routes, then  nodes on the isatap link can use , e.g., RFC 3041
privacy addresses.

In other words, the only addresses that need to be in isatap format are
those that appear in the next-hop fields of a node's IPv6 routing table
entries. (In many cases, those next-hop addresses could simply be link-
local.) As such, a single isatap client can connect many additional hosts.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 May 2003 07:08:27 +0300 (EEST)

> local.) As such, a single isatap client can connect many additional hosts.

Indeed -- but I think this is a rather challenging problem in operator <->
user interface (where it has been proposed in this context), as routing
protocol cannot be used.

Was your point about ISATAP in general, or did you have some method for 
host route discovery in mind for this particular case?

---

From: Fred Templin <[email-masked]>
Date: Thu, 29 May 2003 08:20:50 -0700

>user interface (where it has been proposed in this context), as routing
That's OK. Even better than using a routing protocol is dhcpv6 prefix 
delegation,
with the isatap routers serving as delegating routers. This puts a 
single /64 into
the delegating router's forwarding table instead of a bunch of /128's.

>host route discovery in mind for this particular case?
No - my point was that in fact isatap clients can support many hosts (up to
2**64 when prefix delegation is used) contrary to your assertion that only
a single host is supported.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 May 2003 19:56:30 +0300 (EEST)

> That's OK. Even better than using a routing protocol is dhcpv6 prefix

Careful here: you're proposing to extend ISATAP to be used across multiple 
administrative boundaries -- which is *specifically* has not meant to be 
(AFAIR)!

> with the isatap routers serving as delegating routers.

I assume by "isatap routers" you mean a router supporting ISATAP.

> This
> puts a single /64 into the delegating router's forwarding table instead
> of a bunch of /128's.

This seems irrelevant (in practical terms) in itself.

---

From: Fred Templin <[email-masked]>
Date: Thu, 29 May 2003 09:12:51 -0700

>administrative boundaries -- which is *specifically* has not meant to be 
Nothing of the sort. The isatap client is within the administrative 
domain of
the isatap router. The isatap router serves a /64 dhcpv6 prefix 
delegation to the
client. The client uses this prefix to connect as many additional hosts 
as it wishes
using, e.g., the multi-link subnet model and RA proxies. It's just like 
what happens
when the GGSN serves a /64 to a mobile via the IPv6 PDP context; it has 
nothing
at all to do with multiple administrative boundaries. Again, the main 
point is
that the isatap client can connect many hosts - not just one.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 May 2003 20:27:38 +0300 (EEST)

On Thu, 29 May 2003, Fred Templin wrote:
> domain of the isatap router. The isatap router serves a /64 dhcpv6
> prefix delegation to the client. The client uses this prefix to connect
> as many additional hosts as it wishes using, e.g., the multi-link subnet
> model and RA proxies. It's just like what happens when the GGSN serves a
> /64 to a mobile via the IPv6 PDP context; it has nothing at all to do
> with multiple administrative boundaries. Again, the main point is that
> the isatap client can connect many hosts - not just one.

Could you describe the scenario in more detail?

It seems to me that the approach in above is that ISATAP link-local
addresses would be used between the router and the client.  The client is
in different admin domain as the router (tradeoffs of this might be
manageable), as is in a different admin domain as all the other clients
(which would also appear to be on the same link).

But perhaps I'm missing something here.

---

From: Fred Templin <[email-masked]>
Date: Thu, 29 May 2003 10:46:43 -0700

Pekka Savola wrote:

>addresses would be used between the router and the client.
>
In the simplest cases, yes.

>The client is
>in different admin domain as the router
>
No. The client gets an RA from the router that contains a non-zero router
lifetime and adds it to the default router list. The client is in the 
same admin
domain as the router.

>(tradeoffs of this might be
All the other clients would also be on the same link as the router. Each 
client
can request a dhcpv6 prefix delegation, with the dhcpv6 server implemented
on the router as allowed by the specs. Then, each client can connect 
multiple
additional hosts using the prefix delegation it received from the router.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 May 2003 21:00:35 +0300 (EEST)

On Thu, 29 May 2003, Fred Templin wrote:
> No. The client gets an RA from the router that contains a non-zero
> router lifetime and adds it to the default router list. The client is in
> the same admin domain as the router.

No.  AFAICS, the router belongs to the 3GPP operator.  The client belongs 
to the 3GPP user (user device).  Right?  These are different entities.  
Whether RA is used makes no difference.

> All the other clients would also be on the same link as the router. 

But also on the same link as other clients in the same 3GPP operator (or
maybe the particular GGSN), right?  In any case, it's *NOT* a 
point-to-point link between the router and one client, right?

> Each
> client can request a dhcpv6 prefix delegation, with the dhcpv6 server
> implemented on the router as allowed by the specs. Then, each client can
> connect multiple additional hosts using the prefix delegation it
> received from the router.

That much is roughly clear.

---

From: Fred Templin <[email-masked]>
Date: Thu, 29 May 2003 11:11:37 -0700

>Whether RA is used makes no difference.
OK, but there is no difference between this and the model in which the
GGSN is serving the mobile a native IPv6 PDP context (i.e., the GGSN
belongs to the 3GPP operator and the client belongs to the 3GPP user.)

>point-to-point link between the router and one client, right?
No - it's a multiaccess link just like any other multiaccess link used 
for IPv6.

>That much is roughly clear.
OK.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 May 2003 21:21:07 +0300 (EEST)

> belongs to the 3GPP operator and the client belongs to the 3GPP user.)

Careful: there could be a lot of difference; that is not the original 
ISATAP model.
 
> No - it's a multiaccess link just like any other multiaccess link used 

Thanks for confirmation.  (It isn't 100% clear what you refer to with
"No", but I'm assuming the latter sentence.)

So, other clients are reachable on the same multiccess link, using
link-local addresses.  That seems pretty significant to me.

All in all, it seems ISATAP is applied in a scenario which it hasn't been
originally designed for, but consideration to the differences in scenarios
are overlooked.

---

From: Fred Templin <[email-masked]>
Date: Thu, 29 May 2003 11:53:43 -0700

OK.

>originally designed for, but consideration to the differences in scenarios
We are discussing this application for the first time (as far as I can 
tell),  so I
believe the term "overlooked" is a bit premature.  I believe I have 
convinced
you that there are no functional barriers that keep an isatap client from
connecting multiple hosts. I'll grant you that issues in the trust model 
need
to be dealt with in more detail, however.

Fred
[email-masked]