On Thu, Apr 3, 2025 at 7:45 AM Jean-Michel Combes via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Jean-Michel Combes > Review result: Almost Ready > > Hi, > > I am an assigned INT directorate reviewer for draft-ietf-6man-eh-limits-19. > These comments were written primarily for the benefit of the Internet Area > Directors. Document editors and shepherd(s) should treat these comments just > like they would treat comments from any other IETF contributors and resolve > them along with any other Last Call comments that have been received. For more > details on the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/ > <https://datatracker.ietf.org/group/intdir/about/>. > > I would appreciate clarifications about “Intermediate node” concept, based on > the following text: Hi Jean-Michel, Intermediate nodes have properties of both hosts and routers and so IMO they merit their own class. > > <document> > 1.3. Terminology > > This section provides definitions for some terms used in this document. > > Node: a device that implements IPv6 > > Router: a node that forwards IPv6 packets not explicitly addressed to itself > > Intermediate node: a node that is addressed by an entry in a Routing Header > list where the entry is not the last one in the list > > Host: any node that is not a router or intermediate node > > IPv6 header chain: the IPv6 header and the set of following IPv6 Extension > Headers that precede the upper layer protocol in a packet > > 2. Overview of extension header limits > > <snip> > > Limits are defined for both senders (sending hosts) and receivers (receiving > hosts, intermediate nodes, or routers). A receiver limit is set to limit the > amount of processing or the amount of data in received extension headers. > Sender limits are set to limit the use of extension headers being sent. The > purpose of sender limits is to increase the probability of successful delivery. > </document> > > Why the “intermediate node” concept has been specified? > Indeed, except if I missed something, the “intermediate node” could be > considered as a “receiving host” when receiving a packet and, after RH > extension process, as a “sending host” when sending the packet. Correct? No, a distinction is being per the extension headers that may be processed by various nodes. A host processes all extension headers, a router only processes the Hop-by-Hop extension header, and an intermediate node processes extension headers through the routing header including any Destination Options before the Routing Header. While processing Destination Options is a sort of function for a "receiving host", forwarding a packet is clearly a router function (an intermediate node is forwarding packets because it's sending the packet to the next hop without changing the source address to be its own). > > > BTW, is there something that prevents any “intermediate node” to modify > extension headers (e.g., numbers, length) inside the packet? If not, IMHO, > limits for senders should apply to any "intermediate node" too. They're not allowed to do that since they are not the source of the packet. That is, the source address is still the original one. Albeit, RFC8200 is a little ambiguous on this: "Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." A strict reading of this would allow intermediate nodes to insert extension headers since the node's address is the Destination Address. Some of the segment routing folks did point this out as an allowance to change the Routing Header in flight. I believe the feedback from 6man was that the spirit of the law is that extension headers cannot be inserted or deleted by any node in the path to the *final* destination of the packet. Pragmatically, inserting extension headers or increasing the size of the packet would lead to problems include breaking Path MTU discovery, however there is a proposal to allow nodes in the path to remove extension headers under certain conditions which should be much safer (https://datatracker.ietf.org/doc/draft-herbert-eh-inflight-removal). There's an interesting caveat. An option in Destination Options before the routing header could be marked as modifiable by setting the third highest order bit of the Option Type. Conceptually, this would allow intermediate nodes to modify the Option Data in flight. I'm not sure anyone has ever attempted this, but the standard does seem to allow it. Note that intermediate nodes are forwarding packets like routers, so sending limits don't apply to them. Sending limits are only relevant to hosts which are the only nodes allowed to set extension headers in a packet. Once they're set, all nodes in the packet forward packets without regard to any sending limits. In particular, if a packet is dropped somewhere in the path it's up to the source node to handle that, for instance by removing headers from future packets. This is aided by ICMP errors informing the host of the reason for the discard. Routers and intermediate nodes have no role in this process other than applying receive side limits and sending ICMP errors when a packet is dropped because a limit is exceeded. Tom > > > Thanks in advance for the clarifications. > > Best regards, > > JMC. > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
