![](http://weberblog.net/wp-content/uploads/2020/04/UK-IPv6-Council-Spring-2020-Incorrect-Working-IPv6-Clients-Networks-featured-image-300x169.jpg)
I did a short presentation at the spring 2020 roundtable of the UK IPv6 Council. The talk was about a case study I did with my NTP server listed in the NTP Pool project: For 66 days I captured all NTP requests for IPv6 and legacy IP while analyzing the returning ICMPv6/ICMPv4 error messages. (A much longer period than my initial capture for 24 hours.) Following are my presentation slides along with the results.
At first, here are the slides (PDF):
If you’re only interested in the mere results, here is a short summary:
- dual-stacked public stratum 1 NTP server at ntp3.weberlab.de respectively ntp3-legacy-ip.weberlab.de
- listed with 10 Mbps for each Internet Protocol at the NTP Pool
- captured for 66 days
- note: only 1 out of 5 DNS names from *.pool.ntp.org is handing out AAAA records
- but there are roughly 2x more IPv4 servers in the pool
![](http://weberblog.net/wp-content/uploads/2020/04/Case-Stury-NTP-Pool-01-Number-of-NTP-Packets-1024x285.png)
![](http://weberblog.net/wp-content/uploads/2020/04/Case-Stury-NTP-Pool-02-Distribution-of-ICMP-Errors-1024x285.png)
![](http://weberblog.net/wp-content/uploads/2020/04/Case-Stury-NTP-Pool-03-Distribution-NTP-Clients-1024x311.png)
PS: A more detailed version of this presentation was initially planned for TROOPERS 20, which was canceled for obvious reasons. ;( Maybe I am re-running this study again (for a longer period?) and will submit this talk for #TR21. It would have more details about the capturing process, the tools used for analyzing the messages (tshark among others), and further strange investigations.