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

[Alexandre Petrescu <[e-mail]>]

Le 08/06/2023 à 17:38, Collins, Alan a écrit :
> 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.

If I remember correctly, :: is reserved as an address in a particular
RFC.  Also, the ::/128 has a specific meaning, IIRC, related to default
route in a routing table.

An ::/64 is actually meaning two things: an address :: and/or its prefix
::/64.  I know that in English it is difficult to translate the term
and/or in an algorithm, because one never knows whether someone saying 
in English and/or actually means 'and' or she means 'or'.  These two 
words have specific meaning in programming, and 'and/or' has no clear 
meaning in programming.  Then there is also the term 'either - or', 
which does translate into XOR (exclusive or) in programming.  But we 
cant say that ::/64 is either a prefix or an address, because it can be 
both.

My explanatory speculation of the presence of ::/64 in RA is that the
programmer needed to put something there, but empty.  That empty value
is 0.  And s/he added the plen 64 because s/he felt that all there is to
be as prefix length is 64.  Because s/he felt that 64 is actually the
only 'usable' (so to say) prefix length.

That feeling (64 is the only usable plen) is a misunderstanding, in my
humble oppinion.

Alex


  Then, SLAAC comes back with: inet6
> addr: ::f603:2aff:fe66:c090/64 Scope: Global ,  - snac could also 
> include it in the upcoming improvement.
> 
> 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:
> 
> 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>
> 
>