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

From: "Heatley,N,Nick,TQB R" <[email-masked]>
Date: Mon, 25 Sep 2017 11:56:21 +0000

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)

Thanks to esteemed Android developers putting 464xlat into Android, otherwise this wouldn’t 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).
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

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. I’d 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 25 Sep 2017 18:08:14 +0200

Thanks for the study.

IMHO I agree with some points, and disagree with others.

>   * Mitigate IPv4 private and public address exhaustion

Excuse me, what do you mean by IPv4 private address exhaustion?

I know about IPv4 public address exhaustion.

It may be that a private exhaustion could be solved by a private IPv4 
addressing scheme exclusively, without carving the "64::/" out from 
precious IPv6.

>   * 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)

I dont know what is the 'double control plane signalling'?

In PDP Context setup one just says "type=IPv4IPv6" and it happens very 
fast.  Then there is an IPv4 address and an IPv6 address on the device.

>   * 2 consumer usecases (on the same Internet APN) to consider –
>     on-device apps (smartphone+apps), tethering
>     (smartphone+wifi-tethered device of an unknown OS)

Do you consider cars too?

Because it may be that what you can do for smartphones wont work for cars.

> I had zero IPv6 clients until 464xlat, IPv6 was insufficient without it.

I agree, now you can tell customers to use IPv6 in all confidence, 
because IPv4 is there too.

But tell them too that's not true IPv6.  It is IPv6 with some 
INFORMATIONAL tweaks.  That's somehow a surrogate "IPv6-ready" like in 
"HDReady".

> Prefix-share + 464xlat gave the tethering use-case support.

Good, but wont work for cars, and nor for Road-Side Units, or other 
bigger moving networks.

In a car there are multiple IPv6 subnets, whereas 64share does only 1.

A Road-Side Unit connected on IPv6 cellular also uses multiple IPv6 subnets.

> The result has been rapid deployment,

Rapid deployment of a surrogate IPv6.

> meeting all the requirements,

Who set these requirements?  Is there an RFC containing these reqs?

> we 
> currently observe something like 70% of an IPv6-only devices traffic is 
> IPv6-IPv6 based (and NAT-free).

YEt it does not scale beyond that.  The only way to scale it is to sell 
more smartphones.

At the same time, you block all other devices (watches, cars, IoT) from 
connecting.

You want them all to connect to the Internet _through_ smartphones?

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

_Public_ IPv4 addresses are exhausted.  It means new operators wont get 
any more IPv4.  Old big operators already have huge IPv4 space.

If there is some internal-company too many 10.s everywhere, maybe 
re-design the internal-company addressing architecture.

> incompatible with encaps.)

The provider network should never demand a translation technology. 
Because translation technology (and encap for that matter) is what 
actually _restrains_ the possibilities of growth in the future.

> tethering to an unknown OS is required

I dont understand?

We do want apps purged of IPv4 literals, right?

"Tethering to an unknown OS is required" - I dont know what you  mean.

> see both approaches successful.

I agree.

> Maybe it is to keep IETF relevant to the real world requirements and 
> specific usecases.

I agree.

> I’d like to see IETF do more on usecases/solution 
> context, BCPs can set the context, right?

Yes, it would be good to come up with usecases, problem statement, 
before engaging in new work.

> Maybe I can use it to help drive an IPv6-only 5G?

Good intention.  Do they (5G) have a GTP-IPv6-only version?  No 
encapsulation, just IPv6.

Does the 5G connection setup mechanism provide a /63 prefix for 
end-user?  (or is it still the same old 64 SLAAC everywhere).

Alex

> Nick
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Sep 2017 12:06:13 -0700

> On Sep 25, 2017, at 9:08 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

Several companies, notably Microsoft and Comcast in the v6ops context, and said that they were running out not only of public space but, within their networks, private space. In the CGN context, this (in part, there were other considerations) resulted in us requesting an additional RFC 1918-like prefix for the space between a presumed NAT'd private address space and a CGN.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 25 Sep 2017 20:34:10 +0100

> Several companies, notably Microsoft and Comcast in the v6ops context, and said that they were running out not only of public space but, within their networks, private space. In the CGN context, th…

While I'd never considered that before now, it makes sense. 10/8 only has 16 million addresses (or, say, 65k /24s), plus another million for 172/12 and another 65k for 192.168/16. Given that (for example) Azure uses a lot of RFC1918 addressing internally, it's not hard to see how they could be running into problems.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Sep 2017 21:50:48 +0200

If I’m correct, this was the reason big cable operators such as Comcast, pushed CableLabs to accept IPv6 for the management network at least in DOCSIS 3.0, as they had already run out of RFC1918 space, so they need to duplicate it across his own network, a big trouble … I think SoftBank run into the same problem, probably just a few really big operators, but a big mess for them.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Simon Hobson <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 25 de septiembre de 2017, 21:34
Para: "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Sep 2017 08:50:28 +1000

In message <[email-masked]>, "Heatley,N,Nick,TQB R" writes:
> 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.
> The result has been rapid deployment, meeting all the requirements, we

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.

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

> specific usecases. Id like to see IETF do more on usecases/solution

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Heatley,N,Nick,TQB R" <[email-masked]>
Date: Tue, 26 Sep 2017 21:14:41 +0000

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:[email-masked]] 
Sent: 25 September 2017 23:50
To: Heatley,N,Nick,TQB R <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

> on-device apps (smartphone+apps), tethering (smartphone+wifi-tethered 

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

	Don't do damage.

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

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

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

---

From: james woodyatt <[email-masked]>
Date: Tue, 26 Sep 2017 14:59:27 -0700

> - AND at the client end,  apps are not purged of IPv4 literals OR tethering to an unknown OS is required

For the first two bullet items and the second half of the third bullet item, you only need NAT64+DNS64, not the whole of 464XLAT.

You only put the CLAT on the handset for one thing, and one thing only: dealing with applications that still use IPv4 literals, and it’s not the only way to skin that cat, c.f. the approach used by Apple, which uses a bump-in-the-stack at a higher layer of the operating system instead of using the CLAT according to 464XLAT. It works fine in all the cases anyone really cares about, and when the apps that still use IPv4 literals are all retired from service, it won’ t be necessary ever again.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 27 Sep 2017 00:24:39 +0200

Hi James,

Basically, we could say that CLAT or the bump-in-the-stack, have the same result.

May be the difference is that CLAT can be also in CPEs, which I’m not sure in the case of the bump-in-the-stack.

However, I recall having asked some of the Apple folks working on the HE update (not sure if it was David or Tomy), and unless I misunderstood it, bump-in-the-stack doesn’t solve the tethering problem or something else (not working for literals or apps that use sock api). Again, I’m not sure what was the issue, so I maybe expressing it incorrectly here, but it will be interesting to clarify.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de james woodyatt <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 26 de septiembre de 2017, 23:59
Para: "Heatley,N,Nick,TQB R" <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

    

    
    --james woodyatt <[email-masked]>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Sep 2017 09:44:40 +1000

In message <[email-masked]
> 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

> From: Mark Andrews mailto:[email-masked]
> Subject: Re: v6ops 464xlat case study (was reclassify 464XLAT as standard
> instead of info)
>
>
> In message
> <[email-masked]
> .COM>, "Heatley,N,Nick,TQB R" writes:
> 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.
>
> 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.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 27 Sep 2017 13:47:07 +0900

On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt <[email-masked]> wrote:

> c.f. the approach used by Apple, which uses a bump-in-the-stack at a
> higher layer of the operating system instead of using the CLAT
>

My understanding is that the approach used by Apple requires that
applications be modified. That's feasible given that Apple controls the app
store, but it's not feasible for most OSes.

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Sep 2017 11:08:55 -0700

On Sep 26, 2017, at 21:47, Lorenzo Colitti <[email-masked]> wrote:
> On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
> c.f. the approach used by Apple, which uses a bump-in-the-stack at a higher layer of the operating system instead of using the CLAT
> 
> My understanding is that the approach used by Apple requires that applications be modified. That's feasible given that Apple controls the app store, but it's not feasible for most OSes.

You deleted the key phrase in my earlier message:

>> ...in all the cases anyone really cares about…

Nobody really cares about the apps that can’t (or won’t) be updated.

People pretend to care about those apps, but only because it provides a convenient argument for doing what they were planning to do all along: which is to try to keep IPv4 as viable as possible, for as long as necessary, in the hopes of delaying the transition to IPv6 indefinitely. Furthermore, we pretend to take their pose seriously, because otherwise we’d have to stick our necks out and defend the IPv6 transition on its technical merits: which we long ago debauched when we decided it was perfectly okay for IPv6 to be basically nothing more than IPv4 with bigger address numbers.

---

From: "Heatley,N,Nick,TQB R" <[email-masked]>
Date: Wed, 27 Sep 2017 20:51:03 +0000

Stop speculating.

A specific example: certain vpn clients, still in service, fail when tethered to a nat64/dns64 device. Typically, a customer is tethering their work machine to their personal handset. NAT64/DNS64 does not provide what the client needs and neither can the OS. Such client SW may be older but is still in service, they are not yet end of support.

Customers care if this breaks. So do I, this is doing harm. And no, they won't revert to their corp IT dept. They know this relates to their provider.
With 464xlat these usecases simply work.
I have zero calls into customer services concerning devices with 464xlat.

464xlat is the reason why IPv6-only can work where the end OS is unknown.
IPv6-only for the handset mass-market is the way to mitigate exhaustion.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: v6ops <[email-masked]> on behalf of james woodyatt <[email-masked]>
Sent: Wednesday, September 27, 2017 7:08:55 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

On Sep 26, 2017, at 21:47, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt <[email-masked]<mailto:[email-masked]>> wrote:
c.f. the approach used by Apple, which uses a bump-in-the-stack at a higher layer of the operating system instead of using the CLAT

--james woodyatt <[email-masked]<mailto:[email-masked]>>

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Sep 2017 15:22:23 -0700

On Sep 27, 2017, at 13:51, Heatley,N,Nick,TQB R <[email-masked]> wrote:
> 
> certain vpn clients, still in service, fail

- If those apps are still in service, then they can be updated.
- If they can be updated for security, then they can be updated for IPv6-only operation without 464XLAT.
- If they won’t be updated, then keeping them in service is a security problem.

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Sep 2017 15:34:54 -0700

> On Sep 27, 2017, at 3:22 PM, james woodyatt <[email-masked]> wrote:
> 

Perhaps, if someone has the right source and the authority to do so. We ran into that with the Millennium bug; quite often, the COBOL program containing the two bytes that needed to become four wasn't available to be updated. The company it came from had long since gone out of business or whatever, meaning that the application had to be redeveloped or replaced. Even for products whose developers are among us, the developers may not be interested in doing so. GPGTools on Apple machines ran across that a couple of years ago. I have apps on my phone that I have had to trade out for others because they suddenly didn't work and weren't being updated on some given OS level.

I would be careful with sweeping generalizations. They usually have obvious and important exceptions.

---

From: Ole Troan <[email-masked]>
Date: Thu, 28 Sep 2017 00:43:23 +0200

> IPv6-only for the handset mass-market is the way to mitigate exhaustion.

464xlat is a mechanism to deliver IPv4 service across an IPv6 transport.
Yes, it mitigates exhaustion. - By sharing a single IPv4 address among more and more end-users.
It's just like any other CGN, with the differences being that you need CE support and you can disable IPv4 in the access network.

MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much all do the same.
The main difference is where session state is kept.

464XLAT or more commonly deployed 44464XLAT is the worst of any combination. It keeps sessions state both at the CE/CLAT and the BR/PLAT. Building scalable stateful devices is hard and expensive. And in the case of IPv4 sharing mechanisms unnecessary.

Ole

---

From: Ca By <[email-masked]>
Date: Wed, 27 Sep 2017 23:37:18 +0000

On Wed, Sep 27, 2017 at 3:43 PM Ole Troan <[email-masked]> wrote:

> > A specific example: certain vpn clients, still in service, fail when
> tethered to a nat64/dns64 device. Typically, a customer is tethering their
> work machine to their personal handset. NAT64/DNS64 does not provide what
> the client needs and neither can the OS. Such client SW may be older but is
> still in service, they are not yet end of support.
> >
> > Customers care if this breaks. So do I, this is doing harm. And no, they
> won't revert to their corp IT dept. They know this relates to their
> provider.
> It's just like any other CGN, with the differences being that you need CE
> support and you can disable IPv4 in the access network.
>
> 464XLAT or more commonly deployed 44464XLAT is the worst of any
> combination. It keeps sessions state both at the CE/CLAT and the BR/PLAT.
> Building scalable stateful devices is hard and expensive. And in the case
> of IPv4 sharing mechanisms unnecessary.
>
> Ole

Ole, Mark, and James — always good to have the non-operator viewpoint.
Insightful observations as always.

Nick has offered the “hey we did 464xlat, it worked, no regrets” case
study, also insightful.

I am trying to stay out of this discussion about purity of one solution vs
the other.  I was happy to leave that discussion years ago and move on with
real work.

But i like helping people, so i can share some insight

Slide 4 of a deck

https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-trends-in-ipv6-support-tommy-pauly-00.pdf

The blue area is not one of constant growth.  The lesson is that what James
said does not fly with mobile subscribers that can change carriers.  They
want their “broken” apps. That said, i have it on good word that blue blob
is  thriving now that we added some additional control points to allows
people to use “broken” apps.  Life is good.

Another data point

http://www.worldipv6launch.org/measurements/

As of today in the top 25, Numbers 7, 11, 17, 18 (i think), and 20 have
deployed 464xlat.  Pretty good real world stats moving real v6 packets for
what Ole calls “the worst” and Mark calls “sexy”.

And, i will reinterate an important point Nick made. The majority of
traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a
sliver of traffic requires 464XLAT or 4464.  Those numbers are all growing
in the right direction, more e2e v6.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Sep 2017 10:27:12 +1000

In message <[email-masked]>, Ca By writes:
> > > tethered to a nat64/dns64 device. Typically, a customer is tethering
> > > their work machine to their personal handset. NAT64/DNS64 does not
> > > provide what the client needs and neither can the OS. Such client SW
> > > may be older but is still in service, they are not yet end of support.
> > >
> > > Customers care if this breaks. So do I, this is doing harm. And no,
> > > they won't revert to their corp IT dept. They know this relates to their
> > > provider.
> > > 464xlat is the reason why IPv6-only can work where the end OS is
> > > unknown. IPv6-only for the handset mass-market is the way to mitigate
> > > exhaustion.
> >
> > It's just like any other CGN, with the differences being that you need
> > CE support and you can disable IPv4 in the access network.
> >
> > Building scalable stateful devices is hard and expensive. And in the
> > case of IPv4 sharing mechanisms unnecessary.
> >
> > Ole
>
>

I said other people think it is "sexy".  I'm with Ole, it is the worst
of the solutions.

	It breaks DNSSEC as it depends on DNS64.
	Applications have to deal with "this connection may be NAT'd to IPv4"
	which impacts on those not using 464xlat or NAT64/DNS64.
	It requires application gateways on both ends.
	It requires complicated code on both end.

---

From: Ca By <[email-masked]>
Date: Thu, 28 Sep 2017 01:56:44 +0000

On Wed, Sep 27, 2017 at 5:28 PM Mark Andrews <[email-masked]> wrote:

>
> In message <
> [email-masked]>, Ca
> By writes:
> >

Ethernet is also the worst.

Token ring is much more elegant than ethernet too.  And packet over sonet
is much more industrial than ethernet.

Yet the chaotic mess ethernet is ubiquitous.  Why?  Because people had a
relatively good experience deploying it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Sep 2017 11:17:04 +0900

> Nobody really cares about the apps that can’t (or won’t) be updated.

Those apps' users care. The Apple strategy only works if the OS vendor can
make it clear to app developers that supporting IPv6 is a requirement in
order to continue to run on the platform. That simply isn't feasible for
most OSes.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Sep 2017 11:48:51 +0900

> in the right direction, more e2e v6.

What he said. For many operators, the choice was between a) 60% (and
growing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, and
b) 100% NAT44 traffic.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Sep 2017 11:57:44 +0900

> of IPv4 sharing mechanisms unnecessary.

Many would feel that that's working as intended, and that the role of the
technology is *not* to deliver the highest-possible quality IPv4
experience. The role of the technology is to *unblock IPv6-only* by
providing  *compatibility mode* IPv4 service. In practice that turns out to
be a good incentive for app developers to upgrade to IPv6. That incentive
is not present in dual-stack networks.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Sep 2017 13:06:30 +1000

In message <[email-masked]>
> growing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, and

Garbage.  At worst it would have been growing IPv6 traffic + dropping
NAT44 traffic.  THE OPERATORS ONLY HAD TO TURN ON DUAL STACK.

Dual stack was being delivered by some operators before DNS64 and
NAT64 even existed.

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 28 Sep 2017 12:57:26 +0900

> NAT44 traffic.  THE OPERATORS ONLY HAD TO TURN ON DUAL STACK.

I take it you're not aware that certain 3GPP network releases don't support
dual-stack at all but do support IPv6-only.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Sep 2017 14:08:17 +1000

In message <[email-masked]>
, Ca By writes:
> > > > Yes, it mitigates exhaustion. - By sharing a single IPv4 address
> among
> > > > more and more end-users.
> > > > MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much
> all do
> > > > the same.
> > > I am trying to stay out of this discussion about purity of one
> solution
> > vs

Last time I looked my using ethernet doesn't impact on your using
some other layer 2 technology.

DNS64/NAT64 impacts on those not using the technology.

Mark

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Sep 2017 22:15:41 -0700

> On Sep 27, 2017, at 7:48 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> And, i will reinterate an important point Nick made. The majority of traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a sliver of traffic requires 464XLAT or 4464.  Those numbers are all growing in the right direction, more e2e v6.
> 
> What he said. For many operators, the choice was between a) 60% (and growing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, and b) 100% NAT44 traffic.

And, of course, as IPv6 grows, the reason to translate it diminishes.

Frankly, chair hat off, I'm happy enough seeing IPv6-only domains and 464XLAT where it has to be. The thing for us to focus on right now, I think, is enterprise deployment - at least at their front doors, their web sites and their mail servers. The less folks need IPv4 to talk with their business partners, the less the iron lungs are necessary. From my perspective, that problem eventually takes care of itself. Metcalf's law: the value of a network is a function of the number of it's users.

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Sep 2017 22:18:56 -0700

On Sep 27, 2017, at 10:15 PM, Fred Baker <[email-masked]> wrote:
> I'm happy enough seeing IPv6-only domains and 464XLAT where it has to be.

Dual Stack was and to some extent is necessary. It's a lot easier to deploy IPv6 in a working IPv4 network than to set up a green field. The thing is: how long do you want to run IPv4 after you need it? If you're going to translate IPv4 at the edge anyway, it doesn't matter so much what you're translating from. You can simplify your own network now.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Sep 2017 07:57:06 +0200 (CEST)

> NAT44 traffic.  THE OPERATORS ONLY HAD TO TURN ON DUAL STACK.

NAT64 and the other ipv4-over-ipv6 technologies have the advantage of 
allowing not having to deploy IPv4 at the edge with all that entails in 
form of BCP38 functions, routing protocols, addressing, CGN boxes traffic 
needs to be routed to, etc. Instead you can put your NAT64 machines 
whereever they fit best and don't have to worry about how to get your 
RFC1918 prefix traffic to it. Instead it's tunneled there. Less 
complexity.

So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually 
doesn't do that. DNS64 does. If all devices had 464XLAT then you wouldn't 
have to do DNS64 (apart from the well-known "prefix detection" zones.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Sep 2017 16:22:51 +1000

In message <[email-masked]>, Mikael Abrah
> RFC1918 prefix traffic to it. Instead it's tunneled there. Less 

And how does that relate to the statement I said garbage too?  It
doesn't.  It wasn't A or B.  It was A or B or C or D or E or F.  I
just presented a C to prove that A or B was a wrong description.

I've got zero objections to IPv6-only access networks.  I have
objections to NAT64/DNS64 and 464XLAT as the technology to deliver
IPv4 access over it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Sep 2017 09:10:42 +0200

Even better … you can deploy 464XLAT with DNS64 aware DNS validators, so actually DNSSEC is not broken, so it is a matter of doing the things correctly.

Regards,
Jordi

---

From: Ole Troan <[email-masked]>
Date: Thu, 28 Sep 2017 09:23:50 +0200

> NAT64 and the other ipv4-over-ipv6 technologies have the advantage of allowing not having to deploy IPv4 at the edge with all that entails in form of BCP38 functions, routing protocols, addressing, CGN boxes traffic needs to be routed to, etc. Instead you can put your NAT64 machines whereever they fit best and don't have to worry about how to get your RFC1918 prefix traffic to it. Instead it's tunneled there. Less complexity.

This discussion would benefit from us using terms with precision.

NAT64 is not an IPv4 over IPv6 technology. NAT64 allows an IPv6 application to speak to an IPv4 application.
NAT64 + DNS64 has the issue of breaking DNS64, and forcing every IPv6 application for eternity to be restricted in functionality to what an IPv4 application can do.

464xlat, while reusing the NAT64 component on the network side (which is just a CGN btw), offers shared IPv4 service. From the "user" perspective the '6' part really doesn't matter. It could be any form of transport.

> 
> So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually doesn't do that. DNS64 does. If all devices had 464XLAT then you wouldn't have to do DNS64 (apart from the well-known "prefix detection" zones.

I don't understand what you mean here. These are in my mind two completely different use cases.
NAT64+DNS64 solves the problem of an IPv6 application talking to an IPv4 application (and we can argue if that should really be solved at all). 464XLAT solves the problem, of IPv4 exhaustion by extending IPv4 to live forever (sic!). (Yeah, that last one was meant to be a little provocative, but We are currently in a state where 32 + 16 > 128 appears true).

Best regards,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Sep 2017 17:41:05 +1000

> have to do DNS64 (apart from the well-known "prefix detection" zones.

You do know the RFC 7050 doesn't work with DNSSEC validation enabled.
RFC 7050 specifies CD=0.

    ipv4only.arpa/AAAA (CD=0) -> validating recursive server 
			         (or local validating cache)
    ipv4only.arpa/AAAA (CD=0) -> DNS64 server
    ipv4only.arpa/AAAA ANCOUNT>0 -> validating recursive server
			        (or local validating cache)

                rejected as ipv4only.arpa is signed.

    SERVFAIL -> client

Lets try with CD=1

    ipv4only.arpa/AAAA (CD=1) -> validating recursive server 
			         (or local validating cache)
    ipv4only.arpa/AAAA (CD=1) -> DNS64 server (no synthesis as CD=1)
    ipv4only.arpa/AAAA ANCOUNT=0 -> validating recursive server
			            (or local validating cache)
    ipv4only.arpa/AAAA ANCOUNT=0 -> client (no prefixea found)

To get it to work the validating recursive server has to detect
that prefix discover is occuring.  Perform its own prefix discovery.
Synthesis a prefix discover response.

So yes 464XLAT does require DNSSEC to be broken.

Mark

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Sep 2017 09:58:14 +0200 (CEST)

> You do know the RFC 7050 doesn't work with DNSSEC validation enabled. 

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.

We all know DNS64+NAT64(+464XLAT) isn't optimal, but neither is your 
suggestion to "just run dual stack".

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Sep 2017 10:04:03 +0200

You can have a DNS validator, aware of DNS64.

In the worst case, if you don’t like having a DNS validator aware of DNS64, a much simpler solution is to NOT use DNS64.

464XLAT works also in that scenario, you just force all the IPv4-only traffic to be translated at both sides the CLAT and the PLAT. This is not worse than when you do NAT44.

As this traffic is going to be less and less IPv4, again this is not an issue.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Mark Andrews <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 28 de septiembre de 2017, 9:42
Para: Mikael Abrahamsson <[email-masked]>
CC: "Heatley, N, Nick, TQB R" <[email-masked]>, IPv6 Ops WG <[email-masked]>, james woodyatt <[email-masked]>
Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

    

        SERVFAIL -> client
    
    Lets try with CD=1

    
    
    Mark

---

From: Ole Troan <[email-masked]>
Date: Thu, 28 Sep 2017 10:14:56 +0200

>> 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.
> 
> We all know DNS64+NAT64(+464XLAT) isn't optimal, but neither is your suggestion to "just run dual stack".

I believe you are misrepresenting Mark's position.

It's perfectly fine to run an "IPv4 life extension mechanism" + IPv6, but without NAT64/DNS64.

Ole

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Sep 2017 18:15:27 +1000

In message <[email-masked]>, Mikael Abrah
> 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. 

> suggestion to "just run dual stack".

I've been arguing that one should run DS-Lite or MAP-T or MAP-E
though I don't alway mention all three.

The "just run dual stack" was pointing out Lorenzo's statement that
it was DNS64/NAT64 or IPv4-only was a false dicotomy.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Sep 2017 18:31:31 +1000

In message <[email-masked]>, JORDI PALET M
ARTINEZ writes:
> In the worst case, if you dont like having a DNS validator aware of
> DNS64, a much simpler solution is to NOT use DNS64.
>
> 464XLAT works also in that scenario, you just force all the IPv4-only
> traffic to be translated at both sides the CLAT and the PLAT. This is not
> worse than when you do NAT44.
>

Please go and re-read what is below.  You cannot discover the prefix
using correctly configured DNS software as things currently stand.

Now if you tell IANA to add a insecure delegation for ipv4only.arpa
one can discover the prefix but as things currently stand it is
impossible.

Mark

> CC: "Heatley, N, Nick, TQB R" <[email-masked]>, IPv6 Ops WG
> <[email-masked]>, james woodyatt <[email-masked]>
> Asunto: Re: v6ops 464xlat case study (was reclassify 464XLAT as standard
> instead of info)
>
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 28 Sep 2017 17:47:15 +0900

> configuring the system) then bring up a interface appropriately

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Sep 2017 10:53:42 +0200 (CEST)

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

Do any other mobile operating systems do DHCPv6 on the GTP tunnel? It's 
been too many years since I last looked at GTP packet traces to remember 
if this was done or not.

---

From: Erik Kline <[email-masked]>
Date: Thu, 28 Sep 2017 18:06:04 +0900

On 28 September 2017 at 17:53, Mikael Abrahamsson <[email-masked]> wrote:
> Do any other mobile operating systems do DHCPv6 on the GTP tunnel? It's been
> too many years since I last looked at GTP packet traces to remember if this
> was done or not.

I've no idea.  Nor do I know what might happen to various networks if
DHCPv6 requests were to be made on the mobile interface (even if the O
bit /were/ observed to be set).  The stories of billing system crashes
and so on from the early days of v6 on mobile leave me somewhat
suspicious.

I have been wondering about asking for an API to the modem to query
for the 3GPP release number of the network as a hint for expected
capabilities, but that kinda seems both excessive and like a layering
violation.  ;-)

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 28 Sep 2017 09:44:05 +0000

I could double check CPE routers such as ISR819 with LTE WAN uplink support DHCPv6.

Separately, from PGW point of view, DHCPv6 within an APN seems to be supported -

https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/20/P-GW/b_20_PGW_Admin/b_19_PGW_Admin_chapter_010.html#task_309eb986-4510-425a-81ed-833018e70921

//
The system can be configured to use the Dynamic Host Control Protocol (DHCP) for IPv6 to enable the DHCP servers to pass the configuration parameters such as IPv6 network addresses to IPv6 nodes. DHCPv6 configuration is done within an APN.
//

Given all the thing that get queried and fetched by apps, fetching the rel# being used (assuming available) would add a drop to the ocean. :)

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

On Sep 28, 2017, at 11:06 AM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:

On 28 September 2017 at 17:53, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, 28 Sep 2017, Erik Kline wrote:

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

[email-masked]<mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 Sep 2017 11:47:52 +0200

Le 25/09/2017 à 21:06, Fred Baker a écrit :
> Several companies, notably Microsoft and Comcast in the v6ops 
> context, and said that they were running out not only of public
> space but, within their networks, private space.

In one company I looked at they didnt run out of public IPv4 space, yet
they preferred to extend their internal network by adding private IPv4
space - reasons invoked relate some times the security of NAT, other
times to other reasons.

Running out of private space is probably not a reason that a reasonable
sysadmin could invoke.  One can not run out of private space.  But one
can mis-design a network - yes.

Alex

  In the CGN context, this
> (in part, there were other considerations) resulted in us requesting 
> an additional RFC 1918-like prefix for the space between a presumed 
> NAT'd private address space and a CGN.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Sep 2017 11:58:46 +0200 (CEST)

> can mis-design a network - yes.

Yet large network providers have said they have this exact problem. For 
instance some with a lot more than 16M devices to manage.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 28 Sep 2017 11:59:35 +0200

Le 28/09/2017 à 11:58, Mikael Abrahamsson a écrit :
>> Running out of private space is probably not a reason that a 
>> reasonable sysadmin could invoke.  One can not run out of private 
>> space.  But one can mis-design a network - yes.
> 

I agree with you.

Alex

---

From: Ca By <[email-masked]>
Date: Thu, 28 Sep 2017 12:29:34 +0000

On Thu, Sep 28, 2017 at 2:44 AM Rajiv Asati (rajiva) <[email-masked]>
wrote:

> been
> The system can be configured to use the Dynamic Host Control Protocol
> (DHCP) for IPv6 to enable the DHCP servers to pass the configuration
> parameters such as IPv6 network addresses to IPv6 nodes. DHCPv6
> configuration is done within an APN.
> //
>
>
I may be wrong here, but these instruction likely do not allow the client
mobile to run dhcpv6

What is likely happening here is the Cisco gateway is running SLAAC to the
mobile but selecting / registering the addresses from an external dhcpv6
server.

Here is the hint from the doc that the gateway is the dhcpv6 client, not
the mobile, and thus no support for dhcpv6 / map to the client ( i may be
wrong)

“

   -

   client identifier command configures the client-identifier, which is
   sent to the external DHCP server. By default, IMSI is sent. Another
   available option is MSISDN.
   -

   “

> Given all the thing that get queried and fetched by apps, fetching the
> rel# being used (assuming available) would add a drop to the ocean. :)
>
> Cheers,
> Rajiv Asati
> On Sep 28, 2017, at 11:06 AM, Erik Kline <[email-masked]> wrote:
>
> been

---

From: "Heatley,N,Nick,TQB R" <[email-masked]>
Date: Thu, 28 Sep 2017 12:47:39 +0000

What enterprises need from us is a vision of interconnected networks.
In other words, how do we bring on the next 4 billion end points, and what are the recommended steps to get there.

That is what i thought this BCP discussion should be judged against. The protocol purity stuff, in the absence of running code or real end to end solutions, its a real turn off. It is footnote stuff.
If all mobile operators moved to ipv6-only with the hacks we have discussed, is that the best thing we can do currently and better than do nothing? If yes then we have a BCP.
Nick

From: Fred Baker <[email-masked]>
Sent: Thursday, September 28, 2017 5:15:41 AM
To: Lorenzo Colitti
Cc: Ca By; Heatley,N,Nick,TQB R; IPv6 Ops WG; james woodyatt
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 28 Sep 2017 14:50:36 +0200 (CEST)

> I may be wrong here, but these instruction likely do not allow the client

https://tools.ietf.org/html/rfc6653

There is also this gem that I found:

http://www.google.sr/patents/US9491036

Wonder if that's causing a problem in implementing DHCPv6-PD in SPGW.

Anyhow, TS 23.401 says:

"The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in 
addition to the default prefix) from the PDN GW after completing stateless 
IPv6 address autoconfiguration procedures. The UE acts as a "Requesting 
Router" as described in RFC 3633 [21] and inserts one or more IA_PD 
option(s) into a DHCPv6 Solicit message sent from the UE to the PDN GW. 
The PDN GW acts as the DHCP server and fulfils the role of a "Delegating 
Router" according to RFC 3633 [21]. The UE optionally includes the 
RAPID_COMMIT option in the DHCPv6 Solicit message to trigger two-message 
DHCPv6 procedure instead of the four-message DHCPv6 procedure. The UE 
shall include OPTION_PD_EXCLUDE option code in an OPTION_ORO option to 
indicate support for prefix exclusion. In response to the DHCPv6 Solicit 
message, the UE receives a DHCPv6 Reply message with one or more IA_PD 
prefix(es) for every IA_PD option that it sent in the DHCPv6 Solicit 
message. The PDN GW delegates a prefix excluding the default prefix with 
help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow 
IETF RFC 6603 [70]."

Seems to me that in the standardization documents, it's perfectly fine for 
UE to request prefix using standard DHCPv6-PD, and this is the way it was 
intended to be done.

In 5.3.1.2.3 there is also talk about stateless DHCPv6:

"5.3.1.2.3	IPv6 parameter configuration via stateless DHCPv6
The UE may use stateless DHCPv6 for additional parameter configuration. 
The PDN GW acts as the DHCP server. When PLMN based parameter 
configuration is used, the PDN GW provides the requested parameters from 
locally provisioned database. When external PDN based parameter 
configuration is used, the PDN GW obtains the requested configuration 
parameters from the external PDN as described in the previous clauses. 
When the PDN GW acts as a DHCPv6 server towards the UE, the PDN GW may act 
as DHCPv6 client towards the external PDN to request the configuration 
parameters for the UE. If RADIUS or Diameter is used towards the external 
PDN as described in TS 29.061 [38], the requested configuration parameters 
can be fetched as part of these procedures."

There is also this overview text:

Both EPS network elements and UE may support the following mechanisms:
a.	IPv4 address allocation and IPv4 parameter configuration after the 
attach procedure via DHCPv4 according to RFC 2131 [19] and RFC 4039 [25];
b.	IPv6 parameter configuration via Stateless DHCPv6 according to 
RFC 3736 [20].
c.	Allocation of IPv6 prefixes using DHCPv6 according to 
RFC 3633 [21].

So it's pretty obvious that DHCPv6 is a thing in 3GPP networks, but it's 
optional to implement.

---

From: Gert Doering <[email-masked]>
Date: Thu, 28 Sep 2017 15:08:17 +0200

Hi,

> Dual stack was being delivered by some operators before DNS64 and

Which mobile(!) operator did that?

My recollection was "T-Mobile USA was the first mobile carrier of all to
deliver IPv6, and they did IPv6-only with DNS64/NAT64".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Ca By <[email-masked]>
Date: Thu, 28 Sep 2017 14:05:29 +0000

> deliver IPv6, and they did IPv6-only with DNS64/NAT64".

 Verizon Wireless was before T-Mobile with a large scale production
deployment, they were dual-stack.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 29 Sep 2017 09:39:58 +0200

Hi Erik,

Le 28/09/2017 à 11:06, Erik Kline a écrit :
>> Do any other mobile operating systems do DHCPv6 on the GTP tunnel?
>> It's been too many years since I last looked at GTP packet traces
>> to remember if this was done or not.
> 
> I've no idea.  Nor do I know what might happen to various networks
> if DHCPv6 requests were to be made on the mobile interface (even if
> the O bit /were/ observed to be set).  The stories of billing system
> crashes and so on from the early days of v6 on mobile leave me
> somewhat suspicious.
> 
> capabilities, but that kinda seems both excessive and like a
> layering violation.  ;-)

I heard about a recent IETF protocol "DLEP" that communicates between
the computer and the modem.  Looking at it I see it has a 'Status'
message in which one could probably put that 3GPP release number semantics.

Alex

> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 29 Sep 2017 09:54:07 +0200

Mikael,

I would like to reply, and also ask a few GTP questions publicly.

> Do any other mobile operating systems do DHCPv6 on the GTP tunnel?

I have seen DHCPv6-PD Solicits on Android and on Sierra Legato OS.

> It's been too many years since I last looked at GTP packet traces to 
> remember if this was done or not.

Having loooked at GTP packet traces, I suppose one looked at 3GPP specs
as well.

I would like to ask whether by 3GPP specs the GTP packets can optionally
be transported in IPv6 messages?

3GPP spec "GTP" Rel 15 of September 2017 says this:
> UDP/IP is the only path protocol defined to transfer GTP messages in
>  the version 1 of GTP. A User Datagram Protocol (UDP) compliant with
>  IETF RFC 768 [13] shall be used.

In practice, a packet capture on PGW shows an IPv6 DHCPv6-PD Solicit
message, preceded by a GTP-U Header, which is itself preceded by a "GTPU
Rx PDU" which is an IPv4 UDP packet.

The UDPv4 port number that transports GTP packets is 2152, reserved at
IANA and at that 3GPP spec.

This is the example packet capture I am talking about:

Friday August 11 2017
INBOUND>>>>>  15:45:22:470 Eventid:142004(3)
GTPU Rx PDU, from [IPv4-address]:2152 to [IPv4-address2]:2152 (129)
TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF)
Sequence Number:: NA
GTP HEADER FOLLOWS:
              Version number: 1
               Protocol type: 1 (GTP C/U)
[snip]
GTP HEADER ENDS.
            Payload protocol: IPv6
PROTOCOL PAYLOAD FOLLOWS:
fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546:  [udp sum ok]
IPv6 Header Follows:
[snip]
IA_PD Option Follows:
                 Option Type: 0x0019 (OPTION_IA_PD)
                Option Length: 0x0029
                        IA ID: 0x00000000 (0)
                           T1: 0x00000e10 (3600)
                           T2: 0x00001518 (5400)
IA_PD Prefix Option Follows:
                  Option Type: 0x001a (OPTION_IA_PD_PREFIX)
                Option Length: 0x0019 (25)
               IA Prefix Addr: ::/56
                      PL Time: 0x00000e10 (3600)
                      VL Time: 0x00001518 (5400)
[hlim 1] (len 81)
PROTOCOL PAYLOAD ENDS.

---

From: Erik Kline <[email-masked]>
Date: Fri, 29 Sep 2017 17:00:35 +0900

On 29 September 2017 at 16:39, Alexandre Petrescu
<[email-masked]> wrote:
>> I have been wondering about asking for an API to the modem to query for
>> the 3GPP release number of the network as a hint for expected capabilities,
>> but that kinda seems both excessive and like a
>> layering violation.  ;-)
>
>

https://tools.ietf.org/html/rfc8175 does indeed look quite interesting, thanks!

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 Sep 2017 10:44:59 +0200 (CEST)

> IANA and at that 3GPP spec.

It's an implementation detail whether this is carried over IPv4 or IPv6. 
UDP can be carried by both. If you read 29.060 it talks about GTP over 
both IPv4 and IPv6:

"If an IPv4/IPv6 capable SGSN received IPv4 GGSN addresses from the old 
SGSN, it shall include IPv4 addresses in the fields SGSN Address for 
Control Plane and SGSN Address for User Traffic and IPv6 addresses in the 
fields Alternative SGSN Address for Control Plane and Alternative SGSN 
Address for User Traffic. Otherwise, an IPv4/IPv6 capable SGSN shall use 
only SGSN IPv6 addresses if it has GGSN IPv6 addresses available. If the 
GGSN supports IPv6 below GTP, it shall store and use the IPv6 SGSN 
addresses for communication with the SGSN and ignore the IPv4 SGSN 
addresses. If the GGSN supports only IPv4 below GTP, it shall store and 
use the IPv4  SGSN addresses for communication with the  SGSN and ignore 
the IPv6 SGSN addresses. When active contexts are being redistributed due 
to load sharing, G-PDUs that are in transit across the Gn-interface are in 
an undetermined state and may be lost."

"below GTP" seems to indicate what protocol GTP is run over. There is a 
lot more text in TS 29.060 regarding this, but interested parties can read 
it and form their own opinion. To me it's clear that 3GPP has done the 
work to try to achieve so you can standards-based build a network with no 
IPv4 addresses used for infrastructure. If this works in real life in 
shipping products, that's a whole other question.