So for the #IPv6 #MTU issues we seemed to stumble over at @ffhl, with our asymmetric #BGP routes to/from @FreifunkHamburg / @freifunkMUC I now wrote a small bash script to test a list of websites with varying, asymmetric MTUs: https://github.com/T-X/ipv6-path-mtu-discovery-verifier/. There is a suspicious amount of #Microsoft websites for the failed tests at the bottom.
Next steps would be to add analyzing of #tcpdump captures. But in a few samples it seemed like those sites did not receive / react to our #ICMPv6 Packet Too Big
So we initially had reports from @ffhl users that #Microsoft websites were broken, for instance #Minecraft didn't work. We could reproduce that `wget -6 "https://code.visualstudio.com/"` would hang here at @ffhl, while it would work on a normal home DSL.
The issue to us seems to be that Microsoft seems to ignore #ICMPv6 Packet Too Big messages. Which are essential for #IPv6 Path #MTU discovery...
Can anyone reproduce the issue? If you try it with TCP you might need to create a asymmetric routes.

Пишем ping на Go: сможем ли составить конкуренцию стандартному ping?

Всем привет! Меня зовут Игорь Горбунов, я разрабатываю платформу базовой станции в YADRO и изучаю Golang почти год. Уже перевалил рубеж «вывести на экран сумму четных элементов среза» и захотел написать что-то более сложное. Я интересуюсь сетями, и решил посмотреть, как в Go реализуется работа с протоколами ICMP и ICMPv6. Наиболее простая задача, связанная с ними, — реализация программы ping. Она отправляет указанному узлу сети запросы ICMP типа Echo-Request и ожидает ответы типа Echo-Reply. На первый взгляд — простейшая задача, поэтому усложним ее: построим приложение, похожее на утилиту ping в UNIX-подобных системах. Под катом расскажу, как я решал задачу и с какими подводными камнями столкнулся.

https://habr.com/ru/companies/yadro/articles/870584/

#golang #icmpv6 #ping #go #unix #glibc

Пишем ping на Go: сможем ли составить конкуренцию стандартному ping?

Всем привет! Меня зовут Игорь Горбунов, я разрабатываю платформу базовой станции в YADRO и изучаю Golang почти год. Уже перевалил рубеж «вывести на экран сумму четных элементов среза» и захотел...

Хабр
replacing ARP resolution by something that can resolve the link-layer MAC address in a different way. As it turns out, #IPv6 has an equivalent that’s called Neighbor Discovery Protocol in which a router can determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. This uses #ICMPv6 to send out a query with the Neighbor Solicitation, which is followed by a response in the form of a Neighbor Advertisement.
https://ipng.ch/s/articles/2024/03/06/vpp-with-babel-part-1/
IPng Networks - VPP with Babel - Part 1

@packetdefender decentral service and peer discovery are two more major use-cases for #multicast, I think, which you didn't mention in your article. Like #mDNS, #Bittorrent Local Peer Discovery or #Syncthing Peer Discovery. Also #IPv6 Neighbor Discovery needs multicast and having multicast snooping switches can then greatly reduce such #ICMPv6 ND traffic if you have a large layer 2 broadcast domain. Then it's way more efficient than #ARP for #IPv4.
@awlnx @ffrl @ffhl und denke es sind auch mehr als nur "ein paar Mbit/s", wenn man die Summe aller #ICMPv6 neighbor solicitation transmissions bei größeren #batman_adv broadcast Domänen in Betracht zieht. Das hatte zuletzt grob vll. 2/6 unseres broadcast overheads gemacht. War für mich auch erstmal das primäre Ziel, um #multicast / #IGMP / #MLD snooping in batman_adv und der #Linux bridge zum Laufen zu bekommen. (NS/NDP hat dann aber natürlich wiederrum nichts mit #multicast routing zu tun)
Fact checking IPv6: on a switch without MLD snooping, all ICMPv6 multicast packets (neighbor discovery, router discovery/advertisements and so on) are sent to all ports of the switch; they are thus visible in promiscuous mode by all nodes connected to the switch. And that means that multicast in this case is not more efficient than broadcasts from the network load point of view. Or am I missing something ?
#IPv6 #MLD #ICMPv6 #multicast

@troglobit also in #ICMPv6 RA / #RFC4861 it seems that again only a prefix plus prefix length is allowed. And not a netmask. Which would seem quite useful for #IPv6 #multicast?

And now I'm also wondering if a host's #IPv6 stack receiving any (routeable) unicast prefix via #SLAAC or #DHCPv6 should maybe just install the matching #embeddedRP #multicast prefix on its own, by default on the according interface?

Introductory post: this is my public sub-account for #IPv6 content; my main account is linked in my profile.

I support the complete roll-out of IPv6, including intermediate efforts like dual-stack support and #NAT64 #DNS64 #CLAT, with the ultimate goal of native IPv6 support in all-new deployments, using RFC standards and best practices.

I support subnets no smaller than /64 (#SLAAC), ISPs should delegate prefixes of at least /56 or /48, and #ICMPv6 should be rate-limited, never blocked.

Looking into #proxy -ing #MLD on layer 2 of a #Linux #bridge, between bridge ports. Why does the bridge port answer to #ICMPv6 Neighbor Solicitations and Echo Requests, but not to an MLD query? Even though there is an #IPv6 address on the bridge port? Mysterious. Looking into the code. 🧐 #kernel