Subject: Fwd: New Version Notification for draft-hui-6man-rpl-option-00.txt

From: JP Vasseur <[email-masked]>
Date: Mon, 17 May 2010 15:18:24 +0200

Dear all,

This is to re-activate our discussion during the last IETF meetings.  
Feed-back are very welcome since we would like to move forward as soon  
as possible, this proposed extension is indeed critical for RPL to  
move forward.

Many Thanks.

JP and Jonathan.

Begin forwarded message:

> From: Jonathan Hui <[email-masked]>
> Date: March 12, 2010 6:39:40 PM CEST
> To: [email-masked]
> Cc: "JP Vasseur (jvasseur)" <[email-masked]>
> Subject: New Version Notification for draft-hui-6man-rpl-option-00.txt
>
>
> Hi,
>
> We are working on a new routing protocol (called RPL) within the  
> ROLL WG targeted at low-power and lossy networks (LLNs).  Designed  
> to operate within resource constraints typical to LLNs, RPL uses a  
> slow proactive process to construct and maintain a routing topology  
> but a reactive and dynamic approach to resolving routing  
> inconsistencies.  In short, RPL is designed to utilize routing  
> information placed within data-plane datagrams to detect routing  
> inconsistencies.  To carry RPL routing information within a RPL  
> routing domain, we would like to define a new IPv6 Option to be  
> carried within the IPv6 Hop-by-Hop Option header.
>
> Any comments are appreciated.
>
>
> Filename:	 draft-hui-6man-rpl-option
> Revision:	 00
> Title:		 RPL Option for Carrying RPL Information in Data-Plane  
> Datagrams
> Creation_date:	 2010-03-01
> WG ID:		 Independent Submission
> Number_of_pages: 6
>
> Abstract:
> The RPL protocol requires data-plane datagrams to carry RPL routing  
> information that is processed by RPL routers when forwarding those  
> datagrams. This document describes the RPL option for use within a  
> RPL domain.
>
> --
> Jonathan Hui
>

---

From: Philip Levis <[email-masked]>
Date: Sat, 29 May 2010 10:07:55 -0700

On May 17, 2010, at 6:18 AM, JP Vasseur wrote:

> Dear all,
>
> This is to re-activate our discussion during the last IETF  
> meetings. Feed-back are very welcome since we would like to move  
> forward as soon as possible, this proposed extension is indeed  
> critical for RPL to move forward.
>
> Many Thanks.
>
> JP and Jonathan.

I strongly support this draft; it is a make-or-break extension,  
without which RPL will not be an effective protocol. There is  
extensive experimental evidence from many LLN deployments and  
testbeds that the mechanisms it enables (datapath validation) are  
critical.

I think Jonathan has done an excellent job of narrowly defining what  
the option can do: containing it within a RPL domain addresses most  
of the major concerns with hop-by-hop options.

Phil

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 30 May 2010 15:46:37 -0500

If RFC 2711 already defines a Router Alert Option to use, why do we need
a new option in the Hop by Hop option for roll as specified by this
document?  I suggest we just use a new code value for roll with RFC 2711
and be done with it.  See section 2.1 of RFC 2711.  Here is a list of
what IPv6 protocols already use the Router Alert Option.

http://www.iana.org/assignments/ipv6-routeralert-values/ipv6-routeralert
-values.xhtml

RFC 2711 also already lists the security concerns with use of the Router
Alert Option.  This document is repeating the same security concern.
Further one should look at

http://tools.ietf.org/html/draft-rahman-rtg-router-alert-considerations-
03

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: Saturday, May 29, 2010 1:08 PM
To: JP Vasseur
Cc: [email-masked]
Subject: Re: New Version Notification for
draft-hui-6man-rpl-option-00.txt

Phil
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jonathan Hui <[email-masked]>
Date: Sun, 30 May 2010 21:37:54 -0700

Hemant,

Being able to change the option data hop-by-hop is fundamental to  
RPL's ability to verify routing information consistency.  That is why  
Section 2 of the rpl-option draft states that "the RPL option is  
expected to change en-route."

The Router Alert Option as specified today does not satisfy this  
fundamental requirement.  Section 2.1 of RFC 2711 states that "the  
option must not change en route."

--
Jonathan Hui

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 30 May 2010 23:18:16 -0700

Hi Jonathan,

I read your draft. As I have not read RPL I have to say the draft by
itself was not self contained so was a bit hard to figure out what can
be done in the RPL option.

After finding the Traffic amplification issues, I had a draft
http://tools.ietf.org/html/draft-manral-ipv6-rh4-00 which had some
additional checks that could be required for any new RH header (we had
named it RH4 too).

Though the scope is limited to LLN with RPL, I was wondering if the
issues known would not be an issue in such a network. If not so why?

Thanks,
Vishwas

On Sun, May 30, 2010 at 9:37 PM, Jonathan Hui <[email-masked]> wrote:
>
> Hemant,
>
> Being able to change the option data hop-by-hop is fundamental to RPL's
> ability to verify routing information consistency.  That is why Section 2 of
> the rpl-option draft states that "the RPL option is expected to change
> en-route."
>
> The Router Alert Option as specified today does not satisfy this fundamental
> requirement.  Section 2.1 of RFC 2711 states that "the option must not
> change en route."
>
> --
> Jonathan Hui
>

---

From: Jonathan Hui <[email-masked]>
Date: Sun, 30 May 2010 23:45:54 -0700

Vishwas,

FYI, we currently have two initial 6man drafts that describe  
mechanisms for supporting RPL.  The concrete concerns about the  
routing header seem to apply to the rpl-routing-header draft rather  
than the rpl-option draft.

To answer your question, we did intend to address the well-known  
traffic amplification issue with the check you suggested.  Section 2  
already has initial text specifying that an IPv6 address must not  
appear more than once in the routing header.  In the next version of  
the draft, we'll include an update to Section 3 that verifies the  
requirement when processing the header.

Thanks.

--
Jonathan Hui

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 31 May 2010 08:17:02 -0500

>From: Jonathan Hui [mailto:[email-masked]] 
>Sent: Monday, May 31, 2010 12:38 AM
>To: Hemant Singh (shemant)
>Cc: Philip Levis; JP Vasseur; [email-masked]

>option must not change en route."

Ah, I missed the part in your document that said the option can change
en-route.  In that case, indeed RFC 2711 can't be used.  

Hemant

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 31 May 2010 08:07:27 -0700

Hi Jonathan,

I just re-read the draft I had written about 3 years ago and tried to
figure out things we could further add to your draft.

Do you have any diameter in the RPL network? If so there are 2 questions:

1. Is 255 a good enough value? With your draft we can allow only a
maximum of 255 intermediae nodes.
2. If we think a smaller value like 32/ 64 would be good enough, we
can further constrain the header to allow a maximum number of
addresses.

Thanks,
Vishwas

On Sun, May 30, 2010 at 11:45 PM, Jonathan Hui <[email-masked]> wrote:
>
> Vishwas,
>
> FYI, we currently have two initial 6man drafts that describe mechanisms for
> supporting RPL.  The concrete concerns about the routing header seem to
> apply to the rpl-routing-header draft rather than the rpl-option draft.
>
> To answer your question, we did intend to address the well-known traffic
> amplification issue with the check you suggested.  Section 2 already has
> initial text specifying that an IPv6 address must not appear more than once
> in the routing header.  In the next version of the draft, we'll include an
> update to Section 3 that verifies the requirement when processing the
> header.
>
> Thanks.
>
> --
> Jonathan Hui
>