Subject: [3gv6] Comments on draft-korhonen-v6ops-3gpp-eps-00

From: Hui Deng <[email-masked]>
Date: Fri, 19 Feb 2010 22:47:17 +0800

Dear authors,

I read through this document, it gives a very clear tutorial
about 3GPP architecture and IPv6 related information. it does help
this workshop.
and I have the following comments:

1) it seems that DSMIP6 hasn't been mentioned here which also need
modify the host.
2) Section 6.3, it doesn't talked when the IPv6 prefix/address will be
assigned.
3) Section 8.1, overlapping Ipv4 address doesn't support host to host
communication with Ipv4 applications.
hope it could be clarified.
4) Because there will be different network deployment, some network
might not support IPv6, then
we may need translation for the roaming scenario.
5) both fall back to IPv4 or translation are both good canddiates, it
may need more text there.
6) the explanation of scenario 4 is not sufficent in the appendix.

Last) this document says EPS may some level support dual stack
capable, but that doesn't prove
the whole network such as (charging, firewall, lawful interception,
terminal, service platform, BOSS, routers, applications et al.)
then we couldn't make the recommendation based only on EPS, but u
could make only about EPS, then question continue goes
to where is translation, out of EPS? I guess those haven't been
clarfied suffcient.

Many thanks for the document.

-Hui

---

From: jouni korhonen <[email-masked]>
Date: Mon, 22 Feb 2010 16:58:12 +0200

Dear Hui,

Thanks a lot for reviewing the draft. I have few comments inline.

> 1) it seems that DSMIP6 hasn't been mentioned here which also need

DSMIP6 is inherently an IP mobility solution and not mandatory for the base EPS deployment. Therefore, we do not see a reason to discuss it as a part of this draft giving an overview of the baseline IPv6 in EPS.

> 2) Section 6.3, it doesn't talked when the IPv6 prefix/address will be

Right. We'll mention that.

> hope it could be clarified.

Right. I think we can mention that overlapping IPv4 addresses in EPS cause the same existing issues what any NAT:ed Internet connections have regarding referrals, end-to-end connectivity and such.

> we may need translation for the roaming scenario.

That falls partially into roaming agreements to tackle as there is more involved than just the technical aspect. I would find it odd trying to solve roaming contract misalignments using translation. There are some tricks available but certainly that should not be a) visible to roaming environment, and b) not require visited operator to bother with it if translation is aimed to help out the home operator.

> may need more text there.

We could mention that in order to roaming to work properly between two operators, they also should agree on supported set of protocols.

> 6) the explanation of scenario 4 is not sufficent in the appendix.

Right. However, the whole Appendix A is there just for general information what is going on regarding 23.975. That is not really part of the current EPS IPv6.

> terminal, service platform, BOSS, routers, applications et al.)

This is true. The whole picture is much larger than just IPv6 bearers and such in EPS core. But I also think those are not really in the scope of what the draft is aimed for. We did not, for example, include any operations & management components into illustrated architecture pictures, but just concentrated on what is on the bearer level path between the MN and the anchoring gateway.

> to where is translation, out of EPS? I guess those haven't been

I did not quite catch the last sentence.

> Many thanks for the document.

You are welcome. We take these into account for the revision.

- Jouni

> 
> -Hui
> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6

---

From: <[email-masked]>
Date: Tue, 23 Feb 2010 18:16:36 +0100

Hi Hui,

Thanks for the review and comments. A few clarifications inline below:

> 1) it seems that DSMIP6 hasn't been mentioned here which also need

Not sure if this comment about DSMIP6 is in the context of this I-D as we do
not really mention it in the document.
Mobile IPv6 was designed to be an integral component of the IPv6 stack (if
you go back to the thinking in the late 90s). However that has not really
happened. As a result Mobile IPv6 and subsequently DSMIP6 do require that
the client be implemented on the host. Mobile IPv6 has been an RFC since
2004 and DSMIP6 more recently in addition to the protocols being a part of
the 3GPP standards for the S2c interface.

> 2) Section 6.3, it doesn't talked when the IPv6 prefix/address will be

Good point. It would be useful to indicate the address assignment process as
part of the flow. Will include it in the next rev.

> hope it could be clarified.

Can you give an explicit example of an application that would not work when
the hosts in a 3GPP network have overlapping IPv4 addresses?

Without a clear application example, it is hard to really make a case for
host-to-host communication. IMO there is no issue with having IP sessions
between hosts attached to a 3GPP network which have overlapping IPv4
addresses. The fact is that the packets will traverse the P-GW or in some
cases a NAT44 network element. But as far as the ability to communicate
between IPv4 hosts with the same address is concerned, there is really no
issue. 

> we may need translation for the roaming scenario.

Some 3GPP access networks may not support IPv6 and that will be the case for
many years. It implies two things:
1. IPv6 services and connectivity is unavailable when the UE roams into
those networks. 
2. The UE can obtain IPv6 connectivity via the home operator by tunnelling
IPv6 in IPv4. 

Translation from 6to4 (NAT64) is at least viewed in BEHAVE as a solution for
transition. But I really don't see the need to do translation from 4to6.
And as has been discussed in the past workshop, it is better to encapsulate
than to translate. 

> may need more text there.

Fall back to IPv4 IMO is the most pragmatic and something that would be
needed to ensure that there is minimum disruption to the end users. I am not
so convinced about the need for translatin at this time.

> 6) the explanation of scenario 4 is not sufficent in the appendix.

Again, after reviewing the 3GPP TR, I see scenario 4 as simply being a
variant of scenario 2. So unless you can explain what is the difference in
scenario 4, I am at a loss to add more text to clarify. If you could provide
some text with a better explanation that would of course be appreciated.

> to where is translation, out of EPS? I guess those haven't been

What the document is hoping to explain is the fact that the 3GPP network
architecture is capable of providing IPv6 connectivity to hosts and it does
support a dual-stack deployment model today.
Your point above is more of an operational issue. In order to enable IPv6
connectivity and services in a commercial network, you will need to have
other systems which form part of your overall deployment to be v6 capable as
well. The I-D is not attempting to explain the IPv6 capability of every
component or interface of the 3GPP architecture.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 23 Feb 2010 10:23:10 -0800

Adding to Raj's comment.

> between IPv4 hosts with the same address is concerned, there is really no

Yes, I also think we need a for more specific example. When we bring the UE
to UE communication issue in the context of overlapping IP, we need some
clarification on the complete usage. Its just creating confusion.

- First, the most recommended approach for enabling UE to UE communication
is to go with IPv6. For voice services, its any way the direction. This is
not a legacy requirement. So, the choice of IPv6 makes lot of sense.

- Now, if we still want to support IPv4 for UE to UE in the context of new
services, we need to understand the configuration, how a UE is able to
resolve the other UE's IP address ? Is there DNS provisioning ? Is there an
app server that is providing the peer lookup's. With out all these details,
talking about UE to UE with overlapping IP does not provide a proper context
for discussion. 

- The solution can be made to work using number of ways. But, we need to be
clear if this a legacy app requirement, or a new requirement and on all
aspects of provisioning and the service components.

Sri

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 23 Feb 2010 14:27:48 -0500

Hi Raj,

> Can you give an explicit example of an application that would 
> not work when the hosts in a 3GPP network have overlapping 
> IPv4 addresses?
> 
> Without a clear application example, it is hard to really 
> make a case for host-to-host communication. IMO there is no 
> issue with having IP sessions between hosts attached to a 
> 3GPP network which have overlapping IPv4 addresses. The fact 
> is that the packets will traverse the P-GW or in some cases a 
> NAT44 network element. But as far as the ability to 
> communicate between IPv4 hosts with the same address is 
> concerned, there is really no issue. 

(BTW, this issue has been under discussion on the thread
draft-koodli-ipv6-in-mobile-networks-00) 

If there are overlapped private IPv4 addresses, you have to traverse the
NAT.

The gateway can hairpin the packets without traversing the NAT when the
addresses are unique.
This provides better routing (when the NAT is not on the gateway) and
performance (when NAT is on the gateway, since you don't need to
traverse the NAT)

A meta issue is: when you have a deployment choice, why deliberately
create a situation where the Src and Dst IP addresses are the same in an
IP packet, and then look for workarounds? What happened to identifying
each end-point with a unique IP address? (to the extent we have to live
with NAT, we should, but we don't have to make this transition more
painful IMHO).

Regards,

-Rajeev

---

From: <[email-masked]>
Date: Tue, 23 Feb 2010 20:56:50 +0100

Hi Rajeev,

> If there are overlapped private IPv4 addresses, you have to traverse the

And I don't see a significant downside to it. It would be useful to
understand what applications would for example suffer from having to
traverse a NAT. Or if the concern is something else.
I have seen comments in other emails about having an optimized route between
the hosts. In a 3GPP network which basically has P2P links between the UE
and the P-GW, I don't see what kind of route-optimization would be
accomplished anyway between UEs attached to the same GW or different GWs.

> The gateway can hairpin the packets without traversing the NAT when the

Yes. And the address space for hosts within the context of a single GW could
be unique. But in an operator domain with multiple GWs, the address assigned
to the hosts which are attached via different GWs could be the same.
But in such a model there is really no issue again since NAT44 would deal
with the situation.

> IP packet, and then look for workarounds?

Given that a single P-GW capacity does not exceed the IPv4 private address
space range in terms of connections supported, I do agree that overlapping
IPv4 addresses within the scope of a single GW is a moot point. And if the
addresses overlap within the scope of a single operator domain, that could
be quite easily handled with NAT44.

> What happened to identifying

I guess we all agree that unique identification of end-points via an IP
address is only possible with IPv6. But given the legacy of IPv4, we have to
figure out a way to continue providing service and connectivity to
devices/applications/networks with the least anount of pain.

Rgds,
-Raj

---

From: jouni korhonen <[email-masked]>
Date: Tue, 23 Feb 2010 22:16:58 +0200

Hi,

> aspects of provisioning and the service components.

Agree.. This is the text I added to Section 8.1 the other day for -01.. might still not be perfect but assumes that unless private addresses are from the same managed block and/or anchored to the same gateway, the problems we face are known from Internet & private address/NATed connections. There is actually nothing new in this scenario. There are set of known issues that are not in any way unique to EPS. There are a set of known solutions with a set of identified constraints on those solutions. Again nothing specifically EPS specific.

   ...
   unique.  This has the obvious and know issues of NATed IP connection
   in the Internet.  Direct host to host connectivity becomes
   complicated, unless the hosts are within the same private address
   range pool and/or anchored to the same gateway, referrals using IP
   addresses will have issues and so forth.  However, these are generic
   issues and not only a concern of the EPS.  In general this is not
   seen as a major issue in the EPS for the following reasons:

- Jouni

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 23 Feb 2010 15:31:53 -0500

> > If there are overlapped private IPv4 addresses, you have to 
> traverse 
> > the NAT.
> 
> And I don't see a significant downside to it. It would be 
> useful to understand what applications would for example 
> suffer from having to traverse a NAT. Or if the concern is 
> something else.

If an Application Server is located in the operator network, how would
multiple MNs register with the AS without going through the NAT? It's
not clear to me. The gateways can do pass-through for selected traffic,
and that would work when the addresses are unique. 

> I have seen comments in other emails about having an 
> optimized route between the hosts. In a 3GPP network which 
> basically has P2P links between the UE and the P-GW, I don't 
> see what kind of route-optimization would be accomplished 
> anyway between UEs attached to the same GW or different GWs.

Even at the PGW, it's better to hairpin than to traverse the NAT IMHO.
Why do you have to traverse if you don't need to?

> 
> Yes. And the address space for hosts within the context of a 
> single GW could be unique. But in an operator domain with 
> multiple GWs, the address assigned to the hosts which are 
> attached via different GWs could be the same.
> But in such a model there is really no issue again since 
> NAT44 would deal with the situation.

With multiple gateways, there is no issue since what comes out of (S)Gi
interface is a public IPv4 address.
In other words, the MNs in different gateways don't communicate using
the private IP addresses (i.e., they go through respective NATs)

> Given that a single P-GW capacity does not exceed the IPv4 
> private address space range in terms of connections 
> supported, I do agree that overlapping
> IPv4 addresses within the scope of a single GW is a moot 
> point. And if the addresses overlap within the scope of a 
> single operator domain, that could be quite easily handled with NAT44.

Each gateway doing NAT44 means there will be overlapping addresses
within the operator domain but they are distributed to each gateway
(which means unique pool per gateway)

> > each end-point with a unique IP address? (to the extent we have to 
> > live with NAT, we should, but we don't have to make this transition 
> > more painful IMHO).
> 
> I guess we all agree that unique identification of end-points 
> via an IP address is only possible with IPv6. 

Yes. Even with private IPv4, you still have a choice to provide a unique
IPv4 address with limited scope.

> But given the 
> legacy of IPv4, we have to figure out a way to continue 
> providing service and connectivity to 

Agree.

-Rajeev

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 23 Feb 2010 18:01:27 -0800

> host-to-host communication. IMO there is no issue with having IP sessions

I asked for this from the people saying dual-stack is the way forward,
but never got a response.  What is the name of the application that
requires IPv4 and will not do IPv6?  Which application is it that will
dictate my architecture and require me to not do IPv6-only for
mass-market UEs?  Which application works with NAT44 (today's world)
but will not work with NAT64 (tomorrow's world)?  In my view, most
users will never know that they don't have an IPv4 address when i
change it to IPv6.

Without a clear answer, I am not sure why people keep pushing
dual-stack + NAT44 when i can do single stack IPv6 + NAT64.

---

From: Zhen Cao <[email-masked]>
Date: Wed, 24 Feb 2010 15:23:09 +0800

> DSMIP6 is inherently an IP mobility solution and not mandatory for the base EPS deployment. Therefore, we do not see a reason to discuss it as a part of this draft giving an overview of the baselin…

Could you please search TR23.975 v.0.3.1? DSMIPv6 is there and need discussion.

> Right. We'll mention that.

Thanks.

> This is true. The whole picture is much larger than just IPv6 bearers and such in EPS core. But I also think those are not really in >the scope of what the draft is aimed for. We did not, for example, include any operations & management components into >illustrated architecture pictures, but just concentrated on what is on the bearer level path between the MN and the anchoring >gateway.

But I believe this is crucial for dual stack. If the whole network
impact is not clear yet technically, could we make it the base line,
it is dangerous.

---

From: Zhen Cao <[email-masked]>
Date: Wed, 24 Feb 2010 15:40:24 +0800

> the 3GPP standards for the S2c interface.

So you agree that modifying the host is not indeed an issue. Thanks.

> the hosts in a 3GPP network have overlapping IPv4 addresses?

For example, Bit Torrent application. If the BT server give the
application the same IPv4 address, it fails.

> And as has been discussed in the past workshop, it is better to encapsulate

You do believe NAT64 but not NAT46. But NATPT has existed for a long
time, that NAT46 has been convinced by most people. And we have it in
our network.

> so convinced about the need for translatin at this time.

It does not matter. You prefer double signalings, but we prefer translation.

> some text with a better explanation that would of course be appreciated.

Scenario 4 has been understood by companies in last SA2 meeting,
including Nokia.

> component or interface of the 3GPP architecture.

If the operational issue is resolved, how could we make
recommendations just base on part of the story.

---

From: <[email-masked]>
Date: Wed, 24 Feb 2010 18:29:49 +0100

Inline: 

> So you agree that modifying the host is not indeed an issue. Thanks.

I don't know how you came to the conclusion from the text above that
modifying a host is not an issue :) You must have a different interpretation
engine. 

> application the same IPv4 address, it fails.

This application works quite well in todays IPv4 internet where many hosts
sit behind NATs and essentially have the same address. Why would it be any
different in the 3GPP network?

> time, that NAT46 has been convinced by most people. And we have it in

Please refer to RFC4966 and the recommendation therein.

> It does not matter. You prefer double signalings, but we prefer translation.

Obviously you have made up your mind and are unwilling to consider anything
else. 

> Scenario 4 has been understood by companies in last SA2 meeting,

Right.. And as I said it is just a variant of scenario 2. I don't see a good
enough reason for SA2 to include scenario 4 at all. But that is a 3GPP
decision. 

> recommendations just base on part of the story.

The I-D does not aim to explain all components of the equation. 3GPP can
develop the rest of the details.

-Raj

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 24 Feb 2010 09:53:11 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Zhen Cao
> Sent: Tuesday, February 23, 2010 11:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [3gv6] Comments on draft-korhonen-v6ops-3gpp-eps-00
...
> application the same IPv4 address, it fails.

BitTorrent does not "fail" in that situation.  As described
in draft-boucadair-behave-bittorrent-portrange, when multiple 
BitTorrent clients have the same public IPv4 address and are 
downloading or uploading the same time, BitTorrent operates either 
(a) slower or (b) allowing one download (or upload) at a time.  
This behavior is controlled by the *remote* BitTorrent peer's 
setting of bt.allow_same_ip.  This BitTorrent behavior is 
part of BitTorrent, and intended to prevent a user from
using more than their fair share of download bandwidth from
the swarm.

A detailed analysis of BitTorrent's behavior with shared IPv4
addresses was conducted in 2009 and published here,
http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02
and the results were also presented at one (or two?) 
face-to-face BEHAVE meetings.

-d

> make a case for

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 27 Feb 2010 19:36:04 -0800

Catching up with some mails from last week.

> users will never know that they don't have an IPv4 address when i

Hi Cameron,

This is a very good comment. From technical perspective it is true that all
applications that work over NAT44, should logically work with NAT64 (tunnel
mode for moving the packet to NAT64 function), industry may need some
experience with DNS64 and the issues around it. But, if a deployment chooses
to just go with IPv6-only approach, it should be perfectly fine and we
should ensure we have all the required tools to support that deployment.

But, I do not know how many deployments will go with that approach in the
very near term, But that should indeed be the absolute goal of IPv6
migration efforts as you emphasized. Turning of IPv4 may not be as simple as
it sounds, I'd think it should be a step in the IPv6 migration, but not sure
if that should be the mandated first step. We simply do not have the
experience with NAT64, DNS64 or any side affects related to turning off
IPv4. If this group makes that recommendation or not, not sure any operators
would dare to do that. But, I agree, there should not be any technical gap
and we should ensure, we have the needed tools for supporting that
deployment.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 27 Feb 2010 20:09:26 -0800

On 2/27/10 7:36 PM, "Sri Gundavelli" <[email-masked]> wrote:

> mode for moving the packet to NAT64 function),

Correction. I intended to say, non-host based translation approaches, not
exactly about tunneling...

> industry may need some

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 27 Feb 2010 21:27:29 -0800

> and we should ensure, we have the needed tools for supporting that

Sri,

Good feedback.  And, thanks for your support.  Regarding nobody would
dare to do it or has large scale experience with IPv6-only / NAT64 /
DNS64 , the same can be said for all the other 4 methods in the mobile
/ 3G context, right?  Of the 4 scenarios, i know scenario #3
(IPv6-only) will be working on a production national network at the
3GPP meeting San Francisco.  It is possible to rig the IPv6-only demo
from T-Mobile to demonstrate DS ... but thats not why i rolled out an
IPv6 APN...

Now, you know T-Mobile USA has an IPv6 beta APN in use and on the air.
 Gary Jones from T-Mobile will have a T-Mobile IPv6-only phone and so
will Raj Patil from Nokia.  Please explore the solutions that are
on-hand at the meeting.  Tangible solutions like IPv6-only  that work
both in theory (as you mentioned) and in your hands (as i have shown
in video) certainly count for a lot, right?  So when we talk about not
many operators doing IPv6-only, lets count the IPv6 deployments from
*network operators* on-hand at the 3GPP meeting.  Lets see who can
demonstrate on the production network a very good user experience
using one of the 4 3GPP scenarios.

I have tried to be rigorous in choosing the IPv6-only strategy and
question the canonical answer of just doing dual-stack.  Meaning, i
have looked at the end-state, IPv6-only for all of the Internet, and i
have charted the course backwards to where we are today.  The
quickest, most direct, and least costly is IPv6-only as a new service
for new devices.  This deployment model starts out as a small part of
the network operator's portfolio of handsets and services but grows to
a dominant share over time.  Nobody can or should turn IPv4 off in the
near or medium term.  In my network and many others, 99% of the data
sessions go via NAT44.  The major difference between NAT44 and NAT64
is the the numeric identifier of the UE is of a different format, not
too much else is different.  That said, you can see that I am very
comfortable with NAT44 since that is how I run my network today.  And,
naturally, i see the similarities between NAT44 and NAT64 and i
conclude that it is a suitable technology going forward.  I look at my
traffic profile and 95% of the traffic is web and email, so i know the
risks of one-off protocol incompatibilities are small.

DNS64 is really not very complicated at all, from an operators
perspective.  I personally set it up for the beta network, and i am
not exactly Einstein or a DNS admin, but it works well.

One final note, operators either directly or indirectly pay for each
PDP .... busy hour PDP capacity.  Dual-stack makes PDP cost 2x.  It is
in no way acceptable.  How can I sell the VP of engineering on IPv6
when i tell him it will cost 2x to deploy IPv6 in the packet core (pre
Rel 8)?  As opposed to IPv6-only with NAT64, i can tell him the PDP
cost is the same as today and my NAT cost goes down because in NAT64
native IPv6 flows (today to Google!!!) by-pass NAT and flow directly,
thus less aggregate NAT state.  IPv6-only saves me money and it works
today with NAT64, no other solution saves me money and works today.
Not to mention we are re-instating end-to-end communication for IPv6
flows ... thus incenting  broader IPv6 adoption and innovation in the
IPv6 space.

I do very much appreciate your support and review of this.  I am VERY
optimist about IPv6-only because i have seen it work in my hand and
have modeled both the cost savings and scaling properties, not to
mention the benefit of immediate time to market.

Regards,
Cameron

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 28 Feb 2010 20:12:34 -0800

Hi Jouni,

On 2/23/10 12:16 PM, "jouni korhonen" <[email-masked]> wrote:

> Agree.. This is the text I added to Section 8.1 the other day for -01.. might
> still not be perfect but assumes that unless private addresses are from the
> same managed block and/or anchored to the same gateway, the problems we face
> are known from Internet & private address/NATed connections. There is actually
> nothing new in this scenario. There are set of known issues that are not in
> any way unique to EPS. There are a set of known solutions with a set of
> identified constraints on those solutions. Again nothing specifically EPS
> specific.
> 

The text in -01 is fine.

    4.  New services requiring direct connectivity between hosts should
       be build on IPv6.  Possible existing IPv4-only services and
       applications requiring direct connectivity can be ported to IPv6.

The approach is that for UE to UE, specifically when both the peers are IPv6
enabled and given that these are new apps, its logical that we use IPv6. The
claim that it works for host-based translated approach is not correct, the
ALG applicability point is not there, with the peer having no ability to
distinguish between translated packet and a real packet. Above all, its
simply does not make sense not to use IPv6 for those flows, when both the
peers are IPv6 enabled. Instead of translating the IPv4 packet and sending
it as an IPv6 packet to a peer, after some magic mapping between the
addresses, its better to send it natively. Also, similar challenges exist,
if the AFTR function is collocated with the gateway or outside, there still
needs to be registration mechanisms for registering the NAT'd mapped
addresses with the lookup functions. So, it logical to move such forward
looking apps to IPv6.

Couple of other questions/clarifications.

1. I¹d also add to section 1 (Objectives of transition), to support
IPv6-only UE¹s. Ignoring the order of steps in IP6 migration, but its one of
the goals as Cameron stated. I think, we cannot leave dual-stack as the
final goal of these efforts, we should at least state that requirement. You
may want to consider. And I believe we have the needed tools, if one uses
them or not.

2. Section 5.2: IPv6 Address Configuration.
I assume support exists for Stateless Autoconf using Privacy Extensions.
RFC-3041/RFC-4941 ? Or, is it just 4862 support ?

3. In Section 2.2, is there a mechanism for the apps on the host to use a
specific APN ? Should that be specified ?

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 28 Feb 2010 20:14:36 -0800

Hi Cameron,

Thanks for the discussion.

Glad to see your efforts on getting the IPv6-only demo's. That experience is
critical.

Best Regards
Sri

---

From: jouni korhonen <[email-masked]>
Date: Mon, 1 Mar 2010 08:38:59 +0200

Hi Sri,

Thanks for reading the latest version of the draft. Some answer below..

>> identified constraints on those solutions. Again nothing specifically EPS

Good.

> 1. I’d also add to section 1 (Objectives of transition), to support
> IPv6-only UE’s. Ignoring the order of steps in IP6 migration, but its one of

Right. We think about it what to put there. Still, a dual-stack UE that manages to open IPv6-only PDN connection shows up to the UE stack as an interface that has only IPv6 address(es). The dual-stack UE is still able to function on IPv6 side and it is up to the operator to provide e.g. NAT64 type of functionality, if they so wish. That should be transparent to the UE anyway.

> RFC-3041/RFC-4941 ? Or, is it just 4862 support ?

EPS currently does/mandates RFC4862. However, EPC does not really care about the interface identifiers (except for the step when they configure link-locals). Therefore, RFC3041/4941 should work out of box. The usefulness of these extensions are, though, questionable because the UE is still identified per /64 prefix, so changing the interface identifier does not really provide any extra privacy. 

> specific APN ? Should that be specified ?

On some OSes, like in symbian applications select the access/PDN based on the APN. So you basically can specify the APN per application. On some other OSes multiple APNs could map/do map to separate PDN connections that again map to different prefixes/AP addresses, so in that case it would require the application to bind its sockets to specific address. Then on some OSes (actually cellular modem drivers) you can just open one APN/PDN connection.. where you don't have much choices to play around then.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Mon, 1 Mar 2010 08:40:07 +0200

Hi Sri,

Good.

- Jouni