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

["Heatley,N,Nick,TQB R" <[e-mail]>]

Mark, What is this encapsulation solution? 
There is no running code for this on client devices, as far as I know - regardless of whether we set various vendors' "junior developers" on various parts of 3GPP core stack😊.

The alternative for an operator concerned with exhaustion of private addressing, is to start running overlapping copies of the private address ranges; for different customer segments or data centres or regions of the network.
I am deadly serious about this, this is what operators have done. This comes with or without IPv6, because if you have to run v4 why add in a second address family?
I guess you will be happy with this outcome because you believe NAT44 CGN is superior to NAT64 CGN. But I think you are missing the point.
As others have stated, your perceived issues are all problems tied to IPv4. I have a way that drives IPv6-only in my network.


-----Original Message-----
From: Mark Andrews [mailto:[e-mail]] 
Sent: 25 September 2017 23:50
To: Heatley,N,Nick,TQB R <[e-mail]>
Cc: IPv6 Ops WG <[e-mail]>
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)


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]