Re: [Roll] draft-ietf-6man-rpl-routing-header-07

[Jonathan Hui <[e-mail]>]

On Dec 21, 2011, at 9:24 AM, Mukul Goyal wrote:

>>> [R Cragie]
>>> p7: RPL Instance ID - why is this needed for source routing? RPL is not even used for source routing. This flavors the SRH unnecessarily and the processing does not use it. If the reason is for checking entering and exiting a RPL domain, this processing needs to be stated.
> 
>> [J Hui]
>> Page 12 describes processing rules intended to keep the SRH within a RPL Instance.

Oops, typo.  s/12/13/

> Page 12 has no mention of RPL Instance. Page 13 does mention RPL Instance in the following rules:
> 
>   2.  Datagrams destined elsewhere within the same RPL Instance are
>       forwarded to the correct interface.
> 
>   3.  Datagrams destined to nodes outside the RPL Instance are dropped
>       if the outer-most IPv6 header contains a SRH not generated by the
>       RPL router forwarding the datagram.
> 
> My question is how does a router know whether the next hop is within the same RPL Instance or not? A router has no idea what RPL Instances its neighbors belong to. 
> 
> It seems that a router, that receives a packet with a SRH, does not need to check if it belongs to the RPL Instance mentioned in the SRH. It just needs to check if the next hop belongs to that RPL Instance or not. And as I said in the prev para, I am not sure how would the router make that check.

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.

> 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.

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?

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.

If the RPL router has no idea of the RPL Instance when forwarding, it can choose to forward the packet along anyway.  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...

--
Jonathan Hui