[ipv6-wg] Minutes from RIPE 88

Moin,

I'd appreciate not being called 'Thomas' in the minutes.

Also, it might be good to enrich the note about the post-doc working on
the data-network slides with context ('for Tobias insisting on strict
documentation prefixes on the slides').

With best regards,
Tobias

On Tue, 2024-06-11 at 11:44 +0000, Raymond Jetten via ipv6-wg wrote:
> 
> 
> 
> 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 recordings
> View the stenography transcript
> View the chat logs
>  
>  
> 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 Thomasfor 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 thatTobias 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 beenexperimenting 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 thatthe high cost for missing
> AAAA might be due to less caching time. One solution could be to
> implement an IPv6 service.
>  
> Ondrej answered thatthe 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 thatyou 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 at elisa.fi
> www.elisa.fi
> Lisätietoa henkilötietojen käsittelystä ja tietosuojasta
> Elisallahttps://elisa.fi/tietosuoja
> Mer information om Elisas hantering av personuppgifter och
> dataskyddhttps://elisa.fi/tietosuoja
> More information on personal data management and data protection at
> Elisa 
> https://elisa.com/dataprotection
>  
> *********************************************************************
> ************************
>  
> 
> For Internal Use Only

-- 
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tobias at fiebig.nl