IPv6 Working Group Minutes - RIPE 82

Date: Thursday, 20 May 2021, 10:30 - 12:00 (UTC+2)
WG Chairs: Benedikt Stockebrand, Jen Linkova, Raymond Jetten
Scribe: Adonis Stergiopoulos
Status: Draft

Welcome - Agenda

The Chairs      

This presentation is available at:
https://ripe82.ripe.net/wp-content/uploads/presentations/39-_RIPE82_IPv6WG_Opening.pdf    

The minutes from RIPE 81 were approved. There were no questions or comments. 

WG Chair Re-selection

The Chairs

Jen Linkova was selected for another three years as co-chair of the working group.

An Update on Fragmentation Loss Rates in IPv6

Geoff Huston

The presentation is available at:
https://ripe82.ripe.net/wp-content/uploads/presentations/17-huston-ipv6-v6frag.pdf

Lars Prehn (MPII) asked how many vantage points his team measured from, and if it was really the end hosts that failed, or if there might just be few misconfigured “choke” routers close to the vantage point through which most traffic for the American-based devices passed. If that was the case, the numbers might just reflect the fraction of devices routed via those routers. Geoff said they used four server points and, looking closer at Canada and the USA, different networks had different loss rates, so it was far more likely that this was close to the edge, not close to them. They also measured entire continents, hence they were finding that the “choke” points were not close to them and it was more likely that they were closer to the user, or in the network at that last-hop access network.

Richard Patterson (Sky) asked if the tests included atomic fragments.  Jen clarified that during the presentation, Geoff mentioned that his team used two fragments, initially a larger one and then a smaller one, so it was just one packet with a fragment header but no subsequent fragment. Geoff said this was coming up. In about a month's time, they would have some data available.

Ivan Beveridge (Independent) asked about fragmentation and if they considered that some firewalls set MSS around 1,380. If that was tunnelled, for example due to DDoS-mitigation, they might see some issues.nGeoff said yes, but some seemed to go at 1,400. If a firewall set an MSS down that low, this could create issues and it would be a bizarre thing to do. 

David Schweizer (NetDEF) asked if they had done any tests with fragment sizes less than 1,200. Geoff said 1,200 was the smallest size they had used.

Oliver Gasser (Max Planck Institute for Informatics) asked what the baseline drop rate for IPv6 was. Geoff said this was a talk for another time, but from what he remembered, the base rate was 2%.

Christian Bretterhofer (Independent) asked for an example configuration for ISPs and enterprises to show how to make this work. Geoff said it was simple - they should not drop fragments and ask their router vendors not to drop packets with extension headers.

Jan Žorž (6connect) asked what people inside their particular countries coud do to make this better and how to approach this issue. Geoff said he didn’t know, since equipment had changed and improved over the last five years. 

Alex Le Heux (Independent) asked if they would publish this data with per-AS granularity.  Geoff said yes, and they could be found on the link in the presentation.

Marek Barczyk (SUT Computer Center) asked if they considered testing drop rate of fragmented vs packets with other IPv6 options that triggered a slow path. Geoff responded that he had not considered extension header options other than a null fragment, but he would be willing to test any if people wanted to use them on the network. 

RIPE554-bis

Tim Chown

The presentation is available at:
https://ripe82.ripe.net/wp-content/uploads/presentations/66-ripe82-ipv6wg-ripe554bis.pdf

Jordi Palet Martinez (Independent) referred to slide three of the presentation and asked why only MAP/DS-Lite and not 464XLAT and lw4o6 were used. He volunteered to contribute to this or any other parts of the document. Tim said that Jordi had contributed a lot on this particular topic in the IETF. He thought 464XLAT would be in there but he was unsure about a lightweight lw4o6. He asked Jodie to post this on the list, as it would be mentioned along with NAT64 and DNS64.

Jan Žorž (6connect) said this was just the current version of the document. They wanted to publish it as soon as possible, since many people were using it. If anyone wanted to add additional sections, they were happy to update it after the current version had been published.

MAP-E Residential Deployment and the Issues Encountered

Yannis Nikolopoulos

The presentation is available at:
https://ripe82.ripe.net/wp-content/uploads/presentations/78-ripe82-yanodd-mape.pdf

Blake Willis (Zayo Europe) asked what the driver was that pushed them to switch from MAP-T to MAP-E and if this was attributed to services module requirements. Yannis said they had only ever tried MAP-T in a very brief trial six years ago, and they did not really switch from MAP-T to MAP-E. After they tested both in the trials, they decided to go ahead with MAP-E.

Jan Žorž (6connect) asked what the top three operational issues were with lw4o6 that put them off this path. Yannis said the CPE and the AFTR, as the AFTR could not scale well to a large number of subscribers. Also, the vendor could not put up the extra development effort because there was no interest from other operators. He could not recall a third issue at that moment.

Richard Patterson (Sky) asked for more information on the issues with anycasting the BR and the limitations with policy-based routing that required the ASR99 to be dedicated. Yannis said a potential issue was that an ICMP IPv6 packet that was too big might be sent to the wrong BR if it was anycasted. About the policy-based routing, since MAP-E was implemented as a routing mechanism in Cisco, they put a limit to a specific number of PBR that can be implemented on the box. The limitation was that it can be either one or two per direction.

Jordi Palet Martinez (Independent) referred to slide 24 of the presentation where Yannis talked about S46 RFC8026. He thought it was much better to use RFC 8585, which also included support for 464XLAT. He had much more success in several broadband deployments (GPON, DSL, cellular broadband and just cellular) than all the other options. He said he was also now working on a deployment for 25 million subscribers.  Yannis thanked Jordi for the suggestions.

Sia Saatpoor (Logius) asked about the activation of IPv6 and the use of stimulation. He thought the major role and responsibility for the use of IPv6 lay with the government. In the Netherlands, the highest ICT policy body of the government had decided that all digital Dutch governments must be accessible through IPv6 by the end of 2021. Sia asked what was the role of the government in Greece or other parts of Europe in stimulating the industry. Yannis said he could only talk about the Greek government. It was currently not too far behind, but operators were running part of the governmental network, so they were trying to push IPv6 as much as they could. He was not aware of a Greek government-specific initiative at this point. 

Kostas Zorbadelos (Independent) asked if software mechanisms were the way forward, or if should they stick to CGN (for the IPv4 path) in dual-stack deployments. Yannis replied that he really hoped software mechanisms were still the way to go.

IPv6 Deployment Status

Paolo Volpato

The presentation is available at:
https://ripe82.ripe.net/wp-content/uploads/presentations/64-RIPE-82-Fioccola-Volpato-IPv6-Deployment.pdf

Christian Bretterhofer (Andritz AG) said that many people did not find any business reason to adopt IPv6. He asked if there were any reasons to adopt IPv6. Paolo answered that this was one of the most interesting and critical questions. Unfortunately, there was no definitive answer, and this was also part of the discussion. He advised Christian to look at the use cases and spend more time reading through their draft. Some operators had moved to IPv6 for innovation reasons, enabling new applications even if they were not here yet. There was also some kind of consensus that 5G and IoT were two cases demanding IPv6, but that was not entirely true. Another motivation, which was still somewhat unclear, was the role of governments and national authorities’ actions in favour of IPv6 deployment. He added that there were cases, two of them were in the USA and China, where federal and government agencies had demanded not just support for IPv6, but potentially having only IPv6-based applications. 

Veronika McKillop (UK IPv6 Council) said that the introduction of IPv6 did not immediately relieve the pressure on the IPv4 address pool, and dual-stack did not help with this problem. Only IPv6-only deployment helped with the IPv4 address shortage. She noted that it would be worth clarifying this on the relevant slide. Paolo agreed and said he would update the materials.

Happy Eyeballs Considered Harmful

Jens Link

The presentation is available at:
https://ripe82.ripe.net/wp-content/uploads/presentations/80-he.pdf

Jordi Palet Martinez (Independent) said that he had described this problem a long time ago and it was the reason he had proposed it in the IETF (“Reporting of Happy Eyeballs v2 Failures”), so that ISPs knew something was broken. Jens agreed and replied that other people saw the same problem.

Blake Willis (Zayo Europe) asked if the community was aware of a tool, site or application that users could use to catalog IPv6 problems. Or was that ecosystem hopelessly fragmented too? His question was not answered.

Christian Bretterhofer (Andritz AG) asked if there was a browser plugin to show Happy Eyeball problems like IPvFoo. Jens replied that he was not aware of a plugin and he suggested talking to the browser vendors. 

Alexander Azimov (Yandex) asked whether the adoption of NEL (Network Error Logging) was solving this kind of problem. Jens replied that it might be. He then asked if it was enabled somewhere and if it was analysed should it be enabled.

Gert Doering (Independent) said another example they saw was that Apache-ACLs were not right for IPv4 and browsers were randomly flip-flopping IPv4 and IPv6, and that user reports were inconclusive.

End of the session.