including a CLAT (464XLAT) SSID in RIPE meetings
Hi all, I was suggesting the NCC OPS team to include in the meeting network a VM machine that provides a “CLAT” SSID in the meeting network. They suggested that, same as it was done for the NAT64 SSID, the topic is discussed in the IPv6 WG, as there is not a “formal” procedure to agree on that. So, I checked with the IPv6 WG co-chairs and they asked me to foster this topic in the mailing list … so here we are. While 464XLAT has been extensively tested and deployed in the cellular world, I think most of the wireline and wireless (not cellular) ISPs, haven even heard about it or evaluated the potential for those environments, the same that happens probably with MAP-T/E. Having just a NAT64 gives the impression to the people that today you can deploy IPv6-only access to customers and we know is not the case, because the app. Even if 80% (which will take YEARS to happen) of the app developers “correct” their apps, you will still get many things broken in homes and offices. So is undesirable (in my opinion) to work (only) in that direction. And even more, those apps, hardware, etc., that will never be updated, will never work with a NAT64-only scenario. With 464XLAT (or MAP), you avoid deploying CGN, which is a high cost, and you provide the *same* functionality that today “regular” customers (residential, SMEs, even many big companies that don’t have to export IPv4 services outside their LANs). If we demonstrate this “live” in the RIPE meeting network, I think we can change some of the participant’s minds, and I believe the cost of that is really small, may be a couple of hours of one of your OPS team colleagues, as I’ve already done the work and I’m happy to help them on testing in their lab, document what I’ve done (already working on that), and anything else they may need. Also, if the NAT64 is already there, it becomes much easier, as only the VM with the CLAT is needed (unless you want to “separate” the NAT64 for each SSID). By the way, the plan is to have this also in the next meetings of other RIRs (already planned). So, opinions? Regards, Jordi ********************************************** 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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Dne 22.3.2017 v 22:54 JORDI PALET MARTINEZ napsal(a):
With 464XLAT (or MAP), you avoid deploying CGN, which is a high cost, and you provide the *same* functionality that today “regular” customers (residential, SMEs, even many big companies that don’t have to export IPv4 services outside their LANs). If we demonstrate this “live” in the RIPE meeting network, I think we can change some of the participant’s minds, and I believe the cost of that is really small, may be a couple of hours of one of your OPS team colleagues, as I’ve already done the work and I’m happy to help them on testing in their lab, document what I’ve done (already working on that), and anything else they may need.
Hi Jordi, can you please elaborate some more about how it should look like from the technical point of view? Because as I now read it, I just imagine an SSID with dual-stack IPv6/RFC1918 IPv4, where the IPv6 will go natively, and IPv4 would be: 1. translated from IPv4 to IPv4 (can be part of step 2) 2. translated from IPv4 to IPv6 3. forwarded as IPv6 to another (or even same(!)) box 4. translated from IPv6 to IPv4 5. translated from IPv4 to public IPv4 (can be part of step 4) My bet is that this very complex translating exercise will not harm the packets much more than just a single NAT (except some latency, maybe). And the wireless access network users will just see a dual-stack network with NATed IPv4, which is actually AFAIK the most common way of deploying IPv6 nowadays. Now the question is: How would you explain to an IPv6-newbie what is the difference between `ripemtg` and `ripemtg-464xlat' networks? My explanation would be like: "Those networks work exactly the same way, but in the latter case, there is a one meter long cable back in the ops room, where all the traffic from the latter network is carried as just IPv6 protocol. Then it's translated back to IPv4 for the Internet" But that's probably not the explanation I would like to hear as an IPv6-newbie. Am I missing something? Also:
Having just a NAT64 gives the impression to the people that today you can deploy IPv6-only access to customers and we know is not the case, because the app.
Not a problem with today's smartphones. All iPhone apps has been fixed thanks to Apple's pressure, a lot of recent Android (6.0+) devices features CLAT integrated that works even via Wi-Fi. If Microsoft pushes CLAT into some future version of Windows, the problem with apps would be mostly gone and IPv6-only access networks would be fully usable even for end-stations. Cheers, Ondřej Caletka
Hi Ondrej, Yes, is as you said, an SSID (for example CLAT), which looks like the same as a CPE that a residential or SME can have in his place. The IPv6 traffic will be forwarded natively. The IPv4 traffic that uses DNS will be translated by the NAT64 (which already exist in the NCC network), as if you were connected to the NAT64 SSID. The different is the IPv4 traffic that has literal IPv4 addresses. In the NAT64 case, this is just broken, don’t work (skype, web sites with IPv4 addresses instead of names, etc.). So, when using 464XLAT, the IPv4 traffic that has literal addresses, will be translated like a combined NAT44-NAT46 by the CLAT, then forwarded to the NAT64, which translate it to IPv4 as usual. It doesn’t harm the packets, is already being used in the bigger cellular networks, providing IPv6-only in the WAN link. The participants should not “notice” difference, which is precisely what we want to demonstrate. Your explanation is right in the sense of “this” network, but think in the access network of the ISP. The only difference is if you need a “public” IPv4 for some special incoming traffic, but this is not a normal scenario in residential networks with use CGN, right? The point here is to show that instead of using CGN and relying still in IPv4 is not needed in the wired world, the same as isn’t needed in the cellular world. We just need to have a transparent dual-stack in the LANs. Regards, Jordi -----Mensaje original----- De: ipv6-wg <ipv6-wg-bounces@ripe.net> en nombre de Ondřej Caletka <Ondrej.Caletka@cesnet.cz> Responder a: <Ondrej.Caletka@cesnet.cz> Fecha: viernes, 24 de marzo de 2017, 10:48 Para: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg] including a CLAT (464XLAT) SSID in RIPE meetings Dne 22.3.2017 v 22:54 JORDI PALET MARTINEZ napsal(a): > With 464XLAT (or MAP), you avoid deploying CGN, which is a high cost, and you provide the *same* functionality that today “regular” customers (residential, SMEs, even many big companies that don’t have to export IPv4 services outside their LANs). If we demonstrate this “live” in the RIPE meeting network, I think we can change some of the participant’s minds, and I believe the cost of that is really small, may be a couple of hours of one of your OPS team colleagues, as I’ve already done the work and I’m happy to help them on testing in their lab, document what I’ve done (already working on that), and > anything else they may need. Hi Jordi, can you please elaborate some more about how it should look like from the technical point of view? Because as I now read it, I just imagine an SSID with dual-stack IPv6/RFC1918 IPv4, where the IPv6 will go natively, and IPv4 would be: 1. translated from IPv4 to IPv4 (can be part of step 2) 2. translated from IPv4 to IPv6 3. forwarded as IPv6 to another (or even same(!)) box 4. translated from IPv6 to IPv4 5. translated from IPv4 to public IPv4 (can be part of step 4) My bet is that this very complex translating exercise will not harm the packets much more than just a single NAT (except some latency, maybe). And the wireless access network users will just see a dual-stack network with NATed IPv4, which is actually AFAIK the most common way of deploying IPv6 nowadays. Now the question is: How would you explain to an IPv6-newbie what is the difference between `ripemtg` and `ripemtg-464xlat' networks? My explanation would be like: "Those networks work exactly the same way, but in the latter case, there is a one meter long cable back in the ops room, where all the traffic from the latter network is carried as just IPv6 protocol. Then it's translated back to IPv4 for the Internet" But that's probably not the explanation I would like to hear as an IPv6-newbie. Am I missing something? Also: > Having just a NAT64 gives the impression to the people that today you can deploy IPv6-only access to customers and we know is not the case, because the app. Not a problem with today's smartphones. All iPhone apps has been fixed thanks to Apple's pressure, a lot of recent Android (6.0+) devices features CLAT integrated that works even via Wi-Fi. If Microsoft pushes CLAT into some future version of Windows, the problem with apps would be mostly gone and IPv6-only access networks would be fully usable even for end-stations. Cheers, Ondřej Caletka ********************************************** 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 use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
participants (2)
-
JORDI PALET MARTINEZ -
Ondřej Caletka