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. 

   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.

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