Re: [v6ops] I-D Action: draft-ietf-v6ops-mobile-device-profile-17.txt - C_REC#9 464XLAT

[Alexandru Petrescu <[e-mail]>]

Le 16/02/2015 12:45, Tore Anderson a écrit :
> * Alexandru Petrescu
>
>> What is the name of the software that must exist inside the
>> customer's device?
>
> "CLAT". The device located in the provider's network, the "PLAT", is
> really nothing but a completely standard Stateful NAT64.
>
>>> In other words, the operator does not need to configure or
>>> provision anything beyond Stateful NAT64 + DNS64 for 464XLAT to
>>> function.
>>
>> But it seems to mandate "464XLAT" to exist inside the customer's
>> device, for IPv4-literals, and for non-DNS-based apps.
>
> If you want IPv4 literals to work, you'll need the CLAT, yes.
> However, the operator cannot really control this - if you have a
> device that supports the IPV6 APN type, but no CLAT/464XLAT support,
>  then you can connect to the network just fine. You'll have access to
>  IPv4-only websites etc. through the provider's DNS64/NAT64, but you
>  won't have access to IPv4 literals.

Ok.  But one would agree that access to websites is not access to
the Internet.

> The only control the network operator has here, is that it can
> ensure that all the operator-branded devices it sells in its own
> store do support 464XLAT (i.e., by containing a CLAT).

Ok, the operator may control these devices.

But some operators sell also SIM cards to put in other devices than
smartphones (to put in cars, for example), or in other devices than the
operator-controlled devices.

There would be little possibility for these operators to hope imposing
CLAT on each and every device connecting to 4G.

> If you bring your own device bought from somewhere else, however, the
> operator has no way of knowing if your device contains a CLAT or
> not.

Yes.  And at that point that particular operator no longer offers IPv4
literal access and some IPv4 applications will not work.

>> I also heard that 464XLAT was imported into the cellular world
>> from DSL IPv6 deployments.
>
> No, 464XLAT was designed specifically for mobile networks. I've
> never heard of any DSL/wireline deployment that uses it (although it
> is certainly technically possible).
>
>> I can understand that.  LTE networks bring in high bandwidth; but
>> from the networking point of view there is reason to fear
>> regression (no more publicly routable IPv4 addresses, no more ping
>>  8.8.8.8, apps must use DNS, etc).
>
> I think the need to support IPv4 literals and apps not using DNS
> remains with LTE; the actual change is that LTE networks and devices
> conform to newer 3GPP releases which include the IPV4V6 APN type.
> Thus, devices and networks generally support it. Using IPV4V6, an
> operator can provision the handset with both IPv4 and IPv6
> addresses, ensuring that IPv4 literals work - without requiring a
> CLAT. (As Nick pointed out, RFC1918/RFC6598 exhaustion might still be
> an issue for very large operators though.)

I think IPV4V6 is something good.  Many end devices support IPV4V6
out of the box - it's a below-IP feature.  But CLAT is an IP feature,
not in the kernel, and is something that has to be added, potentially in
conflict with other IP features like openvpn and mobile ip.

Yes I read point saying 20million addresses may be too small (a 10.x
class A supposedly); it is possible.  But several private class As are
afforded with multiple NATs or VPNs.  Address architecture problems
similar to this are common outside the cellular world: e.g. multi-site
international corporations on landlines; yet none uses 464XLAT, and none
enforces the end user terminal to implement NAT, CLAT, VPN.

IPv6 is independent of IPv4 and vice-versa.

Alex


>
> Tore
>
>