6lo WG Agenda - IETF 121, Dublin 15:00-16:30 (UTC) @ Liffey MR 2 15:00-16:30 (Meeting venue time) @ Liffey MR 2 Wednesday, November 6, 2024 Chairs: Shwetha Bhandari, Carles Gomez Responsible AD: Éric Vyncke Minute takers: Esko Dijk, Luigi Iannone, Shwetha Bhandari Jabber scribe: TBD Introduction and draft status Bhandari/Gomez 10 min Agenda bashing; blue sheets; scribe; Jabber scribe Agenda Bashing: No Comments. WG Drafts Status: No Comments. IPv6 Neighbor Discovery Prefix Registration Pascal Thubert 15 min https://datatracker.ietf.org/doc/html/draft-ietf-6lo-prefix-registration-04 Bob Hinden: Isn’t it a huge step for ND to do prefix allocation? We have DHCP for that? Pascal Thubert: DHCP is for getting the prefix, while ND is to inform the router that you have the prefix. There’s a lot of confusion around that. Lorenzo Colitti: We have same problem in other DHCP scenarios. There is no RFC that does not explain how to do it. This is not necessary the only way. Pascal Thubert: Not saying it’s the only way. Instead of designing a new multicast protocol the idea was to reuse the same approach and code as for the unicast addresses. Lorenzo Colitti: Seems backward. Usually it’s the server delegating the prefix. Pascal Thubert: Yes, you have to trust the server. Éric Vyncke: Using RA with Route Information Option (RIO) to do it. Why not use RAs? Pascal Thubert: Long time ago this was the case but people change to the current solution. How the host have got the prefix does not matter. Éric Vyncke: But using the RA does the same. Pascal Thubert: Yes, again it is agnostic. Lorenzo Colitti: There is overlap with SNAC. Why do we need 2/3 things to do the same things. The SNAC protocol does exactly the same with RA. Pascal Thubert: This was a missing link in SNAC, when we started this work. Eric Kline: It is weird a group suggests SNAC RA and this suggests something else. Pascal: Last time I checked this piece was missing. I did present in SNAC. Lorenzo Colitti: SNAC uses existing protocols. We need to check not to publish similar things. Éric Vyncke: If SNAC is using existing protocols for a similar use case, then we need to specify in the I-D the specific use case(s) and why we need a different solution. SNAC does not change any protocol at all. Pascal Thubert: Need to check how it is done, but we do not use multicast. In the meeting chat: Esko Dijk: Maybe good to clarify here that many years in the past, 6LoWPAN-ND was defined differently and separately from regular IPv6-ND. Because of that, 6LoWPAN networks have their own specific messages and the IPv6 ND messages (including RA) were not used - for good reasons I believe. Éric Vyncke: This would probably be useful to clarify this in the I-D for later review. Esko Dijk: So architecturally it would be strange to suddenly mix 6LoWPAN-ND with IPv6-ND (such as a RA message). (Edited in chat, added text:) However, 6LoWPAN-ND seems to have RA as well (https://datatracker.ietf.org/doc/html/rfc6775#autoid-22) although it generally tries to avoid sending multicasts (https://datatracker.ietf.org/doc/html/rfc6775#autoid-7) – something to clarify as Eric said. Path-Aware Semantic Addressing for LLNs Luigi Iannone 20 min https://datatracker.ietf.org/doc/html/draft-ietf-6lo-path-aware-semantic-addressing-08 No further comments from the room. Generic Address Assignment Option for 6LoWPAN ND https://datatracker.ietf.org/doc/html/draft-ietf-6lo-nd-gaao-00 Lorenzo Colitti: Why not use DHCPv6? The draft says that this (GAAO) is more energy efficient than DHCP, but nothing prevents you to use DHCP. Luigi Iannone: This draft does not say you cannot use DHCP. This is for a specific use case, including algorithmic distribution of addresses for stateless forwarding. Erik Kline: Assignment of a long lifetime with DHCP, wouldn’t it be more energy efficient? Luigi Iannone: This format also has a lilfetime field, hence from that perspective they are equivalent. Erik Kline: Recommend not building two solutions to achieve the same goal. Luigi Iannone: I can agree, but is simplistic because you to not look at the context. Lorenzo Colitti: Reuse DHCP packet format instead of defining a new packet format and protocol. Luigi Iannone: Not defining a new protocol. This is just an option of 6LowPAN-ND. Bob Hinden: Any data on energy efficiency? Luigi: I do not have data on energy efficiency but this can be added. Esko Dijk: 6lowPAN-ND is reused to piggy back address assignment in the same message that’s already sent, instead of having separate protocol+packet exchange using DHCPv6. Lorenzo Colitti: Clarifies reuse DHCP protocol (packet + exchange). Is the energy savings justification for defining a new protocol? Pascal Thubert: There’s code footprint on constrained devices to support multiple protocols e.g. add DHCP stack vs extending 6lowPAN-ND. Wonder whether it is not more work to adapt DHCP to this specific use case than to just define an additional option to existing machinery. Transmission of SCHC-compressed Packets over IEEE 802.15.4 Carles Gomez 10 min https://datatracker.ietf.org/doc/html/draft-ietf-6lo-schc-15dot4-07 No further comments from the room. Transmission of IPv6 Packets over Short-Range OWC Younghwan Choi 10 min https://datatracker.ietf.org/doc/html/draft-ietf-6lo-owc-02 Carles Gomez: RFC 7400 requires only experimental flags in the fist part of the option flags. Also the GAAO should align to this allocation. Luigi: Yes, indeed I received exactly the same IANA review moving the flag down. Ann Krieger (vice chair IEEE 802.15): We’ll discuss this document next week in IEEE and may have some comments for you. Éric Vyncke: Do you need a liason statement? Ann Krieger (vice chair IEEE 802.15): Will ask IEEE representative and we will figure out. Esko Dijk: When using compression don’t we need to signal that is optional? Younghwan Choi: Good question, this should be done. Esko Dijk: Is there a generic specification for SCHC that we could include the ‘S’ bit in? E.g. an open draft? (Background: S flag defines a generic SCHC functionality. Also usable in other LL technologies.) Carles: Yes, may be it is worth to have a generic function not specific to this document. Milestones discussion Bhandari/Gomez 05 min Pascal Thubert: On Prefix registration draft very specific solution that is worth to be published. Lorenzo Colitti: Why so much re-inventing. RA can be unicast as well. Pascal Thubert: Is about the code and the expectation that come with it. If the devices use SNAC this means much more code to be used. Esko Dijk: Back in 2014 (actually 2012), RFC 6775 was published and then ND was “forked”. Since then, lots of changes/updates were made and that causes the current divide between methods. SNAC WG’s solution is not suitable right now for 6lo mesh networks (although it will be extended with more in the future.) (Extensive discussion on why 6lo solutions deviate from regular IPv6 and IPv6-ND.) Carles Gomez: We should continue this discussion via other means. Back to milestones: double check with authors on the milestones documents. Pascal Thubert: Dates do not have to be changed. If the decision is to drop or not drop the document, this doesn’t influence the end date. Carles Gomez: Let’s do WGLC and keep milestones. Luigi Iannone: Can put July 2025 as date for the GAAO document. Charter discussion Bhandari/Gomez 10 min Total: 80 min Carles Gomez: Many things happened and evolved since last charter. Time to update. Carles Gomez proposes (minor) updates to charter as redline text (see slides). To discuss on ML. Carles Gomez: No direct/urgent comments on charter. See you in Bangkok! Thanks for contributions.