On Thu, Mar 21, 2024 at 12:46 PM Templin (US), Fred L <[email protected]> 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. 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". 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"... Tom > > Fred > > > -----Original Message----- > > From: Int-area <[email protected]> On Behalf Of Brian E Carpenter > > Sent: Thursday, March 21, 2024 11:59 AM > > To: [email protected] > > 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 <[email protected]> *On Behalf Of > > > *[email protected] > > > *Sent:* Thursday, March 21, 2024 10:46 AM > > > *To:* Toerless Eckert <[email protected]> > > > *Cc:* int-area <[email protected]> > > > *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 <[email protected] > > > <mailto:[email protected]>> 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > > Int-area mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
