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=40boeing....@dmarc.ietf.org> 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 <int-area-boun...@ietf.org> On Behalf Of Brian E Carpenter
Sent: Thursday, March 21, 2024 11:59 AM
To: int-area@ietf.org
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 <int-area-boun...@ietf.org> *On Behalf Of *to...@strayalpha.com
*Sent:* Thursday, March 21, 2024 10:46 AM
*To:* Toerless Eckert <t...@cs.fau.de>
*Cc:* int-area <int-area@ietf.org>
*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 <t...@cs.fau.de
<mailto:t...@cs.fau.de>> 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
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
_______________________________________________
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
