Jad el Cham - 2025-05-15 08:54:41
Hi everyone, I'm Jad El Cham from the RIPE NCC. This chat panel is meant for discussion ONLY. If you have questions for the speaker and you want the session chair to read them out, please write them in the Q&A window, also stating your affiliation. Otherwise, you can ask questions using the microphone icon.
Please note that all chat transcripts will be archived and made available to the public at https://ripe90.ripe.net/.
The RIPE Code of Conduct: https://www.ripe.net/publications/docs/ripe-766/.
Éric Vyncke - 2025-05-15 09:08:51
ICMP Hop Limit exceeded in IPv6 rather than TTL (slide 13) ;-) or officially "Time exceeded'
Fernando Gont - 2025-05-15 09:23:04
im on meetecho btw
Greg Choules - 2025-05-15 09:31:12
It's a feature, not a bug!
Gert Doering - 2025-05-15 09:31:48
Well-meaning OS stupidity
David Lamparter - 2025-05-15 09:47:20
*sigh* wrong order again. Next-hops are picked before source addrs…
Gert Doering - 2025-05-15 09:48:12
if you have two routers, you need to decide on source before deciding on router
Gert Doering - 2025-05-15 09:48:38
(and there the issues start...)
David Lamparter - 2025-05-15 09:48:42
No you don't, you choose a source address that matches the next-hop
David Lamparter - 2025-05-15 09:48:56
This is a common misunderstanding
Éric Vyncke - 2025-05-15 09:51:24
rule 5.5 strikes again
Gert Doering - 2025-05-15 09:51:41
Mmmh. Applications have no view of next-hops, so if you want to decide in the application, you need to pick source first, next-hop accordingly.
David Lamparter - 2025-05-15 09:53:43
Yes and no. This is PvD, which imho needs much more work. But also, pedantically, why would applications be unable to read the host's routing table? ;-)
Gert Doering - 2025-05-15 09:55:13
Applications should neither care for routes nor IPv6 addresses, tbh... they should have an API that tells them "here are ISP A, B, C, which one do you want to use?". In lieu of that, APIs for "what IP addresses are around?" are reasonably portable, while "give me routes" is a portability nightmare...
David Lamparter - 2025-05-15 09:55:20
@Gert here's links to running code btw, to back up what í
David Lamparter - 2025-05-15 09:55:26
https://mailarchive.ietf.org/arch/msg/ipv6/yqepaI_rJj7YLu1U23yKtKpZ6sA/
Gert Doering - 2025-05-15 09:55:43
noted, will read later, thanks
David Lamparter - 2025-05-15 09:57:09
Yeah the "ISP A, B, C" thing is exactly PvD. It's a bit outside my area of expertise, I'm a routing person, but - *some* prior work exists.
Éric Vyncke - 2025-05-15 09:58:40
RFC 8801 partly addresses slide 9 (PvD)
Alexander Zubkov - 2025-05-15 10:00:52
Linux routes has "prefsrc" attribute, so the address is chosen according to the next-hop, if application does not set specific src when binding a socket.
David Lamparter - 2025-05-15 10:00:55
⬆️
Gert Doering - 2025-05-15 10:01:26
Yes, this is a very cool feature of Linux, which I direly miss on FreeBSD
David Lamparter - 2025-05-15 10:01:51
Most routes don't have a prefsrc by default though, SLAAC does not put that
David Lamparter - 2025-05-15 10:02:10
And it breaks privacy kinda
David Lamparter - 2025-05-15 10:02:22
(not completely, but…)
Alexander Zubkov - 2025-05-15 10:02:33
Yes, I didn't mean that it is actively used. But that is a possibility.
Éric Vyncke - 2025-05-15 10:02:36
FYI there is no rule 5.7 in the current RFC 6724 or in its update. It is in Fernando's draft-gont-6man-multi-ipv6-spec-01
Gert Doering - 2025-05-15 10:02:56
Eric, that's what Fernando said "we could add this rule to 6724" :-)
Éric Vyncke - 2025-05-15 10:03:33
;-)
Gert Doering - 2025-05-15 10:05:01
Did someone mention NAT66 already?
Gert Doering - 2025-05-15 10:05:04
*runs*
Kazunori Fujiwara - 2025-05-15 10:05:27
multiple PvDs solve the problem ?
Jad el Cham - 2025-05-15 10:05:55
Hi Kazunori, please write your question in the Q&A panel, or please wait until the end of the talk and ask your question using audio. Thank you!
Éric Vyncke - 2025-05-15 10:06:16
@Gert, even myself considers *NTPv6* as *a* solution
Gert Doering - 2025-05-15 10:07:01
@eric I was just trolling a bit (but indeed for certain scenarios, it's a valuable tool) - for multi-/48 multihoming I would really love to see something better
David Lamparter - 2025-05-15 10:09:13
Yeah I didn't want to open the PvD can if worms in mic 😅
Fernando Gont - 2025-05-15 10:09:40
The spec of implicit PVDs doesnt solve everything
Jen Linkova - 2025-05-15 10:09:54
But pvds are the proper solution
David Lamparter - 2025-05-15 10:11:42
That was Rodrigo Arenas Andrade (for my own reference)
Jen Linkova - 2025-05-15 10:12:52
What a dark image Eric is showing!
Fernando Gont - 2025-05-15 10:13:07
The problem with PVDs is that the solution that really solve the problem implies a new wire protocol
Gert Doering - 2025-05-15 10:13:13
Mostely!
Fernando Gont - 2025-05-15 10:13:28
So you end up in a situation that solving the problem relies on the local routers, not on hosts.
Andrew Yourtchenko - 2025-05-15 10:17:53
*waves* heya all:)
Jen Linkova - 2025-05-15 10:19:40
What was the reason for having different nat44/nat64 pools at all?
Andrew Yourtchenko - 2025-05-15 10:19:44
it was fixed on the fly actually as it was not impacting the existing sessions :)
Gert Doering - 2025-05-15 10:20:07
@jen my understanding is "different routers for nat44/nat64"
Andrew Yourtchenko - 2025-05-15 10:20:13
@Jen: platform limitation, we used CGNAT44 or CGNAT64, so had to use two boxes
Jen Linkova - 2025-05-15 10:20:24
Ah sorry missed that :)
Jen Linkova - 2025-05-15 10:22:00
Good, more v6 than v4. So we are getting closer to "nobody using that ipv4 thingy"
Andrew Yourtchenko - 2025-05-15 10:22:03
but *actually* its kinda nice to have two different boxes, since this gives protocol-and-box redundancy - if you run nat44 and nat64 on the same box and it decides to get unhappy, both will suffer. (though the native v6 was still passing through the NAT44 box, so there is still options to improve
Andrew Yourtchenko - 2025-05-15 10:22:41
@Jen: yep, *actually* the load on nat44 was probably small enough to replace it with an ISR rather than ASR - it was less than a gigabit of traffic IIRC :)
Alexander Zubkov - 2025-05-15 10:22:55
IPv6 traffic over WiFi includes NAT64?
Jen Linkova - 2025-05-15 10:22:57
Well, ideally you need redundancy for the nat boxes,
Andrew Yourtchenko - 2025-05-15 10:24:08
@Alexander: yes. with nat64 you do not have the dual "ipv4 vs ipv6" anymore, it becomes "ipv4 all the way", "ipv6 inside nat64, ipv4 outside" and "native ipv6", the middle one is ipv4 or ipv6 depending on which side of the nat64 you are
Jen Linkova - 2025-05-15 10:24:10
Then you can run nat44 and nat64 on the same set of boxes. Imho the benefit of that is you do not need to rebalance anything as v4 decreases, and v6 level increases
Greg Choules - 2025-05-15 10:25:04
+1 to that.
Andrew Yourtchenko - 2025-05-15 10:25:07
@Jen: yeah, we had that. but we do not replicate the state between the two.
Alexander Zubkov - 2025-05-15 10:26:12
@Andrew, I mean the traffic numbers were measures over WiFi, so actually there could be some NAT64 traffic in the IPv6 traffic, right? Or it was true IPv6 only traffic that was measured?
Andrew Yourtchenko - 2025-05-15 10:26:22
the design can be improved - the main idea this year was to make it modular enough such that we could rip out the nat64 boxes if it all catches fire in the worst case scenario.
Andrew Yourtchenko - 2025-05-15 10:26:58
@Alexander: absolutely. The internal wifi IPv6 traffic is a sum of "IPv6 native" and "IPv6 to nat64"
David Lamparter - 2025-05-15 10:28:21
RFC9047 is what I just mentioned, in case the number got lost
Jad el Cham - 2025-05-15 10:32:18
This session has now ended. Remember to vote for your favourite presentations by Monday, 19 May! Log in to your RIPE NCC Access account on the RIPE 90 website and visit the session pages. If you are logged in, you will see an icon next to a presentation to rate it.
The next session is Database WG, and it will start at 11:00 (UTC+1). More info on the RIPE 90 meeting plan: https://ripe90.ripe.net/programme/meeting-plan/
