Subject: Re: Requesting 6man review of draft-ietf-roll-useofrplinfo-25

From: "C. M. Heard" <[email-masked]>
Date: Mon, 6 May 2019 06:12:14 -0700

On Sun, 5 May 2019 13:22:14 +0100 Nick Hilliard wrote:
> Suresh Krishnan wrote on 04/05/2019 03:37:
> > So please do chime in with your opinions in response to this mail by
> > Wednesday May 15 2019..
>
> this looks like a difficult consequence of force majeure.  Section 3.3
> defines a mechanism to avoid a flag day.  From an operational point of
> view, what matters is that if there is a change in a code point, that
> there is a non-disruptive mechanism which allows migration from old to
> new.  The authors have defined this, and have made it clear that there
> is a significant change in this draft. So they've done the due diligence
> for what's operationally important.
>
> After that, it's a matter of branding / versioning to make it clear to
> us stupid humans that there is a compatibility change.  Whether this is
> done by reclassifying RFC6553 to historic, and/or by renaming the
> contents of the current draft RPL1.1 or RPLv2 or RPLbis or whatever is a
> matter of taste.  But there is the potential for confusion if the same
> label is used for something which is not backwards compatible.

I am not sure that I agree that re-branding is all that important, but
there is a related backward compatibility issue in Section 6.2.4
(https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25#section-6.2.4)
that deserves more explicit disclosure.  That section discusses the flow
of a packet from the general Internet to a non-RPL-aware-leaf, and it
levies a new requirement (not present in the original RPL specs) on a
non-RPL-aware IPv6 host that will act as a leaf in an RPL domain:

   The final node should be able to remove one or more IPv6-in-IPv6
   headers which are all addressed to it.  Furhter details about this
   are mentioned in [I-D.thubert-roll-unaware-leaves], which specifies
   RPL routing for a 6LN acting as a plain host and not aware of RPL.

That "should" is actually a "MUST" and is another significant change to
RFC 6553.  That fact needs to be disclosed in Section 3.1.

Early versions of the document (draft-ietf-roll-useofrplinfo-06 Sec 5.8,
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-06#section-5.8)
did not levy this "automatic tunneling" requirement in the final node
instead required that all RPL routers use hop-by-hop IP-in-IP tunneling,
in conformity with the requirements in RFC 6553 Section 4
(https://tools.ietf.org/html/rfc6553#section-4).

I do not have a problem with levying the requirement, since it does not
apply to general IPv6 hosts, only to those that need to attach to an RPL
domain.  My concern is that it is inadequately disclosed. (Draft authors,
my apologies that I didn't think to ask for this in March 2018 when we
discussed this matter in connection with draft-ietf-roll-useofrplinfo-22).

> Regarding interoperability with other ipv6 routers, so long as the draft
> acknowledges rfc8200 compatibility for hbh headers and doesn't make any
> extra demands for general hbh processing, that's fine.

As far as I can see the draft does not require anything for general IPv6
nodes that are not part of an RPL domain.  So I think it should be fine
from the point of view of 6man.

Mike Heard