Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

[Erik Kline <[e-mail]>]

On 28 September 2017 at 17:15, Mark Andrews <[e-mail]> wrote:
>
> In message <[e-mail]>, Mikael Abrah
> amsson writes:
>> On Thu, 28 Sep 2017, Mark Andrews wrote:
>>
>> > You do know the RFC 7050 doesn't work with DNSSEC validation enabled.
>> > RFC 7050 specifies CD=0.
>>
>> Correct. I don't get your point. This is the local resolver on the device
>> trying to figure out where the NAT64 prefix is. Of course it can't do
>> validation on this specific query.
>
> Why shouldn't it?  DNS64+NAT64 and 464XLAT require all sorts of
> hacks to be deployed to otherwise correctly functioning pieces of
> software just to get them working.
>
> DS-Lite, MAP-E and MAP-T just require the node to request the
> parameters using DHCP (the thing that is supposed to be used for
> configuring the system) then bring up a interface appropriately
> configured.

And here we come to yet another problem that was unsolved in mobile
networks at the time.  At the time the 464xlat/CLAT work was done in
Android (c. 2009) I don't think mobile networks really supported
DHCPv6.  Additionally, at that time many 3GPP networks didn't support
IPv4v6 PDN types but rather required separate IPv4-only and IPv6-only
PDNs to effect dualstack (but the operators could be charged on a
per-PDN basis meaning it doubled the cost to add IPv6).

So what was really wanted at that time was:

    [a] a way to reach the IPv4 Internet from an IPv6-only APN, *and*

    [b] a provisioning mechanism that:

        [i] didn't use the DHCPv6 that wasn't available in the network, and
        [ii] didn't require forklifting 3GPP deployed hardware/software

I suppose we could have tried to fetch a JSON config file from some
HTTP/S service constructed from the APN name or something...  =)

-Erik

I can just feel all the "android and dhcpv6" screeds being written right now...