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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, "Heatley,N,Nick,TQB R" writes:
> There are no arguments about architecture, there are only arguments about
> requirements.
>
> Here is my case study on NAT64/DNS64/464xlat.
> My requirements:
>
>   *   A solution for multi-million numbers of consumer nodes (smartphones)
>   *   Mitigate IPv4 private and public address exhaustion
>   *   Encapsulation is not compatible with the core of 3GPP mobile
> networks  only translation is Core & Service-LAN friendly.
>   *   Keep the provider network simple  the overhead of two address
> families per customer in the mobile core is undesirable (as it doubles
> the control plane signalling)
>   *   2 consumer usecases (on the same Internet APN) to consider
> on-device apps (smartphone+apps), tethering (smartphone+wifi-tethered
> device of an unknown OS)

The problem with those requirement is that miss the most important
one.

	Don't do damage.

DNS64 does damage to the DNS.
NAT64 does damage to IPv6.

DNS64/NAT64 and 464XLAT externalise the cost of not upgrading the
billing software to unwrap the encapsulation.

> Thanks to esteemed Android developers putting 464xlat into Android,
> otherwise this wouldnt have happened.
> DNS64/NAT64 did not get put into production until 464xlat appeared on
> Android.
> I had zero IPv6 clients until 464xlat, IPv6 was insufficient without it.
> Prefix-share + 464xlat gave the tethering use-case support.
> The result has been rapid deployment, meeting all the requirements, we
> currently observe something like 70% of an IPv6-only devices traffic is
> IPv6-IPv6 based (and NAT-free).

Just running the dual stack and a regular CGN rather than a NAT64
also achieves that as IPv6 nodes prefer IPv6 over IPv4 as the
transport.

> I have a good amount of internal mobile core traffic that is IPv6-only
> (the combination of IPv6-only IMS APN for VoWifi and VoLTE, and this
> internet APN).
>
> So this is my opinion: 464xlat is the currently the adopted approach when:
> - IPv4 addresses are (near) exhausted for the mass-market,
> - AND the provider network demands a translation technology (i.e.
> incompatible with encaps.)
> - AND at the client end,  apps are not purged of IPv4 literals OR
> tethering to an unknown OS is required

AND you are willing to be selfish and ignore the costs you are
externalising on everyone else.

No network DEMANDS translation technology.  You could have spent a
little bit of developer time and upgraded the billing software to
understand about encapsulation.  Its a very simple concept.  Even
the most junior of developers could have done this.

> What is the point of seeking BCP for 464xlat? I am not entirely sure.
> It should not be to try to select Apple vs Android approaches, I want to
> see both approaches successful.
> Maybe it is to keep IETF relevant to the real world requirements and
> specific usecases. Id like to see IETF do more on usecases/solution
> context, BCPs can set the context, right?
> Maybe I can use it to help drive an IPv6-only 5G?
> Nick

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]