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

["Collins, Alan" <[e-mail]>]

Hello everyone.

                Thank you for looking into this. I agree with the defensive strategy to remove ambiguity on the “usable PIO”. FYI, we confirmed the RA with PIO /67 was coming from backend router.

There is another scenario from old models e.g. Arris TG1682 which enabling IPv6 support defaults an empty prefix, which waterfalls into getting OTA icmvp6 RAs with ::/64. Then, SLAAC comes back with: inet6 addr: ::f603:2aff:fe66:c090/64 Scope: Global ,  - snac could also include it in the upcoming improvement.


[cid:image001.png@01D999E4.A57260B0]  [cid:image002.png@01D999E4.A57260B0]  [cid:image003.png@01D999E4.A57260B0]

Cheers,
Alan Collins


From: Esko Dijk <[e-mail]>
Date: Tuesday, June 6, 2023 at 4:09 AM
To: Jonathan Hui <[e-mail]>, "Collins, Alan" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Gabe Kassel <[e-mail]>
Subject: [EXTERNAL] [UNVERIFIED SENDER] RE: [Snac] Router using Ipv6 prefix length = 67


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


Hi,

On the requirements in RFC 7084 Section 4.3: specifically this is about requirements 2 and L-2 if I’m correct.

On RFC 2464: this has been obsoleted by RFC 4862. See Section 5.5.3 which has this requirement:

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.  An implementation MAY wish to log a system management
      error in this case.  The length of the interface identifier is
      defined in a separate link-type specific document, which should
      also be consistent with the address architecture [RFC4291<https://www.rfc-editor.org/rfc/rfc4291>] (see
      Section 2<https://www.rfc-editor.org/rfc/rfc4862.html#section-2>).

So per this requirement the host would ignore the PIO /67 and not use it for SLAAC on Wi-Fi.

Agree to clarify the usable PIO to include the prefix length. Maybe it could refer to RFC 4862 5.5.3 for the exact requirements because that has quite some detail.

Regards
Esko

From: Snac <[e-mail]> On Behalf Of Jonathan Hui
Sent: Tuesday, June 6, 2023 00:25
To: Collins, Alan <alaclli=[e-mail]>
Cc: [e-mail]; Gabe Kassel <[e-mail]>
Subject: Re: [Snac] Router using Ipv6 prefix length = 67

Hi Alan,

Thanks for sharing this information.

It seems the Netgear WNP3000 is not conformant to 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:

[cid:image004.png@01D999E4.A57260B0]
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.

[cid:image005.png@01D999E4.A57260B0]

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