On Sat, Feb 20, 2021 at 12:10 PM Nick Hilliard <nick@xxxxxxxxxx> wrote: > > Hi Tom, > > Tom Herbert wrote on 20/02/2021 15:32: > > This is reflected in the statement: "If an IPv6 header chain is > > sufficiently long that it exceeds the packet look-up capacity of the > > router, the router might be unable to determine how the packet should > > be handled, and thus could resort to dropping the packet." It's not to > > me clear what "sufficiently long" means; > > Is this just an issue of dialect? The term "If an IPv6 header chain is > sufficiently long that..." just means "If an IPv6 header chain is long > enough that..." > > > in particular, such a > > statement isn't helpful to the host stack developer trying to figure > > out if the packets they're creating will be properly forwarded. > > That's something that should be addressed in a future ID. Right now > we're concentrating on documenting the problem. > Nick, Maybe so, but without further details I believe the way the problem is being documented is ambiguous and unenlightening. Besides, there has already been work in this area that really could be cited here. For instance, in RFC8883 the different ICMP errors reflect several different ways and provide a lot more detail as to why nodes might drop packets because headers are "too long". That RFC lists the priority of ICMP errors as: 1. Existing ICMP errors defined in [RFC4443]. 2. "Unrecognized Next Header type encountered by intermediate node" 3. "Extension header too big" 4. "Option too big" for length or number of consecutive padding options exceeding a limit. 5. "Option too big" for the length of an option exceeding a limit. 6. "Too many options in an extension header" 7. "Extension header chain too long" headers exceeding a limit. 8. "Too many extension headers" 9. "Headers too long" Numbers 3-8 represent reasons why nodes might drop a packet with extension headers. Number 9 encompasses those cases where a node parses beyond the IPv6 headers chains (for instance a node that parses into GRE encapsulation). Give that these classes are documented, then the obvious question is what are the common limits that should work. RFC8504 does this for some of the limits that are more apropos to the host; hopefully, an outcome of this draft will define some practical limits for routers and set some expectations about what should work. Tom > Nick -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
