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

[Cameron Byrne <[e-mail]>]

 "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