From 01a45caadaed3e0fe7d9428c7408d8e90de9fde7 Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Fri, 27 Feb 2026 13:22:42 -0800 Subject: [PATCH 1/2] Add IPv6 example Addresses the main point of issue 19 without using SIP/RTP as the actual example. Usig IPv6 means that I can add additional point or two as well. Fixes #19 Signed-off-by: Dave Thaler (cherry picked from commit 8e3b2aca136a0481f0e368376b27bdd753c11795) --- draft-iab-protocol-greasing.md | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/draft-iab-protocol-greasing.md b/draft-iab-protocol-greasing.md index ae0c0c4..e78e198 100644 --- a/draft-iab-protocol-greasing.md +++ b/draft-iab-protocol-greasing.md @@ -353,7 +353,7 @@ extension points positively. To some extent this can be thought of as protocol fuzzing. This might be difficult to exercise because varying the protocol elements might change the outcome of interactions, leading to real errors. However, some protocols allow elements to be be safely changed, as shown in the -following example. +following examples. ## Example: QUIC frames @@ -376,6 +376,31 @@ aspects of a transmission, which may not be acceptable for a given use case. As such, positive testing might be most appropriate to use in a subset of connections, or phases within a connection. +## Example: IPv6 + +The IPv6 protocol {{?IPV6=RFC8200}} defines the ability to use extension headers, +and further defines the ability to include options in two of those headers. It +also defines a recommended (but not required) order of such headers. + +If the same headers tend to appear in the same order, and with the same size +and offset most of the time, middleboxes can begin to incorrectly rely on assumptions +that those will always be the case, and lead to ossification and inability to +use new headers or options or differing orders in the future. + +IPv6 did not define grease values, but a sender could vary some aspects of the +protocol, such as varying the order of options within an extension header, +or even including a Destination Options Header with only Pad1 or PadN options +between other headers. + +Doing such variations might discourage ossification but might have some performance +impact if done indiscriminately. For example, making packets larger as a result +might result in fragmentation. + +Finally, there may be security products that already incorrectly rely on +assumptions about header order, size, or location in a packet. Using +variability might then cause operational problems in such networks and +result in a disincentive to use the protocol or device or application using it. + # Considerations for Protocol Versions {#versions} {{TRANSITION}} discusses considerations around planning for transitioning From 03c9053215563fa1e8713febdd1481538d676fdc Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Fri, 27 Feb 2026 13:28:46 -0800 Subject: [PATCH 2/2] Add SIP reference Signed-off-by: Dave Thaler (cherry picked from commit fc607903991087a5e02e76c710576035ca84f6c2) --- draft-iab-protocol-greasing.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/draft-iab-protocol-greasing.md b/draft-iab-protocol-greasing.md index e78e198..fcf8ddb 100644 --- a/draft-iab-protocol-greasing.md +++ b/draft-iab-protocol-greasing.md @@ -352,8 +352,10 @@ Long-term maintenance and interoperability can be ensured by exercising extension points positively. To some extent this can be thought of as protocol fuzzing. This might be difficult to exercise because varying the protocol elements might change the outcome of interactions, leading to real errors. -However, some protocols allow elements to be be safely changed, as shown in the -following examples. +However, some protocols allow elements to be safely changed, as shown in the +following examples. The principles in these two examples are not limited to +the protocols mentioned, but also arise in many other protocols as well +(e.g., the Session Initiation Protocol (SIP) {{?SIP=RFC3261}}). ## Example: QUIC frames @@ -387,18 +389,18 @@ and offset most of the time, middleboxes can begin to incorrectly rely on assump that those will always be the case, and lead to ossification and inability to use new headers or options or differing orders in the future. -IPv6 did not define grease values, but a sender could vary some aspects of the +IPv6 did not define grease values, but a sender may vary some aspects of the protocol, such as varying the order of options within an extension header, or even including a Destination Options Header with only Pad1 or PadN options between other headers. -Doing such variations might discourage ossification but might have some performance -impact if done indiscriminately. For example, making packets larger as a result -might result in fragmentation. +While doing such variations can discourage ossification, they might also have +a negative performance impact if done indiscriminately. For example, making packets +larger as a result might result in fragmentation. -Finally, there may be security products that already incorrectly rely on -assumptions about header order, size, or location in a packet. Using -variability might then cause operational problems in such networks and +Finally, there may be security or gateway middleboxes already deployed that +incorrectly rely on assumptions about header order, size, or location in a packet. +Introducing variability might then cause operational problems in such networks and result in a disincentive to use the protocol or device or application using it. # Considerations for Protocol Versions {#versions}