Re: Mirja Kühlewind's Discuss on draft-ietf-6man-rfc2460bis-09: (with DISCUSS and COMMENT)

[[e-mail]]

Mirja,

[...]

>> I have no good answer. We got this wrong originally, so what can we do in the Internet Standard except document the problem?
> 
> We could actually deprecate the HBH header, and eventually define a new one/assign a new number (at some later point). And this is exactly the case where I see a new extension header coming up.
> 
> As I said in my original discuss it’s just very unsatisfying to change the HBH handling (correctly) and then say it’s not recommended to use it.

The recommendation not to use it, is because the expectation that an application can give all routers along the packet's delivery path instructions, that will be adhered to is wrong. Essentially we're saying that the HBH option should be mostly ignored, and I would expect mostly have applicability within one administrative domain.

> One more point: I recently realized is that given the destination option and the HBH option use the same registry, it actually is very tempting to simply use the destination option header with HBH options because no current router will inspect it and only new boxes that support the new feature (at the edge) may start looking into it. Just as another side note on what we might see happening in future with this recommendation.

I don't understand why you see using a destination option solves anything.
That will just end up being subject to the same operational policies as the HBH header.
And note any packet that doesn't have the TCP or UDP header directly following the IP header has a significantly higher drop probability anyway.

>> (I suspect that the real answer is that to install any kind of flow state, we need to use an explicit flow state creation protocol, not hang it off a packet header designed mainly for stateless processing. If that sounds like a short explanation of why Integrated Services/RSVP failed, it is. And it's surely out of scope for 2460bis.)
> 
> I agree (I’m working on PLUS for this reason but that’s a different topic). Nothing we have to or should address in this document. But we could be more clear and go the next step and deprecate HBH. I didn’t follow the document or wg discuss closely but to my understanding the option to deprecate HBH was not really discuss in the group. Was it?

Some people have even been discussing deprecating extension header altogether.
The working group decided not to deprecate the HBH header at this point. As in, we still think it can be rescued.

Cheers,
Ole