Hi, Haisheng Yu (Johnson),
On 8/6/23 10:01, Haisheng Yu (Johnson) wrote:
Hi， Fernando and Tom,
I have been contemplating Fernando's questions lately, what exactly
hinders the development of extension headers? Is it because IPv6
adoption is not widespread enough? Or do IPv6 extension headers
themselves serve little purpose? Or is it because the use of IPv6
extension headers could potentially decrease network efficiency and
security?
RFC9098 and associated pointers.
I believe all of these reasons have some validity, but none of them are
the primary cause. In my opinion, the main reason is that we lack a
comprehensive understanding of the current development status and
application scenarios of IPv6 extension headers.
Strongly disagree. In fact, having been on the seat to make such
decisions, you're probably assuming that the EH topic, for the folks
making such decisions, is more important than it actually is. i.e., you
don't have the luxury to spend a lot of time on a feature that, for the
most part, doesn't have a real use case in the deployed wor;d (other
than the recent SRv6 in limited domains).
For development and use cases,
https://www.rfc-editor.org/rfc/rfc9288.txt is your friend -- that part
is the important part of the document, I'd say.
Only by thoroughly
understanding the benefits and drawbacks of IPv6 extension headers can
we make better use of them. In the current RFC 8200, extension headers
are only recommended for use, and many service providers are concerned
that handling unfamiliar extension headers could impact the efficiency
and security of control-plane devices, as Fernando mentioned in his
email example.
Yes. And RFC9098 provides enough references with datapoints proving that.
Additionally, because many routing devices forward
packets with unknown processing requirements to control-plane devices
for handling, these impacts exist simultaneously at the forwarding and
control layers.
However, as Tom mentioned, the most secure network in the world is one
that is turned off.
That's not the way a security team works: What you normally want to do
is eliminate unnecessary risk. Risk associated with a feature that is
for the most part, not used for production, is risk you want to eliminate.
We should not refrain from using IPv6 extension
headers simply out of fear of the potential effects on efficiency and
security.
Yes. Everyone is free to play in their own lab or network. Now, if what
you want is me granting arbitrary folks permission to play with EHs in
my production systems, the answer is simple: "No, thank you".
Therefore, I suggest that we consider drafting a document specifically
focused on studying the current development status of IPv6 extension
headers. This document should provide guidance on how IPv6 extension
headers should be handled, when they are useful, and how to correctly
use and process them.
RFC9288 essentially already provides that.
Alternatively, we can iterate on the foundation of
6man-eh-limits, and I would be glad to contribute in this regard.
As long as you/we can't agree on:
* Minimum common denominator (as opposed to a requirement of supporting
arbitrary IPv6 header chains, which is unreal)
* Who is going to pay the associated cost (because in a lot of cases,
processing EHs in the fast path requires $ )
and,
* Have vednors be able to gracefully handle EH chains, without trivial
syntax-processing bugs found every now and then
and,
* provide a compelling feature that folks require (other than |I feel
like playing with EHs)
... the outcome is going to be the same.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
