From nobody Thu Jan 17 03:20:00 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AD9130DEC for ; Thu, 17 Jan 2019 03:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB5Igw8RV3Wk for ; Thu, 17 Jan 2019 03:19:55 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949DF12F1AC for ; Thu, 17 Jan 2019 03:19:55 -0800 (PST) Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id D0D8BFA7 for ; Thu, 17 Jan 2019 12:19:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1547723992; bh=9n68naO9MnSDxgGz2AKYLPQjfP3Uo2u/hyS50Trgw10=; h=From:Date:Subject:To:From; b=NyFOOj23yJhqI8fO9Ps9Q1PCTQ3XP3FQB9naH9YGVBv38ADE8uhKnIkglPGrBbyV0 JcHFHa5B0DIzWkziqYMjBs35YGbb1vKv3Cjss/g8JE2IVZbNViZ90XBjvNMO81uB/x HVjj1fyXelcTNj+ygB1JepnrZ9Kz/rbdjKcpHH0C1XI9kA5Nd4YbdWUGiO2M0qoq0u pj/13aXQ8vn6AhIk7VLK91QIhTrOPapcsYrGebFDt9y4qh3v6BoInKd1nf/lSzhmAh RsvOyfuwG1DUX82qALLRgJfKzVxzbz/zVcUJbaxFIJXlcrPVBDmTVaV69VouMC9/r1 iDq2sORJJKcqQ== Received: from mail-io1-f46.google.com ([209.85.166.46]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Thu, 17 Jan 2019 12:19:47 +0100 (CET) Received: by mail-io1-f46.google.com with SMTP id b23so7474717ios.10 for ; Thu, 17 Jan 2019 03:19:47 -0800 (PST) X-Gm-Message-State: AJcUukctkKYN93aOPNuozhBFKwF4H2Z16ZWyztitkrtsKwlc17eWBFvT 6XMWJs1Clknr8x5YlzOEpobNRtNhhpJ7ZwWtYpw= X-Google-Smtp-Source: ALg8bN6v5zKDapu3Rzc100gfGMf0PX5g9v19TuFKL/CdAbiop8WR52WFnRAtTayHD/GNEDr8rCNqdbVfEKckPpj6bag= X-Received: by 2002:a5d:8491:: with SMTP id t17mr7330119iom.11.1547723981603; Thu, 17 Jan 2019 03:19:41 -0800 (PST) MIME-Version: 1.0 From: Remous-Aris Koutsiamanis Date: Thu, 17 Jan 2019 12:19:48 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000224d92057fa59263" X-ContactOffice-Account: com:113819248 Archived-At: Subject: [Roll] Implementation of draft-ietf-roll-nsa-extension-00 with 6LoRH-style address compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 11:19:58 -0000 --000000000000224d92057fa59263 Content-Type: text/plain; charset="UTF-8" Hi all, as a follow-up to the adoption of draft-ietf-roll-nsa-extension, we have updated the Contiki-based implementation to also perform compression of the addresses stored in the Parent Set (PS) extension proposed. As per Michael's suggestion, we implemented 6LoRH-style address compression. As in RFC 8138, we need a reference address and the one we chose is the DODAG ID, i.e. the address of the DODAG root. We also added an example of the use of the draft extension in examples/ipv6/ rpl-tsch-draft-ietf-nsa-extension. The code has been updated and it is available at: https://github.com/ariskou/contiki/tree/draft-ietf-roll-nsa-extension Kind regards, Aris --000000000000224d92057fa59263 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

as a follow-up to th= e adoption of draft-ietf-roll-nsa-extension, we have updated the Contiki-based implementation to also per= form compression of the addresses stored in the Parent Set (PS) extension p= roposed.
As per Michael's suggestion, we implemented 6LoRH-st= yle address compression. As in RFC 8138, we need a reference address and th= e one we chose is the DODAG ID, i.e. the address of the DODAG root.
We also added an = example of the use of the draft extension in examples/ipv6/rpl-tsch-draft-ietf-nsa-extension.
=
The code has been updated and it is available at:
= https://github.com/arisko= u/contiki= /tree/draft-ietf-roll-nsa-extension

Kind regards,
<= span class=3D"" style=3D"" id=3D":4rh.15" tabindex=3D"-1">Aris

--000000000000224d92057fa59263-- From nobody Thu Jan 17 09:25:10 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D34130EC5 for ; Thu, 17 Jan 2019 09:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUubri_r-bHR for ; Thu, 17 Jan 2019 09:25:04 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98D0130EB5 for ; Thu, 17 Jan 2019 09:25:04 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 88DD13808A for ; Thu, 17 Jan 2019 12:24:25 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8B698CA3; Thu, 17 Jan 2019 12:25:03 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 88C1BCA1 for ; Thu, 17 Jan 2019 12:25:03 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Jan 2019 12:25:03 -0500 Message-ID: <5701.1547745903@localhost> Archived-At: Subject: Re: [Roll] Implementation of draft-ietf-roll-nsa-extension-00 with 6LoRH-style address compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2019 17:25:09 -0000 Very cool, thank you for letting the WG know. So you have suggested updates to the document? Clarificiations? Typos you observed? Remous-Aris Koutsiamanis wrote: > as a follow-up to the adoption of draft-ietf-roll-nsa-extension, we = have > updated the Contiki-based implementation to also perform compression= of the > addresses stored in the Parent Set (PS) extension proposed. > As per Michael's suggestion, we implemented 6LoRH-style address comp= ression. > As in RFC 8138, we need a reference address and the one we chose is = the DODAG > ID, i.e. the address of the DODAG root. > We also added an example of the use of the draft extension in > examples/ipv6/rpl-tsch-draft-ietf-nsa-extension. > The code has been updated and it is available at: > https://github.com/ariskou/contiki/tree/draft-ietf-roll-nsa-extensio= n > Kind regards, > Aris > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Fri Jan 18 06:08:01 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A759126CB6 for ; Fri, 18 Jan 2019 06:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailfence.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7kvxk28DSYk for ; Fri, 18 Jan 2019 06:07:58 -0800 (PST) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B63124D68 for ; Fri, 18 Jan 2019 06:07:57 -0800 (PST) Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 493EC22B for ; Fri, 18 Jan 2019 15:07:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1547820475; bh=5PTIJjfa5zZ9WywFbmG1loAkbn3wNxGpIhe2j2OXkks=; h=References:In-Reply-To:From:Date:Subject:To:From; b=DWNijMTeo/LyuqFpiOouRJoRsoHRJ95BbhZgHeOY6Z3gZVCmdz+aY6U/UUIlqV5qN +ZytMndHx6MZTVv5GWvUcI78s319NfgKp34nj70mzYW18/P4F8bEXUqn4mewSfNixv l1NoMOfbb1G7I/5U73x7yJe3+iP7hwd7L85Bf0GwMg1KRZHGq0Tjh+BT0X03DHJhU0 8xMt3oqW0zeIqc8+C6RdNVTggRSWOk1917xo/HWVeLuj/xBpxTEVSw6RRkWilbTPaa IlA5NxAdzlq7flFSUpo2/HNzjypAsWVC66BVLi9ihGR9Ue0fZmit3XlP4hdI51ht9M CDSpZkaNnllQw== Received: from mail-io1-f54.google.com ([209.85.166.54]) by smtp.mailfence.com (envelope-from ) with ESMTPA for ; Fri, 18 Jan 2019 15:07:51 +0100 (CET) Received: by mail-io1-f54.google.com with SMTP id b16so10811991ior.1 for ; Fri, 18 Jan 2019 06:07:51 -0800 (PST) X-Gm-Message-State: AJcUukdf+aeLL34CwFBLYzrl9O72ukUOCeaQZ0+SWlUFYOQlCBaD9n3x y0doAUdGGnmGsrQicOb5/DZkn9GEyvcWg6PEkww= X-Google-Smtp-Source: ALg8bN4CpkrtPIZoB+rgD2vCjPrm9ssJ2qMjFGY34+UVXfL+5ab/I4xTa1E1hJ6mOlPob3w7iDL8X5UZfTu/cj2KXuI= X-Received: by 2002:a5d:8491:: with SMTP id t17mr10310389iom.11.1547820469837; Fri, 18 Jan 2019 06:07:49 -0800 (PST) MIME-Version: 1.0 References: <5701.1547745903@localhost> In-Reply-To: <5701.1547745903@localhost> From: Remous-Aris Koutsiamanis Date: Fri, 18 Jan 2019 15:07:52 +0100 (CET) X-Gmail-Original-Message-ID: Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000047e3d3057fbc09f6" X-ContactOffice-Account: com:113819248 Archived-At: Subject: Re: [Roll] Implementation of draft-ietf-roll-nsa-extension-00 with 6LoRH-style address compression X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2019 14:08:00 -0000 --00000000000047e3d3057fbc09f6 Content-Type: text/plain; charset="UTF-8" Hi and thanks! We continue to work on this topic. This code update brings the implementation in line with the draft. For the draft, indeed we are also looking for reviewers for some help. Any suggestions, updates or requests for clarifications are *very* welcome. Kind regards, Aris On Thu, Jan 17, 2019 at 6:25 PM Michael Richardson wrote: > Very cool, thank you for letting the WG know. > > So you have suggested updates to the document? > Clarificiations? Typos you observed? > > Remous-Aris Koutsiamanis wrote: > > as a follow-up to the adoption of draft-ietf-roll-nsa-extension, we > have > > updated the Contiki-based implementation to also perform compression > of the > > addresses stored in the Parent Set (PS) extension proposed. > > As per Michael's suggestion, we implemented 6LoRH-style address > compression. > > As in RFC 8138, we need a reference address and the one we chose is > the DODAG > > ID, i.e. the address of the DODAG root. > > We also added an example of the use of the draft extension in > > examples/ipv6/rpl-tsch-draft-ietf-nsa-extension. > > > The code has been updated and it is available at: > > > https://github.com/ariskou/contiki/tree/draft-ietf-roll-nsa-extension > > > Kind regards, > > Aris > > > > > ---------------------------------------------------- > > Alternatives: > > > ---------------------------------------------------- > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00000000000047e3d3057fbc09f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi and thanks!

We continue to work= on this topic. This code update brings the implementation in line with the= draft.
For the draft, indeed we are also looking for reviewers for some= help.
Any suggestions, updates or requests for clarifications are *very= * welcome.

Kind regards,
Aris

On Thu, Jan 17, 2019 at 6:= 25 PM Michael Richardson <mcr@sandel= man.ca> wrote:
Very cool, thank you for letting the WG know.

So you have suggested updates to the document?
Clarificiations?=C2=A0 =C2=A0Typos you observed?

Remous-Aris Koutsiamanis <aris@ariskou.com> wrote:
=C2=A0 =C2=A0 > as a follow-up to the adoption of draft-ietf-roll-nsa-ex= tension, we have
=C2=A0 =C2=A0 > updated the Contiki-based implementation to also perform= compression of the
=C2=A0 =C2=A0 > addresses stored in the Parent Set (PS) extension propos= ed.
=C2=A0 =C2=A0 > As per Michael's suggestion, we implemented 6LoRH-st= yle address compression.
=C2=A0 =C2=A0 > As in RFC 8138, we need a reference address and the one = we chose is the DODAG
=C2=A0 =C2=A0 > ID, i.e. the address of the DODAG root.
=C2=A0 =C2=A0 > We also added an example of the use of the draft extensi= on in
=C2=A0 =C2=A0 > examples/ipv6/rpl-tsch-draft-ietf-nsa-extension.

=C2=A0 =C2=A0 > The code has been updated and it is available at:
=C2=A0 =C2=A0 > https://gith= ub.com/ariskou/contiki/tree/draft-ietf-roll-nsa-extension

=C2=A0 =C2=A0 > Kind regards,
=C2=A0 =C2=A0 > Aris



=C2=A0 =C2=A0 > ----------------------------------------------------
=C2=A0 =C2=A0 > Alternatives:

=C2=A0 =C2=A0 > ----------------------------------------------------
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Roll mailing list
=C2=A0 =C2=A0 > Roll@= ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/r= oll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000047e3d3057fbc09f6-- From nobody Wed Jan 23 13:13:27 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D80A127B4C; Wed, 23 Jan 2019 13:13:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <154827799756.7373.4659113679208183797@ietfa.amsl.com> Date: Wed, 23 Jan 2019 13:13:17 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-24.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 21:13:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Using RPL Option Type, Routing Header for Source Routes and IPv6-in- IPv6 encapsulation in the RPL Data Plane Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-24.txt Pages : 53 Date : 2019-01-23 Abstract: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC 6553 adding a change to the RPL Option Type. Additionally, this document updates RFC 6550 to indicate about this change and updates RFC8138 as well to consider the new Option Type when RPL Option is decompressed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-24 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 23 14:06:36 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3222130F3B for ; Wed, 23 Jan 2019 14:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFEaL_w8w-MV for ; Wed, 23 Jan 2019 14:06:26 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6998130F39 for ; Wed, 23 Jan 2019 14:06:25 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id h50so2969009ede.5 for ; Wed, 23 Jan 2019 14:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6S6R0iI51yyYsrKZIGcoe9a+YbwZwc/kyeDwY1+4B1U=; b=lJ8UoTMGML7KCdNJPgMxFGwF6hxxopYyfWZXhFU3OwBrUSVIfN8Jm+cqTNtM8CyW+t RzEd8zmMSz4sgoew/pLX7gFSFQkFkVLOjJ96RjY1hTz93J7U7JxKcunXYdipAU/dAxox 9uJKtmVuXGsQRCL2y/54vGBuJVfq/QjSX4Vior7dNs1+gcFnqwdXF2ies2w3JiFs1lP0 f7Q/R1VMM4NIpyveeVRuI0IQDuPXO0a+l5wf6ZzfdiVbVIhuL4Og/5cgC501ZqQGeTDB JianpLG2HVoWII+3wmEpH4/MdhyS8F+iTK/l/4fxwtC87CO+PqrrrAgg5mMHfWk2IpKB ZuRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6S6R0iI51yyYsrKZIGcoe9a+YbwZwc/kyeDwY1+4B1U=; b=CapJ+xuOuSTetO970Kscrh5UQlxpSq1jq1HtfgyYTa9Z18uyKN9+VbHx23+Gfc8BA1 lbODN+8dnUtvVwT+kgfo2qI15o7eo8Q14MAkraswOzk3wE5Z8djxQxl3ZqDLoBCkxOHm Lb7oSOkvXRFRgxRmWP7TGpr78azqMVTepr3JZajDnKhLZB3ICR8N3WLm2ekWWph3hbGw stf/6EdIY1w6KqhMBUpjxKEzTMVGHEjYCji17x5Us0h1FrhNjt3NDEKq3UfASS+U7NmR WxO5DyndqotXHi5VcEfp68kdjeiJA/vctUh/BOdUh1PFAwC7nEJAzNr6t2e7EwcN47Y5 S7Mg== X-Gm-Message-State: AJcUukfeh8nffa58YYRuZrdaqamSU84fzppNRm4SjhMcfyRfm9TBHz+e lCgSM7MhCaBC8s+T0/MJa88B7SejYkzw3CR3IMqz9av+ X-Google-Smtp-Source: ALg8bN6yK4VohyRMK3lSUqE2t5Ju/7qIRAZyafqd6rp3HtDG1Zt/WgcMi/J57exf/G+GcjQvYaowy0d+gAOC9U2sVlk= X-Received: by 2002:a05:6402:1347:: with SMTP id y7mr4232549edw.114.1548281183576; Wed, 23 Jan 2019 14:06:23 -0800 (PST) MIME-Version: 1.0 References: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com> In-Reply-To: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com> From: Ines Robles Date: Thu, 24 Jan 2019 00:06:11 +0200 Message-ID: To: Alvaro Retana , roll Cc: alvaro.retana@huawei.com Content-Type: multipart/alternative; boundary="000000000000f5a7fa0580274d67" Archived-At: Subject: Re: [Roll] Datatracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 22:06:35 -0000 --000000000000f5a7fa0580274d67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Alvaro, Many thanks for your review. BIG Apologizes for the delay. Please find the answers in-line as [authors]. Best regards, Michael, Pascal, Ines. On Tue, Aug 14, 2018 at 10:11 PM IETF Secretariat < ietf-secretariat-reply@ietf.org> wrote: > IESG state changed: > > New State: AD Evaluation::Revised I-D Needed > > (The previous state was AD Evaluation::AD Followup) > > =3D=3D=3D AD Review of draft-ietf-roll-useofrplinfo-23 =3D=3D=3D > > > Dear authors: > > I have (finally!) finished reading this document. Thanks for all the wor= k > and time put into working out all the details. > > I have several concerns. I'm listing some of the Major (and > document-wide) ones up front. I also put more comments and questions > inline below. > > (1) [major] Where is the specification of the data-plane behavior? > > This document does a couple of things: it Updates several other RFCs, and > presents a list of *example* flows where the expected behavior is > illustrated. The Updates are mostly about the new RPI value (0x23), but > not about the behavior of the nodes. > > Most of the examples are worded such that they describe actions > (encapsulate, remove, etc.)...and some even include rfc2119 Normative > Keywords. But they are called examples! So...my questions are: is the > behavior illustrated in =C2=A76 and =C2=A77 intended to be Normative? [authors]The examples are intended to illustrate the result of the normative language in RFC8200 and RFC6553. So the examples are intended to be normative explanation of the results of executing that language. > IOW, do these sections include both examples and specify the behavior > expected in the LLN? Is the behavior already specified somewhere else (a= nd > this document is just illustrating)? [authors]The normative language is in RFC8200 (ipv6bis) section 4.2 and section 4, =E2=80=9CThe Hop-by-Hop Options=E2=80=A6=E2=80=9D Combined with the desired results of RFC6553, we conclude that we have to change the option value in order to make things work. > [I am asking that last question just-in-case, because the Introduction > says that "this document clarifies what is the correct and the incorrect > behaviour."] [authors] It says that because the use of RPL in the mentioned cases was not clear to the WG. Thus, we have interoperability issues. > > =C2=A78 seems to attempt to summarize "observations about the cases", but= (if > it is intended to be *the* Normative text about the behavior) it is gener= al > and short. > [authors] It tends to be a summary about the most important findings in the use cases > > [Some of my comments below ask about Normative language... Please take > those in context with the answers here.] > > > (2) [major] Operational Considerations > > Non-storing mode networks don't need the change to 0x23 (=C2=A78.2)...but > making the change creates a flag day, and even then, implementations shou= ld > still process both values (=C2=A73.1). I would really like to see text a= bout > the operational considerations of introducing 0x23. It concerns me that = a > significant change that most[*] networks don't need is being introduced. > Please take a look at rfc5706 (Guidelines for Considering Operations and > Management of New Protocols and Protocol Extensions), specially =C2=A72. > > [*] Most deployed networks work in non-storing mode, right? > [authors]following our understanding, mostly yes. but, e.g. Anima network in storing mode. Not having loop detection. https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-18#sec= tion-6.11.1.3 > > > (3) [minor] >=3D ?? > [authors] Fixed. corrected to 1 <=3D i <=3D n > > There are several (25!) instances of text like this: > > 6LR_i are the intermediate routers from source to destination. In > this case, "1 <=3D i >=3D n", n is the number of routers (6LR) that th= e > packet go through from source (6LN) to destination (6LBR). > > Maybe it's just me, but I don't understand why (or how!) i could ever be > >=3D n. The text says that i are the "intermediate routers from source t= o > destination", while n is "the number of routers...from source (6LN) to > destination (6LBR)". Isn't that the same thing? What am I missing? > > > (4) Style nit: the document uses "we"...a third person style would be > preferable. For example: s/In this section we are going to > describe.../This section describes... > [authors] Fixed. > > > I will wait for the major points to be addressed before starting the IETF > LC. > > Thanks!! > > Alvaro. > > > > [Note: the numbers came from the idnits output.] > > ... > 10 When to use RFC 6553, 6554 and IPv6-in-IPv6 > 11 draft-ietf-roll-useofrplinfo-23 > > [minor] Can we come up with a more descriptive tittle? Also, the > "shorthand" version ("Useof6553") could be improved. > [authors] Fixed. Useof6553 =3D> RPL-data-plane > > > ... > 130 1. Introduction > ... > 156 The related document A Routing Header Dispatch for 6LoWPAN (6LoRH) > 157 [RFC8138] defines a method to compress RPL Option information and > 158 Routing Header type 3 [RFC6554], an efficient IP-in-IP technique, a= nd > 159 use cases proposed for the [Second6TischPlugtest] involving 6loRH. > > [nit] I'm having trouble parsing this last paragraph. It sounds like > rfc8138 (also) defines the use cases, but I don't remember seeing anythin= g > like that in there. Is that what you meant? > [authors]rewritten. RFC8138" defines a mechanism for compressing RPL Option information and Routing Header type 3, as well as an efficient IP-in-IP technique. > > [nit] I think the Introduction would benefit from an overview of the > document; something like "section X talks about abc, section Y presents > examples, etc.". > [authors]added > > 161 2. Terminology and Requirements Language > > 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thi= s > 165 document are to be interpreted as described in RFC 2119 [RFC2119]. > > [major] Please use the RFC8174 template. > [authors]added > > ... > 170 RPL-node: A device which implements RPL, thus we can say that the > 171 device is RPL-capable or RPL-aware. Please note that the device ca= n > 172 be found inside the LLN or outside LLN. In this document a RPL-nod= e > 173 which is a leaf of a DODAG is called RPL-aware-leaf. > > [nit] RPL-capable is not used anywhere else. > [authors]fixed. removed > > ... > 180 pledge: a new device which seeks admission to a network. (from > 181 [I-D.ietf-anima-bootstrapping-keyinfra]) > > 183 Join Registrar and Coordinator (JRC): a device which brings new nod= es > 184 (pledges) into a network. (from > 185 [I-D.ietf-anima-bootstrapping-keyinfra]) > > [minor] Do these two terms need to be defined in this document? They are > only used once, and with a reference to > I-D.ietf-anima-bootstrapping-keyinfra next to them. Also, and more > important, the definition here doesn't match the one in that other draft. > Please take out the definitions and just make reference later on... > [authors]fixed. removed > > 187 Flag day: A "flag day" is a procedure in which the network, or a pa= rt > 188 of it, is changed during a planned outage, or suddenly, causing an > 189 outage while the network recovers [RFC4192] > > [nit] rfc4192 seems like an odd place to pull a reference to "flag day" -= - > specially as it is being defined as "a procedure" and not the effect it > causes, which seems to be how it is used in the text: "creates a flag day= ", > "will experience a flag day", "avoid a flag day". This is not a big issu= e > -- if it was up to me, I would either make my own definition, or just not > define it at all: I think it is a well known term... > [authors]fixed. rewritten > > 191 2.1. hop-by-hop IPv6-in-IPv6 headers > > 193 The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a heade= r > 194 that originates from a node to an adjacent node, using the addresse= s > 195 (usually the GUA or ULA, but could use the link-local addresses) of > 196 each node. If the packet must traverse multiple hops, then it must > 197 be decapsulated at each hop, and then re-encapsulated again in a > 198 similar fashion. > > [minor] That term is not used anywhere...but "hop-by-hop IP-in-IP" is. > [authors]fixed. IP-in-IP replaced by IPv6-in-IPv6 > > IPv6-in-IPv6 and IP-in-IP are used interchangeably throughout the > document. This use is not wrong, but it is inconsistent. Adding a note > about it (even though it may be obvious to many readers that the terms > refer to the same thing) would be nice...being consistent even nicer. > > Later on, "IPIP" is also used... > > > [nit] Why is this definition in its own sub-section? > [authors]fixed. It is included in the section instead. > > 200 3. Updates to RFC6553, RFC6550 and RFC 8138 > > 202 3.1. Updates to RFC 6553 > > ... > 209 [RFC6553] states as showed below, that in the Option Type field of > 210 the RPL Option header, the two high order bits MUST be set to '01' > 211 and the third bit is equal to '1'. The first two bits indicate tha= t > 212 the IPv6 node MUST discard the packet if it doesn't recognize the > 213 option type, and the third bit indicates that the Option Data may > 214 change en route. The remaining bits serve as the option type. > > s/showed/shown > > [major] The 2 MUSTs used above are used paraphrasing rfc6553, and don't > define Normative behavior in this document. Please either use a direct > quote, or use non-normative language. > [authors]fixed to non-normative language. > > ... > 223 Recent changes in [RFC8200] (section 4, page 8), states: "it is now > 224 expected that nodes along a packet's delivery path only examine and > 225 process the Hop-by-Hop Options header if explicitly configured to d= o > 226 so". Processing of the Hop-by-Hop Options header (by IPv6 > 227 intermediate nodes) is now optional, but if they are configured to > 228 process the header, and if such nodes encounter an option with the > 229 first two bits set to 01, they will drop the packet (if they confor= m > 230 to [RFC8200]). Host systems should do the same, irrespective of th= e > 231 configuration. > > [minor] The description above seems to be missing "...if the option is no= t > recognized". > > 233 Based on That, if an IPv6 (intermediate) node (RPL-not-capable) > 234 receives a packet with an RPL Option, it should ignore the HBH RPL > 235 option (skip over this option and continue processing the header). > > s/That/that > > ... > 266 When forwarding packets, implementations SHOULD use the same value = as > 267 it was received (This is required because, RPI type code can not be > 268 changed by [RFC8200]). It allows to the network to be incrementall= y > 269 upgraded, and for the DODAG root to know which parts of the network > 270 are upgraded. > > [major] There seems to be a contradiction above: "SHOULD use the same > value...this is required..." If required by rfc8200, why not use MUST? > [authors]rewritten > > 272 When originating new packets, implementations SHOULD have an option > 273 to determine which value to originate with, this option is controll= ed > 274 by the DIO option described below. > > [minor] =C2=A73.3 defines the option...but it doesn't explicitly say what= the > receivers should do with it. It may be obvious, but it should be explici= t > for completeness. > [authors]rewritten > > [major] It seems to me that the paragraph above may be out of place, > doesn't say much, may be wrong...or maybe all 3. The text says that the > originating value is controlled by the option in =C2=A73.3 (again, but th= at > section doesn't explicitly say what should be done)...but it also says > (with the SHOULD) that an implementation may have valid reasons to not pa= y > attention to the option -- what are those?? > [authors]rewritten to "In the cases where a forwarding node is forwarding traffic that is not addressed directly to it (such as when the outer IPv6-in-IPv6 header is not a Link-Local address), then RFC8200 forbids changing the RPI type code when forwarding. When forwarding traffic that is wrapped in Link-Local IPv6-in-IPv6 headers, the forwarding node is in effect originating new packets, and it MAY make a choice as to whether to use the old (0x63) RPI Type code, or the new (0x23) RPI Type code. In that situation, implementations SHOULD use the same value as was received. This allows to the network to be incrementally upgraded, and in some cases may allow the DODAG root to know which parts of the network are upgraded." > > > ... > 281 3.2. Updates to RFC 8138 > > 283 RPI-6LoRH header provides a compressed form for the RPL RPI > 284 [RFC8138]. It should be considered when the Option Type in RPL > 285 Option is decompressed, should take the value of 0x23 instead of > 286 0x63. > > [major] AFAICT, the compression specified in rfc8138 doesn't include the > RPI option type...but the use of the 6LoRH Type 5 implies the RPI. If I > got that right, then how would the decompressing node know which RPI type > was in use when first compressed? Given that both types may be used in a > network (=C2=A73.1), how would one know unless the 6LoRH type was also ch= anged? > Or are you suggesting that the decompression should always use 0x23? In > any case, I think that stronger language might be needed. > [auhtors] Yes, we are suggesting that if the network is in 0x23 mode (by DIO option), then it should be decompressed to 0x23. RPI-6LoRH header provides a compressed form for the RPL RPI in section 6. A node that is decompressing this header MUST decompress using the RPL RPI option type that is currently active: that is, a choice between 0x23 (new) and 0x63 (old). The node will know which to use based upon the presence of the DODAG Configuration Option described in the next section. > > > 288 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG > 289 Configuration Option Flag. > > 291 In order to avoid a flag day caused by lack of interoperation betwe= en > 292 new RPI (0x23) and old RPI (0x63) nodes, when there is a mix of new > 293 nodes and old nodes, the new nodes may be put into a compatibility > 294 mode until all of the old nodes are replaced or upgraded. > > 296 This can be done via a DODAG Configuration Option flag which will > 297 propogate through the network. Failure to receive this information > 298 will cause new nodes to remain in compatibility mode, and originate > 299 traffic with the old-RPI (0x63) value. > > s/propogate/propagate > > [major] "compatibility mode" > What is "compatibility mode"? Initially I thought that it was maybe the > ability of new nodes to use both RPI values...but the end of the second > paragraph suggests using only 0x63. > > The text suggests that "compatibility mode" can be enabled via "via a > DODAG Configuration Option flag" -- that flag is not defined anywhere...b= ut > "failure to receive this information will cause new nodes to remain in > compatibility mode". So...would it be enabled using a flag, or is it the > default? > > Why wouldn't the default be the new RPI? I can see how most of the > networks will support the old RPI, but that will eventually be the > exception... > [authors]rewritten to In order to avoid a Flag Day caused by lack of interoperation between new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag in the DIO Configuration Option, to indicate when then new RPI value can be safely used. Without this, there could be a mix of new nodes (which understand 0x23 and 0x63), and old nodes (which understand 0x63 only). A new node would not know if it was safe to use 0x23. This is done via a DODAG Configuration Option flag which will propagate through the network. If the flag is received with a value zero (which is the default), then new nodes will remain in RFC6553 Compatible Mode; originating traffic with the old-RPI (0x63) value. > > 301 As stated in [RFC6550] the DODAG Configuration option is present in > 302 DIO messages. The DODAG Configuration option distributes > 303 configuration information. It is generally static, and does not > 304 change within the DODAG. This information is configured at the DOD= AG > 305 root and distributed throughout the DODAG with the DODAG > 306 Configuration option. Nodes other than the DODAG root do not modif= y > 307 this information when propagating the DODAG Configuration option. > > 309 The DODAG Configuration Option has a Flags field which is modified = by > 310 this document. Currently, the DODAG Configuration Option in > 311 [RFC6550] is as follows. . > > 313 Flags: The 4-bits remaining unused in the Flags field are reserved > 314 for flags. The field MUST be initialized to zero by the sender and > 315 MUST be ignored by the receiver. > > 317 0 1 2 3 > 318 +-----------------+--------------------------------------------------= -+ > 319 | Type =3D 0x04 | Opt Length =3D 14| Flags | A | PCS| DIOIntDou= bl. | > 320 +--------------------------------------------------------------------= -+ > 321 | DIOIntMin. | DIORedund. | MaxRankIncrease = | > 322 +-----------------+--------------------------------------------------= -+ > 323 | MinHopRankIncrease | OCP = | > 324 +-----------------+--------------------------------------------------= -+ > 325 |Reserved | Def. Lifetime | Lifetime Unit = | > 326 +-----------------+-----------------+--------------------------------= -+ > > 328 Figure 3: DODAG Configuration Option. > > [minor] Suggestion: instead of copying (and not quoting the Normative > language) the text from rfc6550 above, just indicate what the Update is: > "the unused bits MUST...". Also, I think that Figure 3 is not needed. > [authors]fixed. > > > ... > 342 In case of rebooting, the node does not remember the flag. Thus, t= he > 343 DIO is sent with flag indicating the new RPI value. > > [minor] By "the node", which node are you referring to? The root? If it > doesn't remember, it means that it needs to be configured -- how does tha= t > happen? Why isn't the configuration persistent at the root? > [authors]fixed. 6LN or 6LR added. > > 345 4. Sample/reference topology > > 347 A RPL network in general is composed of a 6LBR (6LoWPAN Border > 348 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN > 349 (6LoWPAN Node) as leaf logically organized in a DODAG structure. > 350 (Destination Oriented Directed Acyclic Graph). > > [minor] The 6BBR doesn't appear in the Figure. > [authors] clarification added > > [nit] BTW, it might be better to put the topology diagram right after thi= s > first paragraph. > [authors] done > > [nit] The DODAG expansion should be on first use. > [authors] done > > 352 RPL defines the RPL Control messages (control plane), a new ICMPv6 > 353 [RFC4443] message with Type 155. DIS (DODAG Information > 354 Solicitation), DIO (DODAG Information Object) and DAO (Destination > 355 Advertisement Object) messages are all RPL Control messages but wit= h > 356 different Code values. A RPL Stack is showed in Figure 5. > > [minor] Not exactly sure what this paragraph has to do with the reference > topology (yet), but (same comment as above) it might be good to put the > figure right after the text. > > s/showed/shown > [authors] done > > > ... > 428 Figure 6: A reference RPL Topology. > > 430 Figure 2 shows the reference RPL Topology for this document. The > 431 letters above the nodes are there so that they may be referenced in > 432 subsequent sections. In the figure, 6LR represents a full router > 433 node. The 6LN is a RPL aware router, or host. > > s/Figure 2/Figure 6 > [authors] done > > [minor] The 6LN is defined in the first paragraph as a node (not a > router). BTW, what is the difference between a "full router" and (just) = a > "router" (6LR vs 6LN)? > [authors] follows rfc 6775: "6LoWPAN Node (6LN): A 6LoWPAN node is any host or router participating in a LoWPAN. This term is used when referring to situations in which either a host or router can play the role described. 6LoWPAN Router (6LR): An intermediate router in the LoWPAN that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs) as well as forward and route IPv6 packets. 6LoWPAN routers are present only in route-over topologies." In our document a 6LN represents a leaf, following the behaviour of https://tools.ietf.org/html/rfc6550#section-8.5 > > [minor] 6LN is characterized above as "RPL aware", but (below) the "Raf" > mark is also used for that -- so it seems that "~Raf 6LN" would be a > "not-RPL aware leaf...RPL aware router, or host". > > Some terminology clean up is needed. > [authors] we added clarifications in the terminology section. referring rfc6775 > > 435 But, the 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I= ) > 436 are RPL nodes with no children hosts. > > [minor] Is there a relevance to the "children hosts" existing? Can it be > concluded that ~Raf nodes have children hosts? > [authors] It could be that a ~Raf have children hosts, but they are not part of the RPL domain and no packets are going to be delivered to them, but for the ~Raf. > > > ... > 446 5. Use cases > ... > 507 This means that when the no-drop RPI option code 0x23 is used, a > 508 packet that leaves the RPL domain of an LLN (or that leaves the LLN > 509 entirely) will not be discarded when it contains the [RFC6553] RPL > 510 Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option MA= Y > 511 be left in place even if the end host does not understand it. > > [minor] If the last RPL-aware node knows that the host doesn't understand > the RPI, why would it not remove it (if it can)? IOW, I understand how i= t > causes no harm (leading to the optional behavior above), but just because > it can be done doesn't mean that it should. Are there cases where it can > be used for something? > [authors] we understand that the RPI is useful only in the RPL domain, not outside of it. > > If the RPI can't be removed because the border is not the destination, > then the MAY above is insignificant: no one can strip it, so there's no > real option. > [authors] fixed. > > 513 NOTE: There is some possible security risk when the RPI information > 514 is released to the Internet. At this point this is a theoretical > 515 situation; no clear attack has been described. At worst, it is cle= ar > 516 that the RPI option would waste some network bandwidth when it > 517 escapes. This is traded off against the savings in the LLN by not > 518 having to encapsulate the packet in order to remove the artifact. > > [major] AFAICT, leaking the RPI means leaking the RPLInstanceID and the > SenderRank. The Security Considerations already mentions what an attacke= r > could do if it knows the RPLInstanceID...but it doesn't say anything abou= t > the SenderRank. > > I'm thinking that the SenderRank may help an attacker to have an idea of > the topology of the LLN, right? I don't know what an attacker can do wit= h > that information, but the fact that could be used for that (and it could = be > a privacy issue) should be mentioned in the Security Considerations secti= on. > [authors] paragraph added. > > ... > 526 A corollory is that an SHR3 or RPI Option can only be removed by an > 527 intermediate router if it is placed in an encapsulating IPv6 Header= , > 528 which is addressed TO the intermediate router. When it does so, th= e > 529 whole encapsulating header must be removed. (A replacement may be > 530 added). This sometimes can result in outer IP headers being > 531 addressed to the next hop router using link-local addresses. > > s/corollory/corollary > [authors]fixed. > > > ... > 541 RPI should be present in every single RPL data packet. There is on= e > 542 exception in non-storing mode: when a packet is going down from the > 543 root. In a downward non-storing mode, the entire route is written, > 544 so there can be no loops by construction, nor any confusion about > 545 which forwarding table to use (as the root has already made all > 546 routing decisions). However, there are still cases, such as in > 547 6tisch, where the instanceID portion of the RPI header may still be > 548 needed to pick an appropriate priority or channel at each hop. > > [major] So...does that mean: in all cases, except downward non-storing > mode if 6tisch is not used, the RPI SHOULD be present? Note that some of > the examples in =C2=A77 actually say that the RPI is optional... > [authors]: Yes, the RPI is optional in non-storing going downwards. The paragraph is updated as follows: " RPI MUST [[NOTE: we increase this to MUST??]] be present in every single RPL data packet. There is one exception in non-storing mode: when a packet is going down from the root the RPI MAY be omitted. The rational is that in a downward non-storing mode, the entire route is written, so there can be no loops by construction, nor any confusion about which forwarding table to use (as the root has already made all routing decisions). However, there are still cases, such as in 6tisch, where the instanceID portion of the RPI header may still be needed [6tisch-minimal draft] to pick an appropriate priority or channel at each hop. > > 550 In the tables present in this document, the term "RPL aware leaf" i= s > 551 has been shortened to "Raf", and "not-RPL aware leaf" has been > 552 shortened to "~Raf" to make the table fit in available space. > > s/is has been/has been > > [nit] There's some repetition; Raf, for example, was already introduced > earlier in this section. > [authros]fixed. It is mentioned in the terminology section > > ... > 557 6. Storing mode > > 559 In storing mode (fully stateful), the sender can determine if the > 560 destination is inside the LLN by looking if the destination address > 561 is matched by the DIO's PIO option. > > [nit] Please expand PIO... > [authors]fixed. > > 563 The following table itemizes which headers are needed in the > 564 following scenarios, and indicates if the IP-in-IP header must be > 565 inserted on a hop-by-hop basis, or when it can target the destinati= on > 566 node directly. There are these possible situations: hop-by-hop > 567 necessary (indicated by "hop"), or destination address possible > 568 (indicated by "dst"). In all cases hop by hop MAY be used. > > [major] Should there be something else Normative in this paragraph? Mayb= e > a MUST to indicate the need for "hop", as in "the IP-in-IP header MUST be > inserted on a hop-by-hop basis"? > [authors]fixed. > > [minor] I'm confused by the nomenclature. The description above seems to > indicate that "hop" and "dst" are mutually exclusive...but the table show= s > a column with a title using "dst" and specific rows containing "hop". Wh= at > does that mean? > [authors]fixed. the nomenclature changed to target and clarification added. The following table itemizes which headers are needed in each of the following scenarios. It indicate if an IPv6-in-IPv6 header MUST be inserted, and whether the destination address of the IPv6-in-IPv6 header is the next hop, or the final target address. There are these possible situations: hop-by-hop necessary (indicated by "hop"), or final target address possible (indicated by "tgt"). In all cases hop by hop MAY be used rather than the final target address. > > 570 In cases where no IP-in-IP header is needed, the column is left > 571 blank. > > [minor] In Figure 7, there are "blank" columns (containing "--"), but > there are also entries that say "No". Are they meant to indicate the sam= e > thing? > [authors]Yes, fixed. > > 573 In all cases the RPI headers are needed, since it identifies > 574 inconsistencies (loops) in the routing topology. In all cases the > 575 RH3 is not needed because we do not indicate the route in storing > 576 mode. > > 578 In each case, 6LR_i are the intermediate routers from source to > 579 destination. "1 <=3D i >=3D n", n is the number of routers (6LR) t= hat > 580 the packet go through from source (6LN) to destination. > > 582 The leaf can be a router 6LR or a host, both indicated as 6LN (see > 583 Figure 6). > > 585 +---------------------+--------------+----------+--------------+ > 586 | Interaction between | Use Case | IP-in-IP | IP-in-IP dst | > 587 +---------------------+--------------+----------+--------------+ > 588 | | Raf to root | No | -- | > 589 + +--------------+----------+--------------+ > 590 | Leaf - Root | root to Raf | No | -- | > 591 + +--------------+----------+--------------+ > 592 | | root to ~Raf | No | -- | > 593 + +--------------+----------+--------------+ > 594 | | ~Raf to root | Yes | root | > 595 +---------------------+--------------+----------+--------------+ > 596 | | Raf to Int | No | -- | > 597 + +--------------+----------+--------------+ > 598 | Leaf - Internet | Int to Raf | Yes | Raf | > 599 + +--------------+----------+--------------+ > 600 | | ~Raf to Int | Yes | root | > 601 + +--------------+----------+--------------+ > 602 | | Int to ~Raf | Yes | hop | > 603 +---------------------+--------------+----------+--------------+ > 604 | | Raf to Raf | No | -- | > 605 + +--------------+----------+--------------+ > 606 | | Raf to ~Raf | No | -- | > 607 + Leaf - Leaf +--------------+----------+--------------+ > 608 | | ~Raf to Raf | Yes | dst | > 609 + +--------------+----------+--------------+ > 610 | | ~Raf to ~Raf | Yes | hop | > 611 +---------------------+--------------+----------+--------------+ > > 613 Figure 7: IP-in-IP encapsulation in Storing mode. > > ... > 726 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root > > 728 In this case the flow comprises: > > 730 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) > > 732 For example, a communication flow could be: Node G --> Node E --> > 733 Node B --> Node A root(6LBR) > > 735 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), > 736 the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6 > 737 header. The IPv6-in-IPv6 header can be addressed to the next hop > 738 (Node B), or to the root (Node A). The root removes the header and > 739 processes the packet. > > [minor] The table below doesn't reflect the case where the IPv6-in-IPv6 > header is addressed to the next hop. > [authors] fixed. > > 741 +------------+------+---------------+---------------+--------------= -+ > 742 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR = | > 743 +------------+------+---------------+---------------+--------------= -+ > 744 | Inserted | -- | IP-in-IP(RPI) | -- | -- = | > 745 | headers | | | | = | > 746 | Removed | -- | -- | -- | IP-in-IP(RPI)= | > 747 | headers | | | | = | > 748 | Re-added | -- | -- | -- | -- = | > 749 | headers | | | | = | > 750 | Modified | -- | -- | IP-in-IP(RPI) | -- = | > 751 | headers | | | | = | > 752 | Untouched | -- | -- | -- | -- = | > 753 | headers | | | | = | > 754 +------------+------+---------------+---------------+--------------= -+ > > 756 Storing: Summary of the use of headers from not-RPL-aware-leaf to > 757 root > > ... > 772 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet > > 774 RPL information from RFC 6553 MAY go out to Internet as it will be > 775 ignored by nodes which have not been configured to be RPI aware. > > [major] The "MAY" (Normative) is out of place as the sentence above is > stating a fact, not specifying a behavior. s/MAY/may > [authors] fixed. > > ... > 835 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet > > 837 In this case the flow comprises: > > 839 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> > 840 Internet > > 842 For example, a communication flow could be: Node G --> Node E --> > 843 Node B --> Node A root(6LBR) --> Internet > > 845 The 6LR_1 (i=3D1) node will add an IP-in-IP(RPI) header addressed > 846 either to the root, or hop-by-hop such that the root can remove the > 847 RPI header before passing upwards. The IP-in-IP addressed to the > 848 root cause less processing overhead. On the other hand, with hop-b= y- > 849 hop the intermediate routers can check the routing tables for a > 850 better routing path, thus it could be more efficient and faster. > 851 Implementation should decide wich approach to take. > > s/wich/which > > [minor] The hop-by-hop option is not reflected in the table. > [authors] fixed. > > > 853 The originating node will ideally leave the IPv6 flow label as zero > 854 so that the packet can be better compressed through the LLN. The > 855 6LBR will set the flow label of the packet to a non-zero value when > 856 sending to the Internet. > > 858 +---------+-----+-------------+-------------+-------------+--------= -+ > 859 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne= | > 860 | | 6 | | [i=3D2,..,n]_ | | t = | > 861 +---------+-----+-------------+-------------+-------------+--------= -+ > 862 | Inserte | -- | IP-in- | -- | -- | -- = | > 863 | d | | IP(RPI) | | | = | > 864 | headers | | | | | = | > 865 | Removed | -- | -- | -- | IP-in- | -- = | > 866 | headers | | | | IP(RPI) | = | > 867 | Re- | -- | -- | -- | -- | -- = | > 868 | added | | | | | = | > 869 | headers | | | | | = | > 870 | Modifie | -- | -- | IP-in- | -- | -- = | > 871 | d | | | IP(RPI) | | = | > 872 | headers | | | | | = | > 873 | Untouch | -- | -- | -- | -- | -- = | > 874 | ed | | | | | = | > 875 | headers | | | | | = | > 876 +---------+-----+-------------+-------------+-------------+--------= -+ > > 878 Storing: Summary of the use of headers from not-RPL-aware-leaf to > 879 Internet > > 881 6.2.4. SM: Example of Flow from Internet to non-RPL-aware-leaf > > 883 In this case the flow comprises: > > 885 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) > > 887 For example, a communication flow could be: Internet --> Node A > 888 root(6LBR) --> Node B --> Node E --> Node G > > 890 The 6LBR will have to add an RPI header within an IP-in-IP header. > 891 The IP-in-IP is addressed to the not-RPL-aware-leaf, leaving the RP= I > 892 inside. > > [minor] The table below seems to be missing the not-RPL-aware-leaf > removing the IP-in-IP header. > [authors] fixed. > > 894 Note that there is a requirement that the final node be able to > 895 remove one or more IP-in-IP headers which are all addressed to it, > 896 mentioned in [I-D.thubert-roll-unaware-leaves] : > > 898 "RPL data packets are often encapsulated using IP in IP. The 6LN > 899 MUST be able to decapsulate a packet when it is the destination of > 900 the outer header and process correctly the inner header." > > [major] I realize that we're not reviewing I-D.thubert-roll-unaware-leave= s > at this point, but how can a requirement be placed on a not-RPL-aware-lea= f > if, by definition, it is not aware of RPL?? ...and I don't think we can > assume it is aware of any other requirement... > [authors] We understand that the requirements are placed on the 6LR that accepts the 6LN registration and also inject the relevant routing information on its behalf. > > If this document depends on the requirement in > I-D.thubert-roll-unaware-leaves, then the reference should be Normative (= it > is now listed as Informative). > [authors]fixed > > ... > 935 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf > ... > 959 It is assume that the two nodes are in the same RPL Domain (that th= ey > 960 share the same DODAG root). At the common parent (Node B), the > 961 direction of RPI is changed (from increasing to decreasing the rank= ). > > s/assume/assumed > [authors]fixed > > > ... > 1079 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware= - > 1080 leaf > ... > 1102 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Nod= e > 1103 G) and inserts the RPI header (RPIa), encapsulated in an > IPv6-in-IPv6 > 1104 header. The IPv6-in-IPv6 header is addressed to the final > 1105 destination. > > [minor] As in 6.2.4, which node removes the IP-in-IP header? For > completion, it seems like the table is missing the fact that the "IPv6 ds= t" > node ignores the RPI. > [authors]fixed. The not-RPL-aware leaf which is the destination removes the IP-in-IP > > 1107 > +----------+-----+-------------+--------------+--------------+------+ > 1108 | Header | IPv | 6LR_1 | 6LR_ia | 6LR_m | IPv= 6 > | > 1109 | | 6 | | | | dst > | > 1110 | | src | | | | > | > 1111 > +----------+-----+-------------+--------------+--------------+------+ > 1112 | Inserted | -- | IP-in- | -- | -- | -- > | > 1113 | headers | | IP(RPI) | | | > | > 1114 | Removed | -- | -- | -- | -- | -- > | > 1115 | headers | | | | | > | > 1116 | Re-added | -- | -- | -- | -- | -- > | > 1117 | headers | | | | | > | > 1118 | Modified | -- | -- | IP-in- | IP-in- | -- > | > 1119 | headers | | | IP(RPI) | IP(RPI) | > | > 1120 | Untouche | -- | -- | -- | -- | -- > | > 1121 | d | | | | | > | > 1122 | headers | | | | | > | > 1123 > +----------+-----+-------------+--------------+--------------+------+ > > 1125 Storing: Summary of the use of headers from not-RPL-aware-leaf t= o > 1126 non-RPL-aware-leaf > > 1128 7. Non Storing mode > ... > 1147 +-----------------+--------------+-----+-----+----------+---------= -+ > 1148 | Interaction | Use Case | RPI | RH3 | IP-in-IP | IP-in-IP= | > 1149 | between | | | | | dst = | > 1150 +-----------------+--------------+-----+-----+----------+---------= -+ > 1151 | | Raf to root | Yes | No | No | -- = | > 1152 + +--------------+-----+-----+----------+---------= -+ > 1153 | Leaf - Root | root to Raf | Opt | Yes | No | -- = | > 1154 + +--------------+-----+-----+----------+---------= -+ > 1155 | | root to ~Raf |no(1)| Yes | Yes | 6LR = | > 1156 + +--------------+-----+-----+----------+---------= -+ > 1157 | | ~Raf to root | Yes | No | Yes | root = | > 1158 +-----------------+--------------+-----+-----+----------+---------= -+ > 1159 | | Raf to Int | Yes | No | Yes | root = | > 1160 + +--------------+-----+-----+----------+---------= -+ > 1161 | Leaf - Internet | Int to Raf |no(1)| Yes | Yes | dst = | > 1162 + +--------------+-----+-----+----------+---------= -+ > 1163 | | ~Raf to Int | Yes | No | Yes | root = | > 1164 + +--------------+-----+-----+----------+---------= -+ > 1165 | | Int to ~Raf |no(1)| Yes | Yes | 6LR = | > 1166 +-----------------+--------------+-----+-----+----------+---------= -+ > 1167 | | Raf to Raf | Yes | Yes | Yes | root/dst= | > 1168 + +--------------+-----+-----+----------+---------= -+ > 1169 | | Raf to ~Raf | Yes | Yes | Yes | root/6LR= | > 1170 + Leaf - Leaf +--------------+-----+-----+----------+---------= -+ > 1171 | | ~Raf to Raf | Yes | Yes | Yes | root/6LN= | > 1172 + +--------------+-----+-----+----------+---------= -+ > 1173 | | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR= | > 1174 +-----------------+--------------+-----+-----+----------+---------= -+ > > 1176 (1)-6tisch networks may need the RPI information. > > [major] When? What are the conditions when it is needed? > [authors] fixed. The leaf can be a router 6LR or a host, both indicated as 6LN (Figure 3). In the Figure they (1) indicates a 6tisch case , where the instanceID portion of the RPI header may still be needed to pick an appropriate priority or channel at each hop. > > 1178 Figure 8: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP > 1179 encapsulation. > ... > 1194 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root > > 1196 In non-storing mode the leaf node uses default routing to send > 1197 traffic to the root. The RPI header must be included to > avoid/detect > 1198 loops. > > [major] Should that "must" be Normative? > [authors] fixed. > > ... > 1224 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf > ... > 1236 The 6LBR will insert an RH3, and may optionally insert an RPI > header. > > [major] Under which conditions should the RPI header be inserted? Or is > it the case where it is not necessary, but it causes no harm if it's > there? Are there benefits? It would be nice to be precise in the > specification to achieve consistent behavior. > [authors]rewritten. > > ... > 1254 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf > ... > 1267 In 6LBR the RH3 is added, it is modified at each intermediate 6LR > 1268 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n)= , > 1269 but left there. If RPI is left present, the IPv6 node which does > not > 1270 understand it will ignore it (following RFC8200), thus encapsulati= on > 1271 is not necesary. Due the complete knowledge of the topology at th= e > 1272 root, the 6LBR may optionally address the IP-in-IP header to the > last > 1273 6LR, such that it is removed prior to the IPv6 node. > > s/necesary/necessary > > [major] So...encapsulation is not needed, but an IP-in-IP header is > optional. When? Are there advantages, disadvantages? Same questions > about the RPI. > [authors]rewritten. > > 1275 > +---------------+-------------+---------------+--------------+------+ > 1276 | Header | 6LBR | 6LR_i(i=3D1) | 6LR_n(i=3Dn) |= IPv6 > | > 1277 > +---------------+-------------+---------------+--------------+------+ > 1278 | Inserted | (opt: RPI), | -- | -- | -- > | > 1279 | headers | RH3 | | | > | > 1280 | Removed | -- | RH3 | -- | -- > | > 1281 | headers | | | | > | > 1282 | Re-added | -- | -- | -- | -- > | > 1283 | headers | | | | > | > 1284 | Modified | -- | (opt: RPI), | (opt: RPI), | -- > | > 1285 | headers | | RH3 | RH3 | > | > 1286 | Untouched | -- | -- | -- | RPI > | > 1287 | headers | | | | > | > 1288 > +---------------+-------------+---------------+--------------+------+ > > [minor] In this case, the destination node would also leave the RH3 heade= r > untouched, right? > [authors]table fixed. the RH3 is consumed by the 6LRn > > 1290 Non Storing: Summary of the use of headers from root to not-RPL- > 1291 aware-leaf > > [minor] This table (and several others) have no name/number. > [authors]table fixed. > > ... > 1375 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf > ... > 1393 The RPI may be added or not as required by networks such as 6tisch= . > > [major] When would that be? Is there a reference? > [authors] removed. > > 1394 The RPI is unnecessary for loop detection. > > [major] Yet the Table shows it...when would it be used, why, etc.? > [authors] fixed. > > 1396 > +----------+---------+--------------+---------------+---------------+ > 1397 | Header | Interne | 6LBR | 6LR_i | 6LN > | > 1398 | | t | | | > | > 1399 > +----------+---------+--------------+---------------+---------------+ > 1400 | Inserted | -- | IP-in-IP (RH | -- | -- > | > 1401 | headers | | 3,opt:RPI) | | > | > 1402 | Removed | -- | -- | -- | IP-in-IP > | > 1403 | headers | | | | (RH3,opt:RPI= ) > | > 1404 | Re-added | -- | -- | -- | -- > | > 1405 | headers | | | | > | > 1406 | Modified | -- | -- | IP-in-IP | -- > | > 1407 | headers | | | (RH3,opt:RPI) | > | > 1408 | Untouche | -- | -- | -- | -- > | > 1409 | d | | | | > | > 1410 | headers | | | | > | > 1411 > +----------+---------+--------------+---------------+---------------+ > > 1413 Non Storing: Summary of the use of headers from Internet to RPL- > 1414 aware-leaf > > ... > 1566 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware= - > 1567 leaf > ... > 1583 As in the previous case, the 6LN will insert an RPI (RPI_1) header > 1584 which MUST be in an IP-in-IP header addressed to the root so that > the > 1585 6LBR can remove this RPI. The 6LBR will then insert an RH3 inside= a > 1586 new IP-in-IP header addressed to the 6LN destination node. The RP= I > 1587 is optional from 6LBR to 6LR_id (RPI_2). > > [minor] The text says that the "new IP-in-IP header [is] addressed to the > 6LN destination node", but the Table below shows the 6LR_id removing it. > [authors] fixed. > > 1589 > +-----------+----------+----------+------------+------------+-------+ > 1590 | Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 > | > 1591 > +-----------+----------+----------+------------+------------+-------+ > 1592 | Inserted | IP-in-IP | -- | IP-in-IP | -- | -- > | > 1593 | headers | (RPI1) | | (RH3, opt | | > | > 1594 | | | | RPI_2) | | > | > 1595 | Removed | -- | -- | IP-in-IP | IP-in-IP | -- > | > 1596 | headers | | | (RPI_1) | (RH3, opt | > | > 1597 | | | | | RPI_2) | > | > 1598 | Re-added | -- | -- | -- | -- | -- > | > 1599 | headers | | | | | > | > 1600 | Modified | -- | IP-in-IP | -- | IP-in-IP | -- > | > 1601 | headers | | (RPI_1) | | (RH3, opt | > | > 1602 | | | | | RPI_2) | > | > 1603 | Untouched | -- | -- | -- | -- | opt > | > 1604 | headers | | | | | RPI_= 2 > | > 1605 > +-----------+----------+----------+------------+------------+-------+ > > 1607 Non Storing: Summary of the use of headers from RPL-aware-leaf t= o > 1608 not-RPL-aware-leaf > > ... > 1654 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- > 1655 aware-leaf > ... > 1674 > +------------+-------+-----------+------------+-------------+-------+ > 1675 | Header | IPv6 | 6LR_1 | 6LBR | 6LR_id | IPv6 > | > 1676 | | src | | | | dst > | > 1677 > +------------+-------+-----------+------------+-------------+-------+ > 1678 | Inserted | -- | IP-in-IP | IP-in-IP | -- | -- > | > 1679 | headers | | (RPI_1) | (RH3) | | > | > 1680 | Removed | -- | -- | IP-in-IP | IP-in-IP | -- > | > 1681 | headers | | | (RPI_1) | (RH3, opt | > | > 1682 | | | | | RPI_2) | > | > 1683 | Re-added | -- | -- | -- | -- | -- > | > 1684 | headers | | | | | > | > 1685 | Modified | -- | -- | -- | -- | -- > | > 1686 | headers | | | | | > | > 1687 | Untouched | -- | -- | -- | -- | -- > | > 1688 | headers | | | | | > | > 1689 > +------------+-------+-----------+------------+-------------+-------+ > > [minor] The optional RPI_2 is not indicated in the 6LBR column. > [authors] fixed. > > > ... > 1696 8.1. Storing mode > ... > 1705 Thanks to the change of the RPI option type from 0x63 to 0x23, the= re > 1706 is no longer any uncertainty about when to use an IP-in-IP header = in > 1707 the storing mode. A Hop-by-Hop Options Header containing the RPI > 1708 option SHOULD always be added when 6LRs originate packets (without > 1709 IP-in-IP headers), and IP-in-IP headers should always be added > 1710 (addressed to the root when on the way up, to the end-host when on > 1711 the way down) when a 6LR find that it needs to insert a Hop-by-Hop > 1712 Options Header containing the RPI option. > > [major] This paragraph starts by saying that "there is no longer any > uncertainty about when to use an IP-in-IP header". However, the > specification is a "SHOULD", which means that there are cases when the > action may not be performed. It sounds like a contradiction to me. In a= ny > case, what are the cases that make it a "SHOULD" and not a "MUST"? > [authors]rewritten. The change of RPI option type from 0x63 to 0x23, makes all Section 4.2 compliant nodes tolerant of the RP= L artifacts. There is therefore no longer a necessity to remove the artifacts when sending traffic to the Internet. This change clarifies when to use an IPv6-in-IPv6 header, and how to address them: The Hop-by-Hop Options Header containing the RPI option SHOULD always be added when 6LRs originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers SHOULD always be added when a 6LR find that it needs to insert a Hop-by-Hop Options Header containing the RPI option. The IPv6-in-IPv6 header is to be addressed to the RPL root when on the way up, and to the end-host when on the way down. > > [major] Should this text include a "SHOULD" as well: "and IP-in-IP header= s > should always be added..."? > [authors]It=E2=80=99s SHOULD so that non-LLN uses of RPL can change this. > > ... > 1731 9. 6LoRH Compression cases > > 1733 The [RFC8138] proposes a compression method for RPI, RH3 and > IPv6-in- > 1734 IPv6. > > 1736 In Storing Mode, for the examples of Flow from RPL-aware-leaf to > non- > 1737 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf compri= se > 1738 an IP-in-IP and RPI compression headers. The type of this case is > 1739 critical since IP-in-IP is encapsulating a RPI header. > > 1741 > +--+-----+---+--------------+-----------+-------------+-------------+ > 1742 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPH= C > | > 1743 > +--+-----+---+--------------+-----------+-------------+-------------+ > > 1745 Figure 9: Critical IP-in-IP (RPI). > > [major] Shouldn't this section also be an Update to rfc8138? > > [major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it is > introduced as Critical here. The header must then be completely specifie= d > in this document and the appropriate registry must be updated (in the IAN= A > Consideration section). > > Specifically...referring to rfc8138... > - the meaning of the TSE depends on the Type (=C2=A74.2), > - the Hop Limit is defined in =C2=A77, should it have the same > behavior/meaning here? > - does the "RPI - 6LoRH" field correspond to the RPI-6LoRH header > (=C2=A76.3)? > - I'm assuming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC > (rfc6282). > [authors] we think that the confusion is because we wrote: =E2=80=9CThe typ= e of this case=E2=80=9D... which sounds like we are changing 8138, when what we mean is that use of this elective type is a MUST for RPL. Type 6 (compressed RPI) is elective in 8138 because non-RPL uses of 6lowpan do not need to support (compressed) RPI headers, but this document makes it a MUST because RPL uses of 6lowpan need it. Is there text that we need to update? > > ... > 1774 11. Security Considerations > > 1776 The security considerations covering of [RFC6553] and [RFC6554] > apply > 1777 when the packets get into RPL Domain. > > s/covering of/covered in > > [minor] Do you mean "are in the RPL Domain" instead of "get into" it? Or > are you talking about when a packet comes into the domain from a > non-RPL-aware node (like a non-RPL-aware-leaf)? I ask because it seems t= o > me that those RFCs only talk about packets that are inside the domain (an= d > not about them getting in). > [authors] fixed. > > 1779 The IPIP mechanism described in this document is much more limited > 1780 than the general mechanism described in [RFC2473]. The willingnes= s > 1781 of each node in the LLN to decapsulate packets and forward them > could > 1782 be exploited by nodes to disguise the origin of an attack. > > 1784 Nodes outside of the LLN will need to pass IPIP traffic through th= e > 1785 RPL root to perform this attack. To counter, the RPL root SHOULD > 1786 either restrict ingress of IPIP packets (the simpler solution), or > it > 1787 SHOULD do a deep packet inspection wherein it walks the IP header > 1788 extension chain until it can inspect the upper-layer-payload as > 1789 described in [RFC7045]. In particular, the RPL root SHOULD do BCP= 38 > 1790 ([RFC2827]) processing on the source addresses of all IP headers > that > 1791 it examines in both directions. > > [major] For all 3 SHOULDs above... Why are they not a MUST? IOW, when > (if countering) would the actions not be performed? Are there other > mechanisms that the root could consider? > [authors]We are being conservative in writing SHOULD, because it these mechanism are not externally visible, an implementer could do something different (better? Faster? cheaper?) if it had the same effect. For instance, an upstream firewall could do the BCP38 filtering or IPIP filtering. Deep Packet Inspection i= s distasteful, but only necessary if there is a need to accept some IPIP headers. > > 1793 Note: there are some situations where a prefix will spread across > 1794 multiple LLNs via mechanisms such as described in > 1795 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering > 1796 needs to take this into account. > > s/such as described/such as the one described > > [major] The text above sounds like the root needs to get some type of > routing information from the other LLN, is that true? What are the > security implications of that? > > I took a very quick look at I-D.ietf-6lo-backbone-router and it seems to > me that there are probably other considerations to be included related to > that mechanism in the context of this document. Given the "in passing" > nature of the note above, and the fact that I-D.ietf-6lo-backbone-router = is > still in process in 6lo, I suggest you take the text/reference out. > [authors]Discussion on the list. > > 1798 Nodes with the LLN can use the IPIP mechanism to mount an attack o= n > 1799 another part of the LLN, while disguising the origin of the attack= . > 1800 The mechanism can even be abused to make it appear that the attack > is > 1801 coming from outside the LLN, and unless countered, this could be > used > 1802 to mount a Distributed Denial Of Service attack upon nodes elsewhe= re > 1803 in the Internet. See [DDOS-KREBS] for an example of such attacks > 1804 already seen in the real world. > > s/Nodes with the LLN/Nodes within the LLN > > [major] Is there any possible mitigation to this inside-the-LLN attack? > It seems to me that this issue is not something introduced by this > document, right? Would authentication help -- is it even possible? Is > there a discussion of this in the main spec? > [authors]Discussion on the list. > > 1806 While a typical LLN may be a very poor origin for attack traffic (= as > 1807 the networks tend to be very slow, and the nodes often have very l= ow > 1808 duty cycles) given enough nodes, they could still have a significa= nt > 1809 impact, particularly if the attack was on another LLN! > Additionally, > 1810 some uses of RPL involve large backbone ISP scale equipment > 1811 [I-D.ietf-anima-autonomic-control-plane], which may be equipped wi= th > 1812 multiple 100Gb/s interfaces. > > [nit] Suggestion: reorder the paragraphs so that the discussion of the > internal threats starts in the third paragraph. It should improve > readability and may avoid some repetition. > [authors]fixed. > > 1814 Blocking or careful filtering of IPIP traffic entering the LLN as > 1815 described above will make sure that any attack that is mounted mus= t > 1816 originate compromised nodes within the LLN. The use of BCP38 > 1817 filtering at the RPL root on egress traffic will both alert the > 1818 operator to the existence of the attack, as well as drop the attac= k > 1819 traffic. As the RPL network is typically numbered from a single > 1820 prefix, which is itself assigned by RPL, BCP38 filtering involves = a > 1821 single prefix comparison and should be trivial to automatically > 1822 configure. > > s/originate compromised/originate from compromised > > [major] Yes, BCP38 will stop an attack, but only if the source addresses > are spoofed. What if they're not? Given that the attack may be hidden, > and assuming that nodes are compromised across multiple LLNs, an attacker > may not care enough to spoof the origins. > [authors]To be disscussed on list > > 1824 There are some scenarios where IPIP traffic SHOULD be allowed to > pass > 1825 through the RPL root, such as the IPIP mediated communications > 1826 between a new Pledge and the Join Registrar/Coordinator (JRC) when > 1827 using [I-D.ietf-anima-bootstrapping-keyinfra] and > 1828 [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for th= e > 1829 RPL root to do careful filtering: it occurs only when the Join > 1830 Coordinator is not co-located inside the RPL root. > > [major] Because of the "SHOULD", both references should be Normative. Th= e > second ID is Informational. Does that really need to be a "SHOULD"?? It > seems to me that "should" would be enough in this case. > [authors]fixed. > > [minor] I'm having trouble parsing the last sentence. What are you tryin= g > to suggest? > [authors] when an entity called Join coordinator is not included inside the root, the root should allow the IPIP traffic. > > 1832 With the above precautions, an attack using IPIP tunnels will be b= y > a > 1833 node within the LLN on another node within the LLN. Such an attac= k > 1834 could, of course, be done directly. An attack of this kind is > 1835 meaningful only if the source addresses are either fake or if the > 1836 point is to amplify return traffic. Such an attack, could also be > 1837 done without the use of IPIP headers using forged source addresses= . > > 1839 If the attack requires bi-directional communication, then IPIP > 1840 provides no advantages. > > 1842 [RFC2473] suggests that tunnel entry and exit points can be secure= d, > 1843 via the "Use IPsec". This solution has all the problems that > > [minor] "This solution"...which one? The rfc2473 suggestion or the one > described in this document? > [authors]rewritten > > 1844 [RFC5406] goes into. In an LLN such a solution would degenerate > into > 1845 every node having a tunnel with every other node. It would provid= e > a > 1846 small amount of origin address authentication at a very high cost; > 1847 doing BCP38 at every node (linking layer-3 addresses to layer-2 > 1848 addresses, and to already present layer-2 cryptographic mechanisms= ) > 1849 would be cheaper should RPL be run in an environment where hostile > 1850 nodes are likely to be a part of the LLN. > > 1852 The RH3 header usage described here can be abused in equivalent wa= ys > 1853 with an IPIP header to add the needed RH3 header. As such, the > 1854 attacker's RH3 header will not be seen by the network until it > 1855 reaches the end host, which will decapsulate it. An end-host SHOU= LD > 1856 be suspicious about a RH3 header which has additional hops which > have > 1857 not yet been processed, and SHOULD ignore such a second RH3 header= . > > [nit] Hmmm...it seems like these threats should have been identified in > rfc6554... > > [major] What does "SHOULD be suspicious" mean? How is that a Normative > behavior? Would being suspicious include dropping the packet or some oth= er > similar action? When would the router *not* be suspicious? Why is that > not a "MUST"? > [authors]The presence of the second RH3 means that there is a configuration mistake somewhere else in the network. It would be reasonable to incremen= t a counter in a MIB (if we had a MIB) when this occurs. Based upon the Postel doctrine, ignoring the extra header (not acting on it), is the best policy. An RH3 header was not completely consumed is discussed in RFC https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header wit= h additional =E2=80=9Cnon-zero Segments Left value, if the IPv6 Destination = Address is not on-link=E2=80=9D should be dropped. In this case, the RH3 header is = *inside* the outer IPv6-in-IPv6 header, which has then been forwarded. We think that this header should simply be ignored in processing the packet= . To do otherwise (such as forwarding) would permit external attackers to send traffic that appears to originate inside the LLN. To be discussed on list > > [major] When should a second RH3 header not be ignored? Why is "MUST" no= t > used? > [authors]Unsure of whether there are uses in the future for this kind of thing. > > 1859 In addition, the LLN will likely use [RFC8138] to compress the IPI= P > 1860 and RH3 headers. As such, the compressor at the RPL-root will see > 1861 the second RH3 header and MAY choose to discard the packet if the > RH3 > 1862 header has not been completely consumed. A consumed (inert) RH3 > > [major] It seems to me that the optional action of the root of discarding > the packet is is contradiction with the "SHOULD ignore such a second RH3 > header" above. Is the subtle difference that we're talking about the roo= t > here, and the end-host above? Why wouldn't the actions be the same if in > both cases the second RH3 header may indicate some type of attack, or at > least something anomalous?? > [authors] If the root ALWAYS discards such packets, then if someone comes u= p with a use for them, then they need to adjust two systems to make it work, creating a flag day situation for that new feature. By saying MAY, we ar= e suggesting that a knob is probably appropriate. > > 1863 header could be present in a packet that flows from one LLN, cross= es > 1864 the Internet, and enters another LLN. As per the discussion in th= is > 1865 document, such headers do not need to be removed. However, there = is > 1866 no case described in this document where an RH3 is inserted in a > non- > 1867 storing network on traffic that is leaving the LLN, but this > document > 1868 SHOULD NOT preclude such a future innovation. It should just be > 1869 noted that an incoming RH3 must be fully consumed, or very careful= ly > 1870 inspected. > > [major] The "SHOULD NOT" seems out of place as there is nothing Normative > in the statement. > [authors]fixed. > > [major] What does "very carefully inspected" mean? Are there actions > resulting from that? > [authors]Subject to extensive Access Control Lists, if permitted. > > 1872 The RPI header, if permitted to enter the LLN, could be used by an > 1873 attacker to change the priority of a packet by selecting a differe= nt > 1874 RPL instanceID, perhaps one with a higher energy cost, for instanc= e. > > s/RPL instanceID/RPLinstanceID > [authors]fixed. > > ... > 1911 13.1. Normative References > > [minor] I think that the following references can be made Informative: > RFC2473, RFC5406 > [authors]fixed. > > ... > 1965 13.2. Informative References > > [nit] I-D.ietf-6man-rfc6434-bis is not referenced in the text. > [authors]fixed. Many thanks again Alvaro!!! > > Datatracker URL: > https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > > --000000000000f5a7fa0580274d67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
Dear Alvaro,
<= br>
Many thanks for your review.

BIG Apo= logizes for the delay. Please find the answers in-line as [authors].
<= div>
Best regards,

Michael, Pascal, = Ines.

On Tue, Aug 14, 2018 at 10:11 PM IETF Secretariat <ietf-secretariat-reply@ietf.= org> wrote:
IESG state changed:

New State: AD Evaluation::Revised I-D Needed

(The previous state was AD Evaluation::AD Followup)

=3D=3D=3D AD Review of draft-ietf-roll-useofrplinfo-23 =3D=3D=3D


Dear authors:

I have (finally!) finished reading this document.=C2=A0 Thanks for all the = work and time put into working out all the details.

I have several concerns.=C2=A0 I'm listing some of the Major (and docum= ent-wide) ones up front.=C2=A0 I also put more comments and questions inlin= e below.

(1) [major] Where is the specification of the data-plane behavior?

This document does a couple of things: it Updates several other RFCs, and p= resents a list of *example* flows where the expected behavior is illustrate= d.=C2=A0 The Updates are mostly about the new RPI value (0x23), but not abo= ut the behavior of the nodes.

Most of the examples are worded such that they describe actions (encapsulat= e, remove, etc.)...and some even include rfc2119 Normative Keywords.=C2=A0 = But they are called examples!=C2=A0 So...my questions are: is the behavior = illustrated in =C2=A76 and =C2=A77 intended to be Normative?=C2=A0


= [authors]The examples are intended to illustrate the result of the normativ= e language in RFC8200 and RFC6553.
So the examples are intended t= o be normative explanation of the results of executing that language.=C2=A0=

=C2=A0=C2=A0
IOW, do these sections include both examples and s= pecify the behavior expected in the LLN?=C2=A0 Is the behavior already spec= ified somewhere else (and this document is just illustrating)?
=

[authors]The normative language is in RFC8200 (ipv= 6bis) section 4.2 and section 4, =E2=80=9CThe Hop-by-Hop Options=E2=80=A6= =E2=80=9D
Combined with the desired results of=C2=A0 RFC6553, we = conclude that we have to change the option value in order to make things wo= rk.
=C2=A0
=C2=A0 [I am asking that last question just-in-case, because the Int= roduction says that "this document clarifies what is the correct and t= he incorrect behaviour."]

[author= s] It says that because the use of RPL in the mentioned cases was not clear= to the WG.
Thus, we have interoperability issues.

=C2=A78 seems to attempt to summarize "observations about the cases&qu= ot;, but (if it is intended to be *the* Normative text about the behavior) = it is general and short.
=C2=A0
[authors] It= tends to be a summary about the most important findings in the use cases= =C2=A0

[Some of my comments below ask about Normative language... Please take thos= e in context with the answers here.]


(2) [major] Operational Considerations

Non-storing mode networks don't need the change to 0x23 (=C2=A78.2)...b= ut making the change creates a flag day, and even then, implementations sho= uld still process both values (=C2=A73.1).=C2=A0 I would really like to see= text about the operational considerations of introducing 0x23.=C2=A0 It co= ncerns me that a significant change that most[*] networks don't need is= being introduced.=C2=A0 Please take a look at rfc5706 (Guidelines for Cons= idering Operations and Management of New Protocols and Protocol Extensions)= , specially =C2=A72.

[*] Most deployed networks work in non-storing mode, right?

[authors]following our understanding, mostly yes.
but, e.g. Anima network in storing mode. Not having loop detection.


(3) [minor] >=3D ??

[authors] Fixed.= corrected to 1 <=3D i <=3D n=C2=A0

There are several (25!) instances of text like this:

=C2=A0 =C2=A06LR_i are the intermediate routers from source to destination.= =C2=A0 In
=C2=A0 =C2=A0this case, "1 <=3D i >=3D n", n is the number = of routers (6LR) that the
=C2=A0 =C2=A0packet go through from source (6LN) to destination (6LBR).

Maybe it's just me, but I don't understand why (or how!) i could ev= er be >=3D n.=C2=A0 The text says that i are the "intermediate rout= ers from source to destination", while n is "the number of router= s...from source (6LN) to destination (6LBR)".=C2=A0 Isn't that the= same thing?=C2=A0 What am I missing?


(4) Style nit: the document uses "we"...a third person style woul= d be preferable.=C2=A0 For example: s/In this section we are going to descr= ibe.../This section describes...

[autho= rs] Fixed.=C2=A0


I will wait for the major points to be addressed before starting the IETF L= C.

Thanks!!

Alvaro.



[Note: the numbers came from the idnits output.]

...
10=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When to use RFC 6553, 65= 54 and IPv6-in-IPv6
11=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dra= ft-ietf-roll-useofrplinfo-23

[minor] Can we come up with a more descriptive tittle?=C2=A0 Also, the &quo= t;shorthand" version ("Useof6553") could be improved.

[authors] Fixed. Useof6553 =3D>=C2=A0 RPL-= data-plane=C2=A0


...
130 1.=C2=A0 Introduction
...
156=C2=A0 =C2=A0The related document A Routing Header Dispatch for 6LoWPAN = (6LoRH)
157=C2=A0 =C2=A0[RFC8138] defines a method to compress RPL Option informati= on and
158=C2=A0 =C2=A0Routing Header type 3 [RFC6554], an efficient IP-in-IP tech= nique, and
159=C2=A0 =C2=A0use cases proposed for the [Second6TischPlugtest] involving= 6loRH.

[nit] I'm having trouble parsing this last paragraph.=C2=A0 It sounds l= ike rfc8138 (also) defines the use cases, but I don't remember seeing a= nything like that in there.=C2=A0 Is that what you meant?
<= div>
[authors]rewritten. RFC8138" defines a mechanism fo= r compressing RPL Option
=C2=A0information and Routing Header typ= e 3, as well as an efficient IP-in-IP technique.=C2=A0

[nit] I think the Introduction would benefit from an overview of the docume= nt; something like "section X talks about abc, section Y presents exam= ples, etc.".

[authors]added=C2=A0<= /div>

161 2.=C2=A0 Terminology and Requirements Language

163=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "= ;REQUIRED", "SHALL", "SHALL NOT",
164=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMEND= ED", "MAY", and "OPTIONAL" in this
165=C2=A0 =C2=A0document are to be interpreted as described in RFC 2119 [RF= C2119].

[major] Please use the RFC8174 template.
[authors]adde= d=C2=A0

...
170=C2=A0 =C2=A0RPL-node: A device which implements RPL, thus we can say th= at the
171=C2=A0 =C2=A0device is RPL-capable or RPL-aware.=C2=A0 Please note that = the device can
172=C2=A0 =C2=A0be found inside the LLN or outside LLN.=C2=A0 In this docum= ent a RPL-node
173=C2=A0 =C2=A0which is a leaf of a DODAG is called RPL-aware-leaf.

[nit] RPL-capable is not used anywhere else.
[authors]= fixed. removed=C2=A0

...
180=C2=A0 =C2=A0pledge: a new device which seeks admission to a network. (f= rom
181=C2=A0 =C2=A0[I-D.ietf-anima-bootstrapping-keyinfra])

183=C2=A0 =C2=A0Join Registrar and Coordinator (JRC): a device which brings= new nodes
184=C2=A0 =C2=A0(pledges) into a network. (from
185=C2=A0 =C2=A0[I-D.ietf-anima-bootstrapping-keyinfra])

[minor] Do these two terms need to be defined in this document?=C2=A0 They = are only used once, and with a reference to I-D.ietf-anima-bootstrapping-ke= yinfra next to them.=C2=A0 Also, and more important, the definition here do= esn't match the one in that other draft.=C2=A0 Please take out the defi= nitions and just make reference later on...
[authors]f= ixed. removed=C2=A0

187=C2=A0 =C2=A0Flag day: A "flag day" is a procedure in which th= e network, or a part
188=C2=A0 =C2=A0of it, is changed during a planned outage, or suddenly, cau= sing an
189=C2=A0 =C2=A0outage while the network recovers [RFC4192]

[nit] rfc4192 seems like an odd place to pull a reference to "flag day= " -- specially as it is being defined as "a procedure" and n= ot the effect it causes, which seems to be how it is used in the text: &quo= t;creates a flag day", "will experience a flag day", "a= void a flag day".=C2=A0 This is not a big issue -- if it was up to me,= I would either make my own definition, or just not define it at all: I thi= nk it is a well known term...

[authors]= fixed. rewritten=C2=A0

191 2.1.=C2=A0 hop-by-hop IPv6-in-IPv6 headers

193=C2=A0 =C2=A0The term "hop-by-hop IPv6-in-IPv6" header refers = to: adding a header
194=C2=A0 =C2=A0that originates from a node to an adjacent node, using the = addresses
195=C2=A0 =C2=A0(usually the GUA or ULA, but could use the link-local addre= sses) of
196=C2=A0 =C2=A0each node.=C2=A0 If the packet must traverse multiple hops,= then it must
197=C2=A0 =C2=A0be decapsulated at each hop, and then re-encapsulated again= in a
198=C2=A0 =C2=A0similar fashion.

[minor] That term is not used anywhere...but "hop-by-hop IP-in-IP"= ; is.

[authors]fixed. IP-in-IP replaced= by IPv6-in-IPv6=C2=A0

IPv6-in-IPv6 and IP-in-IP are used interchangeably throughout the document.= =C2=A0 This use is not wrong, but it is inconsistent.=C2=A0 Adding a note a= bout it (even though it may be obvious to many readers that the terms refer= to the same thing) would be nice...being consistent even nicer.

Later on, "IPIP" is also used...


[nit] Why is this definition in its own sub-section?
[= authors]fixed. It is included in the section instead.=C2=A0

200 3.=C2=A0 Updates to RFC6553, RFC6550 and RFC 8138

202 3.1.=C2=A0 Updates to RFC 6553

...
209=C2=A0 =C2=A0[RFC6553] states as showed below, that in the Option Type f= ield of
210=C2=A0 =C2=A0the RPL Option header, the two high order bits MUST be set = to '01'
211=C2=A0 =C2=A0and the third bit is equal to '1'.=C2=A0 The first = two bits indicate that
212=C2=A0 =C2=A0the IPv6 node MUST discard the packet if it doesn't rec= ognize the
213=C2=A0 =C2=A0option type, and the third bit indicates that the Option Da= ta may
214=C2=A0 =C2=A0change en route.=C2=A0 The remaining bits serve as the opti= on type.

s/showed/shown

[major] The 2 MUSTs used above are used paraphrasing rfc6553, and don't= define Normative behavior in this document.=C2=A0 Please either use a dire= ct quote, or use non-normative language.
[authors]fixe= d to non-normative language.=C2=A0

...
223=C2=A0 =C2=A0Recent changes in [RFC8200] (section 4, page 8), states: &q= uot;it is now
224=C2=A0 =C2=A0expected that nodes along a packet's delivery path only= examine and
225=C2=A0 =C2=A0process the Hop-by-Hop Options header if explicitly configu= red to do
226=C2=A0 =C2=A0so".=C2=A0 Processing of the Hop-by-Hop Options header= (by IPv6
227=C2=A0 =C2=A0intermediate nodes) is now optional, but if they are config= ured to
228=C2=A0 =C2=A0process the header, and if such nodes encounter an option w= ith the
229=C2=A0 =C2=A0first two bits set to 01, they will drop the packet (if the= y conform
230=C2=A0 =C2=A0to [RFC8200]).=C2=A0 Host systems should do the same, irres= pective of the
231=C2=A0 =C2=A0configuration.

[minor] The description above seems to be missing "...if the option is= not recognized".

233=C2=A0 =C2=A0Based on That, if an IPv6 (intermediate) node (RPL-not-capa= ble)
234=C2=A0 =C2=A0receives a packet with an RPL Option, it should ignore the = HBH RPL
235=C2=A0 =C2=A0option (skip over this option and continue processing the h= eader).

s/That/that

...
266=C2=A0 =C2=A0When forwarding packets, implementations SHOULD use the sam= e value as
267=C2=A0 =C2=A0it was received (This is required because, RPI type code ca= n not be
268=C2=A0 =C2=A0changed by [RFC8200]).=C2=A0 It allows to the network to be= incrementally
269=C2=A0 =C2=A0upgraded, and for the DODAG root to know which parts of the= network
270=C2=A0 =C2=A0are upgraded.

[major] There seems to be a contradiction above: "SHOULD use the same = value...this is required..."=C2=A0 =C2=A0If required by rfc8200, why n= ot use MUST?
[authors]rewritten=C2=A0

272=C2=A0 =C2=A0When originating new packets, implementations SHOULD have a= n option
273=C2=A0 =C2=A0to determine which value to originate with, this option is = controlled
274=C2=A0 =C2=A0by the DIO option described below.

[minor] =C2=A73.3 defines the option...but it doesn't explicitly say wh= at the receivers should do with it.=C2=A0 It may be obvious, but it should = be explicit for completeness.
[authors]rewritten=C2=A0=

[major] It seems to me that the paragraph above may be out of place, doesn&= #39;t say much, may be wrong...or maybe all 3.=C2=A0 The text says that the= originating value is controlled by the option in =C2=A73.3 (again, but tha= t section doesn't explicitly say what should be done)...but it also say= s (with the SHOULD) that an implementation may have valid reasons to not pa= y attention to the option -- what are those??

[authors]rewritten to
"In the cases where a forwardin= g node is forwarding traffic that is not
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0addressed directly to it (such as when the outer IPv6-in-I= Pv6 header is not a Link-Local address),
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0then RFC8200 forbids changing the RPI type code when forwa= rding.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wh= en forwarding traffic that is wrapped in Link-Local IPv6-in-IPv6 headers,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the forwarding node is in= effect originating new packets,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0and it MAY make a choice as to whether to use the old (0x63) RPI = Type code,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or the new (0= x23) RPI Type code. In that situation, implementations SHOULD
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use the same value as was received.= =C2=A0 This allows to the network to be incrementally upgraded,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and in some cases may allow the DO= DAG root to know which parts of the network are upgraded."=C2=A0
=


...
281 3.2.=C2=A0 Updates to RFC 8138

283=C2=A0 =C2=A0RPI-6LoRH header provides a compressed form for the RPL RPI=
284=C2=A0 =C2=A0[RFC8138].=C2=A0 It should be considered when the Option Ty= pe in RPL
285=C2=A0 =C2=A0Option is decompressed, should take the value of 0x23 inste= ad of
286=C2=A0 =C2=A00x63.

[major] AFAICT, the compression specified in rfc8138 doesn't include th= e RPI option type...but the use of the 6LoRH Type 5 implies the RPI.=C2=A0 = If I got that right, then how would the decompressing node know which RPI t= ype was in use when first compressed?=C2=A0 Given that both types may be us= ed in a network (=C2=A73.1), how would one know unless the 6LoRH type was a= lso changed?=C2=A0 Or are you suggesting that the decompression should alwa= ys use 0x23?=C2=A0 In any case, I think that stronger language might be nee= ded.

[auhtors] Yes, we are suggesting t= hat if the network is in 0x23 mode (by DIO option),
then it shoul= d be decompressed to 0x23.
RPI-6LoRH header provides a compressed= form for the RPL RPI in section 6.
A node that is decompressing = this header MUST decompress using the RPL RPI option type
that is= currently active: that is, a choice between 0x23 (new) and 0x63 (old).
The node will know which to use based upon the presence of the DODAG= Configuration
Option described in the next section.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

288 3.3.=C2=A0 Updates to RFC 6550: Indicating the new RPI in the DODAG
289=C2=A0 =C2=A0 =C2=A0 Configuration Option Flag.

291=C2=A0 =C2=A0In order to avoid a flag day caused by lack of interoperati= on between
292=C2=A0 =C2=A0new RPI (0x23) and old RPI (0x63) nodes, when there is a mi= x of new
293=C2=A0 =C2=A0nodes and old nodes, the new nodes may be put into a compat= ibility
294=C2=A0 =C2=A0mode until all of the old nodes are replaced or upgraded.
296=C2=A0 =C2=A0This can be done via a DODAG Configuration Option flag whic= h will
297=C2=A0 =C2=A0propogate through the network.=C2=A0 Failure to receive thi= s information
298=C2=A0 =C2=A0will cause new nodes to remain in compatibility mode, and o= riginate
299=C2=A0 =C2=A0traffic with the old-RPI (0x63) value.

s/propogate/propagate

[major] "compatibility mode"=C2=A0

What is "compatibility mode"?=C2=A0 Initially I thought that it w= as maybe the ability of new nodes to use both RPI values...but the end of t= he second paragraph suggests using only 0x63.

The text suggests that "compatibility mode" can be enabled via &q= uot;via a DODAG Configuration Option flag" -- that flag is not defined= anywhere...but "failure to receive this information will cause new no= des to remain in compatibility mode".=C2=A0 So...would it be enabled u= sing a flag, or is it the default?

Why wouldn't the default be the new RPI?=C2=A0 I can see how most of th= e networks will support the old RPI, but that will eventually be the except= ion...
[authors]rewritten to
<t>
=C2=A0 =C2=A0 =C2=A0 In order to avoid a Flag Day caused by lack o= f interoperation
=C2=A0 =C2=A0 =C2=A0 between new RPI (0x23) and = old RPI (0x63) nodes, this section
=C2=A0 =C2=A0 =C2=A0 defines a= flag in the DIO Configuration Option, to indicate when
=C2=A0 = =C2=A0 =C2=A0 then new RPI value can be safely used. Without this, there co= uld
=C2=A0 =C2=A0 =C2=A0 be a mix of new nodes (which understand = 0x23 and 0x63), and old
=C2=A0 =C2=A0 =C2=A0 nodes (which underst= and 0x63 only).=C2=A0 A new node would not know
=C2=A0 =C2=A0 =C2= =A0 if it was safe to use 0x23.
=C2=A0 =C2=A0 </t>
=C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2=A0 This is=C2=A0 done= via a DODAG Configuration Option flag which will
propagate throu= gh the network.=C2=A0 If the flag is received with a
value zero (= which is the default), then new nodes will remain in
=C2=A0 =C2= =A0 =C2=A0 RFC6553 Compatible Mode; originating traffic with the old-RPI (0= x63) value.
=C2=A0 =C2=A0 </t>=C2=A0

301=C2=A0 =C2=A0As stated in [RFC6550] the DODAG Configuration option is pr= esent in
302=C2=A0 =C2=A0DIO messages.=C2=A0 The DODAG Configuration option distribu= tes
303=C2=A0 =C2=A0configuration information.=C2=A0 It is generally static, an= d does not
304=C2=A0 =C2=A0change within the DODAG.=C2=A0 This information is configur= ed at the DODAG
305=C2=A0 =C2=A0root and distributed throughout the DODAG with the DODAG 306=C2=A0 =C2=A0Configuration option.=C2=A0 Nodes other than the DODAG root= do not modify
307=C2=A0 =C2=A0this information when propagating the DODAG Configuration o= ption.

309=C2=A0 =C2=A0The DODAG Configuration Option has a Flags field which is m= odified by
310=C2=A0 =C2=A0this document.=C2=A0 Currently, the DODAG Configuration Opt= ion in
311=C2=A0 =C2=A0[RFC6550] is as follows. .

313=C2=A0 =C2=A0Flags: The 4-bits remaining unused in the Flags field are r= eserved
314=C2=A0 =C2=A0for flags.=C2=A0 The field MUST be initialized to zero by t= he sender and
315=C2=A0 =C2=A0MUST be ignored by the receiver.

317 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A03
318 +-----------------+---------------------------------------------------+=
319 |=C2=A0 Type =3D 0x04=C2=A0 =C2=A0 |=C2=A0 Opt Length =3D 14| Flags=C2= =A0 | A | PCS| DIOIntDoubl.=C2=A0 |
320 +---------------------------------------------------------------------+=
321 | DIOIntMin.=C2=A0 =C2=A0 =C2=A0 |=C2=A0 DIORedund.=C2=A0 =C2=A0 =C2=A0= |=C2=A0 MaxRankIncrease=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
322 +-----------------+---------------------------------------------------+=
323 |=C2=A0 MinHopRankIncrease=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OCP=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
324 +-----------------+---------------------------------------------------+=
325 |Reserved=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Def. Lifetime=C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lifetime Unit=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|
326 +-----------------+-----------------+---------------------------------+=

328=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fig= ure 3: DODAG Configuration Option.

[minor] Suggestion: instead of copying (and not quoting the Normative langu= age) the text from rfc6550 above, just indicate what the Update is: "t= he unused bits MUST...".=C2=A0 Also, I think that Figure 3 is not need= ed.
[authors]fixed.=C2=A0


...
342=C2=A0 =C2=A0In case of rebooting, the node does not remember the flag.= =C2=A0 Thus, the
343=C2=A0 =C2=A0DIO is sent with flag indicating the new RPI value.

[minor] By "the node", which node are you referring to?=C2=A0 The= root?=C2=A0 If it doesn't remember, it means that it needs to be confi= gured -- how does that happen?=C2=A0 Why isn't the configuration persis= tent at the root?

[authors]fixed.=C2=A0= 6LN or 6LR added.

345 4.=C2=A0 Sample/reference topology

347=C2=A0 =C2=A0A RPL network in general is composed of a 6LBR (6LoWPAN Bor= der
348=C2=A0 =C2=A0Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6= LN
349=C2=A0 =C2=A0(6LoWPAN Node) as leaf logically organized in a DODAG struc= ture.
350=C2=A0 =C2=A0(Destination Oriented Directed Acyclic Graph).

[minor] The 6BBR doesn't appear in the Figure.
[au= thors] clarification added=C2=A0

[nit] BTW, it might be better to put the topology diagram right after this = first paragraph.
[authors] done=C2=A0

[nit] The DODAG expansion should be on first use.
[aut= hors] done=C2=A0

352=C2=A0 =C2=A0RPL defines the RPL Control messages (control plane), a new= ICMPv6
353=C2=A0 =C2=A0[RFC4443]=C2=A0 message with Type 155.=C2=A0 DIS (DODAG Inf= ormation
354=C2=A0 =C2=A0Solicitation), DIO (DODAG Information Object) and DAO (Dest= ination
355=C2=A0 =C2=A0Advertisement Object) messages are all RPL Control messages= but with
356=C2=A0 =C2=A0different Code values.=C2=A0 A RPL Stack is showed in Figur= e 5.

[minor] Not exactly sure what this paragraph has to do with the reference t= opology (yet), but (same comment as above) it might be good to put the figu= re right after the text.

s/showed/shown

[authors] done=C2=A0


...
428=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fi= gure 6: A reference RPL Topology.

430=C2=A0 =C2=A0Figure 2 shows the reference RPL Topology for this document= .=C2=A0 The
431=C2=A0 =C2=A0letters above the nodes are there so that they may be refer= enced in
432=C2=A0 =C2=A0subsequent sections.=C2=A0 In the figure, 6LR represents a = full router
433=C2=A0 =C2=A0node.=C2=A0 The 6LN is a RPL aware router, or host.

s/Figure 2/Figure 6
[authors] done=C2=A0

[minor] The 6LN is defined in the first paragraph as a node (not a router).= =C2=A0 BTW, what is the difference between a "full router" and (j= ust) a "router" (6LR vs 6LN)?
[authors] foll= ows rfc 6775:

"6LoWPAN Node (6LN):
= =C2=A0 =C2=A0 =C2=A0 A 6LoWPAN node is any host or router participating in = a LoWPAN.
=C2=A0 =C2=A0 =C2=A0 This term is used when referring t= o situations in which either a
=C2=A0 =C2=A0 =C2=A0 host or route= r can play the role described.

=C2=A0 =C2=A06LoWPA= N Router (6LR):
=C2=A0 =C2=A0 =C2=A0 An intermediate router in th= e LoWPAN that is able to send and
=C2=A0 =C2=A0 =C2=A0 receive Ro= uter Advertisements (RAs) and Router Solicitations (RSs)
=C2=A0 = =C2=A0 =C2=A0 as well as forward and route IPv6 packets.=C2=A0 6LoWPAN rout= ers are
=C2=A0 =C2=A0 =C2=A0 present only in route-over topologie= s."

In our document a 6LN represents a leaf, = following the behaviour of https://tools.ietf.org/html/rfc6550#section-8.5=C2=A0
=

[minor] 6LN is characterized above as "RPL aware", but (below) th= e "Raf" mark is also used for that -- so it seems that "~Raf= 6LN" would be a "not-RPL aware leaf...RPL aware router, or host&= quot;.

Some terminology clean up is needed.
[authors] we adde= d clarifications in the terminology section. referring rfc6775=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
435=C2=A0 =C2=A0But, the 6LN leaves (Raf - "RPL aware leaf"-) mar= ked as (F, H and I)
436=C2=A0 =C2=A0are RPL nodes with no children hosts.

[minor] Is there a relevance to the "children hosts" existing?=C2= =A0 Can it be concluded that ~Raf nodes have children hosts?
[authors] It could be that a ~Raf have children hosts, but they are = not part of the RPL domain and no
packets are going to be deliver= ed to them, but for the ~Raf.=C2=A0


...
446 5.=C2=A0 Use cases
...
507=C2=A0 =C2=A0This means that when the no-drop RPI option code 0x23 is us= ed, a
508=C2=A0 =C2=A0packet that leaves the RPL domain of an LLN (or that leaves= the LLN
509=C2=A0 =C2=A0entirely) will not be discarded when it contains the [RFC65= 53] RPL
510=C2=A0 =C2=A0Hop-by-Hop option known as RPI.=C2=A0 Thus, the RPI Hop-by-= Hop option MAY
511=C2=A0 =C2=A0be left in place even if the end host does not understand i= t.

[minor] If the last RPL-aware node knows that the host doesn't understa= nd the RPI, why would it not remove it (if it can)?=C2=A0 IOW, I understand= how it causes no harm (leading to the optional behavior above), but just b= ecause it can be done doesn't mean that it should.=C2=A0 Are there case= s where it can be used for something?
=C2=A0
[authors] we understand that the RPI is useful only in the RPL domain, not=
outside of it.=C2=A0

If the RPI can't be removed because the border is not the destination, = then the MAY above is insignificant: no one can strip it, so there's no= real option.
[authors] fixed.=C2=A0

513=C2=A0 =C2=A0NOTE: There is some possible security risk when the RPI inf= ormation
514=C2=A0 =C2=A0is released to the Internet.=C2=A0 At this point this is a = theoretical
515=C2=A0 =C2=A0situation; no clear attack has been described.=C2=A0 At wor= st, it is clear
516=C2=A0 =C2=A0that the RPI option would waste some network bandwidth when= it
517=C2=A0 =C2=A0escapes.=C2=A0 This is traded off against the savings in th= e LLN by not
518=C2=A0 =C2=A0having to encapsulate the packet in order to remove the art= ifact.

[major] AFAICT, leaking the RPI means leaking the RPLInstanceID and the Sen= derRank.=C2=A0 The Security Considerations already mentions what an attacke= r could do if it knows the RPLInstanceID...but it doesn't say anything = about the SenderRank.

I'm thinking that the SenderRank may help an attacker to have an idea o= f the topology of the LLN, right?=C2=A0 I don't know what an attacker c= an do with that information, but the fact that could be used for that (and = it could be a privacy issue) should be mentioned in the Security Considerat= ions section.
[authors] paragraph added.=C2=A0

...
526=C2=A0 =C2=A0A corollory is that an SHR3 or RPI Option can only be remov= ed by an
527=C2=A0 =C2=A0intermediate router if it is placed in an encapsulating IPv= 6 Header,
528=C2=A0 =C2=A0which is addressed TO the intermediate router.=C2=A0 When i= t does so, the
529=C2=A0 =C2=A0whole encapsulating header must be removed.=C2=A0 (A replac= ement may be
530=C2=A0 =C2=A0added).=C2=A0 This sometimes can result in outer IP headers= being
531=C2=A0 =C2=A0addressed to the next hop router using link-local addresses= .

s/corollory/corollary
[authors]fixed.=C2=A0


...
541=C2=A0 =C2=A0RPI should be present in every single RPL data packet.=C2= =A0 There is one
542=C2=A0 =C2=A0exception in non-storing mode: when a packet is going down = from the
543=C2=A0 =C2=A0root.=C2=A0 In a downward non-storing mode, the entire rout= e is written,
544=C2=A0 =C2=A0so there can be no loops by construction, nor any confusion= about
545=C2=A0 =C2=A0which forwarding table to use (as the root has already made= all
546=C2=A0 =C2=A0routing decisions).=C2=A0 However, there are still cases, s= uch as in
547=C2=A0 =C2=A06tisch, where the instanceID portion of the RPI header may = still be
548=C2=A0 =C2=A0needed to pick an appropriate priority or channel at each h= op.

[major] So...does that mean: in all cases, except downward non-storing mode= if 6tisch is not used, the RPI SHOULD be present?=C2=A0 Note that some of = the examples in =C2=A77 actually say that the RPI is optional...

[authors]: Yes, the RPI is optional in non-storin= g going downwards. The paragraph is updated as follows:
"=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<t>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 RPI MUST [[NOTE:=C2=A0 we increase this to MUST??]= ] be present in every single RPL data packet. There is one
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 exception in non-storing mode: when a p= acket is going down from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 root the RPI MAY be omitted.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 The rational is that in a downward non-storing mode, the enti= re
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 route is written, so= there can be no loops by construction, nor any
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 confusion about which forwarding table to use (as = the root has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 already ma= de all routing decisions).=C2=A0 However, there are still
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cases, such as in 6tisch, where the inst= anceID portion of the RPI
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 header may still be needed [6tisch-minimal draft] to pick an appropriat= e priority or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 channel a= t each hop.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </t>=C2=A0

550=C2=A0 =C2=A0In the tables present in this document, the term "RPL = aware leaf" is
551=C2=A0 =C2=A0has been shortened to "Raf", and "not-RPL aw= are leaf" has been
552=C2=A0 =C2=A0shortened to "~Raf" to make the table fit in avai= lable space.

s/is has been/has been

[nit] There's some repetition; Raf, for example, was already introduced= earlier in this section.
[authros]fixed. It is mentio= ned in the terminology section=C2=A0

...
557 6.=C2=A0 Storing mode

559=C2=A0 =C2=A0In storing mode (fully stateful), the sender can determine = if the
560=C2=A0 =C2=A0destination is inside the LLN by looking if the destination= address
561=C2=A0 =C2=A0is matched by the DIO's PIO option.

[nit] Please expand PIO...
[authors]fixed.=C2=A0
=

563=C2=A0 =C2=A0The following table itemizes which headers are needed in th= e
564=C2=A0 =C2=A0following scenarios, and indicates if the IP-in-IP header m= ust be
565=C2=A0 =C2=A0inserted on a hop-by-hop basis, or when it can target the d= estination
566=C2=A0 =C2=A0node directly.=C2=A0 There are these possible situations: h= op-by-hop
567=C2=A0 =C2=A0necessary (indicated by "hop"), or destination ad= dress possible
568=C2=A0 =C2=A0(indicated by "dst").=C2=A0 In all cases hop by h= op MAY be used.

[major] Should there be something else Normative in this paragraph?=C2=A0 M= aybe a MUST to indicate the need for "hop", as in "the IP-in= -IP header MUST be inserted on a hop-by-hop basis"?
[authors]fixed.=C2=A0

[minor] I'm confused by the nomenclature.=C2=A0 The description above s= eems to indicate that "hop" and "dst" are mutually excl= usive...but the table shows a column with a title using "dst" and= specific rows containing "hop".=C2=A0 What does that mean?
[authors]fixed. the nomenclature changed to target and clar= ification added.
<t>
=C2=A0 The following table i= temizes which headers are needed in each
=C2=A0 of the following = scenarios. It indicate if an IPv6-in-IPv6 header MUST
=C2=A0 be i= nserted, and whether the destination address of the IPv6-in-IPv6
= =C2=A0 header is the next hop, or the final target address. There are
=
=C2=A0 these possible situations: hop-by-hop necessary (indicated by
=C2=A0 "hop"), or final target address possible (indicat= ed by "tgt").=C2=A0 In
=C2=A0 all cases hop by hop MAY = be used rather than the final target
=C2=A0 address.
&l= t;/t>=C2=A0

570=C2=A0 =C2=A0In cases where no IP-in-IP header is needed, the column is = left
571=C2=A0 =C2=A0blank.

[minor] In Figure 7, there are "blank" columns (containing "= --"), but there are also entries that say "No".=C2=A0 Are th= ey meant to indicate the same thing?
[authors]Yes, fix= ed.=C2=A0

573=C2=A0 =C2=A0In all cases the RPI headers are needed, since it identifie= s
574=C2=A0 =C2=A0inconsistencies (loops) in the routing topology.=C2=A0 In a= ll cases the
575=C2=A0 =C2=A0RH3 is not needed because we do not indicate the route in s= toring
576=C2=A0 =C2=A0mode.

578=C2=A0 =C2=A0In each case, 6LR_i are the intermediate routers from sourc= e to
579=C2=A0 =C2=A0destination.=C2=A0 "1 <=3D i >=3D n", n is = the number of routers (6LR) that
580=C2=A0 =C2=A0the packet go through from source (6LN) to destination.

582=C2=A0 =C2=A0The leaf can be a router 6LR or a host, both indicated as 6= LN (see
583=C2=A0 =C2=A0Figure 6).

585=C2=A0 =C2=A0+---------------------+--------------+----------+----------= ----+
586=C2=A0 =C2=A0| Interaction between |=C2=A0 =C2=A0Use Case=C2=A0 =C2=A0| = IP-in-IP | IP-in-IP dst |
587=C2=A0 =C2=A0+---------------------+--------------+----------+----------= ----+
588=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 Raf to root |=C2=A0 =C2=A0 No=C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 |
589=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+----------+--------------+
590=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0Leaf - Root=C2=A0 =C2=A0 =C2=A0|=C2=A0= root to Raf |=C2=A0 =C2=A0 No=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 --=C2=A0 = =C2=A0 =C2=A0 |
591=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+----------+--------------+
592=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| root to ~Raf |=C2=A0 =C2=A0 No=C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 |
593=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+----------+--------------+
594=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| ~Raf to root |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0root=C2=A0 =C2=A0 =C2=A0|
595=C2=A0 =C2=A0+---------------------+--------------+----------+----------= ----+
596=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 Raf to Int=C2=A0 |=C2=A0 =C2=A0 No=C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 |
597=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+----------+--------------+
598=C2=A0 =C2=A0|=C2=A0 =C2=A0Leaf - Internet=C2=A0 =C2=A0|=C2=A0 Int to Ra= f=C2=A0 |=C2=A0 =C2=A0Yes=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 Raf=C2=A0 =C2= =A0 =C2=A0|
599=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+----------+--------------+
600=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 ~Raf to Int |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0root=C2=A0 =C2=A0 =C2=A0|
601=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+----------+--------------+
602=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 Int to ~Raf |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 hop=C2=A0 =C2=A0 =C2=A0|
603=C2=A0 =C2=A0+---------------------+--------------+----------+----------= ----+
604=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 Raf to Raf=C2=A0 |=C2=A0 =C2=A0 No=C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 |
605=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+----------+--------------+
606=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 Raf to ~Raf |=C2=A0 =C2=A0 No=C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 |
607=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0Leaf - Leaf=C2=A0 =C2=A0 =C2=A0+------= --------+----------+--------------+
608=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 ~Raf to Raf |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 dst=C2=A0 =C2=A0 =C2=A0|
609=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+--------------+----------+--------------+
610=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| ~Raf to ~Raf |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 hop=C2=A0 =C2=A0 =C2=A0|
611=C2=A0 =C2=A0+---------------------+--------------+----------+----------= ----+

613=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 7: IP-in-IP encap= sulation in Storing mode.

...
726 6.1.4.=C2=A0 SM: Example of Flow from not-RPL-aware-leaf to root

728=C2=A0 =C2=A0In this case the flow comprises:

730=C2=A0 =C2=A0not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> = root (6LBR)

732=C2=A0 =C2=A0For example, a communication flow could be: Node G --> N= ode E -->
733=C2=A0 =C2=A0Node B --> Node A root(6LBR)

735=C2=A0 =C2=A0When the packet arrives from IPv6 node (Node G) to 6LR_1 (N= ode E),
736=C2=A0 =C2=A0the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-= in-IPv6
737=C2=A0 =C2=A0header.=C2=A0 The IPv6-in-IPv6 header can be addressed to t= he next hop
738=C2=A0 =C2=A0(Node B), or to the root (Node A).=C2=A0 The root removes t= he header and
739=C2=A0 =C2=A0processes the packet.

[minor] The table below doesn't reflect the case where the IPv6-in-IPv6= header is addressed to the next hop.
[authors] fixed.= =C2=A0

741=C2=A0 =C2=A0+------------+------+---------------+---------------+------= ---------+
742=C2=A0 =C2=A0| Header=C2=A0 =C2=A0 =C2=A0| IPv6 | 6LR_1=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| 6LR_i=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 6LBR=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
743=C2=A0 =C2=A0+------------+------+---------------+---------------+------= ---------+
744=C2=A0 =C2=A0| Inserted=C2=A0 =C2=A0| --=C2=A0 =C2=A0| IP-in-IP(RPI) | -= -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
745=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
746=C2=A0 =C2=A0| Removed=C2=A0 =C2=A0 | --=C2=A0 =C2=A0| --=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= IP-in-IP(RPI) |
747=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
748=C2=A0 =C2=A0| Re-added=C2=A0 =C2=A0| --=C2=A0 =C2=A0| --=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
749=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
750=C2=A0 =C2=A0| Modified=C2=A0 =C2=A0| --=C2=A0 =C2=A0| --=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | IP-in-IP(RPI) | --=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 |
751=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
752=C2=A0 =C2=A0| Untouched=C2=A0 | --=C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
753=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
754=C2=A0 =C2=A0+------------+------+---------------+---------------+------= ---------+

756=C2=A0 =C2=A0 =C2=A0Storing: Summary of the use of headers from not-RPL-= aware-leaf to
757=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0root

...
772 6.2.1.=C2=A0 SM: Example of Flow from RPL-aware-leaf to Internet

774=C2=A0 =C2=A0RPL information from RFC 6553 MAY go out to Internet as it = will be
775=C2=A0 =C2=A0ignored by nodes which have not been configured to be RPI a= ware.

[major] The "MAY" (Normative) is out of place as the sentence abo= ve is stating a fact, not specifying a behavior. s/MAY/may
=
[authors] fixed.=C2=A0

...
835 6.2.3.=C2=A0 SM: Example of Flow from not-RPL-aware-leaf to Internet
837=C2=A0 =C2=A0In this case the flow comprises:

839=C2=A0 =C2=A0not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->r= oot (6LBR) -->
840=C2=A0 =C2=A0Internet

842=C2=A0 =C2=A0For example, a communication flow could be: Node G --> N= ode E -->
843=C2=A0 =C2=A0Node B --> Node A root(6LBR) --> Internet

845=C2=A0 =C2=A0The 6LR_1 (i=3D1) node will add an IP-in-IP(RPI) header add= ressed
846=C2=A0 =C2=A0either to the root, or hop-by-hop such that the root can re= move the
847=C2=A0 =C2=A0RPI header before passing upwards.=C2=A0 The IP-in-IP addre= ssed to the
848=C2=A0 =C2=A0root cause less processing overhead.=C2=A0 On the other han= d, with hop-by-
849=C2=A0 =C2=A0hop the intermediate routers can check the routing tables f= or a
850=C2=A0 =C2=A0better routing path, thus it could be more efficient and fa= ster.
851=C2=A0 =C2=A0Implementation should decide wich approach to take.

s/wich/which

[minor] The hop-by-hop option is not reflected in the table.
[authors] fixed.=C2=A0=C2=A0


853=C2=A0 =C2=A0The originating node will ideally leave the IPv6 flow label= as zero
854=C2=A0 =C2=A0so that the packet can be better compressed through the LLN= .=C2=A0 The
855=C2=A0 =C2=A06LBR will set the flow label of the packet to a non-zero va= lue when
856=C2=A0 =C2=A0sending to the Internet.

858=C2=A0 =C2=A0+---------+-----+-------------+-------------+-------------+= ---------+
859=C2=A0 =C2=A0| Header=C2=A0 | IPv | 6LR_1=C2=A0 =C2=A0 =C2=A0 =C2=A0| 6L= R_i=C2=A0 =C2=A0 =C2=A0 =C2=A0| 6LBR=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Interne |=
860=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 6=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [i=3D2,..,n]_ |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| t=C2=A0 =C2=A0 =C2=A0 =C2=A0|
861=C2=A0 =C2=A0+---------+-----+-------------+-------------+-------------+= ---------+
862=C2=A0 =C2=A0| Inserte | --=C2=A0 | IP-in-=C2=A0 =C2=A0 =C2=A0 | --=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --= =C2=A0 =C2=A0 =C2=A0 |
863=C2=A0 =C2=A0| d=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0| IP(RPI= )=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
864=C2=A0 =C2=A0| headers |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
865=C2=A0 =C2=A0| Removed | --=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | IP-in-=C2=A0 =C2=A0 =C2=A0 | --= =C2=A0 =C2=A0 =C2=A0 |
866=C2=A0 =C2=A0| headers |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| IP(= RPI)=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
867=C2=A0 =C2=A0| Re-=C2=A0 =C2=A0 =C2=A0| --=C2=A0 | --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 |
868=C2=A0 =C2=A0| added=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
869=C2=A0 =C2=A0| headers |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
870=C2=A0 =C2=A0| Modifie | --=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | IP-in-=C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --= =C2=A0 =C2=A0 =C2=A0 |
871=C2=A0 =C2=A0| d=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| IP(RPI)=C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
872=C2=A0 =C2=A0| headers |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
873=C2=A0 =C2=A0| Untouch | --=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | --=C2=A0 =C2=A0 =C2=A0 |
874=C2=A0 =C2=A0| ed=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
875=C2=A0 =C2=A0| headers |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
876=C2=A0 =C2=A0+---------+-----+-------------+-------------+-------------+= ---------+

878=C2=A0 =C2=A0 =C2=A0Storing: Summary of the use of headers from not-RPL-= aware-leaf to
879=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Internet

881 6.2.4.=C2=A0 SM: Example of Flow from Internet to non-RPL-aware-leaf
883=C2=A0 =C2=A0In this case the flow comprises:

885=C2=A0 =C2=A0Internet --> root (6LBR) --> 6LR_i --> not-RPL-awa= re-leaf (IPv6)

887=C2=A0 =C2=A0For example, a communication flow could be: Internet -->= Node A
888=C2=A0 =C2=A0root(6LBR) --> Node B --> Node E --> Node G

890=C2=A0 =C2=A0The 6LBR will have to add an RPI header within an IP-in-IP = header.
891=C2=A0 =C2=A0The IP-in-IP is addressed to the not-RPL-aware-leaf, leavin= g the RPI
892=C2=A0 =C2=A0inside.

[minor] The table below seems to be missing the not-RPL-aware-leaf removing= the IP-in-IP header.
[authors] fixed.=C2=A0=C2=A0

894=C2=A0 =C2=A0Note that there is a requirement that the final node be abl= e to
895=C2=A0 =C2=A0remove one or more IP-in-IP headers which are all addressed= to it,
896=C2=A0 =C2=A0mentioned in [I-D.thubert-roll-unaware-leaves] :

898=C2=A0 =C2=A0"RPL data packets are often encapsulated using IP in I= P.=C2=A0 The 6LN
899=C2=A0 =C2=A0MUST be able to decapsulate a packet when it is the destina= tion of
900=C2=A0 =C2=A0the outer header and process correctly the inner header.&qu= ot;

[major] I realize that we're not reviewing I-D.thubert-roll-unaware-lea= ves at this point, but how can a requirement be placed on a not-RPL-aware-l= eaf if, by definition, it is not aware of RPL??=C2=A0 =C2=A0...and I don= 9;t think we can assume it is aware of any other requirement...
[authors] We understand that the requirements are placed on the 6= LR that accepts the 6LN
=C2=A0 =C2=A0registration and also inject= the relevant routing information on its behalf.=C2=A0

If this document depends on the requirement in I-D.thubert-roll-unaware-lea= ves, then the reference should be Normative (it is now listed as Informativ= e).
[authors]fixed=C2=A0

...
935 6.3.1.=C2=A0 SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf<= br> ...
959=C2=A0 =C2=A0It is assume that the two nodes are in the same RPL Domain = (that they
960=C2=A0 =C2=A0share the same DODAG root).=C2=A0 At the common parent (Nod= e B), the
961=C2=A0 =C2=A0direction of RPI is changed (from increasing to decreasing = the rank).

s/assume/assumed
[authors]fixed=C2=A0


...
1079 6.3.4.=C2=A0 SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aw= are-
1080=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf
...
1102=C2=A0 =C2=A0The 6LR_1 (Node E) receives the packet from the the IPv6 n= ode (Node
1103=C2=A0 =C2=A0G) and inserts the RPI header (RPIa), encapsulated in an I= Pv6-in-IPv6
1104=C2=A0 =C2=A0header.=C2=A0 The IPv6-in-IPv6 header is addressed to the = final
1105=C2=A0 =C2=A0destination.

[minor] As in 6.2.4, which node removes the IP-in-IP header?=C2=A0 For comp= letion, it seems like the table is missing the fact that the "IPv6 dst= " node ignores the RPI.
[authors]fixed. The not-R= PL-aware leaf which is the destination removes the IP-in-IP=C2=A0

1107=C2=A0 =C2=A0+----------+-----+-------------+--------------+-----------= ---+------+
1108=C2=A0 =C2=A0| Header=C2=A0 =C2=A0| IPv | 6LR_1=C2=A0 =C2=A0 =C2=A0 =C2= =A0| 6LR_ia=C2=A0 =C2=A0 =C2=A0 =C2=A0| 6LR_m=C2=A0 =C2=A0 =C2=A0 =C2=A0 | = IPv6 |
1109=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | ds= t=C2=A0 |
1110=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | src |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0= =C2=A0 |
1111=C2=A0 =C2=A0+----------+-----+-------------+--------------+-----------= ---+------+
1112=C2=A0 =C2=A0| Inserted | --=C2=A0 | IP-in-=C2=A0 =C2=A0 =C2=A0 | --=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| --=C2=A0 =C2=A0|
1113=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0| IP(RPI)=C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
1114=C2=A0 =C2=A0| Removed=C2=A0 | --=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0|
1115=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0= |
1116=C2=A0 =C2=A0| Re-added | --=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0|
1117=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0= |
1118=C2=A0 =C2=A0| Modified | --=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | IP-in-=C2=A0 =C2=A0 =C2=A0 =C2=A0| IP-in-=C2=A0 =C2=A0 =C2=A0 =C2=A0|= --=C2=A0 =C2=A0|
1119=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0| IP(RPI)=C2=A0 =C2=A0 =C2=A0 | IP(RPI)=C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
1120=C2=A0 =C2=A0| Untouche | --=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0|
1121=C2=A0 =C2=A0| d=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2= =A0 =C2=A0 =C2=A0 |
1122=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0= |
1123=C2=A0 =C2=A0+----------+-----+-------------+--------------+-----------= ---+------+

1125=C2=A0 =C2=A0 =C2=A0Storing: Summary of the use of headers from not-RPL= -aware-leaf to
1126=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 non-RPL-aware-leaf

1128 7.=C2=A0 Non Storing mode
...
1147=C2=A0 =C2=A0+-----------------+--------------+-----+-----+----------+-= ---------+
1148=C2=A0 =C2=A0|=C2=A0 =C2=A0Interaction=C2=A0 =C2=A0|=C2=A0 =C2=A0Use Ca= se=C2=A0 =C2=A0| RPI | RH3 | IP-in-IP | IP-in-IP |
1149=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 between=C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 dst=C2=A0 =C2=A0|
1150=C2=A0 =C2=A0+-----------------+--------------+-----+-----+----------+-= ---------+
1151=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 Raf to root | Yes | No=C2=A0 |=C2=A0 =C2=A0 No=C2=A0 =C2=A0 |= =C2=A0 =C2=A0 --=C2=A0 =C2=A0 |
1152=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+-----+-----+----------+----------+
1153=C2=A0 =C2=A0|=C2=A0 =C2=A0Leaf - Root=C2=A0 =C2=A0|=C2=A0 root to Raf = | Opt | Yes |=C2=A0 =C2=A0 No=C2=A0 =C2=A0 |=C2=A0 =C2=A0 --=C2=A0 =C2=A0 |=
1154=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+-----+-----+----------+----------+
1155=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| root to ~Raf |no(1)| Yes |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|=C2=A0 =C2= =A0 6LR=C2=A0 =C2=A0|
1156=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+-----+-----+----------+----------+
1157=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| ~Raf to root | Yes | No=C2=A0 |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|=C2= =A0 =C2=A0root=C2=A0 =C2=A0|
1158=C2=A0 =C2=A0+-----------------+--------------+-----+-----+----------+-= ---------+
1159=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 Raf to Int=C2=A0 | Yes | No=C2=A0 |=C2=A0 =C2=A0 Yes=C2=A0 = =C2=A0|=C2=A0 =C2=A0root=C2=A0 =C2=A0|
1160=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+-----+-----+----------+----------+
1161=C2=A0 =C2=A0| Leaf - Internet |=C2=A0 Int to Raf=C2=A0 |no(1)| Yes |= =C2=A0 =C2=A0Yes=C2=A0 =C2=A0 |=C2=A0 =C2=A0 dst=C2=A0 =C2=A0|
1162=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+-----+-----+----------+----------+
1163=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 ~Raf to Int | Yes | No=C2=A0 |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|= =C2=A0 =C2=A0root=C2=A0 =C2=A0|
1164=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+-----+-----+----------+----------+
1165=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 Int to ~Raf |no(1)| Yes |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|=C2= =A0 =C2=A0 6LR=C2=A0 =C2=A0|
1166=C2=A0 =C2=A0+-----------------+--------------+-----+-----+----------+-= ---------+
1167=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 Raf to Raf=C2=A0 | Yes | Yes |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0|= root/dst |
1168=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+-----+-----+----------+----------+
1169=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 Raf to ~Raf | Yes | Yes |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0| root= /6LR |
1170=C2=A0 =C2=A0+=C2=A0 =C2=A0Leaf - Leaf=C2=A0 =C2=A0+--------------+----= -+-----+----------+----------+
1171=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|=C2=A0 ~Raf to Raf | Yes | Yes |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0| root= /6LN |
1172=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+--------------+-----+-----+----------+----------+
1173=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| ~Raf to ~Raf | Yes | Yes |=C2=A0 =C2=A0 Yes=C2=A0 =C2=A0| root/6LR = |
1174=C2=A0 =C2=A0+-----------------+--------------+-----+-----+----------+-= ---------+

1176=C2=A0 =C2=A0(1)-6tisch networks may need the RPI information.

[major] When?=C2=A0 What are the conditions when it is needed?
[authors] fixed.
<t>
=C2=A0 The leaf can= be a router 6LR or a host, both indicated as 6LN (Figure 3). In the Figure= they
=C2=A0 (1) indicates a 6tisch case <xref target=3D"= RFC8180"/>, where the
=C2=A0 instanceID portion of the RP= I header may still be needed to
=C2=A0 pick an appropriate priori= ty or channel at each hop.
</t>=C2=A0

1178=C2=A0 =C2=A0 =C2=A0Figure 8: Headers needed in Non-Storing mode: RPI, = RH3, IP-in-IP
1179=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulation.
...
1194 7.1.1.=C2=A0 Non-SM: Example of Flow from RPL-aware-leaf to root

1196=C2=A0 =C2=A0In non-storing mode the leaf node uses default routing to = send
1197=C2=A0 =C2=A0traffic to the root.=C2=A0 The RPI header must be included= to avoid/detect
1198=C2=A0 =C2=A0loops.

[major] Should that "must" be Normative?
[au= thors] fixed.=C2=A0

...
1224 7.1.2.=C2=A0 Non-SM: Example of Flow from root to RPL-aware-leaf
...
1236=C2=A0 =C2=A0The 6LBR will insert an RH3, and may optionally insert an = RPI header.

[major] Under which conditions should the RPI header be inserted?=C2=A0 Or = is it the case where it is not necessary, but it causes no harm if it's= there?=C2=A0 Are there benefits?=C2=A0 It would be nice to be precise in t= he specification to achieve consistent behavior.
[auth= ors]rewritten.=C2=A0

...
1254 7.1.3.=C2=A0 Non-SM: Example of Flow from root to not-RPL-aware-leaf ...
1267=C2=A0 =C2=A0In 6LBR the RH3 is added, it is modified at each intermedi= ate 6LR
1268=C2=A0 =C2=A0(6LR_1 and so on) and it is fully consumed in the last 6LR= (6LR_n),
1269=C2=A0 =C2=A0but left there.=C2=A0 If RPI is left present, the IPv6 nod= e which does not
1270=C2=A0 =C2=A0understand it will ignore it (following RFC8200), thus enc= apsulation
1271=C2=A0 =C2=A0is not necesary.=C2=A0 Due the complete knowledge of the t= opology at the
1272=C2=A0 =C2=A0root, the 6LBR may optionally address the IP-in-IP header = to the last
1273=C2=A0 =C2=A06LR, such that it is removed prior to the IPv6 node.

s/necesary/necessary

[major] So...encapsulation is not needed, but an IP-in-IP header is optiona= l.=C2=A0 When?=C2=A0 Are there advantages, disadvantages?=C2=A0 =C2=A0Same = questions about the RPI.
[authors]rewritten.=C2=A0

1275=C2=A0 =C2=A0+---------------+-------------+---------------+-----------= ---+------+
1276=C2=A0 =C2=A0| Header=C2=A0 =C2=A0 =C2=A0 =C2=A0 | 6LBR=C2=A0 =C2=A0 = =C2=A0 =C2=A0 | 6LR_i(i=3D1)=C2=A0 =C2=A0 | 6LR_n(i=3Dn)=C2=A0 =C2=A0| IPv6= |
1277=C2=A0 =C2=A0+---------------+-------------+---------------+-----------= ---+------+
1278=C2=A0 =C2=A0| Inserted=C2=A0 =C2=A0 =C2=A0 | (opt: RPI), | --=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| --=C2=A0 =C2=A0|
1279=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 =C2=A0 =C2=A0| RH3=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 | 1280=C2=A0 =C2=A0| Removed=C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | RH3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0|
1281=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 |
1282=C2=A0 =C2=A0| Re-added=C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0|
1283=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 |
1284=C2=A0 =C2=A0| Modified=C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | (opt: RPI),=C2=A0 =C2=A0| (opt: RPI),=C2=A0 | --=C2=A0 =C2= =A0|
1285=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| RH3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = RH3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 |
1286=C2=A0 =C2=A0| Untouched=C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| RPI=C2=A0 |
1287=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 |
1288=C2=A0 =C2=A0+---------------+-------------+---------------+-----------= ---+------+

[minor] In this case, the destination node would also leave the RH3 header = untouched, right?
[authors]table fixed. the RH3 is con= sumed by the 6LRn=C2=A0

1290=C2=A0 =C2=A0 =C2=A0Non Storing: Summary of the use of headers from roo= t to not-RPL-
1291=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 aware-leaf

[minor] This table (and several others) have no name/number.
[authors]table fixed.=C2=A0

...
1375 7.2.2.=C2=A0 Non-SM: Example of Flow from Internet to RPL-aware-leaf ...
1393=C2=A0 =C2=A0The RPI may be added or not as required by networks such a= s 6tisch.

[major] When would that be?=C2=A0 Is there a reference?
[authors] removed.=C2=A0

1394=C2=A0 =C2=A0The RPI is unnecessary for loop detection.

[major] Yet the Table shows it...when would it be used, why, etc.?
[authors] fixed.=C2=A0

1396=C2=A0 =C2=A0+----------+---------+--------------+---------------+-----= ----------+
1397=C2=A0 =C2=A0| Header=C2=A0 =C2=A0| Interne | 6LBR=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| 6LR_i=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 6LN=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
1398=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | t=C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
1399=C2=A0 =C2=A0+----------+---------+--------------+---------------+-----= ----------+
1400=C2=A0 =C2=A0| Inserted | --=C2=A0 =C2=A0 =C2=A0 | IP-in-IP (RH | --=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
1401=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 3,opt= :RPI)=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
1402=C2=A0 =C2=A0| Removed=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |= IP-in-IP=C2=A0 =C2=A0 =C2=A0 |
1403=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| (RH3,opt:RPI) |
1404=C2=A0 =C2=A0| Re-added | --=C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
1405=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
1406=C2=A0 =C2=A0| Modified | --=C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| IP-in-IP=C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
1407=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | (RH3,opt:RPI) |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
1408=C2=A0 =C2=A0| Untouche | --=C2=A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
1409=C2=A0 =C2=A0| d=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
1410=C2=A0 =C2=A0| headers=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
1411=C2=A0 =C2=A0+----------+---------+--------------+---------------+-----= ----------+

1413=C2=A0 =C2=A0 =C2=A0Non Storing: Summary of the use of headers from Int= ernet to RPL-
1414=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 aware-leaf

...
1566 7.3.2.=C2=A0 Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aw= are-
1567=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf
...
1583=C2=A0 =C2=A0As in the previous case, the 6LN will insert an RPI (RPI_1= ) header
1584=C2=A0 =C2=A0which MUST be in an IP-in-IP header addressed to the root = so that the
1585=C2=A0 =C2=A06LBR can remove this RPI.=C2=A0 The 6LBR will then insert = an RH3 inside a
1586=C2=A0 =C2=A0new IP-in-IP header addressed to the 6LN destination node.= =C2=A0 The RPI
1587=C2=A0 =C2=A0is optional from 6LBR to 6LR_id (RPI_2).

[minor] The text says that the "new IP-in-IP header [is] addressed to = the 6LN destination node", but the Table below shows the 6LR_id removi= ng it.
[authors] fixed.=C2=A0

1589=C2=A0 =C2=A0+-----------+----------+----------+------------+----------= --+-------+
1590=C2=A0 =C2=A0| Header=C2=A0 =C2=A0 | 6LN=C2=A0 =C2=A0 =C2=A0 | 6LR_1=C2= =A0 =C2=A0 | 6LBR=C2=A0 =C2=A0 =C2=A0 =C2=A0| 6LR_id=C2=A0 =C2=A0 =C2=A0| I= Pv6=C2=A0 |
1591=C2=A0 =C2=A0+-----------+----------+----------+------------+----------= --+-------+
1592=C2=A0 =C2=A0| Inserted=C2=A0 | IP-in-IP | --=C2=A0 =C2=A0 =C2=A0 =C2= =A0| IP-in-IP=C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 = =C2=A0 |
1593=C2=A0 =C2=A0| headers=C2=A0 =C2=A0| (RPI1)=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | (RH3, opt=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|
1594=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | RPI_2)=C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0|
1595=C2=A0 =C2=A0| Removed=C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0| --= =C2=A0 =C2=A0 =C2=A0 =C2=A0| IP-in-IP=C2=A0 =C2=A0| IP-in-IP=C2=A0 =C2=A0| = --=C2=A0 =C2=A0 |
1596=C2=A0 =C2=A0| headers=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | (RPI_1)=C2=A0 =C2=A0 | (RH3, opt=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|
1597=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | RPI_2)=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0|
1598=C2=A0 =C2=A0| Re-added=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0= =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 |
1599=C2=A0 =C2=A0| headers=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0= |
1600=C2=A0 =C2=A0| Modified=C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0| IP-in-IP= | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| IP-in-IP=C2=A0 =C2=A0| --=C2=A0 = =C2=A0 |
1601=C2=A0 =C2=A0| headers=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = | (RPI_1)=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | (RH3, opt=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|
1602=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | RPI_2)=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0|
1603=C2=A0 =C2=A0| Untouched | --=C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2= =A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| opt=C2=A0 =C2=A0|
1604=C2=A0 =C2=A0| headers=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | RPI_2 |
1605=C2=A0 =C2=A0+-----------+----------+----------+------------+----------= --+-------+

1607=C2=A0 =C2=A0 =C2=A0Non Storing: Summary of the use of headers from RPL= -aware-leaf to
1608=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 not-RPL-aware-leaf

...
1654 7.3.4.=C2=A0 Non-SM: Example of Flow from not-RPL-aware-leaf to not-RP= L-
1655=C2=A0 =C2=A0 =C2=A0 =C2=A0 aware-leaf
...
1674=C2=A0 =C2=A0+------------+-------+-----------+------------+-----------= --+-------+
1675=C2=A0 =C2=A0| Header=C2=A0 =C2=A0 =C2=A0| IPv6=C2=A0 | 6LR_1=C2=A0 =C2= =A0 =C2=A0| 6LBR=C2=A0 =C2=A0 =C2=A0 =C2=A0| 6LR_id=C2=A0 =C2=A0 =C2=A0 | I= Pv6=C2=A0 |
1676=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | src=C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| dst=C2=A0 = =C2=A0|
1677=C2=A0 =C2=A0+------------+-------+-----------+------------+-----------= --+-------+
1678=C2=A0 =C2=A0| Inserted=C2=A0 =C2=A0| --=C2=A0 =C2=A0 | IP-in-IP=C2=A0 = | IP-in-IP=C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | --=C2=A0 = =C2=A0 |
1679=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0| (RPI_= 1)=C2=A0 =C2=A0| (RH3)=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|
1680=C2=A0 =C2=A0| Removed=C2=A0 =C2=A0 | --=C2=A0 =C2=A0 | --=C2=A0 =C2=A0= =C2=A0 =C2=A0 | IP-in-IP=C2=A0 =C2=A0| IP-in-IP=C2=A0 =C2=A0 | --=C2=A0 = =C2=A0 |
1681=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (RPI_1)=C2=A0 =C2=A0 | (RH3, opt=C2=A0= =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|
1682=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | RPI_2)=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0= =C2=A0|
1683=C2=A0 =C2=A0| Re-added=C2=A0 =C2=A0| --=C2=A0 =C2=A0 | --=C2=A0 =C2=A0= =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 |
1684=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0|
1685=C2=A0 =C2=A0| Modified=C2=A0 =C2=A0| --=C2=A0 =C2=A0 | --=C2=A0 =C2=A0= =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 |
1686=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0|
1687=C2=A0 =C2=A0| Untouched=C2=A0 | --=C2=A0 =C2=A0 | --=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| --=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | --=C2=A0 =C2=A0 |
1688=C2=A0 =C2=A0| headers=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0|
1689=C2=A0 =C2=A0+------------+-------+-----------+------------+-----------= --+-------+

[minor] The optional RPI_2 is not indicated in the 6LBR column.
[authors] fixed.=C2=A0


...
1696 8.1.=C2=A0 Storing mode
...
1705=C2=A0 =C2=A0Thanks to the change of the RPI option type from 0x63 to 0= x23, there
1706=C2=A0 =C2=A0is no longer any uncertainty about when to use an IP-in-IP= header in
1707=C2=A0 =C2=A0the storing mode.=C2=A0 A Hop-by-Hop Options Header contai= ning the RPI
1708=C2=A0 =C2=A0option SHOULD always be added when 6LRs originate packets = (without
1709=C2=A0 =C2=A0IP-in-IP headers), and IP-in-IP headers should always be a= dded
1710=C2=A0 =C2=A0(addressed to the root when on the way up, to the end-host= when on
1711=C2=A0 =C2=A0the way down) when a 6LR find that it needs to insert a Ho= p-by-Hop
1712=C2=A0 =C2=A0Options Header containing the RPI option.

[major] This paragraph starts by saying that "there is no longer any u= ncertainty about when to use an IP-in-IP header".=C2=A0 However, the s= pecification is a "SHOULD", which means that there are cases when= the action may not be performed.=C2=A0 It sounds like a contradiction to m= e.=C2=A0 In any case, what are the cases that make it a "SHOULD" = and not a "MUST"?

[authors]re= written.
<t>
=C2=A0 The change of RPI option type= from 0x63 to 0x23, makes all
=C2=A0 <xref target=3D"RFC8= 200"/> Section 4.2 compliant nodes tolerant of the RPL artifacts.= =C2=A0 There
=C2=A0 is therefore no longer a necessity to remove = the artifacts when
=C2=A0 sending traffic to the Internet.=C2=A0 = This change clarifies when
=C2=A0 to use an IPv6-in-IPv6 header, = and how to address them:
=C2=A0 The Hop-by-Hop Options Header con= taining the RPI option SHOULD always
=C2=A0 be added when 6LRs or= iginate packets (without IPv6-in-IPv6
=C2=A0 headers), and IPv6-i= n-IPv6 headers SHOULD always be added
=C2=A0 when a 6LR find that= it needs to insert a Hop-by-Hop Options Header
=C2=A0 containing= the RPI option.=C2=A0 The IPv6-in-IPv6 header is to
=C2=A0 be ad= dressed to the
=C2=A0 RPL root when on the way up, and to the end= -host when on the way down.
</t>=C2=A0

[major] Should this text include a "SHOULD" as well: "and IP= -in-IP headers should always be added..."?
=C2=A0=
[authors]It=E2=80=99s SHOULD so that non-LLN uses of RPL can cha= nge this.=C2=A0

...
1731 9.=C2=A0 6LoRH Compression cases

1733=C2=A0 =C2=A0The [RFC8138] proposes a compression method for RPI, RH3 a= nd IPv6-in-
1734=C2=A0 =C2=A0IPv6.

1736=C2=A0 =C2=A0In Storing Mode, for the examples of Flow from RPL-aware-l= eaf to non-
1737=C2=A0 =C2=A0RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-lea= f comprise
1738=C2=A0 =C2=A0an IP-in-IP and RPI compression headers.=C2=A0 The type of= this case is
1739=C2=A0 =C2=A0critical since IP-in-IP is encapsulating a RPI header.

1741=C2=A0 =C2=A0+--+-----+---+--------------+-----------+-------------+---= ----------+
1742=C2=A0 =C2=A0|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LO= WPAN IPHC |
1743=C2=A0 =C2=A0+--+-----+---+--------------+-----------+-------------+---= ----------+

1745=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= igure 9: Critical IP-in-IP (RPI).

[major] Shouldn't this section also be an Update to rfc8138?

[major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it is i= ntroduced as Critical here.=C2=A0 The header must then be completely specif= ied in this document and the appropriate registry must be updated (in the I= ANA Consideration section).

Specifically...referring to rfc8138...
=C2=A0 =C2=A0- the meaning of the TSE depends on the Type (=C2=A74.2),
=C2=A0 =C2=A0- the Hop Limit is defined in =C2=A77, should it have the same= behavior/meaning here?
=C2=A0 =C2=A0- does the "RPI - 6LoRH" field correspond to the RPI= -6LoRH header (=C2=A76.3)?
=C2=A0 =C2=A0- I'm assuming that the "LOWPAN IPHC" field refe= rs to LOWPAN_IPHC (rfc6282).

[authors] = we think that the confusion is because we wrote: =E2=80=9CThe type of this = case=E2=80=9D...
which sounds like we are changing 8138, when wha= t we mean is that use of this elective type is a MUST for RPL.
Ty= pe 6 (compressed RPI) is elective in 8138 because non-RPL uses of 6lowpan d= o not
need to support (compressed) RPI headers, but this document= makes it a MUST because
RPL uses of 6lowpan need it. Is there te= xt that we need to update?=C2=A0

...
1774 11.=C2=A0 Security Considerations

1776=C2=A0 =C2=A0The security considerations covering of [RFC6553] and [RFC= 6554] apply
1777=C2=A0 =C2=A0when the packets get into RPL Domain.

s/covering of/covered in

[minor] Do you mean "are in the RPL Domain" instead of "get = into" it?=C2=A0 Or are you talking about when a packet comes into the = domain from a non-RPL-aware node (like a non-RPL-aware-leaf)?=C2=A0 I ask b= ecause it seems to me that those RFCs only talk about packets that are insi= de the domain (and not about them getting in).
[author= s] fixed.=C2=A0

1779=C2=A0 =C2=A0The IPIP mechanism described in this document is much more= limited
1780=C2=A0 =C2=A0than the general mechanism described in [RFC2473].=C2=A0 T= he willingness
1781=C2=A0 =C2=A0of each node in the LLN to decapsulate packets and forward= them could
1782=C2=A0 =C2=A0be exploited by nodes to disguise the origin of an attack.=

1784=C2=A0 =C2=A0Nodes outside of the LLN will need to pass IPIP traffic th= rough the
1785=C2=A0 =C2=A0RPL root to perform this attack.=C2=A0 To counter, the RPL= root SHOULD
1786=C2=A0 =C2=A0either restrict ingress of IPIP packets (the simpler solut= ion), or it
1787=C2=A0 =C2=A0SHOULD do a deep packet inspection wherein it walks the IP= header
1788=C2=A0 =C2=A0extension chain until it can inspect the upper-layer-paylo= ad as
1789=C2=A0 =C2=A0described in [RFC7045].=C2=A0 In particular, the RPL root = SHOULD do BCP38
1790=C2=A0 =C2=A0([RFC2827]) processing on the source addresses of all IP h= eaders that
1791=C2=A0 =C2=A0it examines in both directions.

[major] For all 3 SHOULDs above...=C2=A0 Why are they not a MUST?=C2=A0 IOW= , when (if countering) would the actions not be performed?=C2=A0 Are there = other mechanisms that the root could consider?
=C2=A0<= /div>
[authors]We are being conservative in writing SHOULD, because it = these mechanism
=C2=A0are not externally visible, an implementer = could do something different (better?
=C2=A0 Faster? cheaper?) if= it had the same effect.=C2=A0 For instance, an upstream firewall
=C2=A0 =C2=A0could do the BCP38 filtering or IPIP filtering. Deep Packet I= nspection is
=C2=A0 =C2=A0distasteful, but only necessary if ther= e is a need to accept some IPIP headers.=C2=A0

1793=C2=A0 =C2=A0Note: there are some situations where a prefix will spread= across
1794=C2=A0 =C2=A0multiple LLNs via mechanisms such as described in
1795=C2=A0 =C2=A0[I-D.ietf-6lo-backbone-router].=C2=A0 In this case the BCP= 38 filtering
1796=C2=A0 =C2=A0needs to take this into account.

s/such as described/such as the one described

[major] The text above sounds like the root needs to get some type of routi= ng information from the other LLN, is that true?=C2=A0 What are the securit= y implications of that?

I took a very quick look at I-D.ietf-6lo-backbone-router and it seems to me= that there are probably other considerations to be included related to tha= t mechanism in the context of this document.=C2=A0 Given the "in passi= ng" nature of the note above, and the fact that I-D.ietf-6lo-backbone-= router is still in process in 6lo, I suggest you take the text/reference ou= t.

[authors]Discussion on the list.=C2= =A0

1798=C2=A0 =C2=A0Nodes with the LLN can use the IPIP mechanism to mount an = attack on
1799=C2=A0 =C2=A0another part of the LLN, while disguising the origin of th= e attack.
1800=C2=A0 =C2=A0The mechanism can even be abused to make it appear that th= e attack is
1801=C2=A0 =C2=A0coming from outside the LLN, and unless countered, this co= uld be used
1802=C2=A0 =C2=A0to mount a Distributed Denial Of Service attack upon nodes= elsewhere
1803=C2=A0 =C2=A0in the Internet.=C2=A0 See [DDOS-KREBS] for an example of = such attacks
1804=C2=A0 =C2=A0already seen in the real world.

s/Nodes with the LLN/Nodes within the LLN

[major] Is there any possible mitigation to this inside-the-LLN attack?=C2= =A0 It seems to me that this issue is not something introduced by this docu= ment, right?=C2=A0 Would authentication help -- is it even possible? Is the= re a discussion of this in the main spec?

[authors]Discussion on the list.=C2=A0=C2=A0

1806=C2=A0 =C2=A0While a typical LLN may be a very poor origin for attack t= raffic (as
1807=C2=A0 =C2=A0the networks tend to be very slow, and the nodes often hav= e very low
1808=C2=A0 =C2=A0duty cycles) given enough nodes, they could still have a s= ignificant
1809=C2=A0 =C2=A0impact, particularly if the attack was on another LLN!=C2= =A0 Additionally,
1810=C2=A0 =C2=A0some uses of RPL involve large backbone ISP scale equipmen= t
1811=C2=A0 =C2=A0[I-D.ietf-anima-autonomic-control-plane], which may be equ= ipped with
1812=C2=A0 =C2=A0multiple 100Gb/s interfaces.

[nit] Suggestion: reorder the paragraphs so that the discussion of the inte= rnal threats starts in the third paragraph.=C2=A0 It should improve readabi= lity and may avoid some repetition.
[authors]fixed.=C2= =A0

1814=C2=A0 =C2=A0Blocking or careful filtering of IPIP traffic entering the= LLN as
1815=C2=A0 =C2=A0described above will make sure that any attack that is mou= nted must
1816=C2=A0 =C2=A0originate compromised nodes within the LLN.=C2=A0 The use = of BCP38
1817=C2=A0 =C2=A0filtering at the RPL root on egress traffic will both aler= t the
1818=C2=A0 =C2=A0operator to the existence of the attack, as well as drop t= he attack
1819=C2=A0 =C2=A0traffic.=C2=A0 As the RPL network is typically numbered fr= om a single
1820=C2=A0 =C2=A0prefix, which is itself assigned by RPL, BCP38 filtering i= nvolves a
1821=C2=A0 =C2=A0single prefix comparison and should be trivial to automati= cally
1822=C2=A0 =C2=A0configure.

s/originate compromised/originate from compromised

[major] Yes, BCP38 will stop an attack, but only if the source addresses ar= e spoofed.=C2=A0 What if they're not?=C2=A0 Given that the attack may b= e hidden, and assuming that nodes are compromised across multiple LLNs, an = attacker may not care enough to spoof the origins.
[au= thors]To be disscussed on list=C2=A0

1824=C2=A0 =C2=A0There are some scenarios where IPIP traffic SHOULD be allo= wed to pass
1825=C2=A0 =C2=A0through the RPL root, such as the IPIP mediated communicat= ions
1826=C2=A0 =C2=A0between a new Pledge and the Join Registrar/Coordinator (J= RC) when
1827=C2=A0 =C2=A0using [I-D.ietf-anima-bootstrapping-keyinfra] and
1828=C2=A0 =C2=A0[I-D.ietf-6tisch-dtsecurity-secure-join].=C2=A0 This is th= e case for the
1829=C2=A0 =C2=A0RPL root to do careful filtering: it occurs only when the = Join
1830=C2=A0 =C2=A0Coordinator is not co-located inside the RPL root.

[major] Because of the "SHOULD", both references should be Normat= ive.=C2=A0 The second ID is Informational.=C2=A0 Does that really need to b= e a "SHOULD"??=C2=A0 It seems to me that "should" would= be enough in this case.
[authors]fixed.=C2=A0

[minor] I'm having trouble parsing the last sentence.=C2=A0 What are yo= u trying to suggest?
[authors] when an entity called J= oin coordinator is not included inside the root,
the root should = allow the IPIP traffic.=C2=A0

1832=C2=A0 =C2=A0With the above precautions, an attack using IPIP tunnels w= ill be by a
1833=C2=A0 =C2=A0node within the LLN on another node within the LLN.=C2=A0 = Such an attack
1834=C2=A0 =C2=A0could, of course, be done directly.=C2=A0 An attack of thi= s kind is
1835=C2=A0 =C2=A0meaningful only if the source addresses are either fake or= if the
1836=C2=A0 =C2=A0point is to amplify return traffic.=C2=A0 Such an attack, = could also be
1837=C2=A0 =C2=A0done without the use of IPIP headers using forged source a= ddresses.

1839=C2=A0 =C2=A0If the attack requires bi-directional communication, then = IPIP
1840=C2=A0 =C2=A0provides no advantages.

1842=C2=A0 =C2=A0[RFC2473] suggests that tunnel entry and exit points can b= e secured,
1843=C2=A0 =C2=A0via the "Use IPsec".=C2=A0 This solution has all= the problems that

[minor] "This solution"...which one?=C2=A0 The rfc2473 suggestion= or the one described in this document?

[authors]rewritten=C2=A0

1844=C2=A0 =C2=A0[RFC5406] goes into.=C2=A0 In an LLN such a solution would= degenerate into
1845=C2=A0 =C2=A0every node having a tunnel with every other node.=C2=A0 It= would provide a
1846=C2=A0 =C2=A0small amount of origin address authentication at a very hi= gh cost;
1847=C2=A0 =C2=A0doing BCP38 at every node (linking layer-3 addresses to la= yer-2
1848=C2=A0 =C2=A0addresses, and to already present layer-2 cryptographic me= chanisms)
1849=C2=A0 =C2=A0would be cheaper should RPL be run in an environment where= hostile
1850=C2=A0 =C2=A0nodes are likely to be a part of the LLN.

1852=C2=A0 =C2=A0The RH3 header usage described here can be abused in equiv= alent ways
1853=C2=A0 =C2=A0with an IPIP header to add the needed RH3 header.=C2=A0 As= such, the
1854=C2=A0 =C2=A0attacker's RH3 header will not be seen by the network = until it
1855=C2=A0 =C2=A0reaches the end host, which will decapsulate it.=C2=A0 An = end-host SHOULD
1856=C2=A0 =C2=A0be suspicious about a RH3 header which has additional hops= which have
1857=C2=A0 =C2=A0not yet been processed, and SHOULD ignore such a second RH= 3 header.

[nit] Hmmm...it seems like these threats should have been identified in rfc= 6554...

[major] What does "SHOULD be suspicious" mean?=C2=A0 How is that = a Normative behavior?=C2=A0 Would being suspicious include dropping the pac= ket or some other similar action?=C2=A0 When would the router *not* be susp= icious?=C2=A0 Why is that not a "MUST"?
=C2= =A0
[authors]The presence of the second RH3 means that there is a= configuration
=C2=A0mistake somewhere else in the network.=C2=A0= It would be reasonable to increment
=C2=A0 a counter in a MIB (i= f we had a MIB) when this occurs.=C2=A0 Based upon the Postel
=C2= =A0 =C2=A0doctrine, ignoring the extra header (not acting on it), is the be= st policy.
=C2=A0 =C2=A0 An RH3 header was not completely consume= d is discussed in RFC

=C2=A0additional =E2=80=9Cn= on-zero Segments Left value, if the IPv6 Destination Address is
= =C2=A0 not on-link=E2=80=9D should be dropped.=C2=A0 In this case, the RH3 = header is *inside*
=C2=A0 the outer IPv6-in-IPv6 header, which ha= s then been forwarded.
We think that this header should simply be= ignored in processing the packet.
=C2=A0To do otherwise (such as= forwarding) would permit external attackers to send
=C2=A0traffi= c that appears to originate inside the LLN.

=C2=A0= To be discussed on list=C2=A0

[major] When should a second RH3 header not be ignored?=C2=A0 Why is "= MUST" not used?
=C2=A0
=C2=A0[authors]U= nsure of whether there are uses in the future for this kind of thing.=C2=A0=

1859=C2=A0 =C2=A0In addition, the LLN will likely use [RFC8138] to compress= the IPIP
1860=C2=A0 =C2=A0and RH3 headers.=C2=A0 As such, the compressor at the RPL-= root will see
1861=C2=A0 =C2=A0the second RH3 header and MAY choose to discard the packet= if the RH3
1862=C2=A0 =C2=A0header has not been completely consumed.=C2=A0 A consumed = (inert) RH3

[major] It seems to me that the optional action of the root of discarding t= he packet is is contradiction with the "SHOULD ignore such a second RH= 3 header" above.=C2=A0 Is the subtle difference that we're talking= about the root here, and the end-host above?=C2=A0 Why wouldn't the ac= tions be the same if in both cases the second RH3 header may indicate some = type of attack, or at least something anomalous??
=C2= =A0
[authors] If the root ALWAYS discards such packets, then if s= omeone comes up
=C2=A0with a use for them, then they need to adju= st two systems to make it work,
=C2=A0 creating a flag day situat= ion for that new feature.=C2=A0 By saying MAY, we are
=C2=A0 =C2= =A0suggesting that a knob is probably appropriate.=C2=A0

1863=C2=A0 =C2=A0header could be present in a packet that flows from one LL= N, crosses
1864=C2=A0 =C2=A0the Internet, and enters another LLN.=C2=A0 As per the dis= cussion in this
1865=C2=A0 =C2=A0document, such headers do not need to be removed.=C2=A0 Ho= wever, there is
1866=C2=A0 =C2=A0no case described in this document where an RH3 is inserte= d in a non-
1867=C2=A0 =C2=A0storing network on traffic that is leaving the LLN, but th= is document
1868=C2=A0 =C2=A0SHOULD NOT preclude such a future innovation.=C2=A0 It sho= uld just be
1869=C2=A0 =C2=A0noted that an incoming RH3 must be fully consumed, or very= carefully
1870=C2=A0 =C2=A0inspected.

[major] The "SHOULD NOT" seems out of place as there is nothing N= ormative in the statement.
[authors]fixed.=C2=A0
=

[major] What does "very carefully inspected" mean?=C2=A0 Are ther= e actions resulting from that?
=C2=A0
[autho= rs]Subject to extensive Access Control Lists, if permitted.=C2=A0

1872=C2=A0 =C2=A0The RPI header, if permitted to enter the LLN, could be us= ed by an
1873=C2=A0 =C2=A0attacker to change the priority of a packet by selecting a= different
1874=C2=A0 =C2=A0RPL instanceID, perhaps one with a higher energy cost, for= instance.

s/RPL instanceID/RPLinstanceID
[authors]fixed.=C2=A0

...
1911 13.1.=C2=A0 Normative References

[minor] I think that the following references can be made Informative: RFC2= 473, RFC5406
[authors]fixed.=C2=A0

...
1965 13.2.=C2=A0 Informative References

[nit] I-D.ietf-6man-rfc6434-bis is not referenced in the text.
[authors]fixed.=C2=A0

Many thanks again A= lvaro!!!

Datatracker URL: https://datatracker.i= etf.org/doc/draft-ietf-roll-useofrplinfo/

--000000000000f5a7fa0580274d67-- From nobody Mon Jan 28 07:07:33 2019 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B941200D7; Mon, 28 Jan 2019 07:07:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: roll-chairs@ietf.org, roll@ietf.org, mariainesrobles@googlemail.com, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154868805180.3083.14932364610714305513.idtracker@ietfa.amsl.com> Date: Mon, 28 Jan 2019 07:07:31 -0800 Archived-At: Subject: [Roll] roll - New Meeting Session Request for IETF 104 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2019 15:07:32 -0000 A new meeting session request has just been submitted by Ines Robles, a Chair of the roll working group. --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Ines Robles Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: anima manet 6tisch core ace Second Priority: rtgarea 6lo 6man lwig cbor t2trg Third Priority: rtgwg intarea lpwan People who must be present: Michael Richardson Peter van der Stok Alvaro Retana Ines Robles Resources Requested: Special Requests: One of the chairs leaves on Thursday afternoon, it would be nice please if we could have the meeting before Thursday. Meetecho Support --------------------------------------------------------- From nobody Wed Jan 30 08:01:13 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E1C126F72; Wed, 30 Jan 2019 08:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NWCwMKyK65w; Wed, 30 Jan 2019 08:01:07 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E1012426E; Wed, 30 Jan 2019 08:01:04 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id t204so14267oie.7; Wed, 30 Jan 2019 08:01:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=HNmzYfgrG4CbcfK6HwqGIHhDBOOnhxpBYSZ8a8gB+dc=; b=EewQ9FgEknfSRbrpA7MUl2jtPAFptRij4Z8DhwQ2KmfJbefJepY/bxzuUAnTioHfLi K0h9tnCTRELHPmyhNPxXOBS+URvKvp/U867wx3x7bcFQ/dB5RvQyiQnaPCTRqt+wT+md sULQQT0MFKsG4/rG9a29pyKZZO+daGx2epoJGefmw5O6dLWv8kUlH0drh6WH4r+drvas OE7wwKsCMJu4CmM1JaNYHWYEI8LpVI7ZjzJwB9ygwgUBdO1UpG5B3SLkBMXDa4ylPr8i oejcOkCE+BwbWgwPtJIR4XUnkyN9B8iUkXbH9LNWDJCPPJGQgiFUzE/FYIeqoOyVlUIj 8O9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=HNmzYfgrG4CbcfK6HwqGIHhDBOOnhxpBYSZ8a8gB+dc=; b=CqcuVMxqjNH9t8cmOb/L5NSbGOAfztItVsNbZJbgOzdU16ksGXy3oCkmBKdGYSZiIo 7M4PYnQI17kweEpSDL8MaYQkf4OoZLJ1gf5NxLPtXPDug2b6Fio/LND49+LmswzQV/+y FTGzDQZgksSJl+mDPO4H2t2/oiMb3oqfPorIJXAeyhO0MDiQPYWumSgXRKk52wIkh5Zn 7M4T3t314i0xyESY1rMaL9aGCzl2Lzf7QK3QuKVtgFWvxPos9RFn4G0xTXIfKH0LfU7s B8DfPdpbahtDA3GzkfvS3FFsktFropWpgDDBVJBw0TIgwq6RSXAhNedrNz4TEBmt3u6u 7TWA== X-Gm-Message-State: AHQUAuZMyjuLbvsIB4fMuvMHoeJWqPn7020EhF0e2jeqAbkiYfSkTXAQ 0HWodzdbrtlkb4RuLOlSK6Y8/lAqSgq+os2uuu4= X-Google-Smtp-Source: AHgI3IYd8LzIfJJNU8+dQr2RuMTMzOddqUGPzUB+CZbHvC+O/S7Y30oPJZrBirhXqF8IfzT8/+jK+Tx3jatiySPPvGo= X-Received: by 2002:aca:a881:: with SMTP id r123mr13074107oie.207.1548864063242; Wed, 30 Jan 2019 08:01:03 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 Jan 2019 08:01:02 -0800 From: Alvaro Retana In-Reply-To: References: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Wed, 30 Jan 2019 08:01:02 -0800 Message-ID: To: Ines Robles , draft-ietf-roll-useofrplinfo@ietf.org Cc: roll , roll-chairs@ietf.org, Peter van der Stok Content-Type: multipart/alternative; boundary="0000000000004b868e0580af04c7" Archived-At: Subject: Re: [Roll] Datatracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 16:01:12 -0000 --0000000000004b868e0580af04c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 23, 2019 at 5:06:24 PM, Ines Robles ( mariainesrobles@googlemail.com) wrote: [Explicitly adding the Chairs, the Shepherd and the Authors=E2=80=99 alias= =E2=80=A6just for completeness, even though everyone should be in the WG list and there=E2=80= =99s overlap. ;-) ] Ines: Hi! I have some comments below, please take a look. Many of these comments are minor and nits =E2=80=94 the significant items that I think we should settl= e on before starting the IETF LC are: - =E2=80=9Cnormative examples=E2=80=9D (point #1 below): I=E2=80=99ll let y= ou chose how you want to move forward (see below) - Operational Considerations (=C2=A79) is WIP - dependency on I-D.thubert-roll-unaware-leaves (look for line 894) Thanks!! Alvaro. ... (1) [major] Where is the specification of the data-plane behavior? > This document does a couple of things: it Updates several other RFCs, and > presents a list of *example* flows where the expected behavior is > illustrated. The Updates are mostly about the new RPI value (0x23), but > not about the behavior of the nodes. > > Most of the examples are worded such that they describe actions > (encapsulate, remove, etc.)...and some even include rfc2119 Normative > Keywords. But they are called examples! So...my questions are: is the > behavior illustrated in =C2=A76 and =C2=A77 intended to be Normative? [authors]The examples are intended to illustrate the result of the normative language in RFC8200 and RFC6553. So the examples are intended to be normative explanation of the results of executing that language. > IOW, do these sections include both examples and specify the behavior > expected in the LLN? Is the behavior already specified somewhere else (a= nd > this document is just illustrating)? [authors]The normative language is in RFC8200 (ipv6bis) section 4.2 and section 4, =E2=80=9CThe Hop-by-Hop Options=E2=80=A6=E2=80=9D Combined with the desired results of RFC6553, we conclude that we have to change the option value in order to make things work. I understand what you=E2=80=99re trying to do. To me, a =E2=80=9CNormative example=E2=80=9D is an impossible oxymoron: it= =E2=80=99s either an example or it is a Normative specification of the behavior. In this document, the scenarios (maybe a better word than example, specially given how exhaustive the document is in considering all the possibilities) are not consistently treated as not all of them are described using Normative language. Being consistent is *very* important given that we=E2=80=99re dealing with Normative language... **But** my heartburn really flares up when you mention "the normative language in RFC8200...=E2=80=9D because rfc8200 doesn=E2=80=99t use rfc2119= keywords at all. :-( The use of rfc2119 language is a completely separate discussion, but using it here as an interpretation of what is meant in rfc8200 is a stretch=E2=80=A6at least to me. What do I want to see? I would prefer to see the scenarios described NOT using rfc2119 keywords: simply changing the case would be enough. I don=E2=80=99t want to turn this review into a debate around rfc2119 and m= uch less about how to interpret rfc8200. If you really, really prefer to keep the Normative language, please be consistent (use it in all the scenarios). We can see if anyone else in the IESG picks up on this same point or not=E2=80= =A6 ... (2) [major] Operational Considerations > > Non-storing mode networks don't need the change to 0x23 (=C2=A78.2)...but > making the change creates a flag day, and even then, implementations shou= ld > still process both values (=C2=A73.1). I would really like to see text a= bout > the operational considerations of introducing 0x23. It concerns me that = a > significant change that most[*] networks don't need is being introduced. > Please take a look at rfc5706 (Guidelines for Considering Operations and > Management of New Protocols and Protocol Extensions), specially =C2=A72. > > [*] Most deployed networks work in non-storing mode, right? > [authors]following our understanding, mostly yes. but, e.g. Anima network in storing mode. Not having loop detection. https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-18#sec= tion-6.11.1.3 Thanks for including Operational Considerations. =C2=A78 looks good to me= =E2=80=A6and I see that =C2=A79 is still WIP. ... [nit] I think the Introduction would benefit from an overview of the > document; something like "section X talks about abc, section Y presents > examples, etc.". [authors]added This new section mentions the old =C2=A79. ... 187 Flag day: A "flag day" is a procedure in which the network, or a part > 188 of it, is changed during a planned outage, or suddenly, causing an > 189 outage while the network recovers [RFC4192] > > [nit] rfc4192 seems like an odd place to pull a reference to "flag day" -= - > specially as it is being defined as "a procedure" and not the effect it > causes, which seems to be how it is used in the text: "creates a flag day= ", > "will experience a flag day", "avoid a flag day". This is not a big issu= e > -- if it was up to me, I would either make my own definition, or just not > define it at all: I think it is a well known term... > [authors]fixed. rewritten New text: 217 Flag Day: A transition that involves have a network with different 218 values of RPL Option Type. Thus the network do not work correctly. s/involves have a network/involves having a network s/network do not work/network does not work Also, the reference to rfc4192 is not needed anymore. ... ... 266 When forwarding packets, implementations SHOULD use the same value as > 267 it was received (This is required because, RPI type code can not be > 268 changed by [RFC8200]). It allows to the network to be incrementall= y > 269 upgraded, and for the DODAG root to know which parts of the network > 270 are upgraded. > > [major] There seems to be a contradiction above: "SHOULD use the same > value...this is required..." If required by rfc8200, why not use MUST? > [authors]rewritten > > 272 When originating new packets, implementations SHOULD have an option > 273 to determine which value to originate with, this option is controll= ed > 274 by the DIO option described below. > > [minor] =C2=A73.3 defines the option...but it doesn't explicitly say what= the > receivers should do with it. It may be obvious, but it should be explici= t > for completeness. > [authors]rewritten > > [major] It seems to me that the paragraph above may be out of place, > doesn't say much, may be wrong...or maybe all 3. The text says that the > originating value is controlled by the option in =C2=A73.3 (again, but th= at > section doesn't explicitly say what should be done)...but it also says > (with the SHOULD) that an implementation may have valid reasons to not pa= y > attention to the option -- what are those?? > [authors]rewritten to "In the cases where a forwarding node is forwarding traffic that is not addressed directly to it (such as when the outer IPv6-in-IPv6 header is not a Link-Local address), then RFC8200 forbids changing the RPI type code when forwarding. When forwarding traffic that is wrapped in Link-Local IPv6-in-IPv6 headers, the forwarding node is in effect originating new packets, and it MAY make a choice as to whether to use the old (0x63) RPI Type code, or the new (0x23) RPI Type code. In that situation, implementations SHOULD use the same value as was received. This allows to the network to be incrementally upgraded, and in some cases may allow the DODAG root to know which parts of the network are upgraded." Ok, that looks good. You also added: 323 Non-constrained uses of RPL are not in scope of this document, and 324 applicability statements for those uses MAY provide different advice= , 325 E.g. [I-D.ietf-anima-autonomic-control-plane]. If out of scope, don=E2=80=99t use Normative language there. ... 613 Figure 7: IP-in-IP encapsulation in Storing mode. [nit] The table above is called Figure=E2=80=A6 There are also some Tables.= Maybe be consistent about what is called a Table and what is called a Figure. Personally, I don=E2=80=99t care=E2=80=A6I just would prefer consistency. ... 894 Note that there is a requirement that the final node be able to 895 remove one or more IP-in-IP headers which are all addressed to it, > 896 mentioned in [I-D.thubert-roll-unaware-leaves] : > > 898 "RPL data packets are often encapsulated using IP in IP. The 6LN > 899 MUST be able to decapsulate a packet when it is the destination of > 900 the outer header and process correctly the inner header." > > [major] I realize that we're not reviewing I-D.thubert-roll-unaware-leave= s > at this point, but how can a requirement be placed on a not-RPL-aware-lea= f > if, by definition, it is not aware of RPL?? ...and I don't think we can > assume it is aware of any other requirement... > [authors] We understand that the requirements are placed on the 6LR that accepts the 6LN registration and also inject the relevant routing information on its behalf. The text above talks abut the 6LN, not the 6LR. If this document depends on the requirement in > I-D.thubert-roll-unaware-leaves, then the reference should be Normative (= it > is now listed as Informative). > [authors]fixed I still don=E2=80=99t feel too good about depending on requirements for not-RPL-aware nodes in the network=E2=80=A6. In this case, this document wi= ll not be able to be published as an RFC until that *individual* draft is published. Is that what you want? Is there any way to work around this dependency? Why isn=E2=80=99t rfc8200 support enough in this case? ... 1194 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root > > 1196 In non-storing mode the leaf node uses default routing to send > 1197 traffic to the root. The RPI header must be included to > avoid/detect > 1198 loops. > > [major] Should that "must" be Normative? > [authors] fixed. 1322 In non-storing mode the leaf node uses default routing to send 1323 traffic to the root. The RPI header MUST be included since contain= s 1324 the rank information, which is used to avoid/detect loops. s/be included since contains/be included since it contains ... 1254 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf ... > 1267 In 6LBR the RH3 is added, it is modified at each intermediate 6LR > 1268 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n)= , > 1269 but left there. If RPI is left present, the IPv6 node which does > not > 1270 understand it will ignore it (following RFC8200), thus encapsulati= on > 1271 is not necesary. Due the complete knowledge of the topology at th= e > 1272 root, the 6LBR may optionally address the IP-in-IP header to the > last > 1273 6LR, such that it is removed prior to the IPv6 node. > > s/necesary/necessary > > [major] So...encapsulation is not needed, but an IP-in-IP header is > optional. When? Are there advantages, disadvantages? Same questions > about the RPI. > [authors]rewritten. s/Due the complete/Due to the complete ... 1731 9. 6LoRH Compression cases > 1733 The [RFC8138] proposes a compression method for RPI, RH3 and > IPv6-in- > 1734 IPv6. > > 1736 In Storing Mode, for the examples of Flow from RPL-aware-leaf to > non- > 1737 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf compri= se > 1738 an IP-in-IP and RPI compression headers. The type of this case is > 1739 critical since IP-in-IP is encapsulating a RPI header. > > 1741 > +--+-----+---+--------------+-----------+-------------+-------------+ > 1742 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPH= C > | > 1743 > +--+-----+---+--------------+-----------+-------------+-------------+ > > 1745 Figure 9: Critical IP-in-IP (RPI). > > [major] Shouldn't this section also be an Update to rfc8138? > > [major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it is > introduced as Critical here. The header must then be completely specifie= d > in this document and the appropriate registry must be updated (in the IAN= A > Consideration section). > > Specifically...referring to rfc8138... > - the meaning of the TSE depends on the Type (=C2=A74.2), > - the Hop Limit is defined in =C2=A77, should it have the same > behavior/meaning here? > - does the "RPI - 6LoRH" field correspond to the RPI-6LoRH header > (=C2=A76.3)? > - I'm assuming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC > (rfc6282). > [authors] we think that the confusion is because we wrote: =E2=80=9CThe typ= e of this case=E2=80=9D... which sounds like we are changing 8138, when what we mean is that use of this elective type is a MUST for RPL. Type 6 (compressed RPI) is elective in 8138 because non-RPL uses of 6lowpan do not need to support (compressed) RPI headers, but this document makes it a MUST because RPL uses of 6lowpan need it. Is there text that we need to update? I see that you moved this text to =C2=A73.2. The Figure (now 3) is still labeled as =E2=80=9Ccritical=E2=80=9D. ... > 1774 11. Security Considerations Your responses to trisection indicated several times =E2=80=9CDiscussion on= the list=E2=80=9D, but I could=E2=80=99t find those discussions. Did they happ= en already? I would prefer it if the document has mitigation suggestions (at least) in it; that usually makes the SecDir happier. ;-) But that is not an absolute requirement before moving this document forward. ... [major] What does "SHOULD be suspicious" mean? How is that a Normative > behavior? Would being suspicious include dropping the packet or some oth= er > similar action? When would the router *not* be suspicious? Why is that > not a "MUST"? [authors]The presence of the second RH3 means that there is a configuration mistake somewhere else in the network. It would be reasonable to incremen= t a counter in a MIB (if we had a MIB) when this occurs. Based upon the Postel doctrine, ignoring the extra header (not acting on it), is the best policy. An RH3 header was not completely consumed is discussed in RFC https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header wit= h additional =E2=80=9Cnon-zero Segments Left value, if the IPv6 Destination = Address is not on-link=E2=80=9D should be dropped. In this case, the RH3 header is = *inside* the outer IPv6-in-IPv6 header, which has then been forwarded. We think that this header should simply be ignored in processing the packet= . To do otherwise (such as forwarding) would permit external attackers to send traffic that appears to originate inside the LLN. To be discussed on list Ok=E2=80=A6whatever the outcome is, to =E2=80=9Cbe suspicious=E2=80=9D is n= ot something that can be enforced normatively. SHOULD log and error, etc..is something actionable. --0000000000004b868e0580af04c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 23, 2019 at 5:06:24 PM, Ines Robles (= mariainesrobles@googlemai= l.com) wrote:

[= Explicitly adding the Chairs, the Shepherd and the Authors=E2=80=99 alias= =E2=80=A6just for completeness, even though everyone should be in the WG li= st and there=E2=80=99s overlap. ;-) =C2=A0]

Ines:

Hi!

I h= ave some comments below, please take a look.=C2=A0 Many of these comments a= re minor and nits =E2=80=94 the significant items that I think we should se= ttle on before starting the IETF LC are:

- =E2=80=9Cnormative examples=E2=80=9D (point #1 belo= w): I=E2=80=99ll let you chose how you want to move forward (see below)
- Operational C= onsiderations (=C2=A79) is WIP
- dependency on=C2=A0I-D.thubert-roll-unaware-leaves (lo= ok for line 894)

Th= anks!!

<= /div>
Alvaro.


...
<= div dir=3D"ltr">
(1) [major] Where is the specification of= the data-plane behavior?

This document do= es a couple of things: it Updates several other RFCs, and presents a list o= f *example* flows where the expected behavior is illustrated.=C2=A0 The Upd= ates are mostly about the new RPI value (0x23), but not about the behavior = of the nodes.

Most of the examples are worded such that they describ= e actions (encapsulate, remove, etc.)...and some even include rfc2119 Norma= tive Keywords.=C2=A0 But they are called examples!=C2=A0 So...my questions = are: is the behavior illustrated in =C2=A76 and =C2=A77 intended to be Norm= ative?=C2=A0


[authors]The examples are intended to illustrate the r= esult of the normative language in RFC8200 and RFC6553.
So the ex= amples are intended to be normative explanation of the results of executing= that language.=C2=A0

=C2=A0=C2=A0
IOW, do these sections include both examples and specify the b= ehavior expected in the LLN?=C2=A0 Is the behavior already specified somewh= ere else (and this document is just illustrating)?

[authors]The normative language is in RFC8200 (ipv6bis) sectio= n 4.2 and section 4, =E2=80=9CThe Hop-by-Hop Options=E2=80=A6=E2=80=9D
Combined with the desired results of=C2=A0 RFC6553, we conclude that = we have to change the option value in order to make things work.
=

I understand what you=E2=80=99re trying to do.

To me, a =E2=80= =9CNormative example=E2=80=9D is an impossible oxymoron: it=E2=80=99s eithe= r an example or it is a Normative specification of the behavior. =C2=A0

In this document, the scenarios (maybe a better word = than example, specially given how exhaustive the document is in considering= all the possibilities) are not consistently treated as not all of them are= described using Normative language.=C2=A0 Being consistent is *very* impor= tant given that we=E2=80=99re dealing with Normative language...
=
**But** my heartburn really flares up when you mention "= ;the normative language in RFC8200...=E2=80=9D because rfc8200 doesn=E2=80= =99t use rfc2119 keywords at all. :-( =C2=A0The use of rfc2119 language is = a completely separate discussion, but using it here as an interpretation of= what is meant in rfc8200 is a stretch=E2=80=A6at least to me.
<= div>
What do I want to see?=C2=A0 I would prefer to see the s= cenarios described NOT using rfc2119 keywords: simply changing the case wou= ld be enough.

I don=E2=80=99t want to turn this re= view into a debate around rfc2119 and much less about how to interpret rfc8= 200.=C2=A0 If you really, really prefer to keep the Normative language, ple= ase be consistent (use it in all the scenarios).=C2=A0 We can see if anyone= else in the IESG picks up on this same point or not=E2=80=A6

...

= (2) [major] Operational Considerations

Non-storing mode networks don= 't need the change to 0x23 (=C2=A78.2)...but making the change creates = a flag day, and even then, implementations should still process both values= (=C2=A73.1).=C2=A0 I would really like to see text about the operational c= onsiderations of introducing 0x23.=C2=A0 It concerns me that a significant = change that most[*] networks don't need is being introduced.=C2=A0 Plea= se take a look at rfc5706 (Guidelines for Considering Operations and Manage= ment of New Protocols and Protocol Extensions), specially =C2=A72.

[= *] Most deployed networks work in non-storing mode, right?
=

[authors]following our understanding, mostly yes.
=
but, e.g. Anima network in storing mode. Not having loop detection.
=
=
=
=

Thanks for= including Operational Considerations. =C2=A0=C2=A78 looks good to me=E2=80= =A6and I see that =C2=A79 is still WIP.


...

<= div>
[nit] I think the Introduc= tion would benefit from an overview of the document; something like "s= ection X talks about abc, section Y presents examples, etc.".

[authors]added=C2=A0
<= /div>
<= /div>
<= /div>
<= /div>

This new section mentio= ns the old =C2=A79.


...

=
<= div dir=3D"ltr">
187=C2=A0 =C2=A0Flag day: A "flag day" is a= procedure in which the network, or a part
188=C2=A0 =C2=A0of it, is cha= nged during a planned outage, or suddenly, causing an
189=C2=A0 =C2=A0ou= tage while the network recovers [RFC4192]

[nit] rfc4192 seems like a= n odd place to pull a reference to "flag day" -- specially as it = is being defined as "a procedure" and not the effect it causes, w= hich seems to be how it is used in the text: "creates a flag day"= , "will experience a flag day", "avoid a flag day".=C2= =A0 This is not a big issue -- if it was up to me, I would either make my o= wn definition, or just not define it at all: I think it is a well known ter= m...

[authors]fixed. rewritten=C2=A0
=
=
=

New text:

217	   Flag Day: A transition that involves have a n=
etwork with different
218	   values of RPL Option Type.  Thus the network do not work correctly.

s/involves have a network/involves having a network

s/networ= k do not work/network does not work

Also, the reference to rfc4192 is= not needed anymore.


...
...
266=C2=A0 =C2=A0W= hen forwarding packets, implementations SHOULD use the same value as
267= =C2=A0 =C2=A0it was received (This is required because, RPI type code can n= ot be
268=C2=A0 =C2=A0changed by [RFC8200]).=C2=A0 It allows to the netw= ork to be incrementally
269=C2=A0 =C2=A0upgraded, and for the DODAG root= to know which parts of the network
270=C2=A0 =C2=A0are upgraded.
[major] There seems to be a contradiction above: "SHOULD use the same= value...this is required..."=C2=A0 =C2=A0If required by rfc8200, why = not use MUST?
[authors]rewritten=C2=A0

272=C2=A0 =C2=A0When originating new packets, implementations SH= OULD have an option
273=C2=A0 =C2=A0to determine which value to originat= e with, this option is controlled
274=C2=A0 =C2=A0by the DIO option desc= ribed below.

[minor] =C2=A73.3 defines the option...but it doesn'= ;t explicitly say what the receivers should do with it.=C2=A0 It may be obv= ious, but it should be explicit for completeness.
[aut= hors]rewritten=C2=A0

[major] It seems to me that = the paragraph above may be out of place, doesn't say much, may be wrong= ...or maybe all 3.=C2=A0 The text says that the originating value is contro= lled by the option in =C2=A73.3 (again, but that section doesn't explic= itly say what should be done)...but it also says (with the SHOULD) that an = implementation may have valid reasons to not pay attention to the option --= what are those??

[authors]rewritten to=
"In the cases where a forwarding node is forwarding traffic= that is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addressed d= irectly to it (such as when the outer IPv6-in-IPv6 header is not a Link-Loc= al address),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then RFC820= 0 forbids changing the RPI type code when forwarding.

<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When forwarding traffic that i= s wrapped in Link-Local IPv6-in-IPv6 headers,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the forwarding node is in effect originating new pa= ckets,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and it MAY make a= choice as to whether to use the old (0x63) RPI Type code,
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or the new (0x23) RPI Type code. In that= situation, implementations SHOULD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0use the same value as was received.=C2=A0 This allows to the n= etwork to be incrementally upgraded,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0and in some cases may allow the DODAG root to know which parts= of the network are upgraded."=C2=A0
<= /div>
<= /div><= /div>

Ok, that looks good.

You also added:

323	   Non-constrained uses of RPL are not in scop=
e of this document, and
324	   applicability statements for those uses MAY provide different advice=
,
325	   E.g.  [I-D.ietf-anima-autonomic-control-plane].

If out of scope, don=E2=80=99t use Normative language there.


...
<= div>
613=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fi= gure 7: IP-in-IP encapsulation in Storing mode.
=
=
=
<= /div>
<= /div>
<= /div>

=
=
=
=

[nit] The table above is call= ed Figure=E2=80=A6 There are also some Tables.=C2=A0 Maybe be consistent ab= out what is called a Table and what is called a Figure.=C2=A0 Personally, I= don=E2=80=99t care=E2=80=A6I just would prefer consistency.

=
...
894= =C2=A0 =C2=A0Note that there is a requirement that the final node be able t= o
895=C2=A0 =C2=A0remove one or more IP-in-IP = headers which are all addressed to it,
896=C2=A0 =C2=A0mentioned in [I-D= .thubert-roll-unaware-leaves] :

898=C2=A0 =C2=A0"RPL data packe= ts are often encapsulated using IP in IP.=C2=A0 The 6LN
899=C2=A0 =C2=A0= MUST be able to decapsulate a packet when it is the destination of
900= =C2=A0 =C2=A0the outer header and process correctly the inner header."=

[major] I realize that we're not reviewing I-D.thubert-roll-una= ware-leaves at this point, but how can a requirement be placed on a not-RPL= -aware-leaf if, by definition, it is not aware of RPL??=C2=A0 =C2=A0...and = I don't think we can assume it is aware of any other requirement...
=
[authors] We understand that the requirements are placed = on the 6LR that accepts the 6LN
=C2=A0 =C2=A0registration and als= o inject the relevant routing information on its behalf.=C2=A0
<= /div>
<= /div>
<= /div>
<= /div>

The t= ext above talks abut the 6LN, not the 6LR.

If this document depends on the requirement in I-D= .thubert-roll-unaware-leaves, then the reference should be Normative (it is= now listed as Informative).
[authors]fixed=C2=A0
=

I still don=E2=80=99t feel too good about depending on requirements for = not-RPL-aware nodes in the network=E2=80=A6. In this case, this document wi= ll not be able to be published as an RFC until that *individual* draft is p= ublished.=C2=A0 Is that what you want?=C2=A0 Is there any way to work aroun= d this dependency?=C2=A0 Why isn=E2=80=99t rfc8200 support enough in this c= ase?


...

1194 7.1.1.=C2=A0 Non-SM: Example of Flow from RPL-aware-leaf to ro= ot

1196=C2=A0 =C2=A0In non-storing mode the leaf node uses default r= outing to send
1197=C2=A0 =C2=A0traffic to the root.=C2=A0 The RPI heade= r must be included to avoid/detect
1198=C2=A0 =C2=A0loops.

[major= ] Should that "must" be Normative?
[authors]= fixed.=C2=A0
<= /blockquote>
1322	   In non-storing mode the leaf node uses defau=
lt routing to send
1323	   traffic to the root.  The RPI header MUST be included since contain=
s
1324	   the rank information, which is used to avoid/detect loops.

= s/be included since contains/be included since it contains


...

=
1254 7.1.3.= =C2=A0 Non-SM: Example of Flow from root to not-RPL-aware-leaf
=
...
1267=C2=A0 =C2=A0In 6LBR the RH3 is added, it is mo= dified at each intermediate 6LR
1268=C2=A0 =C2=A0(6LR_1 and so on) and i= t is fully consumed in the last 6LR (6LR_n),
1269=C2=A0 =C2=A0but left t= here.=C2=A0 If RPI is left present, the IPv6 node which does not
1270=C2= =A0 =C2=A0understand it will ignore it (following RFC8200), thus encapsulat= ion
1271=C2=A0 =C2=A0is not necesary.=C2=A0 Due the complete knowledge o= f the topology at the
1272=C2=A0 =C2=A0root, the 6LBR may optionally add= ress the IP-in-IP header to the last
1273=C2=A0 =C2=A06LR, such that it = is removed prior to the IPv6 node.

s/necesary/necessary

[majo= r] So...encapsulation is not needed, but an IP-in-IP header is optional.=C2= =A0 When?=C2=A0 Are there advantages, disadvantages?=C2=A0 =C2=A0Same quest= ions about the RPI.
[authors]rewritten.=C2=A0
=
=
=

s= /Due the complete/Due to the complete


...

<= div dir=3D"ltr">
1731 9.=C2=A0 6LoRH Compression cases

1733=C2=A0 =C2=A0The [RFC8138] proposes a co= mpression method for RPI, RH3 and IPv6-in-
1734=C2=A0 =C2=A0IPv6.
1736=C2=A0 =C2=A0In Storing Mode, for the examples of Flow from RPL-aware-= leaf to non-
1737=C2=A0 =C2=A0RPL-aware-leaf and non-RPL-aware-leaf to n= on-RPL-aware-leaf comprise
1738=C2=A0 =C2=A0an IP-in-IP and RPI compress= ion headers.=C2=A0 The type of this case is
1739=C2=A0 =C2=A0critical si= nce IP-in-IP is encapsulating a RPI header.

1741=C2=A0 =C2=A0+--+---= --+---+--------------+-----------+-------------+-------------+
1742=C2= =A0 =C2=A0|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IP= HC |
1743=C2=A0 =C2=A0+--+-----+---+--------------+-----------+---------= ----+-------------+

1745=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 9: Critical IP-in-IP (RPI).

[majo= r] Shouldn't this section also be an Update to rfc8138?

[major] = 6LoRH Type 6 is defined in rfc8138 as an elective type, but it is introduce= d as Critical here.=C2=A0 The header must then be completely specified in t= his document and the appropriate registry must be updated (in the IANA Cons= ideration section).

Specifically...referring to rfc8138...
=C2=A0= =C2=A0- the meaning of the TSE depends on the Type (=C2=A74.2),
=C2=A0 = =C2=A0- the Hop Limit is defined in =C2=A77, should it have the same behavi= or/meaning here?
=C2=A0 =C2=A0- does the "RPI - 6LoRH" field c= orrespond to the RPI-6LoRH header (=C2=A76.3)?
=C2=A0 =C2=A0- I'm as= suming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC (rfc628= 2).

[authors] we think that the confusi= on is because we wrote: =E2=80=9CThe type of this case=E2=80=9D...
which sounds like we are changing 8138, when what we mean is that use of = this elective type is a MUST for RPL.
Type 6 (compressed RPI) is = elective in 8138 because non-RPL uses of 6lowpan do not
need to s= upport (compressed) RPI headers, but this document makes it a MUST because<= /div>
RPL uses of 6lowpan need it. Is there text that we need to update= ?=C2=A0

I see that you mov= ed this text to =C2=A73.2.=C2=A0 The Figure (now 3) is still labeled as =E2= =80=9Ccritical=E2=80=9D.


...
1774 11.=C2=A0 Secu= rity Considerations
<= /div>
<= /div>
<= /div>
<= /div>


=
=
=
Your responses to trisection indica= ted several times =E2=80=9CDiscussion on the list=E2=80=9D, but I could=E2= =80=99t find those discussions.=C2=A0 Did they happen already? =C2=A0
=

I would prefer it if the document has mitigation sugges= tions (at least) in it; that usually makes the SecDir happier. ;-) =C2=A0Bu= t that is not an absolute requirement before moving this document forward.<= /div>

...
[major] What does "SHOULD be suspicious" mean?=C2=A0 How = is that a Normative behavior?=C2=A0 Would being suspicious include dropping= the packet or some other similar action?=C2=A0 When would the router *not*= be suspicious?=C2=A0 Why is that not a "MUST"?
= =C2=A0
[authors]The presence of the second RH3 means that there i= s a configuration
=C2=A0mistake somewhere else in the network.=C2= =A0 It would be reasonable to increment
=C2=A0 a counter in a MIB= (if we had a MIB) when this occurs.=C2=A0 Based upon the Postel
= =C2=A0 =C2=A0doctrine, ignoring the extra header (not acting on it), is the= best policy.
=C2=A0 =C2=A0 An RH3 header was not completely cons= umed is discussed in RFC

https://tools.ietf.org/html/rfc6554#sect= ion-4.2=C2=A0says that an = RH3 header with
=C2=A0additional =E2=80=9Cnon-zero Segments Left = value, if the IPv6 Destination Address is
=C2=A0 not on-link=E2= =80=9D should be dropped.=C2=A0 In this case, the RH3 header is *inside*
=C2=A0 the outer IPv6-in-IPv6 header, which has then been forwarded= .
We think that this header should simply be ignored in processin= g the packet.
=C2=A0To do otherwise (such as forwarding) would pe= rmit external attackers to send
=C2=A0traffic that appears to ori= ginate inside the LLN.

=C2=A0To be discussed on li= st=C2=A0
<= /div><= /div><= /div>

Ok=E2=80=A6whatever the outcome is, to =E2=80=9Cbe suspicio= us=E2=80=9D is not something that can be enforced normatively.=C2=A0 SHOULD= log and error, etc..is something actionable.

<= /html> --0000000000004b868e0580af04c7-- From nobody Wed Jan 30 10:07:35 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5AC131300; Wed, 30 Jan 2019 10:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPtzpIvYO4QV; Wed, 30 Jan 2019 10:07:30 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0D4130ECE; Wed, 30 Jan 2019 10:07:29 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id h15so384976edb.4; Wed, 30 Jan 2019 10:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/+pCKp0z7PlUorSrgYPq8fIVC1JRGzHliW55shXRuB0=; b=hokrhA1fWETaqpAet8F+qqH1cyfZJ7PYCXn15LS60MVsgAJQ082A81nuZ52kIEPnUO cQoJ4u3WBdsv9McrgNvbQHhSa4U7KC6FlEiUF21jS3N3eYC4yFrmB+f6skeDxE9yd3jD h+qO+3B52AQSRhmzkk8vmIOK2nuZRF/kQJTNw1gtf6N/X3/yddE9v2CGlByVpy9ehObx wKnoJIN5V0MCIOCl25MbtnrEmDm8LdFW+WnKofGulrA7EUzo3K5fdLvctnA1/vXGWvs5 GP6pIcZF3cV2nbIGmKsDVYmeosbBWfBfa1aREC3FCasFb5zjcVoPJF0wc/tu3VSCoTq/ TIQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/+pCKp0z7PlUorSrgYPq8fIVC1JRGzHliW55shXRuB0=; b=q714eV9Tx4SB+sSSs7cV+kV9+qf3oOdiyM27lF7n+IylwKjTlcysIIRfggsIVS+HAJ jgkMxZ+MQEeSymJWh3d92LQ8wSH9QflXhUJSE8BH+MSV4hqA8XvGEBJU5w129lkDzhQf XGNxbzHBQoSOQ1zk8J7+EpNIx//ONY97ZwRXq0lVX8+einx5CT5usrAmWuJYhtvGyQ66 +ggPuJ40oMalxQBMXKaYG1MYIYaBSLWGtnxw5fGOtfSlK6OY0homAiqIL/P+HBSnLcg+ FN559gwqRLrTZreOulzrg4gxgPTuiKHr1GkcnKA850ZMGNdRNlwBO7XwCOEZCtXpFDIV wsHQ== X-Gm-Message-State: AJcUukfS6pRpmdGqmHEij1DIFFITFHsgQuVY0e33Ie+wxnXupKnOyslo 7dRF5Ls810IuIb2uJGt04WB2j/pD7YsQBjiDyrw= X-Google-Smtp-Source: ALg8bN7QaMR4qaD215RrHsEpkU6fpOyV5dp1ZvUOBjSBjYS8pmQ5+e6/PzYpWBXKprOGoioc3uUnl91+RYdJaRI5wrQ= X-Received: by 2002:a17:906:4058:: with SMTP id y24mr24994533ejj.230.1548871647354; Wed, 30 Jan 2019 10:07:27 -0800 (PST) MIME-Version: 1.0 References: <153427390944.27108.4373520532151309638.idtracker@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Wed, 30 Jan 2019 20:07:15 +0200 Message-ID: To: Alvaro Retana Cc: roll , Peter van der Stok , draft-ietf-roll-useofrplinfo@ietf.org Content-Type: multipart/alternative; boundary="00000000000057e3e40580b0c8c6" Archived-At: Subject: Re: [Roll] Datatracker State Update Notice: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 18:07:34 -0000 --00000000000057e3e40580b0c8c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Alvaro for your comments. We are going to work on those and get back to you. Cheers, Ines. On Wed, Jan 30, 2019 at 6:01 PM Alvaro Retana wrote: > On January 23, 2019 at 5:06:24 PM, Ines Robles ( > mariainesrobles@googlemail.com) wrote: > > [Explicitly adding the Chairs, the Shepherd and the Authors=E2=80=99 alia= s=E2=80=A6just > for completeness, even though everyone should be in the WG list and there= =E2=80=99s > overlap. ;-) ] > > Ines: > > Hi! > > I have some comments below, please take a look. Many of these comments > are minor and nits =E2=80=94 the significant items that I think we should= settle on > before starting the IETF LC are: > > - =E2=80=9Cnormative examples=E2=80=9D (point #1 below): I=E2=80=99ll let= you chose how you want > to move forward (see below) > - Operational Considerations (=C2=A79) is WIP > - dependency on I-D.thubert-roll-unaware-leaves (look for line 894) > > Thanks!! > > Alvaro. > > > ... > > (1) [major] Where is the specification of the data-plane behavior? > > >> This document does a couple of things: it Updates several other RFCs, an= d >> presents a list of *example* flows where the expected behavior is >> illustrated. The Updates are mostly about the new RPI value (0x23), but >> not about the behavior of the nodes. >> >> Most of the examples are worded such that they describe actions >> (encapsulate, remove, etc.)...and some even include rfc2119 Normative >> Keywords. But they are called examples! So...my questions are: is the >> behavior illustrated in =C2=A76 and =C2=A77 intended to be Normative? > > > > [authors]The examples are intended to illustrate the result of the > normative language in RFC8200 and RFC6553. > So the examples are intended to be normative explanation of the results o= f > executing that language. > > > >> IOW, do these sections include both examples and specify the behavior >> expected in the LLN? Is the behavior already specified somewhere else (= and >> this document is just illustrating)? > > > [authors]The normative language is in RFC8200 (ipv6bis) section 4.2 and > section 4, =E2=80=9CThe Hop-by-Hop Options=E2=80=A6=E2=80=9D > Combined with the desired results of RFC6553, we conclude that we have t= o > change the option value in order to make things work. > > I understand what you=E2=80=99re trying to do. > To me, a =E2=80=9CNormative example=E2=80=9D is an impossible oxymoron: i= t=E2=80=99s either an > example or it is a Normative specification of the behavior. > > In this document, the scenarios (maybe a better word than example, > specially given how exhaustive the document is in considering all the > possibilities) are not consistently treated as not all of them are > described using Normative language. Being consistent is *very* important > given that we=E2=80=99re dealing with Normative language... > > **But** my heartburn really flares up when you mention "the normative > language in RFC8200...=E2=80=9D because rfc8200 doesn=E2=80=99t use rfc21= 19 keywords at > all. :-( The use of rfc2119 language is a completely separate discussion= , > but using it here as an interpretation of what is meant in rfc8200 is a > stretch=E2=80=A6at least to me. > > What do I want to see? I would prefer to see the scenarios described NOT > using rfc2119 keywords: simply changing the case would be enough. > > I don=E2=80=99t want to turn this review into a debate around rfc2119 and= much > less about how to interpret rfc8200. If you really, really prefer to kee= p > the Normative language, please be consistent (use it in all the > scenarios). We can see if anyone else in the IESG picks up on this same > point or not=E2=80=A6 > > ... > > (2) [major] Operational Considerations >> >> Non-storing mode networks don't need the change to 0x23 (=C2=A78.2)...bu= t >> making the change creates a flag day, and even then, implementations sho= uld >> still process both values (=C2=A73.1). I would really like to see text = about >> the operational considerations of introducing 0x23. It concerns me that= a >> significant change that most[*] networks don't need is being introduced. >> Please take a look at rfc5706 (Guidelines for Considering Operations and >> Management of New Protocols and Protocol Extensions), specially =C2=A72. >> >> [*] Most deployed networks work in non-storing mode, right? >> > > [authors]following our understanding, mostly yes. > but, e.g. Anima network in storing mode. Not having loop detection. > > https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-18#s= ection-6.11.1.3 > > > Thanks for including Operational Considerations. =C2=A78 looks good to m= e=E2=80=A6and > I see that =C2=A79 is still WIP. > > > ... > > [nit] I think the Introduction would benefit from an overview of the >> document; something like "section X talks about abc, section Y presents >> examples, etc.". > > > [authors]added > > This new section mentions the old =C2=A79. > > > ... > > 187 Flag day: A "flag day" is a procedure in which the network, or a pa= rt >> 188 of it, is changed during a planned outage, or suddenly, causing an >> 189 outage while the network recovers [RFC4192] >> >> [nit] rfc4192 seems like an odd place to pull a reference to "flag day" >> -- specially as it is being defined as "a procedure" and not the effect = it >> causes, which seems to be how it is used in the text: "creates a flag da= y", >> "will experience a flag day", "avoid a flag day". This is not a big iss= ue >> -- if it was up to me, I would either make my own definition, or just no= t >> define it at all: I think it is a well known term... >> > > [authors]fixed. rewritten > > New text: > > 217 Flag Day: A transition that involves have a network with different > 218 values of RPL Option Type. Thus the network do not work correctly= . > > s/involves have a network/involves having a network > > s/network do not work/network does not work > > Also, the reference to rfc4192 is not needed anymore. > > ... > > ... > > 266 When forwarding packets, implementations SHOULD use the same value = as >> 267 it was received (This is required because, RPI type code can not b= e >> 268 changed by [RFC8200]). It allows to the network to be incremental= ly >> 269 upgraded, and for the DODAG root to know which parts of the networ= k >> 270 are upgraded. >> >> [major] There seems to be a contradiction above: "SHOULD use the same >> value...this is required..." If required by rfc8200, why not use MUST? >> > [authors]rewritten > >> >> 272 When originating new packets, implementations SHOULD have an optio= n >> 273 to determine which value to originate with, this option is >> controlled >> 274 by the DIO option described below. >> >> [minor] =C2=A73.3 defines the option...but it doesn't explicitly say wha= t the >> receivers should do with it. It may be obvious, but it should be explic= it >> for completeness. >> > [authors]rewritten > >> >> [major] It seems to me that the paragraph above may be out of place, >> doesn't say much, may be wrong...or maybe all 3. The text says that the >> originating value is controlled by the option in =C2=A73.3 (again, but t= hat >> section doesn't explicitly say what should be done)...but it also says >> (with the SHOULD) that an implementation may have valid reasons to not p= ay >> attention to the option -- what are those?? >> > > [authors]rewritten to > "In the cases where a forwarding node is forwarding traffic that is not > addressed directly to it (such as when the outer IPv6-in-IPv6 > header is not a Link-Local address), > then RFC8200 forbids changing the RPI type code when forwardin= g. > > When forwarding traffic that is wrapped in Link-Local > IPv6-in-IPv6 headers, > the forwarding node is in effect originating new packets, > and it MAY make a choice as to whether to use the old (0x63) > RPI Type code, > or the new (0x23) RPI Type code. In that situation, > implementations SHOULD > use the same value as was received. This allows to the networ= k > to be incrementally upgraded, > and in some cases may allow the DODAG root to know which parts > of the network are upgraded." > > Ok, that looks good. > > You also added: > > 323 Non-constrained uses of RPL are not in scope of this document, and > 324 applicability statements for those uses MAY provide different advi= ce, > 325 E.g. [I-D.ietf-anima-autonomic-control-plane]. > > If out of scope, don=E2=80=99t use Normative language there. > > ... > > 613 Figure 7: IP-in-IP encapsulation in Storing mode. > > > > [nit] The table above is called Figure=E2=80=A6 There are also some Table= s. Maybe > be consistent about what is called a Table and what is called a Figure. > Personally, I don=E2=80=99t care=E2=80=A6I just would prefer consistency. > > ... > > 894 Note that there is a requirement that the final node be able to > > 895 remove one or more IP-in-IP headers which are all addressed to it, >> 896 mentioned in [I-D.thubert-roll-unaware-leaves] : >> >> 898 "RPL data packets are often encapsulated using IP in IP. The 6LN >> 899 MUST be able to decapsulate a packet when it is the destination of >> 900 the outer header and process correctly the inner header." >> >> [major] I realize that we're not reviewing >> I-D.thubert-roll-unaware-leaves at this point, but how can a requirement= be >> placed on a not-RPL-aware-leaf if, by definition, it is not aware of RPL= ?? >> ...and I don't think we can assume it is aware of any other requirement= ... >> > [authors] We understand that the requirements are placed on the 6LR that > accepts the 6LN > registration and also inject the relevant routing information on its > behalf. > > The text above talks abut the 6LN, not the 6LR. > > If this document depends on the requirement in >> I-D.thubert-roll-unaware-leaves, then the reference should be Normative = (it >> is now listed as Informative). >> > [authors]fixed > > I still don=E2=80=99t feel too good about depending on requirements for > not-RPL-aware nodes in the network=E2=80=A6. In this case, this document = will not > be able to be published as an RFC until that *individual* draft is > published. Is that what you want? Is there any way to work around this > dependency? Why isn=E2=80=99t rfc8200 support enough in this case? > > > ... > > 1194 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root >> >> 1196 In non-storing mode the leaf node uses default routing to send >> 1197 traffic to the root. The RPI header must be included to >> avoid/detect >> 1198 loops. >> >> [major] Should that "must" be Normative? >> > [authors] fixed. > > 1322 In non-storing mode the leaf node uses default routing to send > 1323 traffic to the root. The RPI header MUST be included since conta= ins > 1324 the rank information, which is used to avoid/detect loops. > > s/be included since contains/be included since it contains > > > ... > > 1254 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf > > ... >> 1267 In 6LBR the RH3 is added, it is modified at each intermediate 6LR >> 1268 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n= ), >> 1269 but left there. If RPI is left present, the IPv6 node which does >> not >> 1270 understand it will ignore it (following RFC8200), thus >> encapsulation >> 1271 is not necesary. Due the complete knowledge of the topology at t= he >> 1272 root, the 6LBR may optionally address the IP-in-IP header to the >> last >> 1273 6LR, such that it is removed prior to the IPv6 node. >> >> s/necesary/necessary >> >> [major] So...encapsulation is not needed, but an IP-in-IP header is >> optional. When? Are there advantages, disadvantages? Same questions >> about the RPI. >> > [authors]rewritten. > > s/Due the complete/Due to the complete > > > ... > > 1731 9. 6LoRH Compression cases > > >> 1733 The [RFC8138] proposes a compression method for RPI, RH3 and >> IPv6-in- >> 1734 IPv6. >> >> 1736 In Storing Mode, for the examples of Flow from RPL-aware-leaf to >> non- >> 1737 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf >> comprise >> 1738 an IP-in-IP and RPI compression headers. The type of this case i= s >> 1739 critical since IP-in-IP is encapsulating a RPI header. >> >> 1741 >> +--+-----+---+--------------+-----------+-------------+-------------+ >> 1742 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN >> IPHC | >> 1743 >> +--+-----+---+--------------+-----------+-------------+-------------+ >> >> 1745 Figure 9: Critical IP-in-IP (RPI). >> >> [major] Shouldn't this section also be an Update to rfc8138? >> >> [major] 6LoRH Type 6 is defined in rfc8138 as an elective type, but it i= s >> introduced as Critical here. The header must then be completely specifi= ed >> in this document and the appropriate registry must be updated (in the IA= NA >> Consideration section). >> >> Specifically...referring to rfc8138... >> - the meaning of the TSE depends on the Type (=C2=A74.2), >> - the Hop Limit is defined in =C2=A77, should it have the same >> behavior/meaning here? >> - does the "RPI - 6LoRH" field correspond to the RPI-6LoRH header >> (=C2=A76.3)? >> - I'm assuming that the "LOWPAN IPHC" field refers to LOWPAN_IPHC >> (rfc6282). >> > > [authors] we think that the confusion is because we wrote: =E2=80=9CThe t= ype of > this case=E2=80=9D... > which sounds like we are changing 8138, when what we mean is that use of > this elective type is a MUST for RPL. > Type 6 (compressed RPI) is elective in 8138 because non-RPL uses of > 6lowpan do not > need to support (compressed) RPI headers, but this document makes it a > MUST because > RPL uses of 6lowpan need it. Is there text that we need to update? > > I see that you moved this text to =C2=A73.2. The Figure (now 3) is still > labeled as =E2=80=9Ccritical=E2=80=9D. > > > ... >> 1774 11. Security Considerations > > > Your responses to trisection indicated several times =E2=80=9CDiscussion = on the > list=E2=80=9D, but I could=E2=80=99t find those discussions. Did they ha= ppen already? > > I would prefer it if the document has mitigation suggestions (at least) i= n > it; that usually makes the SecDir happier. ;-) But that is not an absolu= te > requirement before moving this document forward. > > ... > > [major] What does "SHOULD be suspicious" mean? How is that a Normative >> behavior? Would being suspicious include dropping the packet or some ot= her >> similar action? When would the router *not* be suspicious? Why is that >> not a "MUST"? > > > [authors]The presence of the second RH3 means that there is a configurati= on > mistake somewhere else in the network. It would be reasonable to > increment > a counter in a MIB (if we had a MIB) when this occurs. Based upon the > Postel > doctrine, ignoring the extra header (not acting on it), is the best > policy. > An RH3 header was not completely consumed is discussed in RFC > > https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header > with > additional =E2=80=9Cnon-zero Segments Left value, if the IPv6 Destinatio= n Address > is > not on-link=E2=80=9D should be dropped. In this case, the RH3 header i= s *inside* > the outer IPv6-in-IPv6 header, which has then been forwarded. > We think that this header should simply be ignored in processing the > packet. > To do otherwise (such as forwarding) would permit external attackers to > send > traffic that appears to originate inside the LLN. > > To be discussed on list > > Ok=E2=80=A6whatever the outcome is, to =E2=80=9Cbe suspicious=E2=80=9D is= not something that can > be enforced normatively. SHOULD log and error, etc..is something > actionable. > --00000000000057e3e40580b0c8c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Alvaro for your comments. We are going to work o= n those and get back to you.

Cheers, Ines.

On Wed, Jan 30, 2019 at 6:01 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
On January 23,= 2019 at 5:06:24 PM, Ines Robles (mariainesrobles@googlemail.com) wrote:
=

[Explicitly adding the C= hairs, the Shepherd and the Authors=E2=80=99 alias=E2=80=A6just for complet= eness, even though everyone should be in the WG list and there=E2=80=99s ov= erlap. ;-) =C2=A0]

= Ines:

Hi!

I have some comments below,= please take a look.=C2=A0 Many of these comments are minor and nits =E2=80= =94 the significant items that I think we should settle on before starting = the IETF LC are:

- = =E2=80=9Cnormative examples=E2=80=9D (point #1 below): I=E2=80=99ll let you= chose how you want to move forward (see below)
- Operational Considerations (=C2=A79) = is WIP
- dep= endency on=C2=A0I-D.thubert-roll-unaware-leaves (look for line 894)

Thanks!!

Alvaro.


...
=
<= div dir=3D"ltr">
(1)= [major] Where is the specification of the data-plane behavior?

This document does a= couple of things: it Updates several other RFCs, and presents a list of *e= xample* flows where the expected behavior is illustrated.=C2=A0 The Updates= are mostly about the new RPI value (0x23), but not about the behavior of t= he nodes.

Most of the examples are worded such that they describe ac= tions (encapsulate, remove, etc.)...and some even include rfc2119 Normative= Keywords.=C2=A0 But they are called examples!=C2=A0 So...my questions are:= is the behavior illustrated in =C2=A76 and =C2=A77 intended to be Normativ= e?=C2=A0


[authors]The examples are inten= ded to illustrate the result of the normative language in RFC8200 and RFC65= 53.
So the examples are intended to be normative explanation of t= he results of executing that language.=C2=A0

=C2=A0=C2=A0
IOW, d= o these sections include both examples and specify the behavior expected in= the LLN?=C2=A0 Is the behavior already specified somewhere else (and this = document is just illustrating)?

[autho= rs]The normative language is in RFC8200 (ipv6bis) section 4.2 and section 4= , =E2=80=9CThe Hop-by-Hop Options=E2=80=A6=E2=80=9D
Combined with= the desired results of=C2=A0 RFC6553, we conclude that we have to change t= he option value in order to make things work.
=
=
=
=

I understand wha= t you=E2=80=99re trying to do.

To me, a =E2=80=9CNormative example= =E2=80=9D is an impossible oxymoron: it=E2=80=99s either an example or it i= s a Normative specification of the behavior. =C2=A0

In this document, the scenarios (maybe a better word than example, specia= lly given how exhaustive the document is in considering all the possibiliti= es) are not consistently treated as not all of them are described using Nor= mative language.=C2=A0 Being consistent is *very* important given that we= =E2=80=99re dealing with Normative language...

**B= ut** my heartburn really flares up when you mention "the normative lan= guage in RFC8200...=E2=80=9D because rfc8200 doesn=E2=80=99t use rfc2119 ke= ywords at all. :-( =C2=A0The use of rfc2119 language is a completely separa= te discussion, but using it here as an interpretation of what is meant in r= fc8200 is a stretch=E2=80=A6at least to me.

= What do I want to see?=C2=A0 I would prefer to see the scenarios described = NOT using rfc2119 keywords: simply changing the case would be enough.
=

I don=E2=80=99t want to turn this review into a debate = around rfc2119 and much less about how to interpret rfc8200.=C2=A0 If you r= eally, really prefer to keep the Normative language, please be consistent (= use it in all the scenarios).=C2=A0 We can see if anyone else in the IESG p= icks up on this same point or not=E2=80=A6

...

(2) [major] Operational Consideration= s

Non-storing mode networks don't need the change to 0x23 (=C2= =A78.2)...but making the change creates a flag day, and even then, implemen= tations should still process both values (=C2=A73.1).=C2=A0 I would really = like to see text about the operational considerations of introducing 0x23.= =C2=A0 It concerns me that a significant change that most[*] networks don&#= 39;t need is being introduced.=C2=A0 Please take a look at rfc5706 (Guideli= nes for Considering Operations and Management of New Protocols and Protocol= Extensions), specially =C2=A72.

[*] Most deployed networks work in = non-storing mode, right?

[authors]follo= wing our understanding, mostly yes.
but, e.g. Anima network in st= oring mode. Not having loop detection.
<= /div>
<= /div>
<= /div>

Thanks for including Opera= tional Considerations. =C2=A0=C2=A78 looks good to me=E2=80=A6and I see tha= t =C2=A79 is still WIP.


...

[nit] I think the Introduction would benefit from an overv= iew of the document; something like "section X talks about abc, sectio= n Y presents examples, etc.".

[authors= ]added=C2=A0
=
=
=

This new section mentions the old =C2=A79.


...

187=C2=A0 =C2=A0Flag day= : A "flag day" is a procedure in which the network, or a part
= 188=C2=A0 =C2=A0of it, is changed during a planned outage, or suddenly, cau= sing an
189=C2=A0 =C2=A0outage while the network recovers [RFC4192]
<= br>[nit] rfc4192 seems like an odd place to pull a reference to "flag = day" -- specially as it is being defined as "a procedure" an= d not the effect it causes, which seems to be how it is used in the text: &= quot;creates a flag day", "will experience a flag day", &quo= t;avoid a flag day".=C2=A0 This is not a big issue -- if it was up to = me, I would either make my own definition, or just not define it at all: I = think it is a well known term...

[autho= rs]fixed. rewritten=C2=A0

New text:

217	   Flag Day: A trans=
ition that involves have a network with different
218	   values of RPL Option Type.  Thus the network do not work correctly.

s/involves have a network/involves having a network

s/networ= k do not work/network does not work

Also, the reference to rfc4192 is= not needed anymore.


...
...

272=C2=A0 = =C2=A0When originating new packets, implementations SHOULD have an option273=C2=A0 =C2=A0to determine which value to originate with, this option i= s controlled
274=C2=A0 =C2=A0by the DIO option described below.

[= minor] =C2=A73.3 defines the option...but it doesn't explicitly say wha= t the receivers should do with it.=C2=A0 It may be obvious, but it should b= e explicit for completeness.
[authors]rewritten=C2=A0<= /div>

[major] It seems= to me that the paragraph above may be out of place, doesn't say much, = may be wrong...or maybe all 3.=C2=A0 The text says that the originating val= ue is controlled by the option in =C2=A73.3 (again, but that section doesn&= #39;t explicitly say what should be done)...but it also says (with the SHOU= LD) that an implementation may have valid reasons to not pay attention to t= he option -- what are those??

[authors]= rewritten to
"In the cases where a forwarding node is forwar= ding traffic that is not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0addressed directly to it (such as when the outer IPv6-in-IPv6 header is = not a Link-Local address),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0then RFC8200 forbids changing the RPI type code when forwarding.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When forwarding = traffic that is wrapped in Link-Local IPv6-in-IPv6 headers,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the forwarding node is in effect orig= inating new packets,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and= it MAY make a choice as to whether to use the old (0x63) RPI Type code,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0or the new (0x23) RPI Type= code. In that situation, implementations SHOULD
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0use the same value as was received.=C2=A0 This a= llows to the network to be incrementally upgraded,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0and in some cases may allow the DODAG root to kn= ow which parts of the network are upgraded."=C2=A0

Ok, that loo= ks good.

You also added:

323	   Non-constrained uses of RPL a=
re not in scope of this document, and
324	   applicability statements for those uses MAY provide different advice=
,
325	   E.g.  [I-D.ietf-anima-autonomic-control-plane].

If out of scope, don=E2=80=99t use Normative language there.


...
=
<= div dir=3D"ltr">
=
<= div dir=3D"ltr">
613=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 7: IP-in-I= P encapsulation in Storing mode.
=
=
=
=
<= /div>
<= /div>
<= /div>
<= /div>

= = = =

[nit] The table a= bove is called Figure=E2=80=A6 There are also some Tables.=C2=A0 Maybe be c= onsistent about what is called a Table and what is called a Figure.=C2=A0 P= ersonally, I don=E2=80=99t care=E2=80=A6I just would prefer consistency.

...
<= div dir=3D"ltr">
894=C2= =A0 =C2=A0Note that there is a requirement that the final node be able to
895=C2=A0 =C2= =A0remove one or more IP-in-IP headers which are all addressed to it,
89= 6=C2=A0 =C2=A0mentioned in [I-D.thubert-roll-unaware-leaves] :

898= =C2=A0 =C2=A0"RPL data packets are often encapsulated using IP in IP.= =C2=A0 The 6LN
899=C2=A0 =C2=A0MUST be able to decapsulate a packet when= it is the destination of
900=C2=A0 =C2=A0the outer header and process c= orrectly the inner header."

[major] I realize that we're no= t reviewing I-D.thubert-roll-unaware-leaves at this point, but how can a re= quirement be placed on a not-RPL-aware-leaf if, by definition, it is not aw= are of RPL??=C2=A0 =C2=A0...and I don't think we can assume it is aware= of any other requirement...
[authors] We understand t= hat the requirements are placed on the 6LR that accepts the 6LN
= =C2=A0 =C2=A0registration and also inject the relevant routing information = on its behalf.=C2=A0
<= /div>
<= /div>
<= /div>
<= /span>

The text above talks abut the 6LN, not the 6LR.=

If this document depends on th= e requirement in I-D.thubert-roll-unaware-leaves, then the reference should= be Normative (it is now listed as Informative).
[auth= ors]fixed=C2=A0
= = =

I still don=E2=80=99t feel too good about depending = on requirements for not-RPL-aware nodes in the network=E2=80=A6. In this ca= se, this document will not be able to be published as an RFC until that *in= dividual* draft is published.=C2=A0 Is that what you want?=C2=A0 Is there a= ny way to work around this dependency?=C2=A0 Why isn=E2=80=99t rfc8200 supp= ort enough in this case?


...

1194 7.1.1.=C2=A0 Non-SM: Example of Flow from RPL-aware-leaf= to root

1196=C2=A0 =C2=A0In non-storing mode the leaf node uses def= ault routing to send
1197=C2=A0 =C2=A0traffic to the root.=C2=A0 The RPI= header must be included to avoid/detect
1198=C2=A0 =C2=A0loops.

= [major] Should that "must" be Normative?
[au= thors] fixed.=C2=A0
1322	   In non-storing mode the leaf node uses=
 default routing to send
1323	   traffic to the root.  The RPI header MUST be included since contain=
s
1324	   the rank information, which is used to avoid/detect loops.

= s/be included since contains/be included since it contains


...

1254 7.1.3.=C2=A0 Non-SM: E= xample of Flow from root to not-RPL-aware-leaf
...
1267=C2=A0 =C2=A0In 6LBR the RH3 i= s added, it is modified at each intermediate 6LR
1268=C2=A0 =C2=A0(6LR_1= and so on) and it is fully consumed in the last 6LR (6LR_n),
1269=C2=A0= =C2=A0but left there.=C2=A0 If RPI is left present, the IPv6 node which do= es not
1270=C2=A0 =C2=A0understand it will ignore it (following RFC8200)= , thus encapsulation
1271=C2=A0 =C2=A0is not necesary.=C2=A0 Due the com= plete knowledge of the topology at the
1272=C2=A0 =C2=A0root, the 6LBR m= ay optionally address the IP-in-IP header to the last
1273=C2=A0 =C2=A06= LR, such that it is removed prior to the IPv6 node.

s/necesary/neces= sary

[major] So...encapsulation is not needed, but an IP-in-IP heade= r is optional.=C2=A0 When?=C2=A0 Are there advantages, disadvantages?=C2=A0= =C2=A0Same questions about the RPI.
[authors]rewritte= n.=C2=A0
<= /div><= /div><= /div>

s/Due the complete/Due to the complete


...=

<= div dir=3D"ltr">
1731 9.=C2=A0 6LoRH Compression cases=

1733=C2= =A0 =C2=A0The [RFC8138] proposes a compression method for RPI, RH3 and IPv6= -in-
1734=C2=A0 =C2=A0IPv6.

1736=C2=A0 =C2=A0In Storing Mode, for= the examples of Flow from RPL-aware-leaf to non-
1737=C2=A0 =C2=A0RPL-a= ware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
1738=C2= =A0 =C2=A0an IP-in-IP and RPI compression headers.=C2=A0 The type of this c= ase is
1739=C2=A0 =C2=A0critical since IP-in-IP is encapsulating a RPI h= eader.

1741=C2=A0 =C2=A0+--+-----+---+--------------+-----------+---= ----------+-------------+
1742=C2=A0 =C2=A0|1 | 0|0 |TSE| 6LoRH Type 6 |= Hop Limit | RPI - 6LoRH | LOWPAN IPHC |
1743=C2=A0 =C2=A0+--+-----+---+= --------------+-----------+-------------+-------------+

1745=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 9: Cr= itical IP-in-IP (RPI).

[major] Shouldn't this section also be an= Update to rfc8138?

[major] 6LoRH Type 6 is defined in rfc8138 as an= elective type, but it is introduced as Critical here.=C2=A0 The header mus= t then be completely specified in this document and the appropriate registr= y must be updated (in the IANA Consideration section).

Specifically.= ..referring to rfc8138...
=C2=A0 =C2=A0- the meaning of the TSE depends = on the Type (=C2=A74.2),
=C2=A0 =C2=A0- the Hop Limit is defined in =C2= =A77, should it have the same behavior/meaning here?
=C2=A0 =C2=A0- does= the "RPI - 6LoRH" field correspond to the RPI-6LoRH header (=C2= =A76.3)?
=C2=A0 =C2=A0- I'm assuming that the "LOWPAN IPHC"= ; field refers to LOWPAN_IPHC (rfc6282).

[authors] we think that the confusion is because we wrote: =E2=80=9CThe t= ype of this case=E2=80=9D...
which sounds like we are changing 81= 38, when what we mean is that use of this elective type is a MUST for RPL.<= /div>
Type 6 (compressed RPI) is elective in 8138 because non-RPL uses = of 6lowpan do not
need to support (compressed) RPI headers, but t= his document makes it a MUST because
RPL uses of 6lowpan need it.= Is there text that we need to update?=C2=A0
<= /div>
<= /div>
<= /div>
<= /div>

I see that you moved this text to =C2=A73.2.=C2=A0 The F= igure (now 3) is still labeled as =E2=80=9Ccritical=E2=80=9D.


<= div dir=3D"ltr">
<= div dir=3D"ltr">
...
1774 11.=C2=A0 Security Considerations
=
=
=
=
<= p>

Your responses to trisection indicated several times =E2=80=9CDiscu= ssion on the list=E2=80=9D, but I could=E2=80=99t find those discussions.= =C2=A0 Did they happen already? =C2=A0

I would pre= fer it if the document has mitigation suggestions (at least) in it; that us= ually makes the SecDir happier. ;-) =C2=A0But that is not an absolute requi= rement before moving this document forward.

...
[major] What does "SHOULD be sus= picious" mean?=C2=A0 How is that a Normative behavior?=C2=A0 Would bei= ng suspicious include dropping the packet or some other similar action?=C2= =A0 When would the router *not* be suspicious?=C2=A0 Why is that not a &quo= t;MUST"?
=C2=A0
[authors]The presence of th= e second RH3 means that there is a configuration
=C2=A0mistake so= mewhere else in the network.=C2=A0 It would be reasonable to increment
=C2=A0 a counter in a MIB (if we had a MIB) when this occurs.=C2=A0 B= ased upon the Postel
=C2=A0 =C2=A0doctrine, ignoring the extra he= ader (not acting on it), is the best policy.
=C2=A0 =C2=A0 An RH3= header was not completely consumed is discussed in RFC

https://tools.ietf.org/html/rfc6554#section-4.2=C2=A0says that an= RH3 header with
=C2=A0additional =E2=80=9Cnon-zero Segments Left= value, if the IPv6 Destination Address is
=C2=A0 not on-link=E2= =80=9D should be dropped.=C2=A0 In this case, the RH3 header is *inside*
=C2=A0 the outer IPv6-in-IPv6 header, which has then been forwarded= .
We think that this header should simply be ignored in processin= g the packet.
=C2=A0To do otherwise (such as forwarding) would pe= rmit external attackers to send
=C2=A0traffic that appears to ori= ginate inside the LLN.

=C2=A0To be discussed on li= st=C2=A0
<= /div>
<= /div>
<= /div>

Ok=E2=80=A6whatever the outcome is, to =E2=80=9Cbe suspicio= us=E2=80=9D is not something that can be enforced normatively.=C2=A0 SHOULD= log and error, etc..is something actionable.

--00000000000057e3e40580b0c8c6-- From nobody Wed Jan 30 12:55:44 2019 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730F7130FEC for ; Wed, 30 Jan 2019 12:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV9e0t7KeZL0 for ; Wed, 30 Jan 2019 12:55:38 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3011130FEB for ; Wed, 30 Jan 2019 12:55:37 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id y56so761498edd.11 for ; Wed, 30 Jan 2019 12:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=iIzlfGCXVgp2JdBaozQodx27QFhhCtbt2o5tvvkAtLo=; b=KeI6+Eo0SrH+ecmwVVTUkP82Z8cesMnTc2N93zpHT/c3HJOxMcg/tO0ZXxQux85OnO s08YBWU9Hz9TDz8OVWmqAnKl0SsxP0gzQtXr+eLMi5WpLg3eqoxKYtcOCXQJ1Q6yBomm a2LWqpcULuNZxnRWJa3NQBBVTbdRvls747bCBNOG3XbGKTw84qvcnLDfJG/x0dV++/HI eboNcw66I3cenZ3b4H2RAB8twYmExdLOOkK8UiyEDUZQg6cRmvasQfOKzMTTtksumkJb TQrYSjBTkkcswi+LKjUzEGs8cYtbibV5x145JimImgqhAGl1z3g+YLviIQyL46pV8OJw NlNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=iIzlfGCXVgp2JdBaozQodx27QFhhCtbt2o5tvvkAtLo=; b=X0I2Vwcvm4UD9DQkiNKmotqOb/wYrCQk6lOG4zWRW3GOKNlBdm7vH/aW5YnQgBQ27m h+aT6HVq5oMA/wpQ4YJVeocwOv3xv0TrH/5aXSzutN/TOWHzAV3l+hYze+bFsK0H+KMD OQMCOBbtKs8Xtb9JEfuKRw4qEwLztzcSjORbY0AojmCvWD0QyNYq7pG7kMwAALtM6Lbt P9OXBn/jNwh1olFRVLZqLMMlt6ZpX9Vh7REuyzePZmHupo7TUWeT/rCkqidJTyg7+chD 6GVheMvlUM4XRejQYIknbwZ+Fvelz90xq8d02RGheuWLTF7xnuie9JYz068h1CaSjsgr LlVQ== X-Gm-Message-State: AJcUukeOF+W/yEubONUDrBR5GsXaYUF23AoAEMxg8Ka2mzkncVurlFu9 njyEvfyViIxFKkhWfkqvv17DclwTUH1Hph21aQ7hWP/Y X-Google-Smtp-Source: ALg8bN5cNOADHyHPHv1RGwZrsT+OTgyIZDnTqDVdCKKsQARcK1C+1xpZ06qL3RVOoqU/GF4as8QSKYbEyXYAO7ieEs0= X-Received: by 2002:a17:906:4b4c:: with SMTP id j12mr27706340ejv.185.1548881735971; Wed, 30 Jan 2019 12:55:35 -0800 (PST) MIME-Version: 1.0 From: Ines Robles Date: Wed, 30 Jan 2019 22:55:24 +0200 Message-ID: To: roll Cc: Michael Richardson , "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary="000000000000abfecb0580b321fb" Archived-At: Subject: [Roll] Security Considerations for useofrplinfo draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2019 20:55:43 -0000 --000000000000abfecb0580b321fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Please, we would like to have your opinion to address the following major comments/questions: Ticket: 191 https://trac.ietf.org/trac/roll/ticket/191 "Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an attack on another part of the LLN, while disguising the origin of the attack. The mechanism can even be abused to make it appear that the attack is coming from outside the LLN, and unless countered, this could be used to mount a Distributed Denial Of Service attack upon nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of such attacks already seen in the real world." [major] Is there any possible mitigation to this inside-the-LLN attack? Would authentication help -- is it even possible? Ticket 192: https://trac.ietf.org/trac/roll/ticket/192 " Blocking or careful filtering of IPv6-in-IPv6 traffic entering the LLN as described above will make sure that any attack that is mounted must originate from compromised nodes within the LLN. The use of BCP38 filtering at the RPL root on egress traffic will both alert the operator to the existence of the attack, as well as drop the attack traffic. As the RPL network is typically numbered from a single prefix, which is itself assigned by RPL, BCP38 filtering involves a single prefix comparison and should be trivial to automatically configure." [major] BCP38 will stop an attack, but only if the source addresses are spoofed. What if they're not? Given that the attack may be hidden, and assuming that nodes are compromised across multiple LLNs, an attacker may not care enough to spoof the origins. Ticket 193: https://trac.ietf.org/trac/roll/ticket/193 "The RH3 header usage described here can be abused in equivalent ways with an IPv6-in-IPv6 header to add the needed RH3 header. As such, the attacker's RH3 header will not be seen by the network until it reaches the end host, which will decapsulate it. An end-host SHOULD be suspicious about a RH3 header which has additional hops which have not yet been processed, and SHOULD ignore such a second RH3 header." [major] What does "SHOULD be suspicious" mean? How is that a Normative behavior? Would being suspicious include dropping the packet or some other similar action? When would the router *not* be suspicious? Why is that not a "MUST"? The presence of the second RH3 means that there is a configuration mistake somewhere else in the network. It would be reasonable to increment a counter in a MIB (if we had a MIB) when this occurs. Based upon the Postel doctrine, ignoring the extra header (not acting on it), is the best policy. An RH3 header was not completely consumed is discussed in RFC https://tools.ietf.org/html/rfc6554#section-4.2 says that an RH3 header with additional =E2=80=9Cnon-zero Segments Left value, if the IPv6 Destinat= ion Address is not on-link=E2=80=9D should be dropped. In this case, the RH3 h= eader is *inside* the outer IPv6-in-IPv6 header, which has then been forwarded. We think that this header should simply be ignored in processing the packet. To do otherwise (such as forwarding) would permit external attackers to send traffic that appears to originate inside the LLN. What do you think? Thank you very much in advance, The authors. --000000000000abfecb0580b321fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

P= lease, we would like to have your opinion to address the following major co= mments/questions:


"Nodes within the LLN can use the IPv6= -in-IPv6 mechanism to mount an
=C2=A0 =C2=A0attack on another par= t of the LLN, while disguising the origin of the
=C2=A0 =C2=A0att= ack.=C2=A0 The mechanism can even be abused to make it appear that the
=C2=A0 =C2=A0attack is coming from outside the LLN, and unless counte= red, this
=C2=A0 =C2=A0could be used to mount a Distributed Denia= l Of Service attack upon nodes elsewhere in the Internet.=C2=A0 See [DDOS-K= REBS] for an example of
=C2=A0 =C2=A0such attacks already seen in= the real world."

=C2=A0 =C2=A0[major] Is the= re any possible mitigation to this inside-the-LLN attack?=C2=A0=C2=A0
=
=C2=A0 =C2=A0Would authentication help -- is it even possible?=C2=A0



=C2=A0 =C2= =A0prefix, which is itself assigned by RPL, BCP38 filtering involves a
=C2=A0 =C2=A0single prefix comparison and should be trivial to automa= tically
=C2=A0 =C2=A0configure."

= =C2=A0 =C2=A0[major] BCP38 will stop an attack, but only if the source addr= esses are spoofed.=C2=A0 What if they're not?=C2=A0 Given that the atta= ck may be hidden, and assuming that nodes are compromised across multiple L= LNs, an attacker may not care enough to spoof the origins.


=
=C2=A0 =C2=A0"The RH3 header usage described here can be ab= used in equivalent ways
=C2=A0 =C2=A0with an IPv6-in-IPv6 header = to add the needed RH3 header.=C2=A0 As such,
=C2=A0 =C2=A0the att= acker's RH3 header will not be seen by the network until it
= =C2=A0 =C2=A0reaches the end host, which will decapsulate it.=C2=A0 An end-= host SHOULD
=C2=A0 =C2=A0be suspicious about a RH3 header which h= as additional hops which have
=C2=A0 =C2=A0not yet been processed= , and SHOULD ignore such a second RH3 header."

=C2=A0 =C2=A0[major] What does "SHOULD be suspicious" mean?=C2= =A0 How is that a Normative behavior?=C2=A0 Would being suspicious include = dropping the packet or some other similar action?=C2=A0 When would the rout= er *not* be suspicious?=C2=A0 Why is that not a "MUST"?

=C2=A0 =C2=A0The presence of the second RH3 means that ther= e is a configuration mistake somewhere else in the network.=C2=A0 It would = be reasonable to increment a counter in a MIB (if we had a MIB) when this o= ccurs.=C2=A0 Based upon the Postel doctrine, ignoring the extra header (not= acting on it), is the best policy. An RH3 header was not completely consum= ed is discussed in RFC

=C2=A0 =C2=A0https://tools.ietf.org/html/r= fc6554#section-4.2 says that an RH3 header with additional =E2=80=9Cnon= -zero Segments Left value, if the IPv6 Destination Address is not on-link= =E2=80=9D should be dropped.=C2=A0 In this case, the RH3 header is *inside*= the outer IPv6-in-IPv6 header, which has then been forwarded.
= =C2=A0 =C2=A0We think that this header should simply be ignored in processi= ng the packet.=C2=A0 To do otherwise (such as forwarding) would permit exte= rnal attackers to send traffic that appears to originate inside the LLN.

=C2=A0 =C2=A0What do you think?

=


=C2=A0 =C2=A0Thank you very much in adva= nce,

The authors.
--000000000000abfecb0580b321fb--