Subject: [v6ops] comments on draft-ietf-v6ops-v6-in-mobile-networks

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Sep 2010 14:54:06 -0700

"When deploying IPv6 in mobile networks, certain unique challenges
   arise"

--I would also say opportunities, like removal of NATs and keepalives
that improve battery life and applications performance (e2e restored)

"In the following, we primarily focus on translation based mechanisms
such as NAT44 (i.e., translation from public IPv4 to
   private IPv4 and vice versa) and NAT64 (i.e., translation from
public IPv6 to public IPv4 and vice versa)."

--This is because the fundamental 3GPP architecture already allows for
dual-stack operations, there is already a tunneling infrastructure
with GTP, and there is really RFC1918 and public IP exhaust issues.

"In order to delay the exhaustion of public IPv4 addresses, this IP
address needs
   to be a private IPv4 address which is translated into a shared public
   IPv4 address."

-- This address is only assigned and used during active data
connections, and is not required for CS voice calls.  This is
different in LTE where circuit switched calls do not exist.

-- Section 3.2  It is possible to have the distributed model with the
NAT *not* coupled with the GGSN.  The draft mentions NAT on the
Internet border router as centralized and NAT on the GGSN as
distributed, but it is possible to have distributed internet borders
and NAT to take place on dedicated stand-alone devices.  Personally, i
am not excited about coupling together NAT with the GGSN functions.
NAT is such an operational challenge, that coupling it with anything
else seems like too much shared fate.

--Section 3.3 Please reference draft-arkko-ipv6-only-experience

" Migration of applications to IPv6 in MNs with IPv6-only PDN
   connectivity brings challenges.  The applications and services
   offered by the provider obviously need to be IPv6-capable.  However,
   a MN may host other applications which also need to be IPv6-capable
   in IPv6-only deployments.  This can be a "long-tail" phenomenon;
   however, when a few prominant applications start offering IPv6, there
   can be a strong incentive to provide application layer (e.g., socket
   interface) upgrades to IPv6. "

--I estimate 95+% of the Symbian Ovi store apps work with Ipv6 today,
the SDK sandbox makes this easy for developers to make IPv6 work and
not even know it.  I also estimate that with Google and Facebook
already making substantial IPv6 efforts, that nearly 50% of IPv6
enabled user's ISP traffic (legacy NAT44 state) can be e2e IPv6 by the
end of 2011.  The long tail will be the other billion web sites, but
as we know from various studies, most users go in the USA only go to a
few main websites and they account for the vast majority of the
internet traffic.  A few big guys move on IPv6, and the tide on IPv6
vs IPv4 traffic distribution will shift with them.

--Your document should mention IPv4 literals in the IPv6 only network,
there are not many, but they are out there.  Some pointers here
http://groups.google.com/group/ipv4literals

"This is relatively straightforward for an operator's own services and
   applications, provisioned through an appropriate APN (and IPv6-only
   PDP/PDN)."

--Lets not tie this to the APN. Today, UEs can request IPv4 PDP or
IPv6 PDP of a single APN.  The APN can support IPv4, IPv6, or both
IPv4 AND IPv6 PDPs. That said, i can take my current production APN
that only services IPv4, and i can enable it for IPv6.  When a UE
request PDP type = IPv6, it will work for them without impacting the
IPv4 users that make up the majority of the subscriber base.

 --3.4  Regarding FMC, it is important to note that UMA / GAN / and
Femto Cells can all be adversely impacted by CGNs.  The case is that
the fixed-line provider and the mobile provider are different
companies. The user has a femto cell that communicates with the mobile
provider over IPsec using the Internet provide by the fixed-line DSL
provider.  The fixed-line provider has DS-lite deployed or 6RD with
private addresses + CGN.  The fixed line provider has a policy in
their CGN that they terminate any NAT session that last over 4 hours,
or over 24 hours.  I believe this will be common, and some NAT boxes
do this today by default.  The result is dropped calls on the femto
cell (including emergency calls) while the femto cell attempts to
re-attach to the mobile providers network.  This is a bad customer
experience and should be avoided.  There should be guidance that all
the FMC solutions (UMA, GAN, Femto, ...) support IPv6 so they can
connect over the IPv6 broadband service and do not have to go via the
IPv4 CGN and be subject to those CGN limitations.  This also benefits
the fixed line operator that will not have to maintain state for these
long lived IPsec sessions

Regards,

Cameron

---

From: Rajeev Koodli <[email-masked]>
Date: Sun, 26 Sep 2010 22:39:52 -0700

Hi Cameron,

Thank you for your review, and sorry for the delay in responding.
Please see below.

> that improve battery life and applications performance (e2e restored)

Sure. I could say "While IPv6 brings many benefits, certain unique
challenges arise when deploying it in mobile networks".

> with GTP, and there is really RFC1918 and public IP exhaust issues.

Good point. 

"In the following, we primarily focus on translation based
mechanisms such as NAT44 (i.e., translation from public IPv4 to
private IPv4 and vice versa) and NAT64 (i.e., translation from public
IPv6 to public IPv4 and vice versa). We do this because the 3GPP
architecture already has a tunneling infrastructure with the GPRS Tunneling
Protocol (GTP), and the architecture allows for dual-stack and IPv6-only
deployments" 

> different in LTE where circuit switched calls do not exist.

Right. This (i.e., the absence of always-on connection) is mentioned in the
paragraph that follows.

> else seems like too much shared fate.

Yes, I agree that the NAT can be outside the GGSN/PGW. I can mention this.

If NAT is a subscriber-aware feature, then there are benefits to managing
the UDR (User Data Records) and FDR (Flow Data Records) on the same device.
This assumes that the device can provide the required redundancy and HA for
the system state.

> --Section 3.3 Please reference draft-arkko-ipv6-only-experience

Ok.

> vs IPv4 traffic distribution will shift with them.

This is essentially what the paragraph is saying. Yes.

> http://groups.google.com/group/ipv4literals

Ok.

> IPv4 users that make up the majority of the subscriber base.

The sentence is not making any statements about whether there are v6-only or
v4-only APNs etc. It's only stating that an appropriate APN can be made to
support IPv6 PDN/PDP. What you need is the Subscription Profile for the
particular user to support IPv6/IPv4v6 PDN/PDP.

> long lived IPsec sessions

If the wireline broadband has IPv6 support, why would you terminate the
session in a CGN? I mean, why would you not pass-through the CGN and
terminate IPsec over IPv6 at the Femto Gateway?

Thanks,

-Rajeev

> 
> Regards,
> 
> Cameron
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 27 Sep 2010 09:59:17 -0700

<snip>

> terminate IPsec over IPv6 at the Femto Gateway?

Rajeev,

I think my word choice was poor.  The fixed-line broadband provider
has a policy that no NAT session can live longer than 4 hours or 24
hours or some fixed amount of time.  Many NAT systems have policies
like this today to prevent "zombie" sessions from take resources on
the NAT platform.  This type of policy will be harmful to FMC and will
result in dropped calls, poor user experience, and possible issues
with emergency services.

To your point, the femto cell IPsec tunnel / session does not connect
to the CGN, it connect through the CGN, and the IPsec femto session is
established with its IPsec peer at the mobile provider.

The CGN policy will purge the NAT session / state periodically
according the the policy of the CGN, this is a risk to FMC / Femto /
UMA.  My ask is that your document, in the FMC section, note that CGN
will complicate IPv4 FMC systems that are deployed today.  It should
also recommend that FMC solution providers and network operators
quickly adopt IPv6 capabilities to avoid CGN and leverage the
end-to-end IPv6 path that will become available with DS-lite, NAT64,
4RD, 6RD, ....

Thanks,

Camron

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 27 Sep 2010 13:53:33 -0700

> end-to-end IPv6 path that will become available with DS-lite, NAT64,

I can make a note of the CGN session expiry, and its potential impact on the
mobile providers. And, state that with IPv6 pass through, you do not have
the same issue.

Regards,

-Rajeev