Tom, > On Mar 21, 2024, at 2:20 PM, Tom Herbert > <[email protected]> wrote: > > On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert <[email protected]> wrote: >> >> Btw: When i asked on of the 6MAN chairs, about the meaning of an Internet >> Protocol >> Number being an "IPv6 Extension Header" or not, the answer was that in his >> interpretation it is simply whether the header itself has it's own "Next >> Header" >> field using the IANA Assigned Internet Protocol Numbers registry - or not. > > Thanks for asking. So by this definition IPv4 already supports > extension headers :-).
As I remember it, Authentication Header (AH) and Encapsulating Security Payload (ESP) were first developed for IPv6 and then adapted to IPv4. Bob > >> >> 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. > >> >> To me this means that it's simply a matter of consistency of simply calling >> ESP and AH >> "Extension Headers" when we do introduce this concept into IPv4. > > Agreed. > >> >> 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. > > 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: <[email protected]> >>>>>> Date: Thu, Feb 22, 2024 at 5:29 PM >>>>>> Subject: New Version Notification for draft-herbert-ipv4-eh-03.txt >>>>>> To: Tom Herbert <[email protected]> >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>> >>>>> -- >>>>> --- >>>>> [email protected] >>>> >>> >>> -- >>> --- >>> [email protected] >> >> -- >> --- >> [email protected] > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
