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

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

On 22-Mar-24 09:04, Tom Herbert wrote:
> On Thu, Mar 21, 2024 at 12:46 PM Templin (US), Fred L
> <Fred.L.Templin=[e-mail]> wrote:
>>
>> Brian,
>>
>>> Why should the IETF spend effort on upgrading IPv4 capabilities at this point?
>>
>> For air/land/sea/space mobile Internetworking, we expect to engage steady-state IP
>> fragmentation over some paths, but IPv4 will still be in the picture for a long time to
>> come and IPv4 fragmentation has known limitations (e.g., RFC4963). IPv4 fragmentation
>> using the IPv6 Fragment Header (adapted for IPv4) would address many of the issues.
>>
>> This is just to name one example. Another example is adapting IPv6 HBH options to
>> carry IP parcels and Advanced Jumbos in IPv4 packets for operation over networks
>> where IPv4 will still be used for the long term.
>>
>> IPv4 is going to be around for a long time in many networks, so making it work
>> more like IPv6 seems like a useful improvement.
> 
> Yes, we still have IPv4 users that need the capabilities. If everyone
> were on IPv6 we wouldn't need this.

So this proposal hinders IPv6 adoption. I think it would lead to an
"interesting" IETF Last Call discussion.

> 
> To be a little more direct, one purpose of the draft is to nullify a
> persistent argument against using extension headers: "They don't work
> with IPv4".

I was told in Seattle in March 1994 that the Internet was opaque to
new IPv4 options - that's the main reason I stopped work on
https://datatracker.ietf.org/doc/draft-carpenter-aeiou/, in fact.
I understand that you've bypassed that problem in the ipv4-eh
design, but surely the deployment problem here will be worse than
it is for IPv6 extension headers - IPv4 middleboxes and firewalls
are much more widely deployed than they were in 1994.

> We've seen the same story play out in a number of proposals. It goes
> like this: "We want to annotate packets with ancillary network layer
> information like extension headers are designed for, but we still have
> a large number of users still on IPv4 and so using extension headers
> is a showstopper." Unfortunately, all the alternatives for getting
> similar functionality in IPv4 have proven to be essentially hacks
> (like having intermediate devices parse UDP payloads, or somehow use
> VLAN as metadata and turn Ethernet into an E2E protocol). And of
> course, IP options are "not an option"...

Right. But there you've implicitly accepted the limited domain
model, which many in the IETF consider heresy.

    Brian

> 
> Tom
> 
>>
>> Fred
>>
>>> -----Original Message-----
>>> From: Int-area <[e-mail]> On Behalf Of Brian E Carpenter
>>> Sent: Thursday, March 21, 2024 11:59 AM
>>> To: [e-mail]
>>> Subject: Re: [Int-area] [EXTERNAL] Re: New Version Notification for draft-herbert-ipv4-eh-03.txt
>>>
>>> EXT email: be mindful of links/attachments.
>>>
>>>
>>>
>>> On 22-Mar-24 03:53, Robinson, Herbie wrote:
>>>> I would say that, in theory, that’s not a show stopper, but in practice it is a lot of work to implement – enough to suggest that you
>>> wouldn’t get enough implementations to make it useable.
>>>
>>> I'll say it because nobody else has (recently).
>>>
>>> Why should the IETF spend effort on upgrading IPv4 capabilities at this point?
>>>
>>>      Brian
>>>
>>>>
>>>> *From:* Int-area <[e-mail]> *On Behalf Of *[e-mail]
>>>> *Sent:* Thursday, March 21, 2024 10:46 AM
>>>> *To:* Toerless Eckert <[e-mail]>
>>>> *Cc:* int-area <[e-mail]>
>>>> *Subject:* [EXTERNAL] Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt
>>>>
>>>> *[**EXTERNAL SENDER**: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you
>>> recognize the sender and know the content is safe.]***
>>>>
>>>> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> -----------------------------------------------------------------------------------------------------------------------------------------------
>>>>
>>>> On Mar 20, 2024, at 9:35 PM, Toerless Eckert <[e-mail] <mailto:[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.
>>>>
>>>> I haven’t seen it mentioned yet (apologies if so), but there is a big difference between extension headers and encapsulated protocols.
>>>>
>>>> Extension headers - no matter how many - can each refer back to the base header. Same for the first encapsulated protocol.
>>>>
>>>> E.g.:
>>>>
>>>> IP1 IP2 IP3 TCP….TCP uses a pseudo header based on IP3
>>>>
>>>> But:
>>>>
>>>> IPv6a EHb EHc TCP…TCP uses a pseudo header based on IPv6a; each of the EH’s can also refer back to IPv6a
>>>>
>>>> I see NO way to do this with any mechanism for IPv4 except options (whose space is limited). There’s no way to redefine protocol
>>> processing to ensure that information can be “Carried” forward across EHs.
>>>>
>>>> This seems like a show-stopper; has it been addressed?
>>>>
>>>> Joe
>>>>
>>>>
>>>> _______________________________________________
>>>> Int-area mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/int-area
>>> _______________________________________________
>>> Int-area mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/int-area
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area