Hi Jari, I think we are converging. If there are no other comments, we will update the draft based on your review. See below:
On Sep 2, 2011, at 2:19 PM, Jari Arkko wrote: > 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." I like this expanded text. It calls out important issues and provides useful insight. Will add it in the next revision. >>>> 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. I understand the concern and agree with your reasoning. Will make this change in the next revision. >>>> 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? I think it is reasonable to call out the costs up front. We will make this change in the next revision unless there are alternative ideas. Thanks. -- Jonathan Hui -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
