Re: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-eh-03.txt

[Tom Herbert <[e-mail]>]

On Wed, Mar 20, 2024 at 9:35 PM Toerless Eckert <[e-mail]> 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: <[e-mail]>
> > > > > > > Date: Thu, Feb 22, 2024 at 5:29 PM
> > > > > > > Subject: New Version Notification for draft-herbert-ipv4-eh-03.txt
> > > > > > > To: Tom Herbert <[e-mail]>
> > > > > > >
> > > > > > >
> > > > > > > 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
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > ---
> > > > > > [e-mail]
> > > > >
> > > >
> > > > --
> > > > ---
> > > > [e-mail]
> > >
> > > --
> > > ---
> > > [e-mail]
> >
>
> --
> ---
> [e-mail]