On Thu, Mar 7, 2019 at 8:27 AM Joe Touch <[email protected]> wrote: > > Tom, > > On Mar 7, 2019, at 7:53 AM, Tom Herbert <[email protected]> wrote: > > ... > > 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, > > > Firewalls are critical network security devices - even when they’re located > within the client hosts’ control (e.g., enterprise edge) and thus more > E2E-‘compliant’, they currently filter by server port number (i.e., TCP SYN > dest port) - which your solution buries in a chain. > > Your proposal provides port numbers for demuxing (substantially fewer per > endpoint, because it would fix the server port as GUE), but buries the > transport type far enough that intermediate devices would more likely “give > up” and drop packets than go diving for it. > > 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. > > > If you’re on a quest to avoid ossification, you’re digging in the wrong place > and you might not want the result you get. > > Ossification is never fixed by providing “yet another” way to do something we > already can do. > > And, importantly, one person’s ossification is another’s “stable foundation” > that ensures interoperability (i.e., one layer up). So a solution needs to > address a real need in a way that we actually expect will be deployed and > used. > > The solution proposed here intends to increase work by intermediate devices > that have made it very clear they barely want to do forwarding (high speed > routers), obscures information needed by intermediate devices for security > (by burying the transport port at an unpredictable offset), and offers a > network solution to a problem we already understand is better solved at the > transport layer (fragmentation and reassembly). > > So, even after this detailed discussion, we're back where I started - asking > “where’s the need”?
Joe, Extension headers are the means of extending the IPv6 protocol, IP options are the means to extend the IPv4 protocol. IP options are not receiving any attention by IETF, have disadvantages, and are otherwise considered obsolete. IPv6 extension headers are gaining traction as there is active development in things like segment routing and other proposal for new options. This proposal has two components: 1) Allow IPv4 to carry IPv6 extension header numbers in the protocol field, and process as IPv4 extension headers. 2) Encapsulate extension headers and following transport packet in GUE/UDP #1 Brings a valuable feature from IPv6 into IPv4. This allows us to leverage all the good work being done in IPv6 to be in IPv4. #2 Facilitates deployability of extension headers (both IPv4 and IPv6 extension headers) in environments for which natively using extension extension headers is problematic, Tom > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
