| FWIW, as a concrete suggestion:
It might (or might not) be useful to bundle the tunnel software with user-space router software.
But the two are NOT directly related and this spec should not real with the user space router or its functions, IMO.
It definitely should NOT repeat requirements that are already in RFC1812 or RFC8200 regarding routers.
And I still claim this document needs to explain, even if conceptually, how this tunnel ties into router or host as a network interface, regardless of whether that network interface is accessed by an OS or user-space.
Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com On Apr 19, 2023, at 7:41 PM, touch@xxxxxxxxxxxxxx wrote:
Hi, David,
See below..
Joe
— Dr. Joe Touch, temporal epistemologist www.strayalpha.com
On Apr 19, 2023, at 2:16 PM, David Schinazi <dschinazi.ietf@xxxxxxxxx> wrote:
Hi Joe, I'm replying to your earlier email to discuss the points that are not about TCP-in-TCP, and will send a separate reply to the TCP-in-TCP discussion that's further in the thread. David Hi, David,
More below…
Joe
— Dr. Joe Touch, temporal epistemologist
Thanks, more discussion inline. David
...
All devices and processes that relay packets *between* interfaces need to make sure they decrement and check the TTL - that’s already in RFC1812. It is not the job of the tunnel to make sure that happens.
To be clear, I totally agree with you from a conceptual perspective. However, in practice, sometimes a piece of code ends up implementing both the link and the router.
Remember when you and others were claiming that how a tunnel connects to the OS or users is an implementation issue that doesn’t belong in the doc/spec?
I still disagree, because you need to explain HOW (semantically) you interface to the ultimate source or sink of the IP packets.
This, however, is a true implementation issue - and a bad one at that….
We have that in our MASQUE implementation. Because of this, we want to tell implementers "hey if you also implement a router, remember to do router things!”.
Well, there’s “remember to connect this to a router *or a host*”. Then there’s how this would interact with other interfaces on that router or host - which you haven’t defined, and probably won’t make a lot of sense because you have back-to-back devices, one of which is well defined (the host or router where you implement this), and one that’s only partly explained. And there’s no good way to relate those two on the same device.
Which is yet another reason why this should not be deployed with the tunnel - even as an implementation. Include a user-space router or don’t, but please don’t half-do it. I reorganized this part of the doc to very clearly split the link side from the router side, and clearly acknowledge that we just repeat router requirements in case someone is implementing that:
You can add an appendix that says “if you also want to connect this to a user land router, here’s how”. But again, you’re not implementing a user land router. You’re implementing something that isn’t really a router, but takes responsibility for some of the behavior of a router.
This simply doesn’t belong in this spec and should not be part of the tunnel definition at all. If you want to refer readers to an example, here’s one:
I.e., showing readers how to tie this to a user-space router or a kernel router (as an example) is useful.
Including user space router functions as a requirement of a tunnel spec is incorrect.
Joe -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
|
