Mastodawn

Also this datasheet has a field called IP6_MLD_ACT_0_x_x and one called IP6_MLD_ACT_db8_x_x. Acc. to the datasheet to configure forwarding/trapping/copying/dropping settings. The former for #IPv6 #MLD packets with an FF0X::X:X address, and the latter for FF0X::DB8:X:X. And only the latter seems to help with trapping. Even though I'm sending an MLDv1 report for/to ff12::123...
What on earth is this "DB8" about?
#multicast

Show thread

T_X 1d ago

Ah, one small mystery solved, for documentational purposes! #RFC6676, "#Multicast Addresses for Documentation": https://datatracker.ietf.org/doc/rfc6676/
(though still not sure why playing with that helps me for ff12::123...)

RFC 6676: Multicast Addresses for Documentation

This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. This document is not an Internet Standards Track specification; it is published for informational purposes.

IETF Datatracker

Show thread

chexum 1d ago

@T_X 2001:db8: comes immediately to mind indeed, but why would they see a need to handle prefixes in hardware that are only supposed to be in documentation examples?

Show thread

T_X

@chexum RFC6676 says: "It may also be beneficial to filter out such addresses from multicast signalling and to filter out multicast data sent to such addresses". I guess that made some people think it would be nice to have an option in the switch to trap or drop MLD(v1?) reports for those multicast ranges specified in RFC6676.