[6lo] Re: Updating 6Lo prefix registration

[Pascal Thubert]

Hello Esko  The RIO is not supported to be used as a routing protocol. It the preference should not be a metric. It is meant to be issued by routers and consumed by hosts type C for their local routing table. This is as opposed to the prefix registration that consumed by routers and explicitly carries a request from the node to redistribute the prefix in an IGP or SGP. Would you prefer a different wording ? A bientôt; Pascal Le 18 nov. 2024 à 14:04, Esko Dijk <esko.d...@iotconsultancy.nl> a écrit :  Thanks for adding these clarifications.   One sentence part I don’t really understand: “because the RIO is explicitly not intended to serve in routing,”   Do you mean here that the RIO (being inside an RA) is intended to be sent by an IPv6 router; while the thing you’re looking for is a way for an IPv6 host to send information about a prefix to an IPv6 router? ( That appears to be the opposite of what you wrote, at a first glance. That’s why it was unclear to me.)   On the other hand, RIO does not “serve in routing” in the sense that’s it is not an option used in the routing protocol. (Rather for communication to non-routers.)  So that view could support your text. But all in all it’s not clear to me what is intended.   Esko   From: pascal.thub...@gmail.com <pascal.thub...@gmail.com> Sent: Saturday, November 9, 2024 15:24 To: 6lo@ietf.org; 6lo-...@ietf.org Subject: [6lo] Updating 6Lo prefix registration   Dear all :   As requested during the 6lo meeting at IETF 121, I pushed an update to draft indicating why we are not using RA/RIO in this registration. Diff: draft-ietf-6lo-prefix-registration-05.txt - draft-ietf-6lo-prefix-registration-06.txt   First I added a reminder on the protocol design elements that 6LoWPAN leverages for low energy operations (aka, green, or, low-carbon):   6LoWPAN was a pioneering attempt at the IETF to design protocols that    conserve energy, with the primary goal to serve LLNs, though the    general design could be applied in other environments where lowering    carbon emissions is also a priority.  The general design points    include:      *  Placing the protocol complexity in the routers to simplify the       host implementation and avoid expanding the control traffic to all       nodes.      *  Restful operations from the host perspective to enable transient       disconnections where the power usage can be lowered.      This translates into:      *  Stateful proactive knowledge in the routers that is available at       any point of time.      *  Unicast host to router operations stimulated by the host and its       applications.      *  Minimal use of asynchronous broadcast operations that would keep       the host awake and listening with no application-level need to do       so.       Then I added 2 sections at the end of the introduction to detail more specifically why IPv6 RA with RIO is not suited here, fails to respect the 6LoWPAN energy conservation principles above, lacks needful security, etc…   “      This specification extends the above registration and subscription    methods to enable a node to register a prefix to the routing system    and get it injected in the routing protocol.  As with [RFC8505], the    prefix registration is agnostic to the routing protocol in which the    router injects the prefix, and the router is agnostic to the method    that was used to allocate the prefix to the node.  The energy    conservation principles in [RFC8505] are retained as well, meaning    that the node does not have to send or expect asynchronous broadcast    messages.      It can be noted that an energy-conserving node is not necessarily a    router, so even when advertising a prefix, it is a design choice not    to use RA messages that would make the node appear as a router to    peer nodes.  From the design principles above, it is clearly a design    choice not to leverage broadcasts from or to the node, or complex    state machines in the node.  It is also a design choice to use and    extend the EARO as opposed to the Route Information Option (RIO)    [RFC4191] because the RIO is explicitly not intended to serve in    routing, and is lacking related control information like the R bit in    the EARO.  Additionally, an RA with RIO cannot be trusted for a safe    injection in the routing protocol for the lack of the equivalent of    the Registration Ownership Verifier (ROVR) [RFC8928] in the EARO. “     This was uploaded as version 06, so based on the WG meeting discussion, I believe a can now start the WGLC anytime.   Many thanks to all!   Pascal

_______________________________________________
6lo mailing list -- 6lo@ietf.org
To unsubscribe send an email to 6lo-le...@ietf.org