Re: draft-ietf-6man-rpl-routing-header-07

[Mukul Goyal <[e-mail]>]

Hi Jonathan

>It knows whether or not RPL is running on an interface.  It could at least check that.  By the same argument, how do you propose we limit packets to a RPL routing domain?  If we have no good way of limiting packets, then the stated security considerations do not apply.

Just the knowledge that the router is part of a particular RPL instance via a particular interface is no guarantee that all the neighbors reachable via that interface belong to the same RPL instance. On the other hand, a router would clearly know whether its particular interface belongs to the RPL domain or not. A packet wont be sent down an interface if that interface is not part of the RPL domain. Here, I am assuming that the RPL domain is defined in the manner you had suggested (analogous to the definition of a routing domain in Section 1.2 of RFC 1195).

>> It would be a problem if the router were required to check its own membership in the RPL Instance in order to accept a packet with SRH. Routers part of a source route should not need to maintain any state about it. 

>Note that in draft-ietf-roll-rpl, RPL routers do maintain such state already.  I agree the issue comes up with P2P.

Indeed, this would be a big problem for P2P-RPL.

>Remember that the original purpose of the RPL Instance is to support MTR.  The RPL Instance identifies what routing topology to use.  This is important especially if the SRH does not specify the entire path to the destination.  How does the tunnel exit-point know what routing topology to use to reach the destination?

There is no mention of MTR in the RPL specs. As far as RPL spec goes, an RPL Instance is simply a group of DAGs using the same OF. You can not assume that a tunnel exit-point would get any information from RPL Instance ID regarding how to reach the ultimate destination of the packet. That information would probably come from the routing table (which may be getting information via several routing protocols).

>The lack of and need for the RPL Instance identifier was raised during IESG review.  The options are (1) to require inclusion a RPL Option in addition to the RPL routing header or (2) add a RPL Instance field in the RPL routing header itself.  I doubt that you would prefer option 1.

I will try to go back and find the IESG review you have mentioned. If you could quickly direct me to right place, that will be helpful. But, at the moment, it is truly mind-boggling for me that RPL instance id is required to be specified in the source routing header. 

>If the RPL router has no idea of the RPL Instance when forwarding, it can choose to forward the packet along anyway.

Doing that would break the rules in SRH draft.

>  At the very least, the tunnel exit-point should enforce the use of the RPL Instance.  Surely the end-points of a source route should at least know what RPL Instance they are in...

Yes, this RPL Instance is a local instance which has no significance associated. I think you are trying to assign a meaning to RPL Instance ID which it does not currently have under RPL core spec.

Thanks
Mukul