On Wed, Mar 6, 2019 at 9:29 PM Joe Touch <[email protected]> wrote: > > > > 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]> 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. > Joe,
Yes, some intermediate nodes will arbitrarily drop packets. Some will only allow certain UDP ports, some will drop all IPv6, some will drop every transport protocol but TCP, some will drop packets with extension headers, some will drop fragments, some will drop packets with IP options, some will drop ICMP, some will drop UDP packets with surplus space, some will parse into HTTP and drop packets with URLs they don't like, some will drop anything else they please. That's reality. But, DPI in the network => ossification => Internet doesn't evolve. IMO, we need to address this instead of just accepting it as status quo, lest plain TCP/IPv4 is the only thing left that works on the Internet. Transport layer encryption, extending happy eyeballs approach to other features, limited domains, showing value in forward looking features, using the architecturally correct methods of host to network signalling-- are ways to start undoing the harmful effects of ossification. Tom > — > > 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
