Subject: [Roll] IP-in-IP tunneling for HbH Option

From: Dario Tedeschi <[email-masked]>
Date: Fri, 05 Aug 2011 16:07:01 -0700

I been through the archived mailing list, but did not find an answer to 
the following question:

What destination address should be used in the outer header of a tunnel 
when a router needs to add a RPL HbH option on behalf of a non-RPL aware 
leaf node? There are three possibles I can see:
[a]. Use the address of the root node.
[b]. Use the destination address of the original IPv6 header.
[c]. Use the address of your RPL parent.

After some experimentation, I found that both [a] and [b] have issues 
depending on the final destination (the destination of the original 
datagram). I had thought of [c] as a solution, but quickly realized it 
was a bad idea.

Problem 1: Final destination is inside the RPL domain and [a] is used.
---------
For any destination in the RPL domain, the datagram is always sent to 
the root node even when the path to the root includes a node having the 
final destination address or a matching routing entry. This seems 
inefficient at best. Particularly when used in a storing-mode RPL network.

Problem 2: Final destination address is outside the RPL domain via the 
BR and [b] is used.
---------
The BR will not decapsulate, because the destination address of the 
datagram is not one of the BRs addresses (i.e. the datagram is not meant 
for it but some other destination). This means the BR will just forward 
the datagram to the next-hop outside the RPL domain. The final 
destination is not a tunnel exit-point so it then sends a "Parameter 
Problem" message with code=1 back to the source (i.e. the entry-point of 
the tunnel).

Problem 3: [c] is used.
--------
Decapsulation and encapsulation of the original datagram would be 
required at every upward hop within the RPL network.

Solution 1: Use [a] or [b]  depending on whether the final destination 
is outside or inside the RPL domain.
-------
How does a router know whether a destination is inside or outside the 
RPL domain?

Solution 2: Always use [b], but BRs strip off the outer header if 
forwarding outside the RPL domain or forwarding using source-routing 
inside the RPL domain.
-------
This is a simple approach, but perhaps a little ugly. The forwarding 
logic in the BR needs to look past the first IPv6 header to see if it's 
a tunneled packet. If it is tunneled, the outer header is stripped off 
and the original datagram is forwarded.

Dario

---

From: Daniel Gavelle <[email-masked]>
Date: Wed, 10 Aug 2011 10:25:44 +0200

I like solution [2].  The rules are simpler on the router node.  When using 6LowPAN compression, the overhead for using a tunnel is about three bytes rather than five.  All the router nodes on the way up need to look past the outer IP header to get to the hop by hop header to adjust the rank, so I don't think it's too bad that the root node also needs to look past the outer header in order to strip out the outer header and hop by hop header before passing up.  The root node doesn't need to look into or past the inner header.

In Zigbee, we always route off network through the root node and form a separate DAG for each off network connection in a LowPAN.  If it is possible for a single DAG to have multiple off network connections through multiple router nodes, a modified solution [1] may be the better choice.  The hop by hop header would use the destination address of the router where the packet will go off the network.  I don't know how the routers would learn which nodes perform the off network connection for which prefixes.  This (and other) reasons may make it impractical to ever route off network through any node but the root.

Regards,

Daniel.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dario Tedeschi
Sent: 06 August 2011 00:07
To: 'ROLL WG'
Subject: [Roll] IP-in-IP tunneling for HbH Option

Problem 3: [c] is used.
--------

Dario

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 12 Aug 2011 14:56:37 -0700

Hi Daniel

> I like solution [2].
As do I,  for simplicity and efficiency sake.

>   All the router nodes on the way up need to look past the outer IP header to get to the hop by hop header to adjust the rank, ...
Not so. An intermediate router never looks past the outer header, unless 
the destination address in the outer header is one of its own. Solution 
2 would bend that rule, but only at the BR. The reason tunneling is used 
for the upward path is to add the RPL HbH option if one was not already 
present in the original packet. Think of a host sending a packet to it's 
default router (a RPL aware router): The host knows nothing about RPL 
and, therefore, can't add a RPL HbH option. In order for the router to 
forward the packet in the RPL network, it must add the HbH option. 
Tunneling allows it to do that without modifying the original packet. It 
also means that a forwarding error within the RPL network, for that 
packet, will be sent back to the router and not the host, since the 
source address of the outer header is the address of the router. The 
router would, thus, have a chance to act on the error (e.g re-parent or 
reset the trickle timer).

Dario