Subject: Re: [v6ops] Which IPv4aaS mechanisms should CE routers implement first?

From: Fred Baker <[email-masked]>
Date: Sat, 4 Dec 2021 15:06:21 -0800

> On Nov 23, 2021, at 6:25 PM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> Is there any data on what IPv4aaS transition mechanisms are deployed by ISPs today? I was approached by a router vendor asking me "how they should provide IPv6-only" and I was looking for data on which mechanisms are most common.

I think you'll find the most common is 464xlat, which is to say a combination of stateful and stateless IPv4/IPv6 transition (RFC 7915, 6877, 6144, 6146,6052) at the edges.

That said, take a look at 
https://tools.ietf.org/html/draft-ietf-v6ops-transition-comparison
  "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse,

   From a technical preference standpoint, Dual-Stack is the most
   adopted solution, both in wireline (59%) and in cellular networks
   (39%).  In wireline, the second most adopted mechanism is DS-Lite
   (19%), while in cellular networks the second preference goes to
   464XLAT (21%).

If you want to turn off IPv4, translation provides an IPv6-only node a way to communicate with an IPv4-only node, or vice versa. You've heard the quip about democracy; it's the worst form of governance except for all the others. Being an author os some of the documents related to translation, I would say a very similar thought applies. Ds-lite is arguably not an IPv4-as-a-service technology, as it provides an IPv4-in-IPv6 tunnel approach to lead IPv4 traffic to a target IPv4/IPv4 NAT; it provides no way to enable communication with an IPv6-only node apart from native service.

---

From: Ole Troan <[email-masked]>
Date: Sun, 5 Dec 2021 11:17:44 +0100

> On 5 Dec 2021, at 00:06, Fred Baker <[email-masked]> wrote:
> 
> Ds-lite is arguably not an IPv4-as-a-service technology, as it provides an IPv4-in-IPv6 tunnel approach to lead IPv4 traffic to a target IPv4/IPv4 NAT; it provides no way to enable communication with an IPv6-only node apart from native service.

IPv4aaS: a mechanism to provide IPv4 service to an enduser network across an IPv6 only access network. 

DS-lite is definitely an IPv4aaS mechanism. Together with MAP-E, MAP-T, 464XLAT, Lightweight 4over6, L2TP, Public 4over6…
DSTM arguably not, since it provides IPv4aaS in the enduser network itself. 

O.

---

From: Gábor LENCSE <[email-masked]>
Date: Sun, 5 Dec 2021 13:04:14 +0100

Dear Ole,

Yes, I agree that all these mechanisms can be used to provide IPv4 
service to an end user across an IPv6 only access and core network, _if 
the IPv4 protocol stack is enabled in the client software.__
_
The uniqueness of 464XLAT is that if it is used together with DNS64, 
then IPv4 only servers are reachable also for those clients that have 
only IPv6 protocol stack. (Of course, for that you do not need the 
entire 464XLAT infrastructure, but only its PLAT part, what is nothing 
else than a stateful NAT64 gateway.)

Fred, did you mean this difference?

And yes, the combination of stateful NAT64 and DNS64 could be used 
together with any other IPv4aaS technologies, but AFAIK it is used only 
with 464XLAT. (Perhaps because the stateful NAT64 is already there as 
the PLAT, and the only additional thing needed is the DNS64 service.)

Of course, the combination of stateful NAT64 and DNS64 has its own 
limitations. The major applications work with it perfectly, but some do 
not. For our test results, please see:

S. Répás, T. Hajas and G. Lencse, "Application Compatibility of the 
NAT64 IPv6 Transition Technology", /Proceedings of the 37th 
International Conference on Telecommunications and Signal Processing 
(TSP 2014)/, (Berlin, Germany, 2014. July, 1-3.) Brno University of 
Technology, pp. 49-55. DOI: 10.1109/TSP.2015.7296383
Full Paper in PDF 
<http://www.hit.bme.hu/~lencse/publications/TSP-2014-AC.pdf>

Best regards,

Gábor

12/5/2021 11:17 AM keltezéssel, Ole Troan írta:
>
>> On 5 Dec 2021, at 00:06, Fred Baker<[email-masked]>  wrote:
>>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alejandro Acosta <[email-masked]>
Date: Sun, 5 Dec 2021 08:50:14 -0400

Hello,

   Maybe this is not exactly what you are looking for but probably is 
closed enough.

   Summary: in LACNIC for two years in a row we have been working in 
identifying which CPEs are the most common in the part of the world, and 
then looking for which transition mechanisms are supported by them.

   We have published two documents about it. Both can be found in here:

https://www.lacnic.net/5832/1/lacnic/

   The direct link for the latest one is here:

https://www.lacnic.net/innovaportal/file/4297/1/informe-cpes-ipv6-2020-v7.docx.pdf

    I know they are in Spanish :-(  sorry for this.

   Hope this helps to you and probably more people.

Alejandro,

On 23/11/21 10:25 PM, Lorenzo Colitti wrote:
> Hi all,
>
> Is there any data on what IPv4aaS transition mechanisms are deployed 
> by ISPs today? I was approached by a router vendor asking me "how they 
> should provide IPv6-only" and I was looking for data on which 
> mechanisms are most common.
>
> Official IETF guidance in RFC 8585 and 8026 is "do all of them and let 
> ISPs decide, have a nice day", but that's not very helpful to a 
> development team with finite engineering resources and low margins. In 
> particular, it's not helpful to vendors of routers that are updatable 
> and that can thus credibly claim that they can deliver other 
> mechanisms via software update. Those vendors could reasonably argue 
> that it's better for everyone if they launch the most common 
> mechanism(s) first, and then deliver the others in software updates.
>
> It seems like reasonable implementation guidance would be to request 
> OPTION_S46_PRIORITY and parse it, but only initially implement one or 
> two of the mechanisms and leave the others for a future release. If a 
> router did this, what mechanisms should it implement first? MAP-E?
>
> Cheers,
> Lorenzo
>

---

From: Alejandro Acosta <[email-masked]>
Date: Sun, 5 Dec 2021 10:01:10 -0400

Hello,

Alejandro,

---

From: Fred Baker <[email-masked]>
Date: Tue, 14 Dec 2021 15:12:00 -0800

> On Nov 24, 2021, at 12:03 AM, Ole Troan <[email-masked]> wrote:
> 
>> On 24 Nov 2021, at 03:26, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
>> 
>> Is there any data on what IPv4aaS transition mechanisms are deployed by ISPs today? I was approached by a router vendor asking me "how they should provide IPv6-only" and I was looking for data on which mechanisms are most common
> 
> IPv4aaS != IPv6 only

I would agree; IPv4aas is a way of providing IPv4 in a network that doesn't implement it. Something-over-IPv6 is a set of ways to do so; it could be done with Bluetooth Low Energy, MPLS, or any of several other things. My suggestion would be:

   - first, make sure you can run IPv6-only. Turning IPv4 off can be harder than you think. 
   - second, ask yourself what you mean by that. Do you want to run IPv4 in tunnels *over* an IPv6 network connecting edges? Do you want to connect an IPv4-only host using an IPv6 network to connect to another host somewhere else? Second, read section 4.3 of https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment.
   - You might look at RFC 6333, DS-Lite.

---

From: Richard Patterson <[email-masked]>
Date: Wed, 15 Dec 2021 12:37:32 +0000

On Tue, 14 Dec 2021 at 23:12, Fred Baker <[email-masked]> wrote:

> I would agree; IPv4aas is a way of providing IPv4 in a network that
> doesn't implement it.
>

Context is key, is someone talking about an IPv6-only packet flow, or a
particular device or service in the network?  Are they talking about the
control plane or data plane?  If it's not clear, ask them for clarification.

It's a matter of perspective, from an IPv4aaS end-to-end packet flow, of
course there's IPv4 in the mix, but the Access Node won't see any frames
with 0x0800 ethertype, so from my Access Team's perspective, the service is
IPv6-only to them.
Likewise a BNG requires no DHCPv4 server configuration or IPv4 routes, and
RADIUS only needs to keep track of IPv6 address family sessions...... and
so on and so forth.

IPv4aaS != IPv6-only *from an end-to-end packet flow perspective*.

-Rich