On 17-Jun-26 03:24, Pinkert, Tjeerd wrote:
Dear Eric,
I strongly oppose to closing the IPv4 options registry without alternative
means of providing similar features on the network layer level (IP protocol).
As you know there have been several I-Ds the last years requesting IPv4 option
numbers, that were refuted/demoted “because IPv4 options are not an option”.
They weren't an option in 2005, as the reference shows, and they weren't an
option in 1994 on the only occasion that I proposed one. The Internet has been
opaque to IPv4 options for more than 30 years and that isn't going to change.
(draft-gafni-ippm-ioam-ipv4-options-00,
draft-pinkert-ippm-ip-measurement-option-03)
These I-Ds certainly have relevance for use in limited domains, but also over
the internet at large.
I'm the last person to deny the importance of limited domains, but there you
have a much more flexible solution which is of course an IPv6 extension header.
I have the feeling that IPv4 will still be long in existence (another 50 years would not be impossible)
It will be in use for sure, because it works exactly as it is. I think we'd do
the world a favour by declaring it frozen.
Regards
Brian Carpenter
so keeping open the flexibility of extending an IPv4 header should be kept
alive, and be used.
As seen in RFC 6274 it is mainly network owners that do not embrace all IPv4
options, which partially have issues.
Blocking of IP options for those, and those options only, is justified, and
many routers contain the possibility to selectively block IP options.
Note also that this RFC totally debunks the myth that silicon implementations
for variable header sizes are not possible, which is also generally used to
defame IP options.
This is why IPv4 options **appear** broken, but not all IPv4 options are bad,
or IMHO, IPv4 options are not at all bad when defined well.
Sane IPv4 options, without DoS attack surface or processing penalties (i.e.
those that are to be passively transferred by the network) still have valid use
cases.
In my opinion, the IP option number registry should stay available for such
options.
IPv4 options have two serious problems for which a solution should be found:
1. The limited number of IP option numbers available due to the option classes
that are currently not used.
It would be good to propose new numbering rules, where the sections are
removed and a 7-bit IPv4 option number space comes into existence.
This should be backward compatible with implementations, if not, then an
IPv4 option signalling new option definitions can be created.
(type + length + (optional) option table numbers (to open up more number
space when needed) )
The drawback being that this would eat space in the already limited (10
word) maximum space available.
2. Single octet IP options are a no-go, since unknown options cannot be
skipped.
All new IPv4 options should contain a type+length definition for approval
by the IETF.
I would favour it, when rules for the sane use of IPv4 options, in line with
RFC 6274 and addressing the weaknesses in the IPv4 option definition, would be
fixed in an own RFC concerning only this topic.
This should, in my opinion, be possible without breaking backward
compatibility, and it would open up the possibility for sane use of IPv4
options in the future, even on the global internet.
Alternative means could, in my opinion, be extension headers for IPv4, in a
similar way that they are defined for IPv6.
At the moment, I deem it to early to close the IP options registry finally and
definitely, and still see a bright future for IPv4 options.
Best regards,
Tjeerd
*From:*Eric Vyncke (evyncke) <[email protected]>
*Sent:* Dienstag, 16. Juni 2026 14:09
*To:* [email protected]
*Subject:* [Int-area] Closing/updating IPv4-only registries (FW: New Version
Notification for draft-vyncke-intarea-legacy-registries-00.txt)
You don't often get email from [email protected]
<mailto:[email protected]>. Learn why this is important
<https://aka.ms/LearnAboutSenderIdentification>
Dear intarea,
At the request of the IESG and in order to clean-up legacy IPv4-only IANA
registries, please have a look at this IETF draft (it is a glimpse from the
past with Netware!). It is short and hopefully clear.
As usual comments are welcome and I will be happy to present it at IETF-126
(time allowing as it is not an adopted draft); alternatively as the draft is
rather trivial and non-controversial [1] the call for adoption can be done
without IETF-126 presentations.
Note: obviously, this is posted as individual contributor and I won't be the
responsible AD (another AD will process its publication if the WG agrees with
the publication).
Regards,
-éric
[1] happy to be proven wrong of course 😉
*From: *[email protected]
<mailto:[email protected]><[email protected]
<mailto:[email protected]>>
*Date: *Tuesday, 16 June 2026 at 13:54
*To: *Eric Vyncke (evyncke) <[email protected] <mailto:[email protected]>>; Eric Vyncke
(evyncke) <[email protected] <mailto:[email protected]>>
*Subject: *New Version Notification for
draft-vyncke-intarea-legacy-registries-00.txt
A new version of Internet-Draft draft-vyncke-intarea-legacy-registries-00.txt
has been successfully submitted by Éric Vyncke and posted to the
IETF repository.
Name: draft-vyncke-intarea-legacy-registries
Revision: 00
Title: Updates to Legacy IPv4-related IANA Registries
Date: 2026-06-16
Group: Individual Submission
Pages: 6
URL: https://www.ietf.org/archive/id/draft-vyncke-intarea-legacy-registries-00.txt
<https://www.ietf.org/archive/id/draft-vyncke-intarea-legacy-registries-00.txt>
Status: https://datatracker.ietf.org/doc/draft-vyncke-intarea-legacy-registries/
<https://datatracker.ietf.org/doc/draft-vyncke-intarea-legacy-registries/>
HTML: https://www.ietf.org/archive/id/draft-vyncke-intarea-legacy-registries-00.html
<https://www.ietf.org/archive/id/draft-vyncke-intarea-legacy-registries-00.html>
HTMLized:
https://datatracker.ietf.org/doc/html/draft-vyncke-intarea-legacy-registries
<https://datatracker.ietf.org/doc/html/draft-vyncke-intarea-legacy-registries>
Abstract:
IANA maintains several registries that were created for IPv4
extensions. As the IPv4 core specification is no longer being
extended and as some registries do not have a defined IANA
registration procedure, these registries need to be updated to
indicate a registration procedure or to reflect the current practice
that defining such extensions is not recommended.
The IETF Secretariat
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
