I have reviewed this draft.
I have a number of comments, most of which are at this point questions
and discussion items. The comments are included below in three
categories: technical comments, editorial comments, and comments
relating to feedback from other people that may not been fully handled
yet. In general, the draft is well written and largely ready to move to
a Proposed Standard RFC. However, there are a couple of issues that we
need to discuss: MTU requirements, recommendations to consider
alternative designs that exist only as Internet Drafts, and the
feasibility of the loop check.
I also need to apologize that it has taken far too long for me to do
this review. There's no good excuse, but I've had some number of other
documents in the queue this spring, day job requirements, and I knew I
needed to review this document carefully. The rpl-option draft is next
on my reading queue, probably reviewed by Monday.
Technical:
=======
links within a RPL domain SHOULD have
a MTU of at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE (+
additional extension headers or options needed within RPL domain)
octets.
I thought that 6LOWPAN was an important link layer for the application
of RPL. Yet, RFC 4944 specifies a MTU of 1280 octets. The above
requirement seems to be in contradiction with what is available on
6LOWPAN. Am I missing some extension of 6LOWPAN that changes the MTU, or
some other link layer that is expected to be used with RPL? If I'm not
missing anything, wouldn't this cause a problem? It would seem that
either you cannot run RPL on 6LOWPAN, run 6LOWPAN on non standard MTU
values (and we know MTU negotiation is difficult), or you have to change
the expectations of other nodes in the IPv6 Internet about the minimum
assured MTU.
Please clarify/resolve/tell me what I am missing.
A common network configuration for a RPL domain is that all nodes
within a LLN share a common prefix. The SRH introduces the CmprI,
CmprE, and Pad fields to allow compaction of the Address[1..n] vector
when all entries share the same prefix as the IPv6 Destination
Address field of the packet carrying the SRH.
So all segments are treated based on how many bytes they have in common
with the destination address. But the destination address keeps changing
as we go through the intermediate hops. Is it necessary to clarify that
the comparison/shared prefix is with the final destination address, NOT
the address that happens to be in the destination address field currently?
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
<http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-03#ref-I-D.hui-6man-rpl-headers>]
describes
how to avoid using IPv6-in-IPv6 tunneling in such specific cases and
the risks involved.
This sounds like a recommendation to do something in a draft that has
not been through the working group and approved as the something that is
a sound practice. Unless the reference is normative, I think it is
inappropriate to refer to an Internet draft in this manner.
What I would recommend is to (1) change the "... SHOULD use IPv6-in-IPv6
tunneling ..." statement to a MUST in this draft, (2) remove the above
text, and (3) make the corresponding changes to Section 5. Then we can
take hui-6man-rpl-headers through the working group and provide a
second, more light-weight approach that extends what we have
RFC-to-be-draft-ietf-6man-rpl-routing-header.
(FWIW, I think the problem begins when one adds the first byte to a
packet somewhere along the route. It does not not matter so much how
many bytes one adds, just the SRH or also the IP header. Most of the
complications on MTUs and so one start at that point. In any case, SRHs
may not be trivially small either. Assuming 64-bit prefix compression an
SRH for 4 hops would be 40 bytes.)
If such addresses appear more than once and are separated by at least
one address not assigned to that router, the router MUST drop the
packet and SHOULD send an ICMP Parameter Problem, Code 0, to the
Source Address.
...
else if 2 or more entries in Address[1..n] are assigned to
local interface and are separated by at least one
address not assigned to local interface {
discard the packet
}
The text and the code appear to disagree about whether to send an ICMP
Parameter Problem message. Please align. I assume that an ICMP message
is needed.
Because this document specifies that SRH is only for use within a RPL
domain, such attacks cannot be mounted from outside the RPL domain.
As described in Section 5
<http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-03#section-5>,
RPL Border Routers MUST drop datagrams
entering or exiting the RPL domain that contain a SRH in the IPv6
Extension headers.
This is good, and I think the security considerations are sufficient.
However, I would be happier if the draft also recommended that by
default, non-RPL routers and firewalls should drop packets with SRH.
This would help ensure that SRH does not accidentally enter any network
and expose some vulnerability. The practical effect that I'm looking for
is, for instance, not having my Linux kernel process SRH unless I've
configured it to use RPL.
Editorial:
======
In the above scenario, datagrams traveling from source, S, to
destination, D, have the following packet structure:
+------+------+------+--------//-+
| IPv6 | IPv6 | IPv6 | Packet |
| Src | Dst | SRH | Payload |
+------+------+------+--------//-+
This figure is not as clear as it could be. Are the src and dst field
referring to the IPv6 header fields? Would this picture be better if you
showed the IPv6 header explicitly? Please clarify.
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 understood the definition CmprI, but I do not understand this, at
least not at the point of the above text. What is "the segment" that you
are referring to above? SRH carries multiple segments. Please clarify.
Little further down it becomes clear that CmprE refers to the
compression of the last segment. Please make this clear already in the
above text.
Comments relating to feedback from others:
============================
The ADs have received a question from Joseph Reddy, who was asking if
the set of addresses in the SRH should also include the source address
of the node inserting the SRH. His justification for this was the need
to be able to send an ICMP error back to this node. Do we have an answer?
In April, Thomas Narten made some comments on the list and I didn't
think that the discussion finished with any conclusion. Are his concerns
(e.g., from his e-mail on April 29th) valid or not valid? I would like
the working group to conclude this issue one way or the other. I refer
to his comments regarding the feasibility of the loop check in
particular. His e-mail is at
http://www.ietf.org/mail-archive/web/ipv6/current/msg13887.html FWIW I
agree with Thomas' editorial comment on Section 2 clarity. That should
be easy to fix.
Jari
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
