[PATCH 0/3] Enabling IPv6 on Qualcomm MDM9x00 chipsets

[Bjørn Mork]

Dan Williams <dcbw at redhat.com> writes:
> On Wed, 2013-11-27 at 19:08 +0100, Bjørn Mork wrote:
>
>> > Does this still hold for IPV4V6, if the modem supports it?  Or is it
>> > only a problem with SIM:IPv6 & PDP:IPV4 and vice versa?
>> 
>> You tell me. I don't know.  Currently I have a number of IPv4 only SIMs,
>> and one IPv6 only SIM.  I do not have any SIM allowing dual stack IPV4V6
>> connections.
>
> AFAIK, the SIM isn't the problem, it's the device and the carrier/APN.
> The SIM really shouldn't care at all, it's just used for authentication
> and home/roaming.  If the device supports IPv6 (not all do of course)
> then it will request an IPv6 bearer from the carrier, and if the carrier
> supports IPv6 *and* your APN allows IPv6, then you'll get it.

It's possible those SIM restrictions are nothing to worry about in the
real world, but they are definitely there.

This is a description of how I _think_ this works.  It might be based on
completely wrong assumptions...

I believe the SIM is involved in the "if the carrier supports IPv6" (and
actually also the "if the carrier supports IPv4", except that lack of
IPv4 support isn't very common yet).  A set of PGWs (or GGSNs) may
support IPv4, IPv6 or both. The selected PGW depends on the APN, so you
can have a combination of all types using the same carrier/device. So
far everything is fine.

But in LTE (or "evolved" cellular packet data networks in general),
there is this additional concept of a default bearer/attachment where
the device gets an IP (v4 or v6) address assigned when registering in
the network.  That's *before* you are allowed to send any APN info at
all, so the profile comes from the HSS (the LTE equivalent of a HLR)
based on the IMSI.  It contains the UE and PGW addresses.  This means
that there is a mapping from SIM to IPv4 and/or IPv6 in the HSS.  If
there is a mismatch between the HSS profile and device supported
protocol(s), then the device will fail to register in the network using
that SIM.

I believe 3GPP TS 23.401 section 5.3 covers this interoperability
problem quite well, requiring the UE to use PDN type IPV4V6 if it can
support both protocols, and also in cases where it doesn't know which
one it supports.  The HSS could also allow any requested PDN type for
the default bearer, but often it will not (like for my subscriptions).
This is where the problem is.  If neither the HSS or the UE is flexible
wrt IPv4 or IPv6, then failures will happen.

Given this, I wonder if maybe IPV4V6 should always be configured as the
default PDN type in modems? I'm going to test whether that works for
both my SIM types.  Why didn't I think of that before?

Some references:

http://www.eventhelix.com/lte/attach/LTE-Attach-Messaging.pdf
http://www.lteandbeyond.com/2012/01/lte-attach-procedure.html
http://www.3gpp.org/DynaReport/23401.htm


>> From what I understand, there is some doubt about IPV4V6 among
>> operators. If you depend on that type, then you prevent roaming in
>> networks which does not support it, IIUC.  And there are still a few of
>> those around the world.
>> 
>> So the operators seem to be more interested in NAT64/DNS64/464XLAT
>> solutions using IPV6 only PDP contexts than true dual stack solutions.
>> It does make some sense, given that most of them would use NATed RFC1918
>> addresses for the IPv4 part of the IPV4V6 context anyway.
>> 
>> But that's probably because they don't care at all about IPv6 in mobile
>> broadband devices yet
>
> Having IPV4V6 just makes it easier in the client, since the client
> doesn't have to start multiple PDP contexts, one for IPv4 and one for
> IPv6.

It doesn't have to start multiple PDP contexts if it use IPV6 with
464XLAT either, only a single IPV6 type.  It's even easier than IPV4V6,
because you don't have to configure IPv4 addressing and routing for the
session.

> On most modems, that would require either two network ports, or
> one network port and one free TTY for PPP.  In the QMI case, the device
> is perfectly happy to run both protocols over the same network interface
> though, which makes things really, really simple.  AT commands, not so
> much.

Unfortunately we have to live with the fact that IPV4V6 won't be
globally supported for a while, and if you are going to support global
roaming then you cannot depend on IPV4V6.

>> You are probably right.  It doesn't make any sense to me, but that seems
>> to be the way they think.  "Let's just make sure things fail in subtle
>> and random ways.  That will save us from supporting it.  IPv6 is an
>> advanced feature which noone needs.  We can always fix this in the next
>> batch"
>
> Check out my response with the E397 though; it has an 'inactive'
> IPV6_ENABLE NV item, yet I'm still able to use IPv6 with it.  I'll have
> to test other devices too.  Perhaps 'inactive' just means 'default', not
> "unsupported".  I'll try disabling it explicitly and then connecting
> with V6.

Maybe this setting just affects the default bearer?  Maybe you establish
a default IPv4 bearer, and then connect to an IPV6 or IPV4V6 APN?

If so, then it's probably less of a problem.  But less understandable
too.


Bjørn