On Wed, Feb 28, 2018 at 8:39 AM, Fernando Gont <[email protected]> wrote: > On 02/28/2018 01:29 PM, C. M. Heard wrote: >> The option type is being changed from 0x63 to 0x23 precisely so >> that non-RPL routers will NOT drop packets with that option. >> See https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-21, >> which has recently been submitted to the IESG for publication. > > It would seem that such decision has been a response to publication of > RFC8200... but I don't follow.
The wording of the draft can certainly give that impression, but that is not the case. The change was made to prevent packets with the RPI option that exit from an RPL domain from being discarded by a non-RPL node. > What's the reason for which 0x63 was required to be dropped, but 0x23 is > required not to? Because 0x63 has the upper two bits that say "discard the packet" if the option is unrecognized, which would be the case for a non-RPL aware node, while 0x23 has the upper two bits that say "skip over this option and continue processing the header." > Am I missing something, or is the motivation of the change to "comply > with RFC8200"? -- [i]f so, such change is not really required. The motivation is not to comply with RFC 8200, but rather to make it possible for an RPL-aware end node to send an IPv6 datagram to a non-RPL aware node on the general Internet without the need for IP-in-IP encapsulation. See the example in Section 6.2.1 of the above-referenced draft. If a firewall were to (un)helpfully filter packets with the RPI option, then that objective could not be realized. Mike Heard _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
