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

[Mark Andrews <[e-mail]>]

In message <[e-mail]
TLOOK.COM>, "Heatley,N,Nick,TQB R" writes:
> Mark, What is this encapsulation solution?

DS-Lite or MAP-E.

> 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.

Well there is running code for both DS-Lite and I'm pretty sure
there is running code for MAP-E.  Millions of broadband CPE routers
do DS-Lite today.  Given the rate phones get broken, which is the
only reason Apple can get away with their aggressive deprecation
strategy, if you deployed to day you would have a very large deployed
base in 3 years.

Remember the phone and operator can support NAT64/DNS64 and DS-Lite
and/or MAP-E at the same time and the operator can see with a 100%
accuracy which devices support DS-Lite or MAP-E as they advertise
the fact that they do.  This allows the operator to see when legacy
NAT64/DNS64 population gets low enough for it to be switched off.

Alternatively they can play APN games.

> 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?

Because the operating cost get higher and higher.  Because you still need
to add more public IPv4 addresses as your customer base increases.

> 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.

You have a way that puts costs on everyone else.  It isn't the only way.

DS-Lite is a IPv6-only solution all the way to the end device.
MAP-E is a IPv6-only solution all the way to the end device.

DS-Lite and MAP-E both support tethered devices.
DS-Lite the device doesn't perform NAT on the IPv4 traffic.
MAP-E the device needs to NAT the IPv4 traffic in the MAP address/port range.

Mark

> -----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]
> .COM>, "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]

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