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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
