Recent searches

No recent searches

Search options

Only available when logged in.
toad.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon server operated by David Troy, a tech pioneer and investigative journalist addressing threats to democracy. Thoughtful participation and discussion welcome.

Administered by:

Server stats:

273
active users

toad.social: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.1

#icmpv6

0 posts0 participants0 posts today
T_X<p>So for the <a href="https://chaos.social/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> <a href="https://chaos.social/tags/MTU" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MTU</span></a> issues we seemed to stumble over at <span class="h-card" translate="no"><a href="https://chaos.social/@ffhl" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>ffhl</span></a></span>, with our asymmetric <a href="https://chaos.social/tags/BGP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>BGP</span></a> routes to/from <span class="h-card" translate="no"><a href="https://chaos.social/@FreifunkHamburg" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>FreifunkHamburg</span></a></span> / <span class="h-card" translate="no"><a href="https://social.ffmuc.net/@freifunkMUC" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>freifunkMUC</span></a></span> I now wrote a small bash script to test a list of websites with varying, asymmetric MTUs: <a href="https://github.com/T-X/ipv6-path-mtu-discovery-verifier/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/T-X/ipv6-path-mtu-d</span><span class="invisible">iscovery-verifier/</span></a>. There is a suspicious amount of <a href="https://chaos.social/tags/Microsoft" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Microsoft</span></a> websites for the failed tests at the bottom.<br>Next steps would be to add analyzing of <a href="https://chaos.social/tags/tcpdump" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tcpdump</span></a> captures. But in a few samples it seemed like those sites did not receive / react to our <a href="https://chaos.social/tags/ICMPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICMPv6</span></a> Packet Too Big</p>
T_X<p>So we initially had reports from <span class="h-card" translate="no"><a href="https://chaos.social/@ffhl" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>ffhl</span></a></span> users that <a href="https://chaos.social/tags/Microsoft" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Microsoft</span></a> websites were broken, for instance <a href="https://chaos.social/tags/Minecraft" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Minecraft</span></a> didn't work. We could reproduce that `wget -6 "<a href="https://code.visualstudio.com/%22`" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">code.visualstudio.com/"`</span><span class="invisible"></span></a> would hang here at <span class="h-card" translate="no"><a href="https://chaos.social/@ffhl" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>ffhl</span></a></span>, while it would work on a normal home DSL.<br>The issue to us seems to be that Microsoft seems to ignore <a href="https://chaos.social/tags/ICMPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICMPv6</span></a> Packet Too Big messages. Which are essential for <a href="https://chaos.social/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> Path <a href="https://chaos.social/tags/MTU" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MTU</span></a> discovery...<br>Can anyone reproduce the issue? If you try it with TCP you might need to create a asymmetric routes.</p>
Loafer<p>So, *@discuss.systems ; still trying to wrap me head around this IPv6 thing, couldn't sleep last night thinking about it; even though in the past I have successfully setup an IPv6 network via Hurricane Electric Tunnel and receiving a badge at the time for having set it up to the point I could have my <a href="https://discuss.systems/tags/OpenWrt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenWrt</span></a> router pinged on the other end of the tunnel. </p><p>Had no actual <a href="https://discuss.systems/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> connection at that point, but now I believe I do. </p><p>Now I have muddled through a few tutorials on the subject and I am confused as ever.</p><p>I have at my disposal, the tools subnetcalc and the ipaddr library of python which is capable of calculating address ranges based on CIDR notation and for telling you if an address is a network address ranges, from what part of the world, or if an unicast single host address.</p><p>Half way through watching a video that recommends first watching another video with a painfully German guy who seems to really know his stuff and looks like my old coworker Brewbaker were he a bit taller, they must be relatives.</p><p>Allowing the Delegation of Global Address prefix seems to allow for sub-sub netting amongst the original address space, and if you want to prevent this it you disallow it like a land lord disallowing subletting in the lease agreement.</p><p>Also, my Xfinity connection seems to indicate that this prefix will change weekly. And if I want any of my servers to keep their static address they seem as though they will need to be readdressed manually every week, with a Global static address since the downstream prefix of their subnet would change with the weekly prefix change. And then I would have to change the firewall rules too!!!</p><p>Also it seems that somehow <a href="https://discuss.systems/tags/arp" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>arp</span></a> has been replaced by <a href="https://discuss.systems/tags/ICMPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICMPv6</span></a> and some totally confusing process called Neighbor Detection <a href="https://discuss.systems/tags/ND" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ND</span></a> in which routers and hosts advertise and solicitate.</p><p>Also, Site-Local addressing with a FEC0 range appears to have replaced the 172.0.0.0, 10.0.0.0 and 192.168.0.0 ranges but these have also been deprecated so they shouldn't be used.</p><p>And the I didn't-get-an-address, address, 169.0.0.0 has been replaced by FE80 addresses but they can oddly still be communicated with.</p><p>Seems like a mess to me, but learning something new tends to be like that.</p><p>Any tips for the blind group of men trying to describe the elephant to each other you can provide me would be appreciated.</p><p><a href="https://discuss.systems/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a></p>
Paffy<p>Repeat after me: Das ausnahmslose Blocken von <a href="https://social.tchncs.de/tags/ICMPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICMPv6</span></a> Traffic macht <a href="https://social.tchncs.de/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> kaputt.</p>
Matthieu Herrb<p>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 ?<br><a href="https://bsd.network/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> <a href="https://bsd.network/tags/MLD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MLD</span></a> <a href="https://bsd.network/tags/ICMPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICMPv6</span></a> <a href="https://bsd.network/tags/multicast" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>multicast</span></a></p>
Litchralee_v6<p>Introductory post: this is my public sub-account for <a href="https://ipv6.social/tags/IPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPv6</span></a> content; my main account is linked in my profile.</p><p>I support the complete roll-out of IPv6, including intermediate efforts like dual-stack support and <a href="https://ipv6.social/tags/NAT64" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NAT64</span></a> <a href="https://ipv6.social/tags/DNS64" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DNS64</span></a> <a href="https://ipv6.social/tags/CLAT" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CLAT</span></a>, with the ultimate goal of native IPv6 support in all-new deployments, using RFC standards and best practices.</p><p>I support subnets no smaller than /64 (<a href="https://ipv6.social/tags/SLAAC" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SLAAC</span></a>), ISPs should delegate prefixes of at least /56 or /48, and <a href="https://ipv6.social/tags/ICMPv6" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ICMPv6</span></a> should be rate-limited, never blocked.</p>
TrendingLive feeds
About