> On Mar 6, 2019, at 2:38 PM, Tom Herbert <[email protected]> wrote: > > On Wed, Mar 6, 2019 at 10:59 AM Joe Touch <[email protected] > <mailto:[email protected]>> wrote: >> >> >> >> >> >> On 2019-03-06 09:12, Tom Herbert wrote: >> >> On Wed, Mar 6, 2019 at 9:03 AM Joe Touch <[email protected]> wrote: >> >> ... >> >> And yes, we can build an Internet on the Internet - again, as I've noted >> repeatedly throughout the IETF. Or we can use UDP fragmentation - which >> ought to solve all these issues in one shot. >> >> So what's the gain here? >> >> >> Joe, >> >> Please view the proposal in its entirety. >> >> >> Here are the problems, which I already stated, but seem to need restating in >> the exact context of the proposal: >> >> - IP options already cause routers to drop traffic >> this is true for both IPv4 and IPv6; making those options look like IPv6 >> just gives routers a different WAY to drop them >> > Some routers drop extension headers, but not all of them.
See RFC 7126. > If all of > them drop extension headers, then a whole bunch of effort in 6man is > pointless. No argument there. > >> - DPI looks for transport port numbers that are expected, either for service >> gating or even deeper DPI >> and GUE isn't one of them >> > There's no requirement to support DPI into the transport layer. Sure, but the current problem is that mechanisms that defeat DPI can result in traffic being blocked. > In > fact, encryption of the transport layer, like in QUIC, effectively > renders DPI into the transport layer useless. Yes, but not the transport ports. > ... > >> - pushing the actual UDP port numbers used inside a GUE header creates an >> "internet in an internet" >> as noted above, that's a losing battle we've repeatedly tried > > I'm not sure what you mean by "actual UDP port numbers”. The E2E transport being used, rather than the encapsulation layer that you need to create a place between IP and transport for these options as if they were protocols. The issue is that DPI that allows port 443 (even encrypted) and a finite set of other ports would likely block the GUE port. And it wouldn’t dive in to the sequence of headers to find the “actual” transport port inside. — What we know so far is that: - for on-path signaling, routers don’t want to be signaled or interacted with; they’re too busy just forwarding packets - the only other reason for these headers are endpoint features that can - and IMO should - be done at the transport layer Joe
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
