Re: [v6ops] reclassify 464XLAT as standard instead of info

[Alexandre Petrescu <[e-mail]>]

Le 21/09/2017 à 15:40, JORDI PALET MARTINEZ a écrit :
> My guess, didn't tired that, is that if and implementation is using 
> both DHCPv6-PD and 64share, it should be possible to have a single 
> APN. You just need to not “force” the use of the PD if is not being 
> requested by the UE. Is a quick though, but don't see a problem on 
> that.

Dont standardize on something that you think it may work.  We should be
sure it works.

> By the way, if the operator was having problems with DHCPv6-PD,

No, the operator had no problems with DHCPv6-PD.  They had problems with
DHCPv6 - they found it superfluous.  Android did 464xlat, 64share and
NAT-figurex-figurey, so everything was fine.

> it means that the chipset was not filtering that as you indicated 
> before, so blame some chipset vendors, not the IETF.

At some point in time, some modems (e.g. a modem in Huawei E392 USB
dongle) acted as a sort of DHCPv6 Server.  My linux issued DHCPv6
requests, someone answered, and the  operator said it isnt them.  So it
was the modem.

Newer modems like MDM8xxx dont even bother to answer - they simply
block.  Moreover, the designers ack they are blocking it, 'because noone
needs it'.

> I also see a valid case for having 2 APNs. 1) for LTE broadband 
> routers that require more than a /64 (and thus DHCPv6-PD), and 2) for
> the rest that are regular UEs and only require a /64 (64share for the
> tethering)

I can agree to that use case of LTE broadband router vs smartphone, or
one for M2M "Business" devices and one for smartphones.

But two APNs, both for smartphones to connect, is not viable.

You want one APN and many kinds of smartphones and cars to connect to
that single APN.

(there are long discussions about this, and in the past one has seen
movements in that direction)

Alex