This specification extends RFC6550 and RFC8505 to provide routing services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND but do not participate to RPL. This specification also enables the RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG.
This draft is well written and covers the updates to 6550 and 8505 along with detailed rules for behavior of 6LN acting as a RPL Unaware Leaf(RUL), was 6LR, 6LBR and DODAG root to support unicast and multicast routing of packets to and from RUL.

Some nits/comments/questions follow:

1. "The new "P" flag is defined only for MOP value between 0 to 6. "he new "P" flag is defined only for MOP value between 0 to 6.  For a MOP value of 7 or above, the flag MAY indicate something different and MUST NOT be interpreted as "Root Proxies  EDAR/EDAC" unless the MOP specifies it : Given that currently on 0 - 5 MOP are specified and should this be changed to  MOP 6 and above P flag may indicate according to a future specification?
2.  Resizing of fields and changes to existing IANA registries :
      2.1: Resizing the ARO Status values - The proposed update seems file considering the 53 ARO status values that would still be available. There appear to be no backward compatibility issues either.
       2.2: Section12.3. RPL Target Option Flags - This specification reduces the field to 4 bits. - This looks fine as there are no flags defined since RFC 6550 created the flags registry for target options.
3. Towards the end of Section 9.2.1 the specification mentions a RUL that is RPL minimal awareness, this is a bit under specified - "A RUL is not expected to produce RPL artifacts in the data packets,  but it MAY do so." -> is this necessary? Why would an 6LN implementation be built with minimal awareness and capability to build RPI? is there a benefit in doing this?.
4. IANA registry for acceptance and rejection status values - Section 12.4 and 12.5: Only reserve 0 Unqualified rejection/acceptable. However Section 7 specifies copying ARO status into the field where in acceptance/rejection status:
"When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a DAC message, the RPL Root MUST copy the ARO Status unchanged in a RPL Status with the 'A' bit set. The RPL Root MUST set the 'E' flag for all values in range 1-10 which are all considered rejections"
- Shouldn't the registry account for existing ARO status codes in the rejection registry?
- ARO status is a 8 bit field  while RPL status has only 6 bits. While currently there are only 10 status codes defined for ARO, however in future MUST copy may truncate the top 2 bits of the field.