Dear list members,
here are the draft minutes from the IPv6 wg session held during ripe88
if you have any comments, please let us know as soon as possible, preferably this week.
Much thanks to the RIPE NCC for taking the minutes.
IPv6 Working Group RIPE 88
Thursday, 23 May 2024, 11:00-12:30 (UTC+2)
Chairs: Christian Seitz, Jen Linkova and Raymond Jetten
Scribe: Evelien Schilder
Status: Draft
View the stenography transcript
1. Welcome
The presentation is available at:
https://ripe88.ripe.net/archives/video/1352/
Raymond welcomed everyone. The minutes of RIPE 87 were approved. He thanked Jen Linkova for chairing the IPv6 Working
Group since RIPE 67 and acknowledged her outstanding work.
2. Co-Chair-Change
The presentation is available at:
https://ripe88.ripe.net/archives/video/1354/
Jen Linkova stepped down as an IPv6 Working Group chair. Nico Schottelius was selected to replace Jen as a new IPv6 Working
Group chair.
3. Operational Issues Discovered During IPv6-mostly Migration
Jen Linkova, Google
The presentation is available at:
https://ripe88.ripe.net/archives/video/1355/
Jen discussed recommendations and operational issues related to IPv6-mostly migration.
Jordi Palet Martinez, The IPv6 Company, said that he disagreed with Jen’s recommendation to not use DNS64.
Jed replied that
it may be needed, operational experience was necessary to see how many legacy systems rely on it, because this is currently clear.
Jordie said that in his experience when you disable DNS64 and you have CLAT, when reaching IPv4 only destinations, two translations are
needed - CLAT and PLAT. This means extra translation and extra power needed. Given the low level of deployment and usage of DNSSEC, there is an increase in deployment of IPv6 in content providers, the ability to enable for example, in BIND, doesn't break DNSSEC,
and some hosts are already doing AAAA synthesis. He has not found customers with problems with breaking DNSSEC, even for big deployments. Having vendors implement AAAA synthesis is more useful than disabling DNS64.
Jen Linkova replied that it’s a controversial part of the document. She thanked Jordi and asked him to continue this on the list.
Ondøej Caletka, RIPE NCC, said that the RIPE NCC Tech Team ran this experiment this morning where they disabled DNS64 on the IPv6-mostly
network. He said that nothing should break, because either the device would be running dual stack or running IPv6-only. There might be less efficiency. All these issues are from people who actively changed the default configurations of their devices, so he
was interested in fixing these issues in Linux and was happy that the IPv6-mostly network worked during this meeting.
Jen asked if Ondrej would volunteer to get CLAT done for Linux.
Ondrej replied he’s already working on that, so things are happening. There was also a project sponsored by the NLnet Foundation, so things were happening.
Jen thanked him and said the discussion should continue.
Yoshinobu Matsuzaki,
IIJ, said they deployed an IPv6-mostly network at the APRICOT conference in February, and they used an enterprise access point. It’s too smart, as
it assures the client has DHCP and IPv4 address and if the client does not require IPv4, the access point automatically kicks out the association every 10 minutes.
Jen answered that Cisco was supposed to fix that a while ago.
Yoshinobu added that one has to be careful when configuring such an access point.
Jen said it was a good point and that they need to add that to the document.
4. IPv4-with-IPv6 Next-Hop
Tobias Fiebig
The presentation is available at:
https://ripe88.ripe.net/archives/video/1358/
Tobias Fiebig (MPI-INF / AS59645) suggested an end to making IPv4-driven addressing plans. He recommended following RFC
8950 and said that IPv4 with IPv6 next hop is the future. This allows one to fully leverage the available IPv4, to build a clean IPv6-centric addressing scheme and to have IPv4 as a flexible add-on with a central IPv4 IPAM.
Nico Braud-Santoni, Funkfeuer Graz, asked that Tobias mention IPv4 forwarding to an IPv6 next hop on Linux
with net link. He also asked if Tobias could clarify what he meant and under which conditions this would work.
Tobias Fiebig, MPI-INF, said he didn’t have the exact kernel version but with the Debian 12 or Ubuntu 20.04, 22.04, you
can just tell your routing stack on Linux to use a v6 next hop for a v4 route. So it's “ip route add default via inet6 fead:…” and it sends packets.
Robert Scheck said that for RFC 9850 support, Tobias hadn’t mentioned OpenBGPD. He asked if Tobias had considered
OpenBGPD.
Tobias said that he believed that it was on the road map.
Maria Matejka, Bird/CZ.NIC, thanked Thomas
for using documentation prefixes in his presentation. She said she can't remember when she saw a presentation using strictly the documentation prefixes even for IPv4, it must have been years ago.
Tobias answered that he was currently teaching data networks and they have a lot of prefixes on the slides
and the postdoc who had to revise the slides really, really hates him.
Jen commented that
Tobias had said that you get less capability of traceroutes for IPv4. She said that if your routers do the right thing, you do not lose anything. You might lose some capabilities if you have multiple L3 links between two devices.
Tobias answered that she might be overestimating the number of IPv4 addresses in the test setup. He said
there was no IPv4 on loopback.
Jen said she would need to think about this further.
Stefan Pantelmann, AVM, asked if Tobias had compared his approach to other existing protocols working with IPv4 and IPv6,
let's say MAP-T or MAP-E?
Tobias answered that he hadn’t made a comparison, and that this was not a protocol, it was just routing and forwarding
packets. There is no state, there is no translating, it was just forwarding packets and was also not that relevant for client networks. This was more to get it to virtual machines and things that provide services.
Stefan said they had five or six different modes now in their routers that deal with whether the provider offers full
dual stack, DS-Lite or minor form etc. They did not have this as of now and how could it be done.
Tobias said he hadn’t looked at it. Access was the wrong side of the stack for him.
Joerg Jungermann (Northern Data AG) said he’s been
experimenting since 2019. He commented that it makes your network easier and he’s happy to work in an environment where they have IPv6 as a first class citizen. They operate a cloud and having a greenfield deployment makes the
network very easy to manage and to route IPv4 addresses to the clients.
Tobias thanked him and said that if someone was running an IX to please drop him an email. He is looking to access to the peering LAN, a little bit of backhaul and a small virtual machine and the IX members can play with this.
5. IPv4-mapped IPv6 Addresses
Ondøej Caletka, RIPE NCC
The presentation is available at:
https://ripe88.ripe.net/archives/video/1361/
Ondøej spoke about IPv4-mapped IPv6 addresses, which are used for IPv4 compatibility in IPv6 socket API. They are not meant to be used
anywhere on the Internet but apparently some people are putting them into public DNS for cost saving reasons.
Maria Matejka, Bird / CZ.NIC, said that Ondøej should have used fax to contact the German company, they would take it seriously.
Ondøej thanked Maria for the comment.
Nico Braud-Santoni, Funkfeuer Graz, asked if
DNS providers’ authoritative or resolvers could alleviate the problem by providing A records as auxiliary data on AAAA queries, perhaps only in cases where no native IPv6 address is available.
Ondøej thought it might be possible.
Alexander Zubkov, Qrator Labs, said that
the high cost for missing AAAA might be due to less caching time. One solution could be to implement an IPv6 service.
Ondrej answered that
the best way to solve this was by implementing IPv6.
Jen said she agreed that it is necessary to provide clear guidance. She thought it should go in the Happy Eyeballs v3. There is a draft
and has a section about broken AAAA records. The text is on GitHub.
Ondrej agreed that it was a good idea.
Tobias Fiebig, MPI-INF, said he recently got a lot of DNS data and asked if Ondrej wanted to know how bad it was. He could ask a student
to run the data.
Ondrej answered that Tobias could share it with the IPv6 Working Group or DNS Working Group if it’s about
broken DNS.
Tobias said that he would look into it.
Oleksij Samorukov, NetArt Group, said that v6/v4 compatible is a bad idea as it could break layers in a strange way. He also said it would
be interesting to run a global survey on some big DNS registry databases.
Ondrej answered that this was discussed in the IPv6 mailing list, as well as in an incident report from GitHub.
They started preparing for the IPv6 rollout and they found the issue that IPv4-mapped IPv6 addresses started causing
trouble for them.
Raymond Jetten, RIPE NCC Executive Board, said that Ondøej has a volunteer for deploying IPv6 at GitHub and that it’s Jordi.
Blake Willis, Zayo Europe, commented that
you will find that folks that may be running 6PE in their networks, meaning IPv6 with a labelled Unicast next hop which
would be IPv4 Unicast BGP sessions. With JunOS, the router will synthesise one of these address with ::ffff: and the IPv4 loopback of the remote BGP network. Now the next hop is a label but it needs something to resolve the next hop. He didn’t think that the
actual packet has a IPv4-mapped next hop on the wire, but the address might be seen.
Ondøej answered that it's the same
case as the host behaviour because you have a 128-bit field and you have to fill it somehow with a 32-bit number.
Philipp Tiesel, SAP, had two comments.
He said he always considers these types of addresses as a IPv4 address so the behaviour is quite consistent to what
he would have expected even if we should be putting this in AAAA records. He’s asking if Ondrej tried to use it to force a DNS64 IPv6-only host to use the CLAT because this is what he would expect to work. He suggested to taking a macOS, take an AAAA record
and see whether one can avoid DNS64 synthesis, and see whether that works.
Ondrej said he was not sure if he could follow the suggestiong but was open to trying it out.
Tom Hill (BT) asked whether the record DNSSEC was signed.
Ondrej answered that it was.
Tom Hill then asked if Ondøej was aware of NSEC. Not having a record if NSEC is enabled can cost you a lot of money potentially.
Ondrej then said that it was a good point, so maybe the charging scheme of the cloud DNS provider makes sense, but it doesn’t make sense
as people put wrong data in DNS.
Tom said he didn’t have a good answer to that.
6. Thanks, Wrap Up and Rate the Talks
Working Group Chairs
The presentation is available at:
https://ripe88.ripe.net/archives/video/1362/
Raymond thanked the working group and reminded everyone to rate the talks.
The session was concluded.
Raymond Jetten
Senior Technology Specialist
Production
Cloud Services, Networks and connectivity
Interconnectivity & Content
Elisa Oyj
Vuolteenkatu 2
33100 Tampere
+358 45 6700 139
raymond.jetten@elisa.fi
www.elisa.fi
Lisätietoa henkilötietojen käsittelystä ja tietosuojasta Elisalla
https://elisa.fi/tietosuoja
Mer information om Elisas hantering av personuppgifter och dataskydd
https://elisa.fi/tietosuoja
More information on personal data management and data protection at Elisa
https://elisa.com/dataprotection
*********************************************************************************************
For Internal Use Only