Thank you very much Mike!
Yes, we propose to update RFC 6553 from 0x63 to 0x23 based on:
"....[RFC6553] states that in the Option Type field of
the RPL Option header, the two high order bits MUST be set to '01'
and the third bit is equal to '1'. The first two bits indicate that
the IPv6 node MUST discard the packet if it doesn't recognize the
option type, and the third bit indicates that the Option Data may
change en route. The remaining bits serve as the option type.
Recent changes in [RFC8200] (section 4, page 8), states: "it is now
expected that nodes along a packet's delivery path only examine and
process the Hop-by-Hop Options header if explicitly configured to do
so". Processing of the Hop-by-Hop Options header (by IPv6
intermediate nodes) is now optional, but if they are configured to
process the header, and if such nodes encounter an option with the
first two bits set to 01, they will drop the packet (if they conform
to [RFC8200]). Host systems should do the same, irrespective of the
configuration.
Based on That, if an IPv6 (intermediate) node (RPL-not-capable)
receives a packet with an RPL Option, it should ignore the HBH RPL
option (skip over this option and continue processing the header).
Thus, this document updates the Option Type field to: the two high
order bits MUST be set to '00' and the third bit is equal to '1'.
The first two bits indicate that the IPv6 node MUST skip over this
option and continue processing the header ([RFC8200] Section 4.2) if
it doesn't recognize the option type, and the third bit continues to
be set to indicate that the Option Data may change en route. The
remaining bits serve as the option type and remain as 0x3. This
ensures that a packet that leaves the RPL domain of an LLN (or that
leaves the LLN entirely) will not be discarded when it contains the
[RFC6553] RPL Hop-by-Hop option known as RPI...."
[https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-19#section-3.1]
Thanks,
Ines
On 27.11.2017 23:36, C. M. Heard wrote:
Greetings,
It seems to me that the option description and filtering advice given in
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-04#section-4.3.4
is not consistent with the revised definition of the RPI option in
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-19
which is now in WG last call in ROLL. I have cc:'d the authors of
useofrplinfo.
Thanks & regards,
Mike Heard
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
