Hello Klaus: I committed https://github.com/pthubert/6lo-multicast-registration/commit/a7bf315d9e2a760304035e9c505dbdad48f51a05 to address your issue.
Again many thanks! Pascal > -----Original Message----- > From: Pascal Thubert (pthubert) > Sent: lundi 1 août 2022 21:56 > To: Klaus Hueske <klaus.hue...@renesas.com> > Cc: 6lo@ietf.org > Subject: Re: [6lo] I-D Action: draft-ietf-6lo-multicast-registration- > 08.txt > > Great point Klaus, thanks for catching this! > > > Regards, > > Pascal > > > Le 1 août 2022 à 17:12, Klaus Hueske <klaus.hue...@renesas.com> a > écrit : > > > > Hi Pascal, > > > > The draft specifies the usage of "target address" for multicast > registration. To make this consistent, an update for the rules defined > in Section 7.1 of RFC4861 would be required: > > > > ---------------------------------------------------------------------- > ---------------------------------------------------------------- > > 7.1. Message Validation > > > > 7.1.1. Validation of Neighbor Solicitations > > > > A node MUST silently discard any received Neighbor Solicitation > > messages that do not satisfy all of the following validity checks: > > > > - The IP Hop Limit field has a value of 255, i.e., the packet > > could not possibly have been forwarded by a router. > > > > - ICMP Checksum is valid. > > > > - ICMP Code is 0. > > > > - ICMP length (derived from the IP length) is 24 or more octets. > > > > - Target Address is not a multicast address. > > > > ---------------------------------------------------------------------- > ---------------------------------------------------------------- > > > > The last condition would be violated if multicast addresses are used > as target address. > > > > I'd suggest that the draft updates RFC4861 Section 7.1 in a backward > compatible way that would allow multicast target addresses if, and only > if, the "A" or "M" flag is set. > > > > Best regards, > > > > Klaus > > > > -----Original Message----- > > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > > Sent: Montag, 25. Juli 2022 10:59 > > To: i-d-annou...@ietf.org > > Cc: 6lo@ietf.org > > Subject: [6lo] I-D Action: draft-ietf-6lo-multicast-registration- > 08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IPv6 over Networks of Resource- > constrained Nodes WG of the IETF. > > > > Title : IPv6 Neighbor Discovery Multicast Address > Listener Registration > > Author : Pascal Thubert > > Filename : draft-ietf-6lo-multicast-registration-08.txt > > Pages : 31 > > Date : 2022-07-25 > > > > Abstract: > > This document updates RFC 8505 to enable a listener to register an > > IPv6 anycast or and subscribe to an IPv6 multicast address; the > draft > > updates RFC 6550 (RPL) to add a new Non-Storing Multicast Mode and a > > new support for anycast addresses in Storing and Non-Storing Modes. > > This document extends RFC 9010 to enable the 6LR to inject the > > anycast and multicast addresses in RPL. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-6lo-multicast- > registration/ > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-6lo-multicast-registration- > 08.html > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast- > registration-08 > > > > > > Internet-Drafts are also available by rsync at > rsync.ietf.org::internet-drafts > > > > > > > > > > > > Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten > Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, > Arcadiastrasse 10, 40472 Duesseldorf, Germany, > Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax > identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE > 14978647 _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
