On Wed, 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. > > > > Of course, this interpretation is not fully consistent with the way the > > > "IPv6 Extension Header" flag is used in the registry: IPv6 itself does > > > not have this > > > flag, so likely IPv4 should neither, even though both have this "next > > > header" field, > > > but maybe this can be explained by both ofg these being recursion instead > > > of extension > > > when happening in a header chain. > > > > Yes, although it's not clear to me how relevant the flag in the > > registry is. In any case, for IPv4 extension headers it makes sense to > > be consistent with IPv6. > > Well, i started this thread because i was worried thart there was some > semantic > attached to the flag and changing it for existing protocols would cause > potential > behavioral changes we would not want. But seemingly there is no actual > semantic > implied, so we should be able to easily declare AH/ESP in IPv4 to be > extension headers when > your draft goes through. the flag in the registry probably would only impact > the > ability of packet parsers to parse at least the extension header chain.
Toerless, Packet parsers would implement the protocol spec. If spec says there's a Next Header then we'll parse it as a Next Header. I don't believe the registry flags have any relevance to implementations. Tom > > Cheers > Toerless > > > Tom > > > > > > > > Cheers > > > Toerless > > > > > > On Tue, Mar 05, 2024 at 05:56:54PM +0100, Toerless Eckert wrote: > > > > On Mon, Mar 04, 2024 at 06:11:38PM -0800, Tom Herbert wrote: > > > > > We can treat them as EH for purposes of extension header ordering in > > > > > section 2.2. Also, IPv4 AH needs to be updated to take EH into account > > > > > as mentioned below. Other than that I don't believe there are any > > > > > substantive differences. > > > > > > > > Yes, i am trying to use ESP/AH as examples to understand the benefits > > > > of destination headers as opposed to just non-extension headers .. > > > > > > > > > No changes to APIs, we can use the same APis in IPv6 with IPv4. Kernel > > > > > changes to Linux will be straightforward. > > > > > > > > My question was not about differences in API between IPv4/IPv6, but > > > > between when > > > > ESP/AH are (as currently) NOT extension headers in IPv4 vs. after they > > > > become > > > > extension because the kernel changes have been applied. > > > > > > > > Ul;timately, i am trying to understand whether, and if so WHY we should > > > > reclassify ESP and AH in IPv4 to be extension headers. Right now the > > > > only > > > > argument i would know would be "consistency with IPv6", but that by > > > > itself > > > > does not seem to be sufficient to change something for what's being > > > > deployed > > > > worldwide in so many places. So there should be a technical benefit. > > > > > > > > And if the answer is "it does not make any difference whatsoever", then > > > > i also > > > > wonder why we would want to do it... > > > > > > > > > > Any other functional differences ? Aka: i couldn't find a simple: > > > > > > > > > > > > "If i want to define a new protocol header, should i call it an > > > > > > extension header or an ipv6 extension header - for Dummies" ? > > > > > > > > > > I think there are IPv6 extension headers and IPv4 extension headers. > > > > > IPv4 extension headers are probably just a subset of IPv6 extension > > > > > headers. > > > > > > > > That's certainly safer, e.g.: asking for a separate column in the IANA > > > > registry. > > > > > > > > > > be renamed to "IP/IPv6 Extension Header". But when this was done > > > > > > to AH/ESP, and there actually is a functional difference expressed > > > > > > by > > > > > > this extension header (as opposed to non-extension header) status, > > > > > > then > > > > > > what be the imapct of this ? Aka: I upgrade my linux kernel to > > > > > > extension > > > > > > header and all my AH/ESP breaks ? Or i do get the benefit of above > > > > > > (userland access) ? > > > > > > > > > > > > Would there be any (backward compatibility) reason to have new > > > > > > codepoints in IPv4 for ESP/AH > > > > > > with this extension header status and leave the existing (non > > > > > > extension > > > > > > header) codepoints alone ? > > > > > > > > > > No, I don't think we need that. ESP/AH should be backwards compatible. > > > > > For instance, if someone sends AH with HBH in IPv4 then they know that > > > > > their using EH and AH would take into account mutable HBH options. If > > > > > the packet is sent to a host that supports IPv4 EH then they would > > > > > know how to process the AH with HBH correctly. If the packet is sent > > > > > to a legacy node that doesn't support EH, then the packet will bv > > > > > dropped since the host doesn't recognize protocol 0 (HBH). > > > > > > > > Not clear. What you are writing implies that the encoding on the wire > > > > would > > > > change for AH from what it is now. What's exactly the change ? It's not > > > > in the next header field... > > > > > > > > > There is no > > > > > behavioral change at either the receiver or the sender if someone > > > > > sends an AH with no other EH. The draft will need to update RFC4302 to > > > > > describe AH processing with IPv4 EH present. > > > > > > > > > > RFC4303 needs an update as well, but that's just to say that EH after > > > > > the ESP is covered by the encryption, but I don't believe that > > > > > materially changes the requirements. > > > > > > > > I guess unless i can get excited for AH/ESP to get some improved > > > > behavior > > > > when turning into extension headers (see Q above), i'd probably stick > > > > to not touching > > > > them, aka: do not declare them to be extension headers for IPv4. > > > > > > > > Cheers > > > > Toerless > > > > > > > > > Tom > > > > > > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > On Thu, Feb 22, 2024 at 05:40:31PM -0800, Tom Herbert wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I updated the IPv4 extension headers draft. I structured it to be > > > > > > > self-contained without any normative references for IPv6 RFCs. > > > > > > > It's a > > > > > > > little bigger, but about 80% of the text is cut-and-paste from > > > > > > > other > > > > > > > RFCs and drafts. > > > > > > > > > > > > > > Comments are appreciated! > > > > > > > > > > > > > > Tom > > > > > > > > > > > > > > ---------- Forwarded message --------- > > > > > > > From: <internet-dra...@ietf.org> > > > > > > > Date: Thu, Feb 22, 2024 at 5:29 PM > > > > > > > Subject: New Version Notification for draft-herbert-ipv4-eh-03.txt > > > > > > > To: Tom Herbert <t...@herbertland.com> > > > > > > > > > > > > > > > > > > > > > A new version of Internet-Draft draft-herbert-ipv4-eh-03.txt has > > > > > > > been > > > > > > > successfully submitted by Tom Herbert and posted to the > > > > > > > IETF repository. > > > > > > > > > > > > > > Name: draft-herbert-ipv4-eh > > > > > > > Revision: 03 > > > > > > > Title: IPv4 Extension Headers and Flow Label > > > > > > > Date: 2024-02-23 > > > > > > > Group: Individual Submission > > > > > > > Pages: 47 > > > > > > > URL: > > > > > > > https://www.ietf.org/archive/id/draft-herbert-ipv4-eh-03.txt > > > > > > > Status: https://datatracker.ietf.org/doc/draft-herbert-ipv4-eh/ > > > > > > > HTMLized: > > > > > > > https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-eh > > > > > > > Diff: > > > > > > > https://author-tools.ietf.org/iddiff?url2=draft-herbert-ipv4-eh-03 > > > > > > > > > > > > > > Abstract: > > > > > > > > > > > > > > This specification defines extension headers for IPv4 and an > > > > > > > IPv4 > > > > > > > flow label. The goal is to provide a uniform and feasible > > > > > > > method of > > > > > > > extensibility that is common between IPv4 and IPv6. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The IETF Secretariat > > > > > > > > > > > > > > > > > > > -- > > > > > > --- > > > > > > t...@cs.fau.de > > > > > > > > > > > > > -- > > > > --- > > > > t...@cs.fau.de > > > > > > -- > > > --- > > > t...@cs.fau.de > > > > -- > --- > t...@cs.fau.de _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
