On Wed, Mar 20, 2024 at 09:52:48PM -0700, Tom Herbert wrote:
> 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.
I just meant:
>From the parsing perspective, if a parser knows which of the 256 code points
>are
extension headers, then it can skip them, because they all conform to the same
format
of the first 16 bit - even if the parser does not understand them
individually. The same
can not be said about any of the other IP protocol code points.
Cheers
toerless
> 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: <[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]
> > >
> >
> > --
> > ---
> > [email protected]
>
--
---
[email protected]
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
