Date: Wednesday, 26 Oct 2022, 12:00-13:00 (UTC+2)
Chaired By: Benedikt Stockebrand, Raymond Jetten
Scribe: Oleg Muravskiy
Status: Final
IPv6 Working Group Co-Chairs
Raymond reminded participants about the Code of Conduct. The RIPE 84 minutes were approved.
Benedict announced that Raymond's term as co-chair had ended, but that he was happy to continue in that role. There were no further nominations or objections, so Raymond was re-appointed as co-chair.
Pablo Camarillo, Cisco Systems
This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/76-20221026-RIPE85-SR-PathTracing.pdf
Pablo described the recent implementation of an addition to the IPv6 packet header extension that records the path of packets in ECMP networks and presented the use cases that were enabled by this feature.
Leandro Bertholdo, University of Twente, asked how this addition was different from the IPv4 registration option.
Pablo replied that the main difference in this approach was that they recorded the information at the line speed of the basic packet forwarding pipeline, and used only 3 bytes for each node.
Leandro asked the presenter if they recorded an ID of the router that the packet passed.
Pablo replied that they recorded a sequence of interface ID.
Leandro asked if it was for the input interface or the output.
Pablo replied that they recorded an ID of the output interface at each one of the routers
Alexander Azimov, Yandex, asked if this would work in the MPLS core.
Pablo said that this was possible, but that for the moment it was only implemented for IPv6.
Nico Schottelius, ungleich
This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/74-ripe85-open-source-nat64.pdf
Nico showed a comparison of different open source implementations of NAT64, and asked the audience to provide more feedback and point out implementations they missed.
Jan Žorž, 6connect, asked Nico if they had tried a VPP implementation as it was very fast.
Nico said that he hadn’t but that it was nice to know about it.
Urban Suhadolnik, University of Ljubljana, asked if the presenter knew of any CLAT implementation, possibly for Windows, as the user-space implementation of CLAT was missing.
Nico said that he couldn’t answer the question as he was not familiar with this the topic.
Ondřej Caletka, RIPE NCC
This presentation is available at: https://ripe85.ripe.net/wp-content/uploads/presentations/9-RIPE85-Deploying_IPv6_mostly.pdf
Ondřej presented an "IPv6-mostly" network that was implemented at this RIPE Meeting, which combined IPv6 functionality only for devices that supported it, and traditional dual-stack for other devices, all in the same network.
Leonard Wagner, IN-Berlin e.V, asked since which Android PREF64, DHCP option 108 and CLAT were supported.
Ondřej replied that version 11 and above were supported by the vendor, but that he was not sure about older versions.
Michael Richardson, one of the authors of the IPv4-only option, noted that when he developed this feature he never imagined that people would deploy it on DHCP servers and not change anything. He added that it was interesting to see how it worked because they assumed that DHCP servers would not allocate addresses and therefore would not run out of addresses in the pool. So it was cool to see that it just worked without doing that.
He further said that for any connect, if the client was v4-only, and was just creating a v4-only UDP encapsulated thing that the local end of course had no idea what to do with, it had to be encapsulated in a v6 packet to send it. He added that he thought CLAT would be of no help but that it might work on Mac OS but not on other systems. He mentioned that IOS would never work until it went to v6 and that the Cisco people should be embarrassed about this.
Veronika McKillop, UK IPv6 Council, asked which DHCP servers supported RFC8925.
Ondřej replied that this was option 108 and that Kea, at least, did not support it. He added that there were two options. If you have enough addresses for the IPv4 pool, any server that allowed setting a custom option could be used. If there was any special support for this feature, the server would simply respond with option 108 and not allocate an address from the pool. He stated that he was not aware of such an implementation, as even Kea cannot be used in this way. He added that if the pool was empty, it would not even respond and that this was an interesting feature to implement for DHCP server producers.
Jordi Palet Martínez, The IPv6 Company, said that it was worth mentioning that most of the CLAT implementations just used a default NAT64 prefix (the WKP). He added that there was only a single translation when using the CLAT and that two translations were only needed if there were no DNS64 (https://datatracker.ietf.org/doc/rfc8683). He said that even if your network was using NAT, NAT64 would also work well.
Radek Zajic via Meetecho shared that the CLAT on iOS 16 also worked in apps requiring unix/raw sockets too (e.g. Hurricane Electric Network Tools can ping IPv4-only targets via the CLAT).
Ondřej thanked Radek for his comment.
IPv6 Working Group Co-Chairs
Raymond thanked all participants and the RIPE NCC and closed the session.