[Roll] RFC6553 headers if HBH Obsolete? (was Review of draft-ietf-6man-hbh-header-handling-01)

[Michael Richardson <[e-mail]>]

Ronald Bonica <[e-mail]> wrote:
    > I thought about that possibility. But doesn't that mean that hosts
    > would have to recognize HBH forever, if for no reason other than to
    > know enough to move on to the next header?

That's a good point.
Yes, they'd have to know how to skip it if they want to look at the next
header.

So, this would not affect routers that do not care to look at the next
header, but would affect end-hosts ... mostly. And security devices.

Anyone with deployed code *NOW* has this already.
So this only matters to people writing new code (or new chips).

If you think that there is ENOUGH savings... I'm listening.

What would happen to packets with RFC6553 HbH when they hit a core routers
after the change?  Ignore end hosts: I assume that if they need to understand
6553 packets addressed to them that they can afford the code.

Then we need to consider what it means for an LLN gateway that receives
a packet with a 6553 HbH option in it: since they act a bit like MPLS or
VLAN tags, we might have to drop them anyway, since they aren't trusted.

So, at the least, we would like to put IPsec AH on them, but since they are
mutable, that doesn't help that much (at least it authenticates the source,
maybe...), so we actually have to put IPsec tunnel mode on it... at which
point we are essentially back to IPIP headers on a hop-by-hop basis.
(This is precisely the ANIMA ACP model, btw. IPv6(LL)-IPsec-RPI-IPv6..)

So maybe core routers and security devices would never see RFC6553 HbH
headers..!  I'd still like to change them from 63 to 43 for the case where
the end-host doesn't speak RPI, such as in the ANIMA
NOC-does-not-speak-ACP-yet use case.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-