Subject: Re: [3gv6] Latest version of 3GPP IPv6 Migration scenarios

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Feb 2010 17:45:26 +0200

All,

Here's my review of the scenarios document. Pardon me for being brief.
I intend to follow-up later with some suggested text to address some of
these issues.

The technical report identifies
various
scenarios of transition to IPv6 and co-existence of IPv4 and IPv6,
deployment options and impacts on 3GPP network elements. In
particular:

Identify the transition and
co-existence scenarios of interest for operators and the respective
assumptions and requirements.

Analyze existing IP address
allocation mechanism for IPv6 migration if necessary.

Investigate IPv6 transition
mechanisms for the scenarios identified during the study and
investigate their applicability for 3GPP network, and identify the
compatibility among applicable transition mechanisms.

Identify any impact on 3GPP
network elements.

Provide recommendations on IPv6
transition and co-existence of IPv4 and IPv6 and identify if any
normative work is needed.

The scope section is a bit unclear. Its not clear whether it is talking
about operational, equipment, or standards impacts. It does not define
what the starting point is. We should avoid talking about technical
details like address allocation in this section. I do not think the
third bullet should start from transition tools and try to apply them
to the 3GPP context; I'd much rather see us work from the operator
requirements towards what is needed. Here's a possible rewrite:

"This technical report discusses IPv6 deployment and IPv4-IPv6
co-existence on 3GPP networks. The purpose of this report is to
identify transition and co-existence scenarios of interest for the
operators. The goal is to understand how the 3GPP operators can employ
IPv6 to address their business needs.

The report provides operational guidance and network architecture
advice on how to employ IPv6 for each of the identified scenarios.

Existing 3GPP standards specify the baseline dual-stack IPv6 support
model that is widely supported in existing network equipment. The
report also identifies impacts, if any, on 3GPP network elements that
goes beyond this existing support."

To alleviate the shortage of public
IPv4 addresses, the usage of private IPv4 addresses can be considered
(e.g., the RFC 1918 addresses). The utilisation of private IPv4
addresses should not require new procedures to be specified for the
UE in order to ensure maximum applicability in a network with an
early dual-stack UE population.

... should not require ... => ... does not require ...

I.e., existing devices are all already capable of this.

The challenge of this scenario lies in
the limited number of private IP addresses. In case more than 16
million UEs are active (i.e., have an active PDP context/EPS bearer)
in the same network at the same time, the network will run out of
private IPv4 addresses. In order to avoid this, the operator may have
to consider assigning the same IPv4 address to multiple UEs.
Nevertheless, the operator expects that legacy IPv4 applications
continue to work in this situation.

As above, the text is unclear about the actual impacts. It is a fact
that the UE and the legacy IPv4 applications are not affected (any more
than they are affected by NATs in general).

It might be a different question whether current GGSN equipment
supports this mode of operation. It would certainly be a very useful
thing to do.

5.1 Scenario 1:
Dual-stack connectivity with Limited Public IPv4 Address Pools

This is a valid scenario, but I think the description leaves something
to be desired. It is presented as turning on dual stack will magically
bring more available IPv6 services. It does not, but there are specific
things that an operator can do in order to increase the fraction of
IPv6 traffic. Google over IPv6 and similar arrangements, for instance.
(Speaking as someone who suddenly noticed this week that all youtube
traffic in his home is now on IPv6.)

5.3 Scenario 3: UEs with IPv6-only
connection and applications using IPv6

The operator decides to only assign
IPv6 prefixes to the UEs due to e.g. shortage of IPv4 addresses or to
address use cases, in which it appears beneficial - from an
operational perspective - to only assign IPv6 addresses (e.g. m2m
scenarios). UEs with IPv6-only connectivity running applications
using IPv6 should however still be able to access both IPv4- or
IPv6-enabled services.

Based on this scenario description,
two
use cases need to be considered:

1) The UE,
configured only with an IPv6 prefix, has to be able to access IPv4
services

2) The UE,
configured only with an IPv6 prefix, has to be able to access IPv6
services.

I have an issue that may relate to multiple scenarios, but I am
bringing it up here.

The scenarios are focusing on the IP deployment part only, and leave a
lot of contextual information away. For instance, I can imagine a M2M
deployment scenario where pure IPv6 only makes a lot of sense. And for
that I think only use case 2 makes sense. But for other applications
the situation can be very different. For instance, if you are offering
Internet access to general purpose terminals, your requirements can be
very different. Use case 1 makes more sense now. But then again you
cannot assume all current devices support IPv6, so how do you arrange
for just the IPv6 capable devices to use this type of a network? Is
there a special APN, and how is that provisioned? If we need a special
APN and another one to support the legacy devices, isn't this kind of
like dual stack, so why were we doing this to begin with?

You do not necessarily need to answer these specific questions but I
would like see complete scenarios so that I can evaluate whether there
some deployment issues in them.

5.4 Scenario 4: IPv4 applications
running on a Dual-stack host with an assigned IPv6 prefix and a
shared IPv4 address and having to access IPv4 services

In this scenario an IPv4 application
running on a dual-stack UE requires to access IPv4 services without
the operator having to allocate a unique non-shared (private or
public) IPv4 address to the UE. The dual-stack UE running these
applications uses an
IPv4 address that is shared amongst many other UEs, and uses
an IPv6 prefix.

I don't understand this. Why is it a business requirement that each
device must have a shared IPv4 address, without doing it the usual way
(RFC 1918 and a NAT44)? One possible reason for doing this would lack
of sufficient space in RFC 1918 address ranges, but if so, how is this
scenario different from 5.2?

6    High level requirements

The high-level requirements are to cover all the scenarios described in
Section 5 in roaming and non-roaming cases. The IPv6 migration
architecture should take into consideration any possible impacts to the
policy architecture.

This section is still empty.

7 Solutions and functional flows description

I am not sure this document should talk about solutions, and in
particular solutions at a flow level. Network diagrams and explanations
of how tools such as DS, NAT44, NAT64, etc. can be used would appear to
be a better level of description.

8                Evaluation

TBD

Recommendations

TBD

Its not clear to me what the contents here should be. In any case,
these sections are still empty.

Annex B: Overview of Solutions for IPv6
Transition

Its not clear to me how this section connects to the rest of the
document. Also, the list of potential IPv6 transition tools is far from
complete.

Jari