Jonathan,
Please see inline. If you agree with what I'm writing here you should just
submit a new draft version and we can take it from there. But it might be that
on some aspects we need further discussion.
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.
Yes, 6LoWPAN is one of the target link layers. I agree that this statement is
problematic with strict adherence to RFC 4944. Note, however, that there are
IEEE 802.15.4 variants (i.e. 802.15.4g) that support frame lengths up to 2KB.
I'm not sure it would be wise to limit the capabilities of alternative IEEE
802.15.4 link technologies.
I would propose to remove the cited statement. It is unnecessary given that
the next revision of this draft will require tunneling.
Ok. But it doesn't really remove the technical issue, which is a conflict two
competing objectives (small MTU for efficiency and avoiding fragmentation due
to header insertion). How about adding this text:
"To avoid fragmentation, it is desirable to employ MTU sizes that allow for the
header expansion, i.e., at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE. Even so, to
take advantage of this, the communicating endpoints need to be aware that they can not
use the full MTU, through Path MTU discovery, for instance. The larger MTU size is
unfortunately not available on all links, for instance on 6LOWPAN links the MTU is 1280
bytes. However, it is expected that much of the traffic on these types of networks
consists of much smaller messages than the MTU anyway, so performance degradation through
fragmentation would be limited."
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?
The intent really was to utilize the current IPv6 Destination value since all entries
except the last will carry the same CmprI prefix bytes. Now, I can see there is an issue
when we consider the final entry controlled by CmprE. The intent was that CmprE would
only differ when operating in "transport mode" and the SRH would thus be
removed according to Section 5 of the draft.
OK
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.)
In general, I agree with your concern. However, after re-reading the draft, do
is it necessary to mandate a particular solution (i.e. RFC 2473)? Instead, how
do you feel about the following modified text:
To deliver a datagram, a router MAY specify a source route to reach
the destination using a SRH. There are two cases that determine how
to include an SRH with a datagram.
1. When the source node inserts an SRH, it may do so directly
within the datagram itself.
2. When an intermediate node inserts an SRH, it should do so in
a way that does not cause path MTU issues and ensures ICMP
errors caused by inserting the SRH return to the source of the
SRH rather than the original datagram. One such method is
IPv6-in-IPv6 tunneling [RFC 2473].
No, I don't think this will be sufficient. For one, we are writing
specifications that should be complete and lead to interoperable solutions. We
need to say what the implementations do. Secondly, I don't understand how the
non-tunneling solution would deal with some of the fragmentation issues. In
IPv6 we don't do fragmentation in routers on the path. Third, leaving any
handwaving about other ways of doing the encap without full, WG-reviewed and
accepted specification of that other way is not appropriate for a proposed
standard RFC.
I still recommend doing here what I suggested initially.
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.
Agree.
OK
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.
Agree.
OK
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.
Yes, the src and dst fields are IPv6 header fields. Will update the figure to
be more explicit.
Good.
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.
Correct. Will clarify in the next revision.
OK
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?
When using tunneling, the ICMP error should go back to the source of the outer
IPv6 header.
OK
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.
My personal belief is that LLN devices will generally have more computation
capability relative to communication capability, so I'm not terribly concerned
with the processing overhead. That said, I'm not a fan of the loop check and
would prefer less complexity. We only required such checks to deal with
security concerns that have been raised in the past with RH0. If others feel
that the checks are unnecessary or have alternative suggestions, I'm more than
happy to make the changes.
The problem is that the concerns with RH0 are valid, so cecks (or at least some
checks) are required, I think. One way to deal with this concern is to document
the limitations of the RPL routing header, i.e., state upfront that it requires
significant per-packet processing. Then the issue would at least not be a
surprise to anyone. Thoughts?
Jari
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
