Subject: draft-ietf-6man-rpl-option questions

From: Richard Kelsey <[email-masked]>
Date: Thu, 10 Nov 2011 11:14:29 -0500

In section 4, "Router Behavior" draft-ietf-6man-rpl-option
says:

   Routers MUST use IPv6-in-IPv6 tunneling, as specified in
   [RFC2473] to include a new RPL Option in datagrams that
   are sourced by other nodes.

What destination should be used for the tunnel header?  The
router adding the RPL option may not know if the original
destination is inside or outside the RPL domain.  And if the
original destination is outside the RPL domain, the router
may not know the address of the border router that will
forward the datagram outside.

Also, there are normative statements which use the term "RPL
domain", such as

   Datagrams sent between nodes within a RPL domain MUST include
   a RPL Option or RPL Source Route Header (SRH) and MAY include
   both.

but "RPL domain" is not defined.  In particular, if a RPL
router has a non-RPL-aware host, is the host inside the RPL
domain?  Or is the router then a border router and messages
to the host need to be tunnelled to it?

                                    -Richard Kelsey

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 10 Nov 2011 09:03:01 -0800

Hi Richard,

> forward the datagram outside.

The tunnel header's destination should be the next RPL router along the path towards the destination.  If, for example, a router only knows the next-hop destination (i.e. the DODAG Parent), then the tunnel header's destination will be the DODAG Parent itself.  Note that the original packet may traverse multiple such tunnels within the same RPL domain in order to reach its destination.  Let me propose the following update to Section 4:

4.  RPL Router Behavior

  To deliver an IPv6 datagram to its destination, a router may need to
  insert a new RPL Option.  Routers MUST use IPv6-in-IPv6 tunneling, as
  specified in [RFC2473] to include a new RPL Option in datagrams that
  are sourced by other nodes.  Using IPv6-in-IPv6 tunneling ensures
  that the delivered datagram remains unmodified and that ICMPv6 errors
  generated by inserting the RPL Option are sent back to the router
  that generated the routing header.

  A RPL router chooses the next RPL router that should process the
  original packet as the tunnel exit-point.  In some cases, the tunnel
  exit-point will be the final RPL router along a path towards the
  original packet's destination and the original packet will only
  traverse a single tunnel.  One example is when the final destination
  or the destination's attachment router is known to be within the same
  RPL domain.

  In other cases, the tunnel exit-point will not be the final RPL
  router along a path and the original packet may traverse multiple
  tunnels to reach the destination.  One example is when a RPL router
  is simply forwarding a packet to one of its DODAG Parents.  In this
  case, the RPL router sets the tunnel exit-point to a DODAG Parent.
  When forwarding the original packet hop-by-hop, the RPL router only
  makes a determination on the next hop towards the destination.

  A RPL router receiving an IPv6-in-IPv6 packet destined to it
  processes the tunnel packet as described in Section 3. of [RFC2473].
  Before IPv6 decapsulation, the RPL router MUST process the RPL Option
  if one exists.  If the router determines that it should forward the
  original packet to another RPL router, it MUST encapsulate the packet
  again using IPv6-in-IPv6 tunneling to include the RPL Option.  Note
  that fields within the RPL Option that do not change hop-by-hop MUST
  remain the same as those received from the prior tunnel.

  To avoid fragmentation, it is desirable to employ MTU sizes that
  allow for the header expansion (i.e. at least 1280 + 40 (outer IP
  header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the
  maximum RPL Option header size for a given RPL network.  To take
  advantage of this, however, the communicating endpoints need to be
  aware of the MTU along the path (i.e. through Path MTU Discovery).
  Unfortunately, the larger MTU size may not be available on all links
  (e.g. 1280 octets on 6LoWPAN links).  However, it is expected that
  much of the traffic on these types of networks consists of much
  smaller messages than the MTU, so performance degradation through
  fragmentation would be limited.

> to the host need to be tunnelled to it?

I agree that "RPL domain" is not well defined.  But after some thought, I think replacing with "RPL Instance" may be more appropriate.  In particular, we really want to limit the use of these RPL options/headers to a RPL Instance, not just a collection of routers that are all operating RPL.

If you agree to the above, I'll make the changes in my updates to address the LC comments.

Thanks.

--
Jonathan Hui