Enno, >>> comply with it. The onus is on them, not on us asking folks to comply >>> with existing standards. >> >> Yes, we have heard your position on this now. >> There is of course a lot more nuance to this argument. > > could you please explain said 'nuance' in more detail?
I could try, although I fear it will be a rehash of what has already been said many times already in this debate. The IETF and the Internet architecture has a pugnacious relationship with packet mangling in the network. Steve embodied the Internet architeure principles in the IPv6 protocol suite. The IPv6 architecture consists only of routers and hosts (no middleboxes). Ensuring that routers would not need to process further into the packet than the IPv6 header, and ensure that extension header chains were expensive to parse in hardware. As well as requiring all implementations to support IPsec. Knowing that encryption was the only way to guarantee end to end transparency. Now, contrast that with the "real world", I challenge you to find a service on the Internet where the packet isn't mangled in some way between the two end-points. Be that IPv4 or IPv6. The problems with header insertion on the open Internet are well understood. That's not what is being discussed here though. What is discussed here is what is acceptable to do within a limited domain. To packets that _you_ own, i.e. originate and terminate within a domain where you control all devices. If I own and manage three routers, R1 -- R2 -- R3. You are saying that if R1 sends a packet to R3, it is not allowed to off-load some functions to R2? Going to be difficult to do stuff like service chaining then. When putting in the restrictions in RFC8200, which makes a lot of sense on the open Internet, it was always clear that there could and would be exceptions to this. Those are the ones we are discussing now. Conflating the two use cases and claiming that the arguments for why it's a bad idea on the open Internet also applies to a limited domain, only serves to polarise the debate. My suspicion is that the header insertion argument is a straw-man. Best regards, Ole _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
