Thanks.
FWIW, AFAICT inserting headers on the fly also breaks PLPMTUD too
(though PLPMTUD will eventually recover).
Joe
On 2/7/2017 11:38 AM, otroan(_at_)employees(_dot_)org wrote:
Joe,
Can anyone give those of us not tracking 672 messages a brief summary?
IMO, without diving into that thread deeply, I agree with the new proposed
text below from Brian:
Posted to list on Satuday.
https://mailarchive.ietf.org/arch/msg/ietf/MJexpTisUTSN2XrkkYVVLPJrjFM/?qid=8e4597241d656835af9f01439581f375
With one exception, extension headers are not processed, inserted,
deleted or modified by any node along a packet's delivery path, until
the packet reaches the node (or each of the set of nodes, in the case
of multicast) identified in the Destination Address field of the IPv6
header.
In fact, I'd go further to say that that non-HBH EHs should not even be
*viewed* or used as context by intermediate nodes.
And any limits on what can be done with HBH EHs should be stated explicitly.
I'd be glad if at least the EH lengths didn't change.
The original intent of the IPv6 design was certainly that. Routers should
have no need to look beyond the first 40 byte header (with one exception) and
everything else was end to end encrypted so there wouldn't be any purpose
looking there anyway.
We might get into trouble with the implementation report.
If anyone knows of any implementation, software or hardware that is compliant
with that, I'd certainly like to know. :-)
Best regards,
Ole