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

[Brian E Carpenter <[e-mail]>]

On 21-Mar-24 17:20, Tom Herbert wrote:
> On Wed, Mar 20, 2024 at 8:36 PM Toerless Eckert <[e-mail]> 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: <[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]
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area