Subject: Re: Hop-by-Hop Extension Header processed in Slow Path ?

From: RJ Atkinson <[email-masked]>
Date: Fri, 4 Feb 2011 18:08:20 -0500

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-masked]

---

From: Christian Huitema <[email-masked]>
Date: Fri, 4 Feb 2011 23:45:03 +0000

> To me, (3) -- including advice explaining why the hop-by-hop behaviour is problematic -- seems like a sensible approach.  

There is actually an advantage to having a single "hop by hop" option. It means that by default everything else is end-to-end. Routers can thus "just forward it" without violating any IETF recommendation. That's much simpler than having to maintain a table of which payload require intermediate processing and which don't.

-- Christian Huitema