On 4th February 2011 at 09:00:15 -0500, Joel Halpern wrote: > Given what we know about packet processing, any extension that believes > it will be processed by every router along the path is probably fooling > itself. > > Therefore, documenting something that claims to provide > that functionality is probably a mistake. > > At that point, we go to the question of whether, for those packets > that want hop-by-hop processing by some routers distinct from the > end point to which the packet is addressed, how should we do it. > > 1) Don't. > > 2) Extensions: Note that our underlying documents specifically > say not to do that, for very good reasons. Even the new document > on extension headers was only describing extension headers > for end-to-end processing. > > 3) Use HbH anyway. There is hardware that can ignore it. > There is hardware that can parse it. We coudl certainly > couple that with discouraging all such use.
+1 to everything above. To me, (3) -- including advice explaining why the hop-by-hop behaviour is problematic -- seems like a sensible approach. Trying to say that IPv6 options with hop-by-hop behaviour can't be created at all is actually less effective than a document explaining why hop-by-hop *behaviours* can be problematic and requiring IESG Approval before any new IPv6 options with hop-by-hop behaviour are specified. > We have found, repeatedly, that pretending we can direct packets > to every router along a path is just not a good idea. Note that > even our OAM fanatics (MPLS-TP) have given up on trying that trick. +1 to that also. > That of course would bring us back to discussing where extensions > with end-to-end semantics should go. I am still unclear why the > end-to-end options header is not sufficient for those cases. Agreed. Moreover, worked examples already exist showing that the IPv6 Destination Options Header can be used as-is to support new end-to-end IPv6 options not envisioned back in 1995. Further, we know that some existing widely deployed commercial IPv6 routers can parse-past the Destination Options Header at wire speed if appropriate (e.g. to look at transport-layer protocol and transport-layer port numbers as part of an ACL decision). Yours, Ran [email protected] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
