| Hi, Martin,
I don’t think this document should repeat requirements stated elsewhere. That invites confusion as to where this spec ends and the router requirement reminders begin. At best, it might mention that requirements in RFC1812 apply to routers implemented in conjunction with this tunnel.
It’s also stated inversely - that these might not apply to implementations that don’t include a router. It’s the converse - these apply only to implementations that *additionally* implement a router. Implementing a router should not be implied as part of the mechanism.
That section also misstates IP TTL decrement: When IP proxying endpoints forward IP packets between different
links, they will decrement the IP Hop Count (or TTL) upon
encapsulation, but not upon decapsulation. Again, tunnels shouldn’t be doing this. Encapsulation isn’t what decrements a TTL; forwarding is. That happens in the router, which may or may not be included in tunnel implementation. It never happens between to hosts, if that’s where this tunnel’s packets ultimately go.
The remainder of this section discusses what to do, but it’s never clear that all the discussion applies to the router that is outside the scope of the tunnel, not part of the tunnel itself. It actually specifically talks about IP proxying endpoints that operate as routers - again implying that being a router is part of the spec.
— It might be possible to word this in ways that do not imply routing as part of the tunnel, but it’s not there yet.
Joe
— Dr. Joe Touch, temporal epistemologist www.strayalpha.com
On Apr 20, 2023, at 1:05 PM, Martin Duke <martin.h.duke@xxxxxxxxx> wrote:
Hi Joe,
Thanks for all the time you have put into this exchange.
I'm taking a close look at Section 7. IIUC, the router function language you refer to is in Section 7.2. Section 7.2 begins by saying
"The requirements in this section are a repetition of requirements that apply to IP routers in general, and might not apply to implementations of IP proxying that rely on external software for routing."
Is the common-sense reading of this that it's not "part of the tunnel spec", and therefore that this won't complicate draft-ietf-intarea-tunnels needlessly?
Martin Hi, David,
I’m fine with how the congestion control issue has been resolved.
I think the doc should include some discussion of how it would be used, which can include a router bundled with implementations.
However, my advice to the INTAREA ADs is that router functions must not be included *as part of the tunnel spec*. I don’t want to have to add this to draft-ietf-intarea-tunnels as a counterexample or with updates.
Joe
— Dr. Joe Touch, temporal epistemologist
Hi Joe,
Thank you for the very productive discussion around this draft. We've landed the majority of your feedback as changes into the document that are reflected in draft-ietf-masque-connect-ip-12. However, there remain two points: 1) inclusion of text that applies to routers that we see as important implementer advice instead of implementation-specific advice about TUN interfaces 2) whether disabling congestion control is a MAY or a SHOULD And for those, we're going to have to agree to disagree. The conversation was definitely interesting, but at this point I don't think we'll reach agreement on them.
Thanks, David
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
|
