Hi Jari, Could you tell us if you think that we have addressed your concerns, and we will post the new revision ?
Many Thanks, JP and Jonathan. On Sep 16, 2011, at 5:08 PM, Jonathan Hui wrote: > > 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 > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
