On Thu, Mar 21, 2024 at 8:18 AM Robinson, Herbie <Herbie.Robinson=40stratus....@dmarc.ietf.org> wrote: > > But they aren’t independent. There are going to be dozens of places where it > scans the packet in order to extract the port number from the ULP headers > (TCP, UDP, etc). Those will all break. And that includes all of the > processing offload and packet routing done in the NIC. > > > > And those are just a few things I could think of in 2 minutes…
Hi Herbie, But none of those things break any *protocol standard*. When intermediate nodes do deep parsing into packets to find port numbers they are not following a standard protocol, they are doing that on their own accord. And note that port number extraction is an opportunistic mechanism, it only works when a device has support for specific protocols in a packet. For instance, most devices can extract ports from TCP and UDP, but can they extract them from DCCP or SCTP? What about GRE or IPIP and other tunneling protocols? Even if they do all of those, they can't extract port numbers from an ESP packet. So port number extraction already doesn't work in a bunch of cases, and IPv4 EH doesn't create a new problem in that regard. As for NICs, I don't think that is much of a problem any more. We now expect them to be programmable to easily support new protocols. So skipping over some new EH to find port numbers isn't much of an issue (actually, it's the same code they would use with IPv6 so it's just a matter of enabling the protocol numbers for new EH). >From the POV of intermediate nodes, extension headers are just another protocol they might see. If they want to parse them that's fine, if they want to ignore them like they would need to do with ESP or some other protocol they don't implement that's fine. What they shouldn't do is just drop packets because they don't approve of the protocols they encapsulate. If we accept that they can do that, then we're accepting the ossification of the Internet as status quo. Tom > > > > In the host it's not a horrible amount of work since extension headers > are mostly independent of the IP protocol and we'll be able to share a > lot of implementation. For instance, supporting Fragment Header in > IPv4 is fairly straightforward, most of the logic dealing with > fragments in reassembly is agnostic to the IP protocol (except for > using the addresses to match fragments to the reassembly queue). I > imagine it's probably less than fifty Lines of Code to support IPv4 > Fragment Header in Linux. > > Support in routers is already there inasmuch that they can forward > packets of any unresognized IP Protocol. Router support for IPv4 HBH > or the IPv4 flow label is completely optional. > > Tom > > > > > > > > > > > From: Int-area <int-area-boun...@ietf.org> On Behalf Of to...@strayalpha.com > > Sent: Thursday, March 21, 2024 10:46 AM > > To: Toerless Eckert <t...@cs.fau.de> > > Cc: int-area <int-area@ietf.org> > > Subject: [EXTERNAL] Re: [Int-area] New Version Notification for > > draft-herbert-ipv4-eh-03.txt > > > > > > > > [EXTERNAL SENDER: This email originated from outside of Stratus > > Technologies. Do not click links or open attachments unless you recognize > > the sender and know the content is safe.] > > > > > > > > ________________________________ > > > > On Mar 20, 2024, at 9:35 PM, Toerless Eckert <t...@cs.fau.de> wrote: > > > > > > > > On Wed, Mar 20, 2024 at 09:20:24PM -0700, Tom Herbert wrote: > > > > In other words, Destination Option Headers do not have fundamentally > > distinct > > processing requirements on the destination host examining it than any other > > possible protocol header (e.g.: UDP, TCP), or at least we could not find > > such a description > > for any such guiding rules or treatment differences in RFC8200. > > > > > > Yes, that's mostly how all the IP protocols are implemented. > > Processing of an encapsulated protocol isn't completely independent, > > for instance the pseudo header for the TCP and UDP checksum is > > different for IPv4 and IPv6. > > > > > > Right. But it seems unrelated to whether or not a header is an extension > > header, > > TCP and UDP not being extension headers for example. > > > > > > > > I haven’t seen it mentioned yet (apologies if so), but there is a big > > difference between extension headers and encapsulated protocols. > > > > > > > > Extension headers - no matter how many - can each refer back to the base > > header. Same for the first encapsulated protocol. > > > > > > > > E.g.: > > > > > > > > IP1 IP2 IP3 TCP…. TCP uses a pseudo header based on IP3 > > > > But: > > > > IPv6a EHb EHc TCP… TCP uses a pseudo header based on IPv6a; each of the > > EH’s can also refer back to IPv6a > > > > > > > > I see NO way to do this with any mechanism for IPv4 except options (whose > > space is limited). There’s no way to redefine protocol processing to ensure > > that information can be “Carried” forward across EHs. > > > > > > > > This seems like a show-stopper; has it been addressed? > > > > > > > > Joe > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
