On 27/2/20 04:51, Dirk Steinberg wrote:
On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont <fg...@si6networks.com
<mailto:fg...@si6networks.com>> wrote:
Hello, Eric,
On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
> Writing this without any hat,
>
> Please note that on the logical side, it still have to be
"proven" that this idea is strictly forbidden by RFC 8200.
Here's the proof part:
1) Isn't IPv6 end to end?
2) How do core components of IPv6, such as AH and PMTUD work in the
present of intermediate nodes that can add and/or remove arbitrary
extension headers?
It should be clear from the above that EH insertion/deletion is
forbidden.
As I already explained to you this is not true.
The wording of RFC8200 clearly allows this.
The node addresses by the DA of the packet can do this.
I understand that you would like to modify the wording of
RFC8200 to make your point true but it simply is not.
Repeating a false statement does not make it true.
Please answer the questions I've asked, and you'll get the response:
IPv6 is end to end, and does not support header insertion or deletion
en-route to the final destination. It would break core IPv6 components
such as PMTUD and AH.
If you find that the wording in RFC8200 should be improved, so be it: we
already have to improve it from RFC2460, and it seems you still trying
to find ways to circumvent the spec.
If the spec warrants a *clarification*, so be it: we already did it from
RFC2460, we did it for RFC8200 for the fragmentation part, and we may
also have to do it for EH processing (and not only for this issue).
I have given it a shot here: https://www.rfc-editor.org/errata/eid5933
That's what erratas are for.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
