An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)
draft-ietf-6man-rpl-routing-header-07

[Ballot comment]
Comment added on 11/30.

The working group summary is pretty terse.  I think it would be
helpful to explain that the design and use of the option morphed
several times during the working group discussion before
it arrived at its current state.  Also, the working group summary
should refer to the roll (not RPL) working group.

Comment added on 12/18.

In the second paragraph, section 4.1, is RFC 2119 language
needed in this sentence?

  In the case that the source route is longer than the
  original datagram's IPv6 Hop Limit, only the initial hops (determined
  by the original datagram's IPv6 Hop Limit) should be included in the
  SRH.

[Ballot discuss]
Edited on 12/16/2011

1. I think there is an inadvertent omission of some text.  From
section 4.2:

  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.

There should also be text explicitly requiring that the router drops
the datagram.

2. Cleared, based on first paragraph of section 4.1 and integration
of (former) section 5 into section 4.

3. (Added regarding new text in rev -06)  I understand the purpose
of the new text.  I think clarification is needed:

* in the case the source route is longer than the Hop Limit in the
original datagram, only the initial hops (determined by the Hop
Limit) should be include in the SRH.  I think an implementor
would likely infer the correct behavior but clarification would
be good
* the references to Hop Limit should indicate if it's the
Hop Limit in the original datagram or the Hop Limit in the tunnel
header

[Ballot discuss]
Same discuss point as for the other RPL doc. Should have the same
solution as well.

What countermeasures exist for the attacks listed in section 6? I guess
at least some hop-by-hop authentication and integrity would provide some
accountability and prevent some spoofs. Doesn't RPL have some such
mechanism that can be used? If so, then wouldn't it be right to
RECOMMEND support for that and maybe even use of that?

[Ballot discuss]
Holding a discuss for IANA:

IESG:

IANA has questions about draft-ietf-6man-rpl-routing-header-04.txt:

The IANA Considerations section asks us to register the following:

1) a Routing Type at http://www.iana.org/assignments/ipv6-parameters

2) a code under "Destination Unreachable" in the ICMPv6 "Code" Fields
registry at http://www.iana.org/assignments/icmpv6-parameters

However, it does not tell us how to fill in the description field for
these registrations. We could guess that the description for the latter
might be "the router cannot satisfy the strict source-route
requirement," but the document isn't clear. Please add the precise text
you want us to use in the registry for both registrations.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC. This
message is only to confirm what actions will be performed.

Thanks,

Amanda Baber
IANA

[Ballot comment]
Comment added on 11/30.

The working group summary is pretty terse.  I think it would be
helpful to explain that the design and use of the option morphed
several times during the working group discussion before
it arrived at its current state.  Also, the working group summary
should refer to the roll (not RPL) working group.

[Ballot discuss]
I'm stepping right out of my knowledge box so I might get back in it quite quickly:

I find it interesting that you've modeled SRH on SSSR:

  The function of SRH is intended to be very similar to IPv4's Strict
  Source and Record Route option [RFC0791].

but RFC 6274 says this about the SSSR option:

  As with the LSRR, while the SSSR option may be of help in debugging
  some network problems, its security implications outweigh any
  legitimate use of it.

Some of the security implications are as follows:  Among
other things, the option can be used to:

  o  Bypass firewall rules

  o  Reach otherwise unreachable Internet systems

  o  Establish TCP connections in a stealthy way

  o  Learn about the topology of a network

  o  Perform bandwidth-exhaustion attacks

I guess the ship may have sailed but I'm curious why one thinks is not worth using but this is modeling behavior after it.  Are these issues introduced now as well?

[Ballot discuss]
I'm stepping right out of my knowledge box so I might get back in it quite quickly:

I find it interesting that you've modeled SRH on SSSR:

  The function of SRH is intended to be very similar to IPv4's Strict
  Source and Record Route option [RFC0791].

but RFC 6274 says this about the SSSR option:

  As with the LSRR, while the SSSR option may be of help in debugging
  some network problems, its security implications outweigh any
  legitimate use of it.

I guess the ship may have sailed but I'm curious why one thinks is not worth using but this is modeling behavior after it.

[Ballot comment]
I have no objection to the publication of this document, but I have a number of small editorial questions/comments that I hope you will address along the way.

Section 2

  First, RPL routers implement a strict source route policy where each
  and every IPv6 hop is specified within the SRH.

appears to be in conflict with

  2.  If the SRH only specifies a subset of the path from source to
      destination, the router uses IPv6-in-IPv6 tunneling [RFC2473]

This probably just needs clarifying text in the paragraph. There is
explanation of when the situation occurs (after the numbered list).

---

Section 3 Next Header

Shouldn't your base reference be RFC 2460? If IPv6 was to choose to
diverge from IPv4, which one would you follow?

---

Section 3 Routing Type

You do not mention the use to which this field is put anywhere in your
document. It should probably go here.

---

Section 3 Reserved

You have not said how the Reserved field is handled.

---

It would have been useful to state (section 4.1?) how "segments left"
is set on the initial SRH and whether the first entry in the address
list includes the source node.

---

Section 4.2

          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 {

This check is more specific than the text previously indicated. This
is the first mention of non-adjacent repeat addressing.

---

Section 4.2

            swap the IPv6 Destination Address and Address[i]

Do you really mean swap? Or do you just want to set DstA = Address[i] ?

---

Section 4.2

I'm surprised that you check and decrement the hop limit so late in the
cycle.

[Ballot discuss]
I have two Discuss issue that should be easy to resolve.

1. I think there is an inadvertent omission of some text.  From
section 4.2:

  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.

There should also be text explicitly requiring that the router drops
the datagram.

2. This issue requires a little clarification before I can provide an
actionable Discuss issue.  Is it possible to deploy RPL in a network
in which not all of the nodes in the network participate in RPL?
E.g., can there be "leaf" nodes, the equivalent of hosts, that do not
participate in RLL and that exchange datagrams with immediate
neighbors that are RPL routers?  If so, I think there needs to be
additional text similar to that in section 5 describing how a RPL
router must ensure that it doesn't forward a datagram containing an
SRH to a non-RPL leaf node.

[Ballot comment]
Please double-check the first paragraph of section 4 to make sure that "ICMPv6 errors generated by inserting the RPL option" is really what you mean to say - are you talking about errors that resulted from inserting the option itself, or possibly other ICMP errors that might result from other data in the tunnel header?

[Ballot comment]
- how are RPL routers supposed to know which of them are border routers
at what point in time? Doesn't needing to know this further constrain the
applicability of this scheme?

- is it allowed for a RPL router to just drop an SRH and replace it with
an entirely new SRH?

- s1, "necessary mechanisms" is a bit odd, be better to name them if
they're known/agreed already.

- 6.1 seems to imply that all the attacks listed can be mounted from
within the LLN. Truth in advertising would call for saying that
explicitly.

[Ballot discuss]
Same discuss point as for the other RPL doc. Should have the same
solution as well.

What countermeasures exist for the attacks listed in section 6? I guess
at least some hop-by-hop authentication and integrity would provide some
accountability and prevent some spoofs. Doesn't RPL have some such
mechanism that can be used? If so, then wouldn't it be right to
RECOMMEND support for that and maybe even use of that?

[Ballot comment]
- how are RPL routers supposed to know which of them are border routers
at what point in time? Doesn't needing to know this further constrain the
applicability of this scheme?

- is it allowed for a RPL router to just drop an SRH and replace it with
an entirely new SRH?

- s1, "necessary mechanisms" is a bit odd, be better to name them if
they're known/agreed already.

- 6.1 seems to imply that all the attacks listed can be mounted from
within the LLN. Truth in advertising would call for saying that
explicitly.

IANA has questions.

The IANA Considerations section asks us to register the following:

1) a Routing Type at http://www.iana.org/assignments/ipv6-parameters

2) a code under "Destination Unreachable" in the ICMPv6 "Code" Fields
registry at http://www.iana.org/assignments/icmpv6-parameters

However, it does not tell us how to fill in the description field for
these registrations. We could guess that the description for the latter
might be "the router cannot satisfy the strict source-route
requirement," but the document isn't clear. Please add the precise text
you want us to use in the registry for both registrations.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (An IPv6 Routing Header for Source Routes with RPL) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'An IPv6 Routing Header for Source Routes with RPL'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-31. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In Low power and Lossy Networks (LLNs), memory constraints on routers
  may limit them to maintaining at most a few routes.  In some
  configurations, it is necessary to use these memory constrained
  routers to deliver datagrams to nodes within the LLN.  The Routing
  for Low Power and Lossy Networks (RPL) protocol can be used in some
  deployments to store most, if not all, routes on one (e.g. the
  Directed Acyclic Graph (DAG) root) or few routers and forward the
  IPv6 datagram using a source routing technique to avoid large routing
  tables on memory constrained routers.  This document specifies a new
  IPv6 Routing header type for delivering datagrams within a RPL
  domain.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
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] 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, 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

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Brian Haberman is the document shepherd for this document, has reviewed
this version, and believes it is ready for IESG review.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

This draft has been reviewed by both members of the 6man WG and the
ROLL WG. The shepherd does not have concerns with the depth or breadth
of these reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

This document has strong concurrence from a small number of WG participants.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist 
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

This draft passes all ID-nits checks.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

All references are in order.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations are in order.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

N/A.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        In Low power and Lossy Networks (LLNs), memory constraints on
        routers may limit them to maintaining at most a few routes.  In
        some configurations, it is necessary to use these memory
        constrained routers to deliver datagrams to nodes within the LLN.
        The Routing for Low Power and Lossy Networks (RPL) protocol can
        be used in some deployments to store most, if not all, routes on
        one (e.g. the Directed Acyclic Graph (DAG) root) or few routers
        and forward the IPv6 datagram using a source routing technique
        to avoid large routing tables on memory constrained routers.
        This document specifies a new IPv6 Routing header type for
        delivering datagrams within a RPL domain.

    Working Group Summary
        This document was reviewed by the 6man and RPL WGs and
        represents the consensus of those groups.

    Document Quality
        Several external groups have indicated their plans to
        carry out large-scale deployments using the RPL option
        defined in this document.