Subject: Comment on rpl-routing-header draft

From: "Reddy, Joseph" <[email-masked]>
Date: Thu, 21 Apr 2011 11:15:03 -0500

( resending as original post didn't go through... )

Hi,

I have a comment on the rpl-routing-header draft that was noticed during interoperability testing conducted by the zigbee alliance.

In the most common usage of this header, the border router inserts a source routing header with the full set of intermediate nodes before forwarding it towards the destination within the RPL network.

In case of a forwarding error along the route, the intermediate node sends the icmp error message to the source node, however in this case it actually needs to send to the node that inserted the routing header.

To fix this issue, the suggestion is that the node that inserts the soruce routing header should include its own address as the first address in the list. This will allow intermediate nodes to send error to it for forwarding failures.

-Regards, Joseph

---

From: Daniel Gavelle <[email-masked]>
Date: Fri, 22 Apr 2011 10:25:25 +0200

I support Joseph's proposal and plan to add it to our implementation.

Regards,

Daniel.

--

__________________________________________________

Daniel Gavelle, Software Team Leader
Low Power RF Solutions (formerly Jennic Ltd.)
NXP Semiconductors Furnival Street,
Sheffield,
S1 4QT, UK
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Comp Reg No: 3191371 - Registered In England
http://www.nxp.com http://www.jennic.com
__________________________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Reddy, Joseph
Sent: 21 April 2011 17:15
To: [email-masked]'
Subject: Comment on rpl-routing-header draft

Hi,

-Regards, Joseph

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Apr 2011 12:05:28 +0200

The message from Joseph Reddy is important and makes sense.

I have a remark to that message as well: when the RH is built as you 
suggest (BR inserts is own address in the RH (the one on which 
interface? an ll address?)) it may be questionable about how the AH 
authentication header is applied to it.

BEcause - we do not have a specification about how to apply AH on RH5 
(although we do know how to apply AH on other RHs).

But we do have example text suggesting how to apply AH on RH5.

The RH5 is currently specified at:
http://www.ietf.org/id/draft-ietf-6man-rpl-routing-header-03.txt

The example text suggesting applying AH on RH5, in the RoLL WG email 
archives, somewhere sept or october 2010.

Alex

Le 21/04/2011 18:15, Reddy, Joseph a écrit :
> ( resending as original post didn’t go through… )
> Hi,
> I have a comment on the rpl-routing-header draft that was noticed during
> interoperability testing conducted by the zigbee alliance.
> In the most common usage of this header, the border router inserts a
> source routing header with the full set of intermediate nodes before
> forwarding it towards the destination within the RPL network.
> In case of a forwarding error along the route, the intermediate node
> sends the icmp error message to the source node, however in this case it
> actually needs to send to the node that inserted the routing header.
> To fix this issue, the suggestion is that the node that inserts the
> soruce routing header should include its own address as the first
> address in the list. This will allow intermediate nodes to send error to
> it for forwarding failures.
> -Regards, Joseph
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 22 Apr 2011 07:37:34 -0700

Hi Joseph,

I presume that you are not using IP-in-IP tunneling.  If you were using IP-in-IP tunneling as the draft suggests, then the source address of the inserting router is included in the outer IP header.

Your comment seems relevant to draft-hui-6man-rpl-headers-00, which describes what needs to be done to directly insert the extension header in the packet (and the risks involved with doing so).  Note that this draft has expired.  Is there interest to revive it?

--
Jonathan Hui

---

From: "Reddy, Joseph" <[email-masked]>
Date: Wed, 20 Apr 2011 11:21:06 -0500

Hi,

-Regards, Joseph

---

From: "Reddy, Joseph" <[email-masked]>
Date: Mon, 25 Apr 2011 11:53:46 -0500

Hi Jonathan,

Yes, we do not use IP-in-IP tunneling and instead simply insert the RH header in the packet.
The other draft you mention is useful but I dont think it is suffcient. We still need to change the extension header to include the address of the node inserting it...am i missing something ?

-Joseph

________________________________
From: Jonathan Hui [mailto:[email-masked]]
Sent: Friday, April 22, 2011 7:38 AM
To: Reddy, Joseph
Cc: [email-masked]'
Subject: Re: Comment on rpl-routing-header draft

Hi Joseph,

--
Jonathan Hui

Hi,

-Regards, Joseph

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Apr 2011 08:56:38 -0400

> forwarding it towards the destination within the RPL network.

and then.

> Yes, we do not use IP-in-IP tunneling and instead simply insert the RH head=
> er in the packet.

What specification are you following that says do this?

Routing headers (as designed and specified) are inserted by an
originating node (whether the original sender or a tunnel entry
point). If you have a middle node insert this header to an existing
packet, no suprise things are not going to work.

Thomas

---

From: "Reddy, Joseph" <[email-masked]>
Date: Tue, 26 Apr 2011 18:39:06 -0500

Hi Thomas

Since RPL protocol is intended to operate in networks with constrained devices and lossy, low-bandwidth links, there is a desire to not require IP-in-IP tunnelling that is usually used for inserting routing headers. This is detailed in the draft http://tools.ietf.org/html/draft-hui-6man-rpl-headers-00 but I realize now this draft expired recently. Perhaps this can be revived as it is helps to improve the applicability of RPL protocol. 

-Joseph

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Tuesday, April 26, 2011 5:57 AM
To: Reddy, Joseph
Cc: Jonathan Hui; [email-masked]'
Subject: Re: Comment on rpl-routing-header draft

and then.

> Yes, we do not use IP-in-IP tunneling and instead simply insert the RH 
> head= er in the packet.

Routing headers (as designed and specified) are inserted by an originating node (whether the original sender or a tunnel entry point). If you have a middle node insert this header to an existing packet, no suprise things are not going to work.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Apr 2011 21:07:51 -0400

If you are purposefully breaking existing Standards Track
specifications (which is what it sounds like you are doing) in order
to "not require IP in IP tunneling" (a local optimization), you
probably won't get much sympathy here. Certainly not from me!

Thomas

> Since RPL protocol is intended to operate in networks with
>  constrained devices and lossy, low-bandwidth links, there is a
>  desire to not require IP-in-IP tunnelling that is usually used for
>  inserting routing headers. This is detailed in the draft
>  http://tools.ietf.org/html/draft-hui-6man-rpl-headers-00 but I
>  realize now this draft expired recently. Perhaps this can be
>  revived as it is helps to improve the applicability of RPL
>  protocol.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 27 Apr 2011 08:19:29 -0400

Hi Joseph,

On 4/26/11 7:39 PM, Reddy, Joseph wrote:
> constrained devices and lossy, low-bandwidth links, there is a desire
> to not require IP-in-IP tunnelling that is usually used for inserting
> routing headers. This is detailed in the draft
> realize now this draft expired recently. Perhaps this can be revived
> as it is helps to improve the applicability of RPL protocol.

That draft has been replaced with draft-ietf-6man-rpl-routing-header.  I
suggest that you take a look at that draft (currently being reviewed by
the IESG), especially section 4.

Regards,
Brian

> 
> -Joseph
> 
> -----Original Message----- From: Thomas Narten
> [mailto:[email-masked]] Sent: Tuesday, April 26, 2011 5:57 AM To:
> Reddy, Joseph Cc: Jonathan Hui; [email-masked]' Subject: Re: Comment
> on rpl-routing-header draft
> 
>> In the most common usage of this header, the border router inserts
>> a source routing header with the full set of intermediate nodes
>> before forwarding it towards the destination within the RPL
>> network.
> 
> and then.
> 
>> Yes, we do not use IP-in-IP tunneling and instead simply insert the
>> RH head= er in the packet.
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Apr 2011 08:34:59 -0400

Hmm. Section 4 says:

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

SHOULD would be OK, here, if there was some alternative that might be
appropriate on some situations. But the document is silent on those
alternatives. In which case, I wonder why this is not a MUST. Is it
because other types of tunneling would be OK? (If so, giving such an
example would be good).

But then later:

   In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due
   to the added cost and complexity required to process and carry a
   datagram with two IPv6 headers.  [I-D.hui-6man-rpl-headers] describes
   how to avoid using IPv6-in-IPv6 tunneling in such specific cases and
   the risks involved.

I strongly object to this text. It suggests that that other
approaches, presumably including those that violate existing IETF
specs, might be OK too. We should not do this.

Or am I missing something here?

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Wed, 27 Apr 2011 09:02:40 -0400

Hi Thomas,

> because other types of tunneling would be OK? (If so, giving such an

I would assume that any type of tunneling would be allowed (e.g., GRE),
and agree that it would be useful to enumerate at least general
situations where the SHOULD can be ignored.

I *thought* some of those alternatives were discussed in the RPL spec,
but they don't appear to be (draft-ietf-roll-rpl).

> Or am I missing something here?

I perused draft-hui-6man-rpl-headers and it appears to describe how to
insert/remove the RPL routing header at the RPL network border.  Would
you prefer if the exception alluded to above via reference to that draft
be explicitly included in this draft?

Regards,
Brian

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Apr 2011 09:20:55 -0400

> situations where the SHOULD can be ignored.

Agreed.

> be explicitly included in this draft?

I don't immediatly see the value of the draft-hui-6man-rpl-headers at
all. It seems incomplete.

Is this intended to be standards track? 

Seems to me, there there are some (important) gaps. As such, the
document isn't useful.

For example, Section 3 talks about the mechanics of how to restore a
packet (by removing headers) in some cases. How on earth is a node
supposed to know it needs to do this? How can it distinguish between a
packet that was properly created by the originating node (i.e., is
fully compliant with existing routing header rules) vs. one where an
intermediate router took shortcuts because it didn't want to do
tunneling?

Is there an assumption this is all manually configured somehow? Or?

Thomas

---

From: Brian Haberman <[email-masked]>
Date: Wed, 27 Apr 2011 09:27:52 -0400

> Is this intended to be standards track? 

The header indicates Standards Track, but it is an individual draft at
this point.  The authors have not asked 6MAN to consider adopting it.

> Is there an assumption this is all manually configured somehow? Or?

No clue.  I would suggest engaging the draft authors or asking on the
ROLL WG mailing list.  It may also be worthwhile to mention your
concerns to the IESG given that the routing header draft's current state.

Regards,
Brian

---

From: Thomas Narten <[email-masked]>
Date: Fri, 29 Apr 2011 15:16:20 -0400

I went and reviewed this document in more detail. Below are my
comments. I will send Jari a heads-up as well, since this is in his
queue for review as well.

2011-04-29 review of -03

   Third, to avoid some attacks that lead to the deprecation of RH0,
   routers along the way MUST verify that loops do not exist with in the
   source route.

THis requirement is processor/resource intensive. and has to be done
on every hop on every packet! I don't see how this will be done in
practice, given the premise that the nodes have limited resources and
hence need the special routing header.

   Case 2 also occurs whenever a RPL router needs to insert a source
   route when forwarding datagram.  One such use case with RPL is to
   have all RPL traffic flow through a Border Router and have the Border
   Router use source routes to deliver datagrams to their final
   destination.  When including the SRH using tunneled-mode, the Border
   Router would encapsulate the received datagram unmodified using IPv6-
   in-IPv6 and include a SRH in the outer IPv6 header.

Text in this section could be more clear if it was always stated where
the packets were going. I.e., being clear about whether a packet is
coming from outside the routing domain and being delivered inside the
domain, etc. "saying flow through the router" convers a lot of
different cases.

   CmprI               4-bit unsigned integer.  Number of prefix octets
                       from each segment, except than the last segment,
                       that are elided.  For example, a SRH carrying
                       full IPv6 addresses in Addresses[1..n-1] sets
                       CmprI to 0.

   CmprE               4-bit unsigned integer.  Number of prefix octets
                       from the segment that are elided.  For example, a
                       SRH carrying a full IPv6 address in Addresses[n]
                       sets CmprE to 0.

I don't understand the difference. is CmprE just for the last address
(If so, say so). and when does it make sense to a different prefix
length for just the last address?

  4.1.  Generating Source Routing Headers

   To deliver an IPv6 datagram to its destination, a router may need to
   generate a new SRH and specify a strict source route.  Routers SHOULD

not "strict source route", but the routing header type defined in the
previous section.
      
   use IPv6-in-IPv6 tunneling, as specified in [RFC2473] to include a
   new SRH 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 a SRH are sent back to the router
   that generated the routing header.

Either the above should be a MUST, or you should explain what you have
in mind as far as other alernatives. Do you just been other forms of
tunneling?

   Performing IP-in-IP encapsulation may grow the datagram to a size
   larger than the IPv6 min MTU of 1280 octets.  To help avoid IP-layer
   fragmentation caused by IP-in-IP encapsulation, links within a RPL
   domain SHOULD be configured with a MTU of at least 1280 + 40 (outer
   IP header) + SRH_MAX_SIZE (+ additional extension headers or options
   needed within RPL domain) octets.

And any router that adds one of these headers better (MUST) correctly
do proper PMTU/"ICMP packet too big" handling. Or you will have black
hole and other fun problems. 

This section should be deleted. Adding such headers would seem to
violate existing standards. THis document should not suggest that ever
makes sense.

   The function of SRH is intended to be very similar to IPv4's Strict
   Source and Record Route option [RFC0791].  After the routing header
   has been processed and the IPv6 datagram resubmitted to the IPv6
   module for processing, the IPv6 Destination Address contains the next
   hop's address.  When forwarding an IPv6 datagram that contains a SRH
   with a non-zero Segments Left value, if the IPv6 Destination Address
   is not on-link, a router SHOULD send an ICMP Destination Unreachable
   (ICMPv6 Type 1) message with ICMPv6 Code set to (TBD by IANA) to the
   packet's Source Address.  This ICMPv6 Code indicates that the IPv6
   Destination Address is not on-link and the router cannot satisfy the
   strict source route requirement.  When generating ICMPv6 error
   messages, the rules in Section 2.4 of [RFC4443] must be observed.

should the packet also be dropped? Why doesn't the above text say
that? 

   To detect loops in the SRH, a router MUST determine if the SRH
   includes multiple addresses assigned to any interface on that router.

This is too computation expensive for every forwarding node to do. I
don't think it will happen in practice. This is an example of a bad
IETF MUST, because it will widely be ignored.

   For datagrams exiting the RPL domain, RPL Border Routers MUST check
   for a SRH.  If Segments Left is 0, the router MUST remove the SRH
   from the datagram.  If the SRH was included using tunneled mode and
   the RPL Border Router serves as the tunnel end-point, removing the
   outer IPv6 header serves to remove the SRH as well.  Otherwise, the
   RPL Border Router assumes that the SRH was included using transport
   mode and MUST remove the SRH from the IPv6 header.  If Segments Left
   is non-zero, the router MUST drop the datagram.

What does "transport mode" mean above? If there is an SRH, and the
packet is about to be forwarded outside the domain, the packet gets
discarded. Full stop.  (Right?)

Thomas