Re: [Snac] Router using Ipv6 prefix length = 67

[Alexandre Petrescu <[e-mail]>]

Le 06/06/2023 à 00:24, Jonathan Hui a écrit :
> Hi Alan,
> 
> Thanks for sharing this information.
> 
> It seems the Netgear WNP3000 is not conformant to

I have a list of 2 other XXX things (e.g. openbsd implementation, and 
linux vslaac patch) which might be considered by some people, or maybe 
by WG consensus, to be non conformant to the documents you cite.

I also know about some RFCs who explicitely, or some times silently, 
tell that these 2-3 things are right to do what they do.

I am not sure who is right or wrong, or whether there is a notion of 
rightfulness to start with in this context.

Alex

  RFC 7084 Section 4.3
> <https://datatracker.ietf.org/doc/html/rfc7084#section-4.3> and RFC 2464 
> Section 4 <https://datatracker.ietf.org/doc/html/rfc2464#section-4>. 
> That said, I think it makes sense for the stub router implementation to 
> be defensive in these situations and include prefix length in the 
> definition of a "usable prefix".
> 
> As for spec text, draft-ietf-snac-simple-01 Section 5.1.1 already states:
> 
>     IPv6 addressing is considered to be present on the link if a usable
>     on-link prefix is advertised on the adjacent infrastructure link.  A
>     usable on-link prefix is a prefix advertised on the link that has a
>     preferred time of 30 minutes or more, is marked on-link and allows
>     autonomous configuration.
> 
> One could argue that "allows autonomous configuration" already covers 
> this requirement, given that RFC 2464 Section 4 states:
> 
>     An IPv6 address prefix used for stateless autoconfiguration [ACONF]
>     of an Ethernet interface must have a length of 64 bits.
> 
> If we wanted to make a change, we could add some clarifying text like:
> 
>     A prefix that allows autonomous configuration includes having the PIO
>     A-flag set to 1 and required prefix length for the given link.
> 
> Thoughts?
> 
> --
> Jonathan Hui
> 
> 
> 
> On Sun, Jun 4, 2023 at 10:33 AM Collins, Alan 
> <alaclli=[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     __ __
> 
>     Hello Ted, Jonathan. ____
> 
>     __ __
> 
>                      We have multiple test setups testing Matter over
>     Thread back-to-back pairing while connected to infrastructure using
>     different (hundreds) of Wifi AP with default settings. The setup:____
> 
>     __ __
> 
>     ____
> 
>     Recently, while using Netgear WNP3000 , the Matter pairing failed.
>     The non-thread matter controller is not getting an IPv6 global
>     address, so even that the routing table contains the prefix to reach
>     into the Thread BR, the IP stack does not allow it without a global
>     IP of its own. ____
> 
>     __ __
> 
>     Thread BR is only sending icmpv6 RA with RIO. The PIO is not
>     included because there is another router in the network already
>     sending PIO. ____
> 
>     However, since that PIO has length = 67, the non-Thread matter
>     controller won’t use it to create a global IP. It’s not even sending
>     NS for DAD. ____
> 
>     __ __
> 
>     ____
> 
>     __ __
> 
>     We think the abnormal ipv6 PIO prefix RA is from the backend Cisco
>     OUI MAC address. We are investigating. ____
> 
>     __ __
> 
>     However, this opens an opportunity to create a more robust behavior
>     from Thread BR, to add more logic into processing the existing PIO
>     before deciding not to send a PIO of its own. ____
> 
>     __ __
> 
>     Thank you in advance for looking into this.____
> 
>     __ __
> 
>     Cheers,____
> 
>     Alan Collins ____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     -- 
>     Snac mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/snac
>     <https://www.ietf.org/mailman/listinfo/snac>
> 
>