Subject: RE: 3gpp-analysis-05: miscellaneous non-critical issues

From: <[email-masked]>
Date: Thu, 2 Oct 2003 15:45:43 +0300

Andreas,

I'm glad to get more operator comments on the v6ops mailing list; thanks for your comments! Some short replies below.

-----Original Message-----
From: ext [mailto:[email-masked]]
Sent: 02 October, 2003 09:55

Well, let's add a comment from an operator here...

Here are some facts:
- Today's 2.5/3G networks are running on IPv4.
- Today's economic situation is quite difficult.
- Nobody operating a network wants to touch a running system if not
absolutely necessary.

It is therefore very much needed to think about a phased introduction of
IPv6. It is just _not_ realistic to think of a direct move from IPv4 to
native IPv6 - let's make this clear here!

Operators _need_ mechanisms to introduce IPv6 in phases. A first phase
should be fully non-intrusive, cheap but still secure. Tunneling from
the UE (e.g. using ISATAP) seems to perfectly be suited to meet these
requirements. 

I expect the v6ops WG to write guidelines that help the operators in the
introduction of IPv6 in their networks. Such guidelines just have to
consider a phased introduction. Everything else is just not realistic
and not of use for operators. I am looking forward to such documents
from this group.

JW: I know that the current situation is not an easy one. And I fully agree that the principle of phased IPv6 induction is correct.

I can also see that IPv6 can be tested / demonstrated etc. using tunneling in the UE. But putting basic IPv6 support in the GPRS network is not that difficult. IPv6 support in a GPRS nw includes (at least) the following points:

* Upgrading (a) GGSN to support IPv6 PDP contexts (that basically means dual stack support in the GGSN). This is only needed on the "upper IP layer" / user layer in the 3GPP architecture. Network layer (below GTP tunnels) can still be IPv4. See RFC3314, Figure 2.
* SGSN should support IPv6 PDP context signalling (especially if charging is considered..), i.e. it must be possible to activate an IPv6 PDP context.
* HLR support for IPv6
* IPv6 Access Point Names should also be configured to the packet core DNS
* you also might want to put up a (configured) IPv6-in-IPv4 tunnel from the GGSN e.g. to the IPv6 island (can be in the operator's network or elsewhere) that provides IPv6 services
* IPv6 capable firewall can also be considered

According to my current understanding, the above does not require big investments and in many cases software upgrades are sufficient.

Furthermore, introducing (some) IPv6 support in the network does not cause problems with the current IPv4 network, i.e. IPv6 can be run simultaneously without disrupting IPv4 traffic! This is not a 3GPP-specific thing; this is one of the good sides of the dual stack deployment. There is no need to immediately move from native IPv4 to native IPv6 support in the cellular networks.

Best Regards, 
		-Juha W.-

---

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Fri, 3 Oct 2003 16:32:22 +0200

>  > > => I didn't ask to have "don't tunnel from the UE"
>  > > in the text. I was commenting on the new text.
>  > > I don't think the draft should include opinions on how 
>  > > easy it is to upgrade to V6 and whether that involves
>  > > SW or HW upgrades. It's not useful. 
>  > 
>  > It seems very useful to me, although the wording may not be 
>  > optimal.  If 
>  > upgrading to v6 is relatively easy, we can recommend 
>  > upgrading to IPv6.
> 
> => I'm afraid that we cannot make a general assessment 
> here of how "easy" it is to upgrade to v6. Leave it to
> the operators because we have no "one statement fits all".
> As a general comment. I'd like to minimise opinions in 
> IETF specs and keep it concrete and straight forward. 
> 
> If operators think it's easy to upgrade, I'm sure they
> will do what they need to do. Putting it in the draft
> will not "make them believe".

I think this is not true at all.  Remember that we're not specifying a 
protocol here .. but giving recommendations on deployment.  We can, and 
should, "make them believe".  Education is one important part of the 
solutions specs.

(KEM) Falling behind on emails but this one caught my eye.
I don't think operators are as dumb as you are making them. 
Many have been working on IPv6 for some time and will not just
blindly accept what is in a draft. The reasoning is important.

>  > >    That's 
>  > >  > also expected to happen during the early phases of 
>  > >  > transition.  If the 
>  > >  > operator doesn't care about IPv6 users at all, the users can 
>  > >  > just stay out 
>  > >  > of those networks.
>  > > 
>  > > => The point is: Your operator cares about v6 and wants 
>  > > to offer you the services that IPv6 enables 
>  > 
>  > Right so far..
>  > 
>  > > while you're
>  > > roaming. 
>  > 
>  > If your SP wants to enable services while you're roaming, 
>  > your SP needs to 
>  > convince those networks it has roaming agreements with to enable
v6? 
> 
> => No way... What's the incentive for another operator to do that? 

Not to lose money from the customers it would bring, simple as that.

(KEM) From what I know your thinking is way too simplistic.
We should leave the business decisions to those who know how to
run a mobile network. 

>  > > It is not relevant how the visited operator feels
>  > > about v6. 
>  > 
>  > I fear this is very relevant.  Your home operator can't 
>  > really offer what 
>  > it can't provide.  So, it should not *guarantee* you IPv6 
>  > services while 
>  > you roam, as simple as that..
> 
> => Well, it can when tunneling is used. But you seem
> to say that it "shouldn't", despite the fact that it
> can.

Yeah, it *could* provide a service, if we recommend a tunneling
mechanism
(or multiple ones) to be implemented in all UE's.  If it isn't
implemented 
in all UE's it's not going to fly.  So, we have to balance whether we
want 
the transition mechanism at the UE, or not; and which kind of transition

mechanism it would be (i.e., whether there would be any problems in
that).

Configured tunneling could be acceptable to me _in the roaming case
(only)_, but a bit unsure yet.  Depending on how 3GPP architecture is
built up, "automatic this" (in conjunction with v4 PDP context
activation 
procedures), this the difficulty could range from trivial to really 
difficult.

(KEM) So you've basically described ISATAP, not configured tunnelling.

>  > > But the point is, 
>  > > requiring an operator to support v6 will not necessarily
>  > > eliminate tunneling when the UE roams to another network
>  > > (whose managers don't want to support v6 and will implement
>  > > v6ops recommendations). 
>  > 
>  > So, don't use v6 in those networks then?
> 
> => Unless you provide a serious reason we can't support
> this suggestion, especially when there are ways of achieving
> this. 

Ways which may jeopardize the simplicity and robustness of the 3GPP 
transition.

(KEM) Simplicity in terms of Operations? I wouldn't think so.

>  > > => But in this case the visited network doesn't care about 
>  > > v6. I'm not sure how eliminating the use of V6 through 
>  > > a tunnel will give the visited network an incentive to
>  > > deploy v6.
>  > 
>  > For example, if the customers select a different operator 
>  > when they roam
>  > because the one they tried first doesn't support v6 
>  > ("v4-only operator
>  > loses customers and thus money"), I guess the operator which didn't
>  > support v6 would start to see some benefit in deploying v6 
>  > if the number
>  > of users warrants that.  There could also be some PR 
>  > gains/losses involved
>  > here.
> 
> => I just can't relate this to what's happening today.
> This is really speculative and I prefer to keep the
> draft technical and concrete. The draft doesn't mandate
> tunnelling but it doesn't discount it either. I don't
> see any good reasons for discounting it. If people think
> it's too complex (I don't) then they won't implement it 
> or deploy it. This is not our call though. This is up to vendors
> and operators to choose.

It is our business to make the best recommendations we can.  Saying "do
whatever you want [or whatever some others seem to be doing]" or listing
3-4 different options of possible ways forward is not useful advice.  We
should figure out which recommandations are best, and if someone chooses
to ignore them for whatever reason, that's not our problem.

(KEM) Being reasonable and getting IPv6 deployed is our business.
Being unreasonable and unrealistic will automatically mean that
other solutions will be sought. I don't want the latter to happen.

/Karim