Hi, regarding MLD, RFC3810. I see that is similar to IGMP in these aspects:
Section 5. Message Formats: "All MLDv2 messages described in this document MUST be sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RFC2711] in a Hop-by-Hop Options header." Messages described in the document are only Query and Report. Section 5.1.15. Destination Addresses for Queries: "*However*, a node MUST accept and process any Query whose IP Destination Address field contains *any* of the addresses (unicast or multicast) assigned to the interface on which the Query arrives. This might be useful, e.g., for debugging purposes." Section 5.2.14. Destination Addresses for Reports: "In addition, a node MUST accept and process any version 1 Report whose IP Destination Address field contains *any* of the IPv6 addresses (unicast or multicast) assigned to the interface on which the Report arrives. This might be useful, e.g., for debugging purposes." So, I think that the same logic that I suggested for IGMP can be valid for MLD: If the IP Destination Address is multicast, then the TTL should be 1. If the IP Destination Address is not multicast, then no restrictions on TTL. In IPv6 ( https://www.ciscopress.com/articles/article.asp?p=2803866&seqNum=5#:~:text=An%20IPv6%20multicast%20address%20defines,has%20a%20unicast%20source%20address. ): An IPv6 multicast address defines a group of devices known as a multicast group. IPv6 multicast addresses use the prefix ff00::/8, shown in Table 4-10, which is equivalent to the IPv4 multicast address 224.0.0.0/4. A packet sent to a multicast group always has a unicast source address. Thanks for your time. Il giorno ven 24 feb 2023 alle ore 21:41 Alexandr Nedvedicky < sas...@fastmail.net> ha scritto: > Hello, > > </snip> > > On Fri, Feb 24, 2023 at 08:57:51PM +0100, Alexander Bluhm wrote: > > > > > Regarding MLD, I can't say anything because I've never tested multicast > > > routing with IP6. > > > > We should figure out what RFC says about IPv6 MLD. If we use Luca's > > smarter logic for IPv4, we should also fix IPv6. > > > > completely agree. I like Luca's suggestion for IPv4. > > sashan >
