Draft: roll-useofrplinfo

Commentary: Consistent use of " RPL option Type " " RPL Option Type . Bug : in one place " option value " was mentioned in place of " Option Type " . Note that option value has a different meaning in RPL Option . ... plus other mostly harmless nits . 
 the " option value " is changed to " value " Thank you very much for your corrections !
This document illustrates that is is not always possible to know for
sure at the source that a packet will only travel within the RPL
domain or may leave it.
This document illustrates that it is not always possible to know for
sure at the source that a packet will only travel within the RPL
domain or may leave it.
In order to avoid a Flag Day caused by lack of interoperation between
new RPI option Type (0x23) and old RPI option Type (0x63) nodes, this
section defines a flag in the DIO Configuration option, to indicate
when then new RPI option Type can be safely used.  This means, the
flag is going to indicate the value of Option Type that the network
is using for the RPL Option.  Thus, when a node join to a network
will know which value to use.  With this, RPL-capable nodes know if
it is safe to use 0x23 when creating a new RPL Option.  A node that
forwards a packet with an RPI MUST NOT modify the Option Type of the
RPL Option.
In order to avoid a Flag Day caused by lack of interoperation between
new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes, this
section defines a flag in the DIO Configuration option, to indicate
when the new RPI Option Type can be safely used.  This means, the
flag is going to indicate the value of Option Type that the network
will be using for the RPL Option.  Thus, when a node joins to a
network will know which value to use.  With this, RPL-capable nodes
know if it is safe to use 0x23 when creating a new RPL Option.  A
node that forwards a packet with an RPI MUST NOT modify the Option
Type of the RPL Option.
Currently, the DODAG Configuration option in RFC6550 states: "the
unused bits MUST be initialize to zero by the sender and MUST be
ignored by the receiver".  If the flag is received with a value zero
(which is the default), then new nodes will remain in RFC6553
Compatible Mode; originating traffic with the old-RPI option Type
(0x63) value.  If the flag is received with a value of 1, then the
option value for the RPL Option MUST be set to 0x23.
In the case of rebooting, the node (6LN or 6LR) does not remember the
RPL Option Type (i.e., whether or not the flag is set), so DIO
messages sent by the node would be sent with the flag unset until a
DIO message is received with the flag set, indicating the new RPI
value. The node will use the value 0x23 if it supports this feature.
Currently, the DODAG Configuration option in RFC6550 states: "the
unused bits MUST be initialize to zero by the sender and MUST be
ignored by the receiver".  If the flag is received with a value zero
(which is the default), then new nodes will remain in RFC6553
Compatible Mode; originating traffic with the old-RPI Option Type
(0x63) value.  If the flag is received with a value of 1, then the
Option Type for the RPL Option MUST be set to 0x23.
In the case of reboot, the node (6LN or 6LR) does not remember the
RPL Option Type (i.e., whether or not the flag is set), so DIO
messages sent by the node would be sent with the flag unset until a
DIO message is received with the flag set, indicating the new RPI
value. The node will use the value 0x23 if it supports this feature.