On 21-Mar-24 17:20, Tom Herbert wrote:
On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert <t...@cs.fau.de> 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 :-).
Well, look at
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header
and https://www.rfc-editor.org/rfc/rfc7045.html#section-4
We did try to clarify this.
Brian
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: <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
_______________________________________________
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
