Discussion:
IPv6: dropping RH0?
(too old to reply)
Maxime Villard
2018-04-19 11:41:18 UTC
Permalink
I say we nuke it, but in fact it's more complicated than that. The RH0 option
was obsoleted in RFC5095 [1], because it has security implications. While we
did drop RH0 in our input path, the code for the output path is still there.

In other words, we don't process any received RH0, but we can still emit
RH0s - not automatically, but on demand, if a user calls setsockopt to set a
routing option of type 0.

RFC5095 states that:

"IPv6 implementations are no longer required to implement RH0 in any
way."

Given this, the RH0s we emit won't go very far, they will likely be blocked
by the first router encountered. All the systems I looked at drop RH0s in
the input path, and at least PF was modified to kick RH0s by default.

You can find the RH0 code by looking for the "IPV6_RTHDR_TYPE_0" keyword on
NXR. It mostly comes down to ip6_output.c and xform_ah.c.

Wanted to know if someone would disagree on removing it, etc.

[1] https://tools.ietf.org/html/rfc5095

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Fernando Gont
2018-04-20 19:19:33 UTC
Permalink
Post by Maxime Villard
I say we nuke it, but in fact it's more complicated than that. The RH0 option
was obsoleted in RFC5095 [1], because it has security implications. While we
did drop RH0 in our input path, the code for the output path is still there.
In other words, we don't process any received RH0, but we can still emit
RH0s - not automatically, but on demand, if a user calls setsockopt to set a
routing option of type 0.
    "IPv6 implementations are no longer required to implement RH0 in any
     way."
Given this, the RH0s we emit won't go very far, they will likely be blocked
by the first router encountered. All the systems I looked at drop RH0s in
the input path, and at least PF was modified to kick RH0s by default.
You can find the RH0 code by looking for the "IPV6_RTHDR_TYPE_0" keyword on
NXR. It mostly comes down to ip6_output.c and xform_ah.c.
Wanted to know if someone would disagree on removing it, etc.
[1] https://tools.ietf.org/html/rfc5095
Please go ahead remove it!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Maxime Villard
2018-04-24 18:41:27 UTC
Permalink
Post by Fernando Gont
Post by Maxime Villard
I say we nuke it, but in fact it's more complicated than that. The RH0 option
was obsoleted in RFC5095 [1], because it has security implications. While we
did drop RH0 in our input path, the code for the output path is still there.
In other words, we don't process any received RH0, but we can still emit
RH0s - not automatically, but on demand, if a user calls setsockopt to set a
routing option of type 0.
"IPv6 implementations are no longer required to implement RH0 in any
way."
Given this, the RH0s we emit won't go very far, they will likely be blocked
by the first router encountered. All the systems I looked at drop RH0s in
the input path, and at least PF was modified to kick RH0s by default.
You can find the RH0 code by looking for the "IPV6_RTHDR_TYPE_0" keyword on
NXR. It mostly comes down to ip6_output.c and xform_ah.c.
Wanted to know if someone would disagree on removing it, etc.
[1] https://tools.ietf.org/html/rfc5095
Please go ahead remove it!
Done, I removed it yesterday.

Maxime

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...