Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18 (cont)
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 09 October 2020 19:45 UTC
Return-Path: <pthubert@cisco.com>
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 4BF7E3A1510; Fri, 9 Oct 2020 12:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MSEnfGkL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=awDYqI2g
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 wWsExVHDqJ4d; Fri, 9 Oct 2020 12:45:46 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BE53A150E; Fri, 9 Oct 2020 12:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=140438; q=dns/txt; s=iport; t=1602272746; x=1603482346; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=k4L3g55LKinrI3XoRSCNvNKvXS/z+DNx1Kv/l+Qrdog=; b=MSEnfGkLDHyaTV7S5Ck5IyBQZ2AvAxL3avwkOLS50y8JrTYU65E1ZiqG RfDgo7aGJ7wpcuMg+zs2gw5ynai1YApJBLTnYaJooG7gQ5PI3IA26oVdO DpXUEbpHcYlEMFWNM4o4UKordpc6JNMd7HCbnE1ylP9Sh6w061PvTDTKt o=;
IronPort-PHdr: 9a23:ybJD7B2wa7OCu+G+smDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxWGuadiiVbIWcPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWlcDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoPk1cGcK4bFrX8TW+6DcIEUD5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DDCgCXvYBf/4wNJK1GEAqBCYMhIwYoB3BRCC8shD2DRgONUoECl3mBQoERA1ULAQEBDQEBJQgCBAEBhEoCF4F8AiU4EwIDAQELAQEFAQEBAgEGBG2FLwEsDIVyAQEBAQIBEggBCAQNDAEBJQUGBwEEDQEIDgoCAhEVAgQwFREBBAENDRqDAAWCSwMOIAEOP51nAoE5iGF2fzODAQEBBYE3AhEYgzkYghADBoEOKoJygl9MQoQLgQiBQxuBQT+BEAFDUX5JNT6CXAEBAQEBFn0CEgEHCgIBAgQBGwUQFQwCBYJYM4Itj38SBgIGBAcJIoIzPYcrgn+IW5AKCYEBCoJoiQCCF4NyUYsvgxOKCASFPY5akxyBeoh2kHwFgUeCaQIEAgQFAg4BAQWBayMNBVVwcBUaIYJpUBcCDYEZhy+FYxeBAgECgkmFFIVCdAI1AgYBCQEBAwl8iwYCBSEHgThfAQE
X-IronPort-AV: E=Sophos;i="5.77,355,1596499200"; d="scan'208";a="578184554"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2020 19:45:43 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 099Jjh0v023085 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2020 19:45:43 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 9 Oct 2020 14:45:42 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 9 Oct 2020 14:45:41 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 9 Oct 2020 15:45:41 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b87EdGMsMo9Z4eZCg6Q3U9kFm76fStMTM823ns+UYyybUvGsHD+oi2YwSLsdG+EJnHKX8uibfelWlTrQXl+35GnfHvX16SXnv6mHifRedxBfrF0FWEIUA9NiEGtiduZzSMqsw7T86ryelnQ0VyrtDl3Gf4i7G/4onCODoaHNzSrDlgMn8/fUmKk7Z2weKquO2svDDSfwRIXBS7vglMR5e1VshnJzy/qOxf2afbZBONRJy9QthcxxxXMocDFa7qaXKTEQIGHgRR+Xesn4TgA23DXYhBXRdSGO9DJLFPPAvL8brMbqtz2fw/X8J9rZf8JVxrXaOxpzUACCK1/W7gAIqQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k4L3g55LKinrI3XoRSCNvNKvXS/z+DNx1Kv/l+Qrdog=; b=cgNv+17rt3HQnv38tQYjWqar/QIC/UNyv+yEhtmlYmM2fSDRwndR8ZI16EPOZzZJggfPt7O+X0GpeZMnt2rDt+C4OPP6tw8CKDX+z7/Y+ZqSILsDFSXQvVIzSjhKd/HMjaP/ZnmKw6zNROfIo5rCCaBv19kvxXr5ZsmWuvJ5vU53IYXWtnkitDfZsDaNKCFtUcN/MSGduWAJJ00D2/La54ct4u1vYjfgPdV756Fd1e8muVR33vUsj6MVmGGKhykawqyQ02mtmo6lk3W9Mgo6osoWmnnyh2YvoC+1LPK4U2q3Ni1ozXTeLIneNv4wUsFq2oemrj/r/YDRFykvaQzV5A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k4L3g55LKinrI3XoRSCNvNKvXS/z+DNx1Kv/l+Qrdog=; b=awDYqI2gUEszF8htqcL0xo6C7VMjWpjzogVmNfHgtP3qMjP0dO+GD3mxj/cpIz62zTt0v1F4tqGzzYXaG1gpqamQkhLv330weDYP1Tcow3zA6uQY0khUjjq45C06rq7/5Rghvq9krAcEkwrfyi1bKKxw+5NOhhD4e3moUmLxvYw=
Received: from CY4PR11MB1352.namprd11.prod.outlook.com (2603:10b6:903:2a::23) by CY4PR1101MB2150.namprd11.prod.outlook.com (2603:10b6:910:18::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Fri, 9 Oct 2020 19:45:38 +0000
Received: from CY4PR11MB1352.namprd11.prod.outlook.com ([fe80::e960:8c02:b46b:ef52]) by CY4PR11MB1352.namprd11.prod.outlook.com ([fe80::e960:8c02:b46b:ef52%10]) with mapi id 15.20.3433.048; Fri, 9 Oct 2020 19:45:38 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-roll-unaware-leaves@ietf.org" <draft-ietf-roll-unaware-leaves@ietf.org>
CC: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, Rahul Jadhav <rahul.ietf@gmail.com>
Thread-Topic: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)
Thread-Index: AdaeB8TMM0jXPLOPQLKlKyaQoVj7Fw==
Date: Fri, 09 Oct 2020 19:45:25 +0000
Deferred-Delivery: Fri, 9 Oct 2020 19:45:14 +0000
Message-ID: <CY4PR11MB1352E8FE5B4F6039EB39F425D8080@CY4PR11MB1352.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:edff:150d:934a:a6fa]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fddda330-3490-4eb3-e945-08d86c8be612
x-ms-traffictypediagnostic: CY4PR1101MB2150:
x-microsoft-antispam-prvs: <CY4PR1101MB21507A43446D490D7773FFB6D8080@CY4PR1101MB2150.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:2582;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: X14gBNsrZDINGElvNiYmakXgD1Heq7HcxaEK6UfNMaXibGjIEugyyxklg8MzVriFI0zE4BL8LHbClD6piJ9r6+tl07tXG/9z04gfNuaay6mZai6BfxaVlFLh+HixwuXdMAJWYH6zVx0DKTqL3thWKrl+ByIhECeAXT83f9RGeEIhd4QQu8EyV8LUO5SeVDuOy4VjchvczWrRmt5Wj3mp8fmU9clBBPwnKltCIRAZU8jAxDJoeTSvh4KPCL5MZpjeHO+ECJTYHw3H7Uvl8o++TbMxr4sw1VXQ5oxi8DxhEChonzaIwINYVNs4rrc3JQmrzZ7H7zrpvfRpFA6dep+DqosiKt+Wa2p8kWfvv562cCGHRH4fQb7+HjQu5XIOpg9dSgezEjOFw0OYyiPDvpvpf40Hvg98BalSRl6+Zkg/eBXyuDMU5//2CKCZ9zAUMA92
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR11MB1352.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(39860400002)(376002)(396003)(136003)(6666004)(2906002)(186003)(5660300002)(64756008)(7696005)(66446008)(66556008)(76116006)(66946007)(71200400001)(45080400002)(66476007)(52536014)(8676002)(83730400001)(54906003)(110136005)(8936002)(86362001)(83080400001)(316002)(33656002)(6506007)(966005)(83380400001)(55016002)(30864003)(16799955002)(66574015)(478600001)(4326008)(9686003)(579004)(559001)(569008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: yJV/VAvPMGCwSyJwXlyZ232E2SoejlCk5CJG92V1KXijZiQJcj/F+lG7LHErkwzEyBySyfUbVged38onuuJSt2Nb6rLH+bFAGaSBna1Y5CI4D090KcgjnDkmp/cgexY2eJHWU9y9JuGGedzDMKe4SkRIgwR0WYPh96ISmv4y1Jt5oeK4czR9RT8gB9MSmL/RLo5kW+ZTXR4Wdj4T8t3PDRYf61QE7jF9EfoLK016qvIuzg//3JLfnV31qNJKSKMv09zXMIdz1wJ/DDxqZFOJ+eHL68JCYV9VFN7FnnRdw3WEJ/Au2RQ88M1Sb9GNJSNghpJLg5lIk4mQNn/auDLGqsPGCtfQO/faFVryRJ4IkIX7tCdlHZ3XPgM253BMTGiqSbtigQiBciDuegecVzuyjAhq3+L7jUDtqnsVAVH/TnlafW450Anb6U4DzEV3BULjr7c472q5ZlgMaevrj9TjuGaWs1UX0yArmZG8EAnF2fZZtvtHyzaacdBe1eWQBk7nvkKw4W1gL9zeDhpks0cJOujcOU2AfJnwrAvckC3GxdYK/g46ONHjfDEM2fjD4Zbu9UC7wb1YfGcxdgHY+7ypxMBWZ6jd1vzBUqTyAGNML10mcV6FvggADxtWLHhAal4+9Yx6dzx9XgJinF0vZnpl/0XXS1HIOWpi6DTxwvNhyAeUXZ6BEZtCdxFvfmFmocB+PEQg8wKXpk13ONn4CrcHgQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB1352.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fddda330-3490-4eb3-e945-08d86c8be612
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 19:45:38.7758 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: f2ja0iuR8TO/I0ezHKyQCUFeNcPdpr1boUYMChYSY2mDqDYdrUNMWYmsLcEDljcdFOU9A/Cu9C8RNwcnBDD4wQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2150
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/v_IOf7e7qcscJHKySN7Ezn9G96g>
Subject: Re: [Roll] AD Review of draft-ietf-roll-unaware-leaves-18 (cont)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2020 19:45:54 -0000
Hello Alvaro: This is the continuation of the mail sent yesterday. Since we only discussed the update 8505 / 6775 story I copied the whole mail below so you can reply to this for the whole discussion. I committed the result in the IETF datatracker as draft 22 as a reference since we made major changes already. A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-22 > I'm including 3 different sections below. > > (1) Inline comment to your response to my review (of -18). > > (2) Some additional nits on -21. > > (3) You didn't reply past the initial comment in §5, which makes me think > that your email client truncated my message. :-( [I've seen this happen > many times before, specially when the receiver is using Outlook. Please > take a look at the archive just in case.] I am including the comments > starting in §5 (based on -18). The sections don't match to -21, but I'll > leave that exercise to you. ;-) > > > > > === Part 1: comments on your review === > > > On September 18, 2020 at 10:00:30 AM, Pascal Thubert wrote: > > ... > > > 440 4. Updating RFC 6550 > ... > > > 442 This document specifies a new behavior whereby a 6LR injects DAO > > > 443 messages for unicast addresses (see Section 10) and multicast > > > 444 addresses (see Section 11) on behalf of leaves that are not aware of > > > 445 RPL. The RUL addresses are exposed as external targets [RFC6550]. > > > 446 Conforming [USEofRPLinfo], an IP-in-IP encapsulation between the 6LR > > > 447 and the RPL Root is used to carry the RPL artifacts and remove them > > > 448 when forwarding outside the RPL domain, e.g., to a RUL. > > > > > > > > > > > [] Is there anything in rfc6550 that limits the source of the routing > > > information in the DAOs? It seems to me that rfc6550 already allows > > > external information to be injected in the network...so getting it from a > > > RUL doesn't sound like an Update to me. > > > > > > > True, that is not why we have the updates. See sections "Updated RPL Status > > " and "Updated RPL Target Option" > > ...but this text is in the section titled "Updating RFC 6550". > > Perhaps this section should be titled "Changes/Enhancements/? to > rfc6550" -- and then the subsections can explicitly spell out the > Updates. [Assuming that change, I won't make the same comment on the > other pieces of this section.] > I like enhancements, changing the title to " Enhancements to RFC 6550 ". We end up as follows if I understood you well: 6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 12 6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 13 6.2. New Flag in the RPL DODAG Configuration Option . . . . . 14 6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 15 7. Extending draft-ietf-roll-efficient-npdao . . . . . . . . . . 16 8. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 16 > This clear differentiation between items that are > changes/enhancements, and ones that represent a formal Update is what > I want to see clarified. For RFC 6550 The term updates remains in the section " The RPL Target Option " since we want to generalize the new format. This is to become the base for not only this spec but a trusted DAO operation in general. It is added in the " Updated RPL Status " section as " This specification updates the RPL Status with subfields as indicated below: " For RFC 8505: The term "updates" remains for the reduction of the Status code range. It now applies to both RFC 6775 and RFC 8505. > === Part 2: Additional comments based on -21 === > > [Line numbers from idnits.] > > > ... > 188 * Section 6, Section 7, and Section 8 present the additions made to > 189 [RFC6550], [EFFICIENT-NPDAO], and [RFC8505]. > > [] "additions" Changes/extensions/updates?? > I picked "changes", added 6775, as discussed in parallel thread > > === Part 3: remaining comments (based on -18) === > > ... > 484 5. Updating draft-ietf-roll-efficient-npdao > > [major] To me, Updating an RFC means that the implementations of that > RFC should also implement this one. In this case, there would be an > expectation that all nodes that support the DCO would support the > Non-Storing MOP as well. Is that what is intended? > > Note that Updating is different than simply expecting the nodes that > implement this specification to comply. > > [Personal opinion: I don't think a formal Update of > draft-ietf-roll-efficient-npdao is needed. As mentioned below, this > document "extends"...] > That was already gone, but then, we also discuss this in another thread > > 486 [EFFICIENT-NPDAO] defines the DCO for RPL Storing Mode only, with > a > 487 link-local scope. This specification extends its use to the Non- > 488 Storing MOP, whereby the DCO is sent unicast by the Root directly to > 489 the RAN that injected the DAO message for the considered target. > > 491 This specification leverages the DCO between the Root and the 6LR > 492 that serves as attachment router for a RUL. > > [] Just another piece of information: draft-ietf-roll-efficient-npdao > already "assumes that all the 6LRs in the network support this > specification". draft-ietf-roll-efficient-npdao did not Update > rfc6550, so it is not expected that "basic" RPL nodes would know what > the DCO is... > Understood > [major] Regardless of whether this document Updates NPDAO or not, some > text should be added related to the possibility that not all nodes may > know what the DCO is. See §10.2.3. I note an unfortunate name collision between the DCO message and the DODAG Config. Option, but we do not use DCO for the latter so we should be OK Another note: section 10.2.3 is now 9.2.3 If I understand you it's can be easy one. This spec only uses NPDAO in non-storing mode. This means is end-to-end between the Root and the 6LR that implements this spec. Intermediate nodes just route a packet unaware that this is a control packet. So all we need to is indicate that the 6LR MUST support the DCO as updated therein. Suggestion to cover it here: 7. Extending draft-ietf-roll-efficient-npdao [EFFICIENT-NPDAO] defines the DCO message for RPL Storing Mode only, with a link-local scope. All nodes in the RPL network are expected to support the specification since the message in processed hop by hop along the path this is being cleaned up. This specification extends the use of the DCO message to the Non- Storing MOP, whereby the DCO is sent end-to-end by the Root directly to the RAN that injected the DAO message for the considered target. In that case, intermediate nodes do not need to support [EFFICIENT-NPDAO]; they forward the DCO message as a plain IPv6 packet between the Root and the RAN. This specification leverages the Non-Storing DCO between the Root and the 6LR that serves as attachment Router for a RUL. A 6LR and a Root that support this specification MUST implement the Non-Storing DCO. > > > 494 6. Updating RFC 8505 > > [major] To me, Updating an RFC means that the implementations of that > RFC should also implement this one. In this case, there would be an > expectation that all 6LRs would support the change. Is that what is > intended? > > Note that Updating is different than simply expecting the nodes that > implement this specification to comply...in this case, *if* "the RPL > Root advertise[s] the capability...". > > [Personal opinion: rfc8505 applies to 6LRs in general, not just RPL > routers in particular...so I think that Updating it is not the right > choice.] > <was: Whao, a difficult one. We update the RFC8505 behavior. But not to all type of node that implement RFC 8505. Only those that are RPL Routers. So what is the most important? That we change the operation of an RFC or that the change ios scoped to a subset of nodes? I'm asking, not proposing and answer. The reason behind is that is another RFC updates RFC 8505 with a change that is not compatible, the fact that we did not update will make it harder to track. > Now: We update RFC 6775 and RFC 8505 because we alter the range of the ND Status Code. We extend RFC 6775 and RFC 8505 because we refrain from sending the from sending the EDAR on a registration refresh with the 'R' flag. We extend RFC 6775 because we process the 'R' flag in the NA(EARO) and other stuff in the RUL perspective section. > > 496 This document updates [RFC8505] to change the behavior of a RPL > 497 Router acting as 6LR in the 6LoWPAN ND Address Registration of a > RUL > 498 acting as 6LN. If the RPL Root advertise the capability to proxy the > 499 EDAR/EDAC exchange to the 6LBR, the 6LR refrains from sending the > 500 keep-alive EDAR message. Instead, if it is separated from the 6LBR, > 501 the Root regenerates the EDAR message to the 6LBR periodically, > upon > 502 a DAO message that signals the liveliness of the Address. > > > [] See the comment in §8 about a separate reason to Update rfc8505 and > rfc6775. > > > ... > 510 7.1. Support of 6LoWPAN ND > > 512 In order to obtain routing services from a 6LR, a RUL MUST > implement > 513 [RFC8505] and set the "R" and "T" flags in the EARO. The RUL > SHOULD > 514 support [AP-ND] to protect the ownership of its addresses. The RUL > 515 MUST NOT request routing services from a 6LR that does not > originate > 516 RA messages with a CIO that has the L, P, and E flags all set as > 517 discussed in Section 3.3.1, unless configured to do so. > > [major] I may be lost already... A RUL is by definition RPL-unaware. > It then follows that a RUL can't be assumed to be aware of this > specification, right? If so, then all the Normative language used in > this section can't be used because we can't specify the behavior of a > node that (by definition) is not aware of this document. [See more > related comments below.] This document is not RPL. A RUL is not aware of RFC 6550 but it must implement this. I believe with the help of Michael and the new text in the introduction, this is now resolved. For memory, that new text is " [USEofRPLinfo] introduces the terms RPL-Aware-Leaf (RAL) and RPL- Unaware Leaf (RUL). A RAL is a Leaf that injects Host routes in RPL to manage the reachability of its IPv6 addresses. Conversely, a RUL does not participate to RPL and cannot inject routes. Section 5 details a Host-to-Router interface that the RUL needs to implement to advertise its IPv6 addresses to a Router that supports this specification. The document specifies how the Router injects those addresses as Host Routes in the RPL network on behalf of the RUL. " > > Note that §1 defines a RUL this way: "A RUL is an IPv6 Host [RFC8504] > that needs a RPL-Aware Router to obtain routing services over the RPL > network." > Yes. It does not support RFC 6550 and needs a router that does; not clear what the contradiction was, but the text is the one that changed. I hope it is cleared now? > > [major] "The RUL SHOULD support [AP-ND] to protect the ownership of > its addresses." When it is ok for the RUL not to support AP-ND? > IOW, why is the support only recommended and not required? I see what you mean; more than in most case, the answer appear to be in the question. This text was already changed per your previous review; it now says " It is suggested that the RUL also implements [AP-ND] to protect the ownership of its addresses. " If you ask me, RFC 8505 and AP ND should be REQUIRED in 8504bis. > > > ... > 523 Parallel Address Registrations to several 6LRs SHOULD be performed > in > 524 an rapid sequence, using the exact same EARO for the same Address. > 525 Gaps between the Address Registrations will invalidate some of the > 526 routes till the Address Registration finally shows on those routes. > > > > [major] How fast is in "rapid sequence"...how big can "gaps" be? If > using Normative language, then the text needs to be specific. The point is that during the window thus created, only a subset of the routes will be available which limits the load balancing. I made that change for your review already? Strange. Parallel Address Registrations to several 6LRs should be performed in an rapid sequence, using the exact same EARO for the same Address. Gaps between the Address Registrations will invalidate some of the routes till the Address Registration finally shows on those routes. > > > 528 [RFC8505] introduces error Status values in the NA(EARO) which can > be > 529 received synchronously upon an NS(EARO) or asynchronously. The > RUL > 530 MUST support both cases and MUST refrain from using the address > when > 531 the Status Value indicates a rejection. > > [major] "MUST support both cases and MUST refrain" Isn't this > behavior already specified in rfc8505? We shouldn't use normative > language in that case (unless you are quoting directly). > Again already changed, more below. > > [major] I didn't find a "rejection" Status Value. I'm assuming you're > referring to a group of values: Duplicate Address, Moved, etc.. > Please be explicit. > That's in section 6.3 where we have " E: 1-bit flag. Set to indicate a rejection. When not set, a value " Let me add a reference. So we end up with " [RFC8505] introduces error Status values in the NA(EARO) which can be received synchronously upon an NS(EARO) or asynchronously. The RUL needs to support both cases and should refrain from using the address when the Status Value indicates a rejection (see Section 6.3). " > 533 7.2. External Routes and RPL Artifacts > > 535 Section 4.1 of [USEofRPLinfo] provides a set of rules detailed below > 536 that MUST be followed for routing packets from and to a RUL. > > [major] Because the specification is in USEofRPLinfo already, then > there's no need to normatively require it here as well. Also, not all > the actions in §4.1/USEofRPLinfo are required, some are just > recommended, so there would be a Normative conflict. s/MUST/must > Done > > ... > 554 The RPL data packets always carry a Hop-by-Hop Header to transport > a > 555 RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates > 556 its packets with an RPI, the 6LR needs to tunnel them to the Root to > 557 add the RPI. As a rule of a thumb and except for the very special > 558 case above, the packets from and to a RUL are always encapsulated > 559 using an IP-in-IP tunnel between the Root and the 6LR that serves the > 560 RUL (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, > 561 8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details). > > [minor] Listing all these sections may be prone to errors or > inconsistency. What about §7.1.3/§8.3.2? Maybe simply "see > [USEofRPLinfo] for details" is better. > Or a middle term between your proposals, e.g. ," sections 7 and 8 of [USEofRPLinfo] for details"? I hate the idea of asking to look at the whole big draft without a little help on where to search. > > 563 In Non-Storing Mode, packets going down carry a Source Routing > Header > 564 (SRH). The IP-in-IP encapsulation, the RPI and the SRH are > 565 collectively called the "RPL artifacts" and can be compressed using > 566 [RFC8138]. Figure 10 presents an example compressed format for a > 567 packet forwarded by the Root to a RUL in a Storing Mode DODAG. > > [minor] s/Figure 10/Appendix A > > Ok > ... > 576 A RUL is not expected to support the compression method defined in > 577 [RFC8138]. Unless configured otherwise, the border router MUST > 578 restore the outgoing packet before forwarding over an external route, > 579 even if it is not the destination of the incoming packet, and even > 580 when delivering to a RUL. > > [minor] s/restore/uncompress Ok > > > [major] "the border router MUST restore the outgoing packet before > forwarding over an external route, even if it is not the destination > of the incoming packet" > > USEofRPLinfo already specifies this behavior, so please don't specify > it again. Also, the language of "even if it is not the destination" > made me think twice about complying with rfc8200. Maybe better to > describe the behavior in the same way that USEofRPLinfo does. > > Suggestion> > A RUL is not expected to support the compression method defined in > [RFC8138]. The border router uncompresses the packet before forwarding > over an external route to a RUL [USEofRPLinfo]. > Thanks for the suggestion. Applied. > > ... > 608 8. Updated RPL Status > ... > 623 Table 1: RPL Status per RFC 6550 > > [minor] Please add a table (later in this section) showing the updated > RPL Status...along with a forward reference to the IANA Considerations > sub-section where the new registry is created. > We have this " 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |E|A| Value | +-+-+-+-+-+-+-+-+ Figure 5: RPL Status Format " > > [] BTW, this change should formally Update rfc6500. I read rfc6550. Yes, this is one of the 2 reasons to the formal update. Please note that there is no existing registry for the RPL status so we are creating it. But we're also merging the statis with the DCO-ACK Status In that we deprecate https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-dco-ack-status So we should update the NPDAO draft and remove that entry shouldn't we? Note that NPDAO is already in missref because of this draft https://www.rfc-editor.org/cluster_info.php?cid=C310 > > > 625 The 6LoWPAN ND Status was defined for use in the EARO and the > 626 currently defined values are listed in table 1 of [RFC8505]. This > 627 specification enables to carry the 6LoWPAN ND Status values in RPL > 628 DAO and DCO messages, embedded in the RPL Status field. > > [minor] "the currently defined values are listed in table 1 of [RFC8505]" > > Given that the registry is being modified, and that other values may > be added...it doesn't seem like a good idea to point at "currently > defined values". Please take out that part of the sentence. Ack; I can provide a ref to support the initial words instead " The 6LoWPAN ND Status was defined for use in the EARO, see section 4.1 of [RFC8505]. " > > 630 To achieve this, Section 13.2 reduces the range of the EARO Status > 631 values to 0-63 to ensure that they fit within a RPL Status as shown > 632 in Figure 3. > > [major] "Section 13.2 reduces the range" > > §13.2 is part of the IANA Considerations, which reflects what is > specified elsewhere. IOW, specify the reduced range elsewhere > (here?). > > Suggestion> > To achieve this, the range of the EARO Status values is reduced to 0-63. > This reduction ensures that the values fit within a RPL Status as shown in > Figure 3. > The suggestion is greatly appreciated. You also asked for the fwd pointer to IANA. " To achieve this, the range of the EARO Status values is reduced to 0-63. This reduction ensures that the values fit within a RPL Status as shown in Figure 5. See Section 12.2, Section 12.5, and Section 12.6 for the IANA declarations. " > > [major] What about the ARO? The Status values are shared between the > EARO and the ARO. The IANA update applies to the registry that was created by RFC 6775 and updated by RFC 8505. The text actually points at RFC 6775 as the reference for the registry so we are impacting both ARO and EARO. " 12.2. Resizing the ARO Status values Section 12 of [RFC6775] creates the Address Registration Option Status Values Registry with a range 0-255. This specification reduces that range to 0-63. IANA is requested to reduce the upper bound of the unassigned values in the Address Registration Option Status Values Registry from -255 to -63. " > > > [major] Changing the range of values is not as easy as updating the > registry...the behavior of the EARO and ARO have to be updated. This > means that this document should Update both rfc6775 and rfc8505 where > it relates to the redefined Status field. Isn't this transitive? I mean the field defined in RFC 6775 is updated by RFC 8505. Maybe the 6lo group should clarify that the ARO is deprecated somehow? > > The E/A flags (below) don't seem to apply to the ARO/EARO, so a > specification of the behavior is needed; something like "ignore the > first two bits". > > > 634 0 1 2 3 4 5 6 7 > 635 +-+-+-+-+-+-+-+-+ > 636 |E|A| Value | > 637 +-+-+-+-+-+-+-+-+ > For "E" its another way if saying >127 as RPL did in the past. So this is not a change that the code can see. For "A" set, there was no such case in the past. Now I'm confused. Who should ignore the bits? An old implementation will see unknown status values when the A bit is set by a new implementation. An old implementation will not set those bits because the status values > > ... > 643 E: 1-bit flag. Set to indicate a rejection. When not set, a value > 644 of 0 indicates Success/Unqualified acceptance and other values > 645 indicate "not an outright rejection" as per RFC 6550. > > [minor] "When not set, a value of 0...and other values..." This is > just one bit, so there are only two values, not "other values". ;-) > You obviously mean "a value of 0...and other values of the RPL > Status". > > s/a value of 0/an RPL Status value of 0 Ok > > > [major] ""not an outright rejection" as per RFC 6550" rfc6550 > differentiated between a "rejection" and "not an outright rejection". > Is the intent for the rejection codes to reflect that difference (at > some point), or is the ability to signal the difference lost? This describes the art of RPL? In this case, not a rejection means that the command was accepted but something meaningful happened that is worth signaling. The problem is to enable a backward compatibility for new status codes. A code written today will not be able to understand beyond the fact that the bit is set or not. But at least it can consider that the command was executed or not and take a different path. > > > ... > 649 Status Value: 6-bit unsigned integer. If the 'A' flag is set this > 650 field transports a Status Value defined for IPv6 ND EARO. When > 651 the 'A' flag is not set, the Status Value is defined for RPL. > > [major] This change in the RPL Status format should be a formal Update > of rfc6550. Done > > > 653 When building a DCO or a DAO-ACK message upon an IPv6 ND NA or > a EDAC > 654 message, the RPL Root MUST copy the 6LoWPAN ND Status > unchanged in > 655 the RPL Status and set the 'A' bit. The RPL Root MUST set the 'E' > 656 flag for Values in range 1-10 which are all considered rejections. > > [nit] s/'A' bit/'A' flag Done twice > > [major] What should the receiver do if the corresponding 6LoWPAN ND > Status is unknown? Or does it matter? I'm wondering if "MUST" is the > right requirement, or if should be "SHOULD"... > > > [major] What should a receiver do if the E flag is not set for "Values > in range 1-10"? Fair enough. > > > [major] For future rejection-related values, the E flag has to also be > set, right? Right, that is what makes it hard, but if you look at it, 6LoWPAN ND is missing that bit. So an existing implementation already has the problem of dealing with unknown status which means that by default it is an error. So setting the 'E' flag for unknown value is the safe bet. > How can we word the specification so that we don't depend > on future specification saying that the E flag has to be set? I worry > that not all the status codes use the work "rejection", even if their > description (rfc8505) can be interpreted as such. Maybe something > like this: > > The RPL Root MUST set the 'E' flag for all rejection Values. The Status > Codes in range 1-10 [rfc8505] are all considered rejections. > Excellent; I added 'unknown' " The RPL Root MUST set the 'E' flag for all rejection and unknown Status Codes. The Status Codes in range 1-10 [RFC8505] are all considered rejections." > > 658 Reciprocally, upon a DCO or a DAO-ACK message from the RPL Root > with > 659 a RPL Status that has the 'A' bit set, the 6LR MUST copy the RPL > 660 Status Value unchanged in the Status field of the EARO when > 661 generating an NA to the RUL. > > [major] "MUST copy the RPL Status Value unchanged" Even if the value > is unknown? Yes. It is unknown to the Root but still informative, e.g., at the 6LR or looking at traces. Why loose that information? > > > 663 9. Updated RPL Target Option > ... > 679 With this specification the ROVR is the remainder of the RPL Target > 680 Option. The size of the ROVR is indicated in a new ROVR Size field > 681 that is encoded to map one-to-one with the Code Suffix in the EDAR > 682 message (see table 4 of [RFC8505]). > > [nit] "ROVR Size field" The field is called ROVRsz. To be > consistent, perhaps describe the field (below) as "ROVRsz (ROVR > Size):" > Cool, done > > [?] Why is the size of the ROVR needed? It can be figured out from > the setting of the F flag and the Option and Prefix Lengths. Just > curious. > In EDAR we have to deduce from the overall length and that blocked the extensibility of the message, e.g., to add options. So we ended up coding it in the code suffix, see https://tools.ietf.org/html/rfc8505#section-4.2. Better safe than sorry. > > 684 The modified format is illustrated in Figure 4. It is backward > 685 compatible with the Target Option in [RFC6550] and SHOULD be used > as > 686 a replacement in new implementations even for Storing Mode > operations > 687 in preparation for upcoming security mechanisms based in the ROVR. > > [nit] s/modified format/updated format > Yep; note the not-so-subtle hint that ROVR was designed for ROV even if defined in ND ; ) > [major] "It is backward compatible..." > > True, but what about "forward" compatible? If the F flag is not set, > how does a receiver know that this is the updated Option? The legacy implementation reads the bits up to Prefix Length And ignores the rest. So it ignores that the address of the host is in full, and it ignores that the ROVR is present. The other way around, the ROVRsz set to 0 indicates that the ROVR is not there. So we get: " ROVRsz (ROVR Size): Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits, respectively. A value if 0 thus denotes a legacy Target Option. " > Is there a > chance of spurious information (in either the flag or the ROVRsz) to > be present and cause the receiver to misinterpret the information? I > know that rfc6550 specifies that the "field MUST be initialized to > zero by the sender and MUST be ignored by the receiver"...but I just > want to test the edges. Well it's a MUST... if a reserved field is not set to 0 all bets are off anywhere you use a reserved space for backward compatibility. The chances is that Rover Size + Prefix Length as wrongly computed exceed the Option Length, in which case it can be detected and reported. > > This forward compatibility may be a reason to formally Update rfc6550. The updated RTO is one of the 2 reasons, the status being the other; but I do not think we have a forward compatibility problem. > > > [major] "SHOULD be used as a replacement in new implementations" > > Referring to §4 (Updating RFC 6550) and my comments there about > Updating... If this change is an Update -- meaning that all RPL nodes > must support it --, when would it be ok to not use it? IOW, why is it > a recommendation and not a requirement. Extremely constrained nodes may not be able to. > > OTOH, the modification is backwards compatible...so only the nodes > that need to understand the change need to implement it. > > > [major] "...in preparation for upcoming security mechanisms" > > What it that? If support is required for a different specification, > what is it? It seems to me that recommending the use in preparation > for something in the future is not appropriate in a specification > without an explicit reference. > > > 689 0 1 2 3 > 690 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 692 | Type = 0x05 | Option Length |ROVRsz |F|Flags| Prefix Length | > 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 694 | | > 695 | Target Prefix (Variable Length) | > 696 . . > 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 698 | | > 699 ... Registration Ownership Verifier (ROVR) ... > 700 | | > 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 703 Figure 4: Updated Target Option > > [nit] Align the bit numbers: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > 705 New fields: > > 707 ROVRsz: Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4, > 708 denoting a ROVR size of 64, 128, 192, or 256 bits, respectively. > > [major] s/MAY be 1, 2, 3, or 4/MUST be 1, 2, 3, or 4 > > It is not optional to use those values, they are the only ones. > > > [?] Why are 4 bits needed if there are only 4 values? Why not just use 3? > > > [major] What should the receiver do if a different value is used? > > > 710 F: 1-bit flag. Set to indicate that Target Prefix field contains an > 711 Address of prefix advertiser in full. > > [minor] To be in sync with the Registry in §15: > s/F:/F (Advertiser Address in Full): > I'd rather say: " The new 'F' flag is set to indicate that the Target Prefix field contains the IPv6 address of the advertising node, in which case the length of the Target Prefix field is 128 bits regardless of the value of the Prefix Length field. If the 'F' flag is reset, the Target " To your point on the registry I changed the first appearance of the 'F' flag to: " Section 6.7.7 of [RFC6550] introduces the RPL Target Option, which can be used in RPL Control messages such as the DAO message to signal a destination prefix. This document adds the capabilities to transport the ROVR field (see Section 4.2.3) and the IPv6 Address of the prefix advertiser when the Target is a shorter prefix. Their use is signaled respectively by a new ROVR Size field being non-zero and a new "Advertiser address in Full" 'F' flag set, more in Section 6.1. This specification defines the new "Root Proxies EDAR/EDAC" (P) flag and encodes it in one of these reserved flags of the RPL DODAG Configuration option, more in Section 6.2 " > > ... > 716 10. Protocol Operations for Unicast Addresses > > 718 The description below assumes that the Root sets the "P" flag in the > 719 DODAG Configuration Option and performs the EDAR proxy > operation. > > [major] Where is the "P" flag defined? I didn't find it in this draft. It is now in that new text where we describe the relation with the MOP " This specification defines a new flag "Root Proxies EDAR/EDAC" (P). The 'P' flag is encoded in position 1 of the reserved Flags in the DODAG Configuration Option (counting from bit 0 as the most significant bit) and set to 0 in legacy implementations as specified respectively in Sections 20.14 and 6.7.6 of [RFC6550]. The 'P' flag is set to indicate that the Root performs the proxy operation, which implies that it supports this specification and the updated RPL Target Option (see Section 6.1). Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the definition of the Flags applies to Mode of Operation (MOP) values zero (0) to six (6) only. For a MOP value of 7, the Root is expected to perform the proxy operation by default. " > > > ... > 726 10.1. General Flow > > [minor] It would be very nice if at the start of this sub-section a > note mentioned the fact that §10.2 contains the detailed operation. > That would help the linear reader (like me!) time in trying to figure > out the details. ;-) Oups. Noting that section 10 is now section 9. I added just before 9.1: " Section 9.1 provides an overview of the route injection in RPL, whereas Section 9.2 offers more details from the perspective of the different nodes involved in the flow. 9.1. General Flow " > > > [minor] Also, it would be great if this overview had forward > references to where the detail is provided. > Problem is that is triaged per node type. > > ... > 775 On the first Address Registration, illustrated in Figure 5 for RPL > 776 Non-Storing Mode, the Extended Duplicate Address exchange takes > place > 777 as prescribed by [RFC8505]. If the exchange fails, the 6LR returns > 778 an NA message with a negative status to the 6LN, the NCE is not > 779 created and the address is not injected in RPL. If it is successful, > 780 the 6LR creates an NCE and injects the Registered Address in the RPL > 781 routing using a DAO/DAO-ACK exchange with the RPL DODAG Root. > > [major] "the Extended Duplicate Address exchange takes place as > prescribed by [RFC8505]" Yes, except that NA is delayed until after > the RPL registration is completed. (See related comments in §10.2.2 > below.) > The EDAR exchange does not comprise the NA. AlsoRFC 8505 does not indicate a strict timing for the NA. But I expect this issue resurfaces later as you indicate. Let's see: > > 783 An issue may be detected later, e.g., the address moves within the > 784 LLN or to a different Root on a backbone [6BBR]. In that case the > 785 value of the status that indicates the issue can be passed from > 786 6LoWPAN ND to RPL and back as illustrated in Figure 6. > > [minor] "backbone router" is not used anywhere else. Do we need to > introduce this term and reference here? It seems like an unnecessary > reference to me. 6BBR is defined in https://www.rfc-editor.org/authors/rfc8929.html , now in AUTH 48. Since * it exists and * may provide a synchronous or asynchronous error in a NA(EARO) * does not expect (or could not care less) that the 6LBR and the Root may be separated I thought we needed the flow to complete the picture. This is also the the only known case where we inject "moved" or "removed" so I thought it was worth mentioning to get the full picture. Actually the original figure next had a typo, the node on the right was not a 6LBR but a 6BBR on the right. I changed to present both in case the Root is not collocated ith the 6LBR. I also indicated the protocols in the figure for clarity. " An issue may be detected later, e.g., the address moves to a different DODAG with the 6LBR attached to a different 6LoWPAN Backbone Router (6BBR), see Figure 5 in section 3.3 of [6BBR]. The 6BBR may send a negative ND status, e.g., in an asynchronous NA(EARO) to the 6LBR. [6BBR] expects that the 6LBR is collocated with the RPL root, but if not, the 6LBR MUST forward the Status Code to the originator of the EDAR, either the 6LR or the RPL root that proxies for it. The ND Status Code is mapped in a RPL Status Value by the RPL Root, and then back by the 6LR. Figure 8 illustrates this in the case where the 6LBR and the Root are not collocated, and the Root proxies the EDAR messages. 6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR <-ND-> 6BBR | | | | | | | | | NA(EARO) | | | | |<------------| | | | EDAC | | | | |<-------------| | | | DCO | | | | |<------------| | | | NA(EARO) | | | | |<-------------| | | | | | | | | Figure 8: Asynchronous Issue If the Root does not proxy, then the EDAC with a negative status reaches the 6LR directly. In that case, the 6LR MUST clean up the route using a DAO with a Lifetime of zero, and propagate the status back to the RUL in a NA(EARO) with the "R" flag not set.. " I moved the text above down a bit where it seems to fit more logically > ... > 800 An Address re-Registration is performed by the 6LN to maintain the > 801 NCE in the 6LR alive before lifetime expires. Upon the refresh of an > 802 Address re-Registration, as illustrated in Figure 7, the 6LR injects > 803 the Registered Address in RPL. > > > > [major] Under what circumstances does the process in Figure 7 apply? > I'm assuming that only if the registration hasn't expired, is that > true? Earlier we explain that the lifetimes are aligned. Since you may have missed it, I clarify that text as: " To achieve this, the lifetimes and sequence counters in 6LoWPAN ND and RPL are aligned. " And then " An Address Registration refresh is performed by the 6LN to maintain the NCE in the 6LR alive before the lifetime expires. Upon the refresh of a registration, the 6LR reinjects the corresponding route in RPL before it expires, as illustrated in Figure 7. " > If the registration already expired, should the whole process > (Figure 5) be repeated? Yes but the alignment of lifetime is meant to avoid that. I see mention of (re)registration in §10.2.1, > but none in §10.2.2. > The first paragraph was about this. " Also as prescribed by [RFC8505], the 6LR generates an EDAR message upon reception of a valid NS(EARO) message for the registration of a new IPv6 address by a 6LN. If the initial EDAR/EDAC exchange succeeds, then the 6LR installs an NCE for the Registration Lifetime. For the registration refreshes, if the RPL Root has indicated that it proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see Section 6), the 6LR MUST refrain from sending the keep-alive EDAR. " Let me use 'registration refresh' throughout for consistency. > ... > 828 The 6LR may receive a requested DAO-ACK after it received an > 829 asynchronous DCO, but the negative Status in the DCO supersedes a > 830 positive Status in the DAO-ACK regardless of the order in which they > 831 are received. Upon the DAO-ACK - or the DCO if one arrives first - > 832 the 6LR responds to the RUL with an NA(EARO). > > [major] "the negative Status in the DCO supersedes a positive Status > in the DAO-ACK regardless of the order in which they are received" > > I don't remember anything like this in > draft-ietf-roll-efficient-npdao. Should something be mentioned? There was no mapping between ND and RPL so far. We are redefining the DCO status to be a RPL status and conform the same mapping as the rest. DCO is asynchronous; the message may fly slower or faster than the DAO-ACK. We want to avoid confusion if both are received with a different status. > The > ability of a parent to send an unsolicited DCO seems to fall in the > same category: the DAO-ACK doesn't matter if the DCO was received > first... Yes > > I'm assuming the DCO negative status in this case has some type of > expiration time, right? I'm thinking of the case where a problem did > occur, but on a retry there is success...?? I do not know of such a case. But then, that should be a case where the 'E' flag is cleared. Else the DCO destroys the route. > > This property of the DCO allows a rogue node to invalidate a > registration. Something similar to this text from > draft-ietf-roll-efficient-npdao should be included in the Security > Considerations section: > > This document introduces the ability for a common ancestor node to > invalidate a route on behalf of the target node. The common ancestor > node could be directed to do so by the target node using the 'I' flag > in DCO's Transit Information Option. However, the common ancestor > node is in a position to unilaterally initiate the route invalidation > since it possesses all the required state information, namely, the > Target address and the corresponding Path Sequence. Thus a rogue > common ancestor node could initiate such an invalidation and impact > the traffic to the target node. > Makes sense; I added " [EFFICIENT-NPDAO] introduces the ability for a rogue common ancestor node to invalidate a route on behalf of the target node. In that case, the RPL Status in the DCO has the 'A' flag not set, and a NA(EARO) is returned to the 6LN with the 'R' flag not set. This encourages the 6LN to try another 6LR. If a 6LR exists that does not use the rogue common ancestor, then the 6LN will eventually succeed gaining reachability over the RPL network in spite of the rogue node. " > > 834 The RUL MAY terminate the registration at any time by using a > 835 Registration Lifetime of 0. This specification requires that the RPL > 836 Target Option transports the ROVR. This way, the same flow as the > 837 heartbeat flow is sufficient to inform the 6LBR using the Root as > 838 proxy as illustrated in Figure 7. > > [major] s/MAY/may In this case, the sentence is just pointing at a > fact, not making a normative statement. > Done > > 843 10.2. Detailed Operation > > 845 10.2.1. Perspective of the RUL Acting as 6LN > > 847 This specification does not alter the operation of a 6LoWPAN ND- > 848 compliant 6LN, and a RUL is expected to operate as follows: > > [minor] s/6LN, and a RUL /6LN/RUL, which Done > > > 850 1. The 6LN obtains an IPv6 global address, either using Stateless > 851 Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix > 852 Information Option (PIO) [RFC4861] found in an RA message, or > 853 some other means such as DHCPv6 [RFC3315]. > > [major] s/RFC3315/RFC8415 Oups > > > 855 2. Once it has formed an address, the 6LN (re)registers its address > 856 periodically, within the Lifetime of the previous Address > 857 Registration, as prescribed by [RFC6775], to refresh the NCE > 858 before the lifetime indicated in the EARO expires. It MUST set > 859 the "T" flag and the TID is incremented each time and wraps in a > 860 lollipop fashion (see section 5.2.1 of [RFC8505] which is fully > 861 compatible with section 7.2 of [RFC6550]). > > [minor] s/It MUST set the "T" flag and the TID is incremented/It MUST > set the "T" flag. The TID is incremented > Done > > [nit] s/[RFC8505] which/[RFC8505], which Done > > > 863 3. As stated in section 5.2 of [RFC8505], the 6LN can register to > 864 more than one 6LR at the same time. In that case, it uses the > 865 same EARO for all of the parallel Address Registrations. The 6LN > 866 SHOULD send the registration(s) that have a non-zero Registration > 867 Lifetime and ensure that one succeeds before it terminates other > 868 registrations, to maintain the state in the network and at the > 869 6LBR and minimize the churn. > > [major] "The 6LN SHOULD send the registration(s) that have a non-zero > Registration Lifetime..." > > It sounds as if you're trying to specify what the value of the > Registration Lifetime should be. If so: s/that have a non-zero/with a > non-zero Done > > What are the cases when it is ok to not use a non-zero value? IOW, > why is it recommended and not required? rfc8505 talks about setting > the Registration Lifetime to 0, which brings me to: it seems to me > that the Normative language may be out of place since the > specification is already made in rfc8505. ?? What is recommended is to do the registration(s) that keep(s) the state active before the ones that destroy it, so there is no transient when the state is destroy for nothing. Rewording to: " 3. As stated in section 5.2 of [RFC8505], the 6LN can register to more than one 6LR at the same time. In that case, it uses the same EARO for all of the parallel Address Registrations. The 6LN SHOULD send the NS(EARO), if any, that maintain a registration active (i.e., with a non-zero Registration Lifetime) and ensure that one succeeds before it sends an NS(EARO) that terminates other registrations, to avoid the churn related to transient route invalidation in the RPL network. " > 871 4. Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets > 872 the "R" flag in the EARO of at least one registration, whereas > 873 acting as a RAN it never does. If the "R" flag is not echoed in > 874 the NA, the RUL SHOULD attempt to use another 6LR. The RUL > 875 SHOULD send the registration(s) with the "R" flag set and ensure > 876 that one succeeds before it sends the registrations with the flag > 877 reset. In case of a conflict with the preceeding rule on > 878 lifetime, the rule on lifetime has precedence. > > [nit] "6LN acting as a RUL" The title of this section is "Perspective > of the RUL Acting as 6LN", which one is it? ;-) Argl The former Fixed; multiple places > > > [minor] "whereas acting as a RAN it never does" rfc8505 says this: > "A 6LR that manages its reachability SHOULD NOT set the R flag". > "SHOULD NOT" doesn't imply never. Agreed, that is incorrect. I removed that extra text. > > [minor] "If the "R" flag is not echoed in the NA..." I didn't find in > rfc8505 where echoing the R flag is discussed. But §10.2.2 requires > the R flag set...is that where the specification is? . Which means we extend RFC 8505. At some point we want to apply that to any node that sets the 'R' flag. Maybe a 6Lo draft that generalizes this in the future? > > [major] "SHOULD send the registration(s) with the "R" flag set and > ensure that one succeeds before it sends the registrations with the > flag reset." > > This text is in conflict with §5.1/rfc8505: "MUST set the R flag to > indicate that it is not a router and that it will not handle its own > reachability". There isn't a provision for a RUL to not set the R > flag. I did not write that text in that meaning. Maybe that's my English. The text is meant to say that it MUST set the R flag if it wishes to indicate that it is not a router and blah. This spec shows cases where the 6LN enables and disables routing in a collection of 6LRs while it is active in others, and provides means to move the routing registrations. " As stated in section 5.2 of [RFC8505], the 6LN can register to more than one 6LR at the same time. In that case, it uses the same EARO for all of the parallel Address Registrations, with the exception of the Registration Lifetime field and the setting of the R flag that may differ. The 6LN SHOULD send the NS(EARO), if any, that maintain a registration active (i.e., with a non-zero Registration Lifetime) and ensure that one succeeds before it sends an NS(EARO) that terminates another registration, to avoid the churn related to transient route invalidation in the RPL network. " > > > 880 5. The 6LN may use any of the 6LRs to which it registered as default > 881 gateway. Using a 6LR to which the 6LN is not registered may > 882 result in packets dropped at the 6LR by a Source Address > 883 Validation function (SAVI) so it is NOT RECOMMENDED. > > > > [minor] Please add an Informative reference to SAVI. Done > > > [major] s/NOT RECOMMENDED/not recommended > This text is not specifying normative behavior related to interoperability. > > Done > 885 Even without support for RPL, a RUL may be aware of opaque values > to > 886 be provided to the routing protocol. If the RUL has a knowledge of > 887 the RPL Instance the packet should be injected into, then it SHOULD > 888 set the Opaque field in the EARO to the RPLInstanceID, else it MUST > 889 leave the Opaque field to zero. > > > [major] If a RUL is *unaware* by definition, I don't see how this > paragraph can fit in this specification...especially because it seems > to be speculating about potential knowledge ("may be aware of opaque > values")... What do we call a RUL that has partial knowledge? We do not have a name for that. Do we need one? The idea is that the stack can be provided with an opaque that is passed on. This is a way to implement was is now known as app aware networking in IoT ; ) There's a difference between being provided with an instance number and speaking fluent RPL. I removed aware as follows: " Even without support for RPL, a RUL may be configured with an opaque value to be provided to the routing protocol. If the RUL has knowledge of the RPL Instance the packet should be injected into, then it SHOULD set the Opaque field in the EARO to the RPLInstanceID, else it MUST leave the Opaque field to zero. " > 895 A RUL is not expected to produce RPL artifacts in the data packets, > 896 but it MAY do so. For instance, if the RUL has a minimal awareness > 897 of the RPL Instance then it can build an RPI. A RUL that places an > 898 RPI in a data packet MUST indicate the RPLInstanceID of the RPL > 899 Instance where the packet should be forwarded. All the flags and the > 900 Rank field are set to zero as specified by section 11.2 of [RFC6550]. > > [major] s/MAY/may In this case, the text is just expressing a fact, > not a Normative action. I'm still confused what a normative MAY is ! > > [major] The Normative text in this paragraph is equivalent to the one > above (two paragraphs up)...please avoid duplication/redundancy. You lost me. I reread (twice) the text above. And this is the only place the RUL manipulates the opaque. > > > [major] "A RUL that places an RPI in a data packet MUST indicate the > RPLInstanceID of the RPL Instance where the packet should be > forwarded." > > So...even if we leave the *unaware* nature of a RUL out...this text > means that any leaf can inject traffic onto an RPL Instance, just by > knowing the ID (or even guessing it). Please add some text in the > Security Considerations about how the rfc6553 considerations apply > here too. I agree on principle, not sure what to do with RFC 6553. RFC 6553 discusses inconsistencies in the forwarding plane that are discovered by the router not the host. What about: " The Opaque field in the EARO enables the RUL to suggest a RPLInstanceID where its traffic is placed. This opens to attacks where a RPL instance would be reserved for critical traffic, e.g., with a specific bandwidth reservation, that the additional traffic generated by a rogue may disrupt. This may be alleviated by traditional access control mechanisms where the 6LR shapes the incoming traffic from the 6LN. " > > > 902 10.2.2. Perspective of the Border Router Acting as 6LR > > [nit] How else would a Border Router act as? We turned around 6LR acting as a.. above. This applies here too: 9.2.2. Perspective of the 6LR Acting as Border Router > > > [] This terminology of "acting as" is confusing... <sigh> > We sync'ed above. But yes. > 912 If the "R" flag is set in the NS(EARO), the 6LR MUST inject the Host > 913 route in RPL, unless this is barred for other reasons, such as the > 914 saturation of the RPL parents. The 6LR MUST use a RPL Non-Storing > 915 Mode signaling and the updated Target Option (see Section 9). The > 916 6LR MUST request a DAO-ACK by setting the 'K' flag in the DAO > 917 message. Success injecting the route to the RUL is indicated by the > 918 'E' flag set to 0 in the RPL status of the DAO-ACK message. > > [major] What is "the Host route"? I guess you mean a "host route to > the Registered Address contained in the EDAC". Or, as you mention > later, "router to the RUL". > It is the host route to the Registered Address contained in the target of the NS(EARO). Saying 'to the RUL' is a simplification. I changed to "RUL's address". But that really makes text awkward. I checked, we use "the host route" several times. Related to this, the first use is " Section 5 details a Host-to-Router interface that the RUL needs to implement to advertise its IPv6 addresses to a Router that supports this specification. The document specifies how the Router injects those addresses as Host routes in the RPL network on behalf of the RUL. " > > [major] "MUST...unless" The use of MUST implies no > exceptions. s/MUST/SHOULD OK; not sure I agree but I did it. My concern is that a MUST could be conditional. If blah then MUST. So what I wrong with MUST do this, unless condition blah? I wen through the text, this applies several times. > > > 920 The Opaque field in the EARO hints the 6LR on the RPL Instance that > 921 SHOULD be used for the DAO advertisements, and for the forwarding > of > 922 packets sourced at the registered address when there is no RPI in the > 923 packet, in which case the 6LR MUST encapsulate the packet to the > Root > 924 adding an RPI in the outer header. If the Opaque field is zero, the > 925 6LR is free to use the default RPL Instance (zero) for the registered > 926 address or to select an Instance of its choice. > > [major] "hints" It is really a hint, or the RPL Instance? If only a > hint, where would the Instance that "SHOULD be used" come from? The > text in §10.2.1 implies that the 6LN knows what the Instance is. The 6LR may be configured to map the opaque in a RPLINstanceID. E.g., the opaque means an application, and the router maps an application to an Instance. This is outside the scope of this spec. That's why it is opaque. > [major] "the RPL Instance that SHOULD be used for the DAO advertisements" > > When would the 6LR not use the Instance signaled by the 6LN? IOW, why > is this a recommendation and not a requirement? This is a hint for a policy but yes I signal in the RPLInstanceId directly is easier. More follows... > > [major] "SHOULD be used for...forwarding...in which case the 6LR MUST > encapsulate the packet to the Root adding an RPI in the outer header" > > There's a Normative conflict between recommending the use of the > RPLInstanceID and requiring the use of the RPI (which contains the > RPLInstanceID). > I removed both uppercase and in fact the encaps thing which is a resay of useofrplinfo. There's a MUST about the instance a bit later that serves the purpose. More follows... > [minor] How is the 6LR to "select an Instance of its choice"? > §11.2/rfc6550 talks specifically about the need for guidance for > external packets: > > The definition and provisioning of RPL Instances are out of scope for > this specification. Guidelines may be application and implementation > specific, and they are expected to be elaborated in future companion > specifications. Those operations are expected to be such that data > packets coming from the outside of the RPL network can unambiguously > be associated to at least one RPL Instance and be safely routed over > any instance that would match the packet. > Great point! I picked the quote (and I love whoever wrote it even if that's me). More follows... > > 928 If the "I" field is not zero, then the 6LR MUST consider that the > 929 Opaque field is zero. If the Opaque field is not zero, then it is > 930 expected to carry a RPLInstanceID for the RPL Instance suggested by > 931 the 6LN. If the 6LR does not participate to the associated Instance, > 932 then the 6LR MUST consider that the Opaque field is zero; else, that > 933 is if the 6LR participates to the suggested RPL Instance, then the > 934 6LR SHOULD use that Instance for the Registered Address. > > [nit] There is some redundancy/repetition between this paragraph and > the last one. Yes, cleaning up More follows... > > > [major] "If the "I" field is not zero, then the 6LR MUST consider that > the Opaque field is zero." > > rfc8505 already specifies pretty much the same thing. It is more abstract, the hint could have been an indirection to the instanceid but OK More follows... > > OLD> > If the "I" field is not zero, then the 6LR MUST consider that the > Opaque field is zero. If the Opaque field is not zero, then it is > expected to carry a RPLInstanceID for the RPL Instance suggested by > the 6LN. > > NEW> > As described in rfc8505, if the "I" field is zero, then the Opaque field > is expected to carry the RPLInstanceID suggested by the 6LN. Otherwise, > the Opaque field is ignored. > Got you. Summary of all the above: " The Opaque field in the EARO provides a mean to signal which RPL Instance is to be used for the DAO advertisements and the forwarding of packets sourced at the Registered Address when there is no RPI in the packet. As described in [RFC8505], if the "I" field is zero, then the Opaque field is expected to carry the RPLInstanceID suggested by the 6LN; otherwise, there is no suggested Instance. If the 6LR participates in the suggested RPL Instance, then the 6LR MUST use that RPL Instance for the Registered Address. If there is no suggested RPL Instance or else if the 6LR does not participate to the suggested Instance, it is expected that the packets coming from the 6LN "can unambiguously be associated to at least one RPL Instance" [RFC6550] by the 6LR. " > ... > 939 1. The Registered Address is signaled as Target Prefix in the > 940 updated Target Option in the DAO message; the Prefix Length is > 941 set to 128. The ROVR field is copied unchanged from the EARO > 942 (see Section 9). > > [minor] "Prefix Length is set to 128" ...and the F flag is set. Yes I should mention: The F flag must not be set. The advertiser is the 6LR not the 6LN. > > > > 951 4. the Path Lifetime in the TIO is computed from the Lifetime in the > 952 EARO Option. This adapts it to the Lifetime Units used in the > 953 RPL operation; note that if the lifetime is 0, then the DAO > 954 message is a No-Path DAO that cleans up the the routes down to > 955 the RUL; this also causes the Root as a proxy to send an EDAR > 956 message to the 6LBR with a Lifetime of 0. > > [minor] s/Lifetime/Registration Lifetime > > > [minor] "Path Lifetime in the TIO is computed" How? Given that the > Registration Lifetime is in seconds, but the Lifetime Unit can be in > days, there may be cases where the result is close to 0. Would that > result in an NPDAO? > Yes, clarification needed " 4. the Path Lifetime in the TIO is computed from the Registration Lifetime in the EARO. This operation converts seconds to the Lifetime Units used in the RPL operation. This creates the deployment constraint that the Lifetime Unit is reasonably compatible with the expression of the Registration Lifetime. e.g., a Lifetime Unit of 0x4000 maps the most significant byte of the Registration Lifetime to the Path Lifetime. In that operation, the Path Lifetime must be rounded, if needed, to the upper value to ensure that the path has a longer lifetime than the registration. Note that if the Registration Lifetime is 0, then the Path Lifetime is also 0 and the DAO message becomes a No-Path DAO, which cleans up the routes down to the RUL's address; this also causes the Root as a proxy to send an EDAR message to the 6LBR with a Lifetime of 0. " > > > ... > 961 Upon receiving the DAO-ACK or an asynchronous DCO message, the > 6LR > 962 MUST send the NA(EARO) to the RUL. > > [major] "Upon receiving the DAO-ACK ...the 6LR MUST send the NA(EARO)". > > My interpretation is that the 6LR will wait for the DAO-ACK before > sending the NA(EARO), is that correct? Yes, normally; the DCO could have interrupted that. More below: > > §9.3/rfc6550: > > 4. A node receiving a unicast DAO message with the 'K' flag set > SHOULD respond with a DAO-ACK. A node receiving a DAO message > without the 'K' flag set MAY respond with a DAO-ACK, especially > to report an error condition. > > 5. A node that sets the 'K' flag in a unicast DAO message but does > not receive a DAO-ACK in response MAY reschedule the DAO message > transmission for another attempt, up until an implementation- > specific number of retries. > > This text says that the 6LR may never receive a DAO-ACK. If that > happens (even after trying again), what should the 6LR do? During > this time the RUL is waiting for the NS(EARO)... Yes, this was implicitly inherited but OK I added it in the text quoted below " Upon receiving or timing out the DAO-ACK after an implementation- specific number of retries, the 6LR MUST send the corresponding NA(EARO) to the RUL. Upon receiving an asynchronous DCO message, if a DAO-ACK is pending then the 6LR MUST wait for the DAO-ACK to send the NA(EARO) and deliver the status found in the DCO, else it MUST send an asynchronous NA(EARO) to the RUL immediately. " > 974 If the 'A' flag is not set in the RPL Status of the DAO-ACK, then the > 975 6LoWPAN ND operation succeeded and an EARO Status of 0 (Success) > MUST > 976 be returned to the RUL, even if the 'E' flag is set in the RPL > 977 Status. The EARO Status of 0 MUST also be used if the 6LR could not > 978 even try to inject the route. > > [major] "If the 'A' flag is not set in the RPL Status of the DAO-ACK, > then the 6LoWPAN ND operation succeeded..." > > §8 says this: "the RPL Root MUST copy the 6LoWPAN ND Status unchanged > in the RPL Status and set the 'A' bit" This means that if the A flag > is not set then the Root didn't comply with the MUST in §8...or that > it did not copy result from the EDAC...which then means that the > DAO-ACK is not valid. What am I missing? The 'A' flag is not set if the error came from RPL, like the Root is unhappy for a reason not related to ND. This is not a 6LoWPAN problem and the 6LoWPAN piece is considered a success. > > [major] "even if the 'E' flag is set" Sorry, what? The E flag > indicates a rejection... I thought I understood the logic (in §8) of > setting the A/E flags...but it seems that I didn't. It would be ideal > to then be explicit about the different combinations and how we can > get to them. Same as above, there is a RPL Error, no ND error, the ND status that is returned is OK, but the R flag is down, meaning that an ND binding was created but no route. This is what the sentence right after indicates. Maybe I can place moe things around to make the logic more clear. A and E are independent. " An error injecting the route causes the 'E' flag to be set. If the error is not related to ND, the 'A' flag is not set. In that case, the registration succeeds but the RPL route is not installed. So the NA(EARO) is returned with a positive status but the R Flag not set, which means that the 6LN obtained a binding but no route. If the 'A' flag is not set in the RPL Status of the DAO-ACK, then the 6LoWPAN ND operation succeeded, and an EARO Status of 0 (Success) MUST be returned to the 6LN. The EARO Status of 0 MUST also be used if the 6LR did not attempt to inject the route but could create the binding after a successful EDAR/EDAC exchange or refresh it. If the 'E' flag is set in the RPL Status of the DAO-ACK, then the route was not installed and the 'R' flag MUST NOT be set in the NA(EARO). The 'R' flag MUST NOT be set if the 6LR did not attempt to inject the route. " > > > 980 This means that, in case of an error injecting the route that is not > 981 related to ND, the registration succeeds but the RPL route is not > 982 installed, which is signaled by the "R" flag reset. It is up to the > 983 6LN to keep the binding with the 6LR or destroy it. > > > [major] Figure 5 seems to indicate that the DAO-ACK is generated when > the EDAC is received, which is inline with the specification in §8 > ("the RPL Root MUST copy the 6LoWPAN ND Status unchanged in the RPL > Status and set the 'A' bit"). Yes, this is plain RFC 8505. This is now figure 6. > ..but from the last few paragraphs it > seems that there are other reasons for generating the DAO-ACK. While > not clear from the Figure, §10.2.3 does hint by saying "if a DAO is > pending"... Again, I think that this part of the operation has to be > much more explicit. I added the only known example which is that of the backbone router in figure 8, showing that the EDAC can be asynchronous. This completes a flow in the 6BBR draft, rfc-to-be 8929. > > rfc6550 has no information about "pending" DAOs, or how fast the > DAO-ACK is to be sent. In fact, there is no firm requirement for the > DAO-ACK to exist, just hope that it does: > > - §6.4/rfc6550: "The DAO message may optionally, upon explicit request or > error, be acknowledged by its destination with a Destination Advertisement > Acknowledgement (DAO-ACK) message back to the sender of the DAO." > > This sentence suggests that the DAO-ACK is optional, even if > requested, and §9.3/rfc6550 supports that: > > " 3. A node MAY set the 'K' flag in a unicast DAO message to solicit a > unicast DAO-ACK in response in order to confirm the attempt. > > 4. A node receiving a unicast DAO message with the 'K' flag set > SHOULD respond with a DAO-ACK. A node receiving a DAO message > without the 'K' flag set MAY respond with a DAO-ACK, especially > to report an error condition. > " > > Note that "SHOULD respond with a DAO-ACK" leaves the door open to not > doing it. Unfortunately rfc6550 didn't explicitly mention what may be > the reasons to not send a DAO-ACK (or not using MUST instead). > > In summary, there doesn't seem to be a guarantee that a DAO-ACK will > be received...which means that the 6LN may be left waiting for a > response to the registration (the same issues appears to be present > for a re-registration). This is bad, and the practice is that implementations always respond to the K. This is how we know that the route works in non-storing mode. Happy to add that SHOULD->MUST to the list of thing this spec updates if you think it is worthwhile. The text changed above has a time out but that assumes failure. > > 985 In a network where Address Protected Neighbor Discovery (AP-ND) is > 986 enabled, in case of a DAO-ACK or a DCO indicating transporting an > 987 EARO Status Value of 5 (Validation Requested), the 6LR MUST > challenge > 988 the 6LN for ownership of the address, as described in section 6.1 of > 989 [AP-ND], before the Registration is complete. This ensures that the > 990 address is validated before it is injected in the RPL routing. > > [major maybe] "network where...(AP-ND) is enabled" Just to make sure > I'm understanding: the network itself is not enabled for AP-ND, but > the important nodes (6LN, 6LR, Root and 6LBR) are. IOW, RPL only > carries the EARO status values that result from the AP-ND operation. > If this true? Yes, Alvaro; see https://www.rfc-editor.org/authors/rfc8928.html#name-extensions-to-the-capabilit for the on/off bit similar to what we do inn RPL with our turnon flags. AP-ND is enabled network wide, like all the nodes you mention must support it. In RPL, every node is a 6LR for its children when they join. So that's pretty much everybody that has to support it. > Also, the only reason the EARO Status Value would be 5 is if the 6LN > already supports AP-ND, right? I'm asking this because of the "MUST > challenge" above, and §7.1 saying that the "RUL SHOULD support > [AP-ND]" (recommended, not required). > > If my understanding is correct, then the text as is looks fine. :-) > Ouf! > > 992 If the challenge succeeds then the operations continue as normal. In > 993 particular a DAO message is generated upon the NS(EARO) that > proves > 994 the ownership of the address. If the challenge failed, the 6LR > 995 rejects the registration as prescribed by AP-ND and may take actions > 996 to protect itself against DoS attacks by a rogue 6LN, see Section 12. > > [minor] "a DAO message is generated upon the NS(EARO) that proves the > ownership of the address" > > It would be very nice is a new figure was included (either here or in > §10.1) to show this updated flow. Added > > > 998 The 6LR may at any time send a unicast asynchronous NA(EARO) with > the > 999 "R" flag reset to signal that it stops providing routing services, > 1000 and/or with the EARO Status 2 "Neighbor Cache full" to signal that it > 1001 removes the NCE. It may also send a final RA, unicast or multicast, > 1002 with a Router Lifetime field of zero, to signal that it stops serving > 1003 as router, as specified in section 6.2.5 of [RFC4861]. > > [minor] What are the RPL actions that should take place? For example, > if the 6LR "stops providing routing services" to a specific 6LN, but > still acts as a router for others...should it also send an NPDAO/DCO > to remove the routing state? Is there a reference somewhere about how > a RPL router gracefully "stops serving as router"? > In theory this is done upon a DCO indicating that the path is lost, but there is no DCO to be sent, since there is no child router. If this is a personal decision of the 6LR then it may sent a Dao with a lifetime of 0. " The 6LR may at any time send a unicast asynchronous NA(EARO) with the R Flag reset to signal that it stops providing routing services, and/ or with the EARO Status 2 "Neighbor Cache full" to signal that it removes the NCE. It may also send a final RA, unicast or multicast, with a Router Lifetime field of zero, to signal that it stops serving as Router, as specified in section 6.2.5 of [RFC4861]. This may happen upon a DCO or a DAO-ACK message indicating the path is already removed; else the 6LR should remove the Host route using a DAO message with a Path Lifetime of zero. " > 1005 If a 6LR receives a valid NS(EARO) message with the "R" flag reset > 1006 and a Registration Lifetime that is not 0, and the 6LR was injecting > 1007 the Registered Address due to previous NS(EARO) messages with the > "R" > 1008 flag set, then the 6LR MUST stop injecting the address. It is up to > 1009 the Registering 6LN to maintain the corresponding route from then > on, > 1010 either keeping it active via a different 6LR or by acting as a RAN > 1011 and managing its own reachability. > > [major] "MUST stop injecting the address" Can you be more specific? > What does this mean in RPL terms? Send an NPDAO/DCO? The spec describes the injection early, that's the DAO with the registered address as Target and the 6LR in the TIO. But since you ask, the reader will want a refresh at this point. I'm just concerned that the sentence grows heavy. Also, thinking twice, it might make sense to clean the path right away as opposed to let it time out. " A valid NS(EARO) message with the R Flag not set and a Registration Lifetime that is not zero signals that the 6LN wishes to maintain the binding but does not require the routing services from the 6LR (any more). Upon this message, if, due to previous NS(EARO) with the R Flag set, the 6LR was injecting the Host route to the Registered Address in RPL using DAO messages, then the 6LR MUST invalidate the Host route in RPL using a DAO with a Path Lifetime of zero. It is up to the Registering 6LN to maintain the corresponding route from then on, either keeping it active via a different 6LR or by acting as a RAN and managing its own reachability. " > 1013 10.2.3. Perspective of the RPL Root > > 1015 A RPL Root SHOULD set the "P" flag in the RPL DODAG Configuration > 1016 Option of the DIO messages that it generates (see Section 4) to > 1017 signal that it proxies the EDAR/EDAC exchange and supports the > 1018 Updated RPL Target option. The remainder of this section assumes > 1019 that it does. > > [major] If the Root supports the functionality, when would it be ok > for it to not set the P flag? IOW, why is it recommended and not > required? [Note that I may be missing context because there is no > specification for that flag.] There is no context, just the fact that some admins may not want the feature though I cannot fathom why. I made it a MUST and removed " The remainder of this section assumes that it does" > > > 1021 Upon reception of a DAO message, for each updated RPL Target > Option > 1022 (see Section 9) that creates or updates an existing RPL state, the > 1023 Root MUST notify the 6LBR. This can be done using an internal API if > 1024 they are integrated, or using a proxied EDAR/EDAC exchange if they > 1025 are separate entities. > > [major nit] "MUST notify the 6LBR. This can be done..." I'm not too > happy with the wording as it seems to provide options to a > requirement... > > Suggestion> > The Root MUST notify the 6LBR by using a proxied EDAR/EDAC exchange if > they are separate entities. If the RPL Root and 6LBR are integrated, > then an internal API can be used. > VBut there's text before that; let me see " Upon reception of a DAO message, for each updated RPL Target Option (see Section 6.1) that creates or updates an existing RPL state, the Root MUST notify the 6LBR by using a proxied EDAR/EDAC exchange. If if the RPL Root and the 6LBR are integrated, an internal API can be used. " > > ... > 1043 Upon receiving an EDAC message from the 6LBR, if a DAO is pending, > 1044 then the Root MUST send a DAO-ACK back to the 6LR. Else, if the > 1045 Status in the EDAC message is not "Success", then it MUST send an > 1046 asynchronous DCO to the 6LR. > > [?] "if a DAO is pending" Even though rfc6550 doesn't talk about > "pending", I take this to mean that the DAO hasn't been ack'd. Just > wondering (because I couldn't find it in rfc6550), is there a timer > that defines the time between receiving the DAO and sending a DAO-ACK. > I'm also wondering about it since sending a DAO-ACK is only > recommended. This is introduced by this spec | | | | | |-- DAO --->| | | | |-- EDAR -->| | | | | <- DAO pending | | |<-- EDAC --| | |<- DAO-ACK-| | > > > [major] What if the EDAC message is not received? Should the Root > signal a failure? What if the EDAC message comes in after a failure > is signaled? This should presumably not happen, especially since the > 6LN already registered...but I'm worried about the timing. > Very right. Added: " The proxied EDAR/EDAC exchange MUST be protected with a timer of an appropriate duration and a number of retries, that are implementation-dependent, and SHOULD be configurable since the Root and the 6LBR are typically nodes with a higher capacity and manageability than 6LRs. Upon timing out, the Root MUST send an error back to the 6LR as above, either using a DAO-ACK or a DCO, as appropriate, with the 'A' and 'E' flags set in the RPL status, and a RPL Status Value of of "6LBR Registry Saturated" [RFC8505]. " > [major] Some text should be added related to the possibility that not > all nodes may know what the DCO is. > > Suggestion (borrowing from §4.6.2/EFFICIENT-NPDAO)> > This document assumes that all the 6LRs in the network support this > specification. If there are 6LRs in the DCO message path which do not > support this document, then the issue indication may not reach the 6LR. > Alternatively, the Root could... > > I stopped there because the text above says that the Root "MUST send > an asynchronous DCO". Yes but this applies to a registration that was made with this spec using non storing mode, so it is known that the 6LR does support this spec. The NPDAO was meant for storing mode and the DCO message had to be relayed hop by hop, placing the requirement on intermediate nodes. > > > ... > 1059 11. Protocol Operations for Multicast Addresses > ... > 1068 "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its > 1069 updated version "Multicast Listener Discovery Version 2 (MLDv2) for > 1070 IPv6" [RFC3810] provide an interface for a listener to register to > 1071 multicast flows. MLDv2 is backwards compatible with MLD, and adds > in > 1072 particular the capability to filter the sources via black lists and > 1073 white lists. In the MLD model, the Router is a "querier" and the > 1074 Host is a multicast listener that registers to the querier to obtain > 1075 copies of the particular flows it is interested in. > > > > > > [major] In general, the text talks about an "MLD listener/querier" -- > are you using "MLD" to indicate support for both rfc2710/rfc3810, or > are you assuming MLDv1 support only? The phrase "MLDv2 is backwards > compatible with MLD" is what is confusing me. > > I also ask because the pim WG has an ongoing discussion about > deprecating MLDv1. I am assuming MLDv2, which is what rfc8504 > requires. If so, let's focus on rfc3810. > OKI > > [-] s/capability to filter the sources via black lists and white > lists/support for source filtering > > That is the language used in rfc3810. Removed, no point > > > 1077 On the first Address Registration, as illustrated in Figure 8, the > 1078 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in > 1079 order to start receiving the flow immediately. > > [minor] "On the first Address Registration..." Do you mean when the > 6LN registers its own address (Figure 5)? I would assume you're > talking about when the 6LN decides to listen to multicast; maybe > reword... > What about " The equivalent of the first Address Registration happens as illustrated in Figure 10. The 6LN, as an MLD listener, sends an unsolicited Report to the 6LR. This enables it to start receiving the flow immediately, and causes the 6LR to inject the multicast route in RPL. " > > 1081 6LN/RUL 6LR Root 6LBR > 1082 | | | | > 1083 | unsolicited Report | | | > 1084 |------------------->| | | > 1085 | <L2 ack> | | | > > [] See the comment below about the L2 ack. This same phrase shows up > in Figure 9 later on... > > 1086 | | DAO | | > 1087 | |-------------->| | > 1088 | | DAO-ACK | | > 1089 | |<--------------| | > 1090 | | | <if not listening> | > > [minor] "if not listening" Even if the 6LBR is listening, the Report > should be unsolicited, right? I'm not sure what this phrase means... > I meant if the root is not already listening to the mcast group. IOW if that RUL is the first listener in the DODAG. Changed <if not listening> to <if not done already> > ... > 1097 Since multicast Layer-2 messages are avoided, it is important that > 1098 the asynchronous messages for unsolicited Report and Done are sent > 1099 reliably, for instance using a Layer-2 acknowledgment, or attempted > 1100 multiple times. > > [major] The lack of reliable transmission is already addressed in > rfc3810. What concerns me about the text is the suggestion that a > different (L2 ack) mechanism can be used for MLD without any > specifics. I can remove. Suffice to say that the MLD report is sent as a UNICAST MAC message which ensured its reliability on Wireless. " With this specification, the asynchronous messages for unsolicited Report and Done are sent by the 6LN as MAC-Layer unicast to the 6LR. " > > > 1102 The 6LR acts as a generic MLD querier and generates a DAO for the > 1103 multicast target. The lifetime of the DAO is set to be in the order > 1104 of the Query Interval, yet larger to account for variable propagation > 1105 delays. > > [minor] s/multicast target/Multicast Address in the Report message Here we are talking about RPL, which calls places the multicast group in a Target Option. So we're used to calling that a target. " Upon a DAO with a Target option for a multicast address, the RPL Root checks if it is already registered as a listener for that address, and if not, it performs its own unsolicited Report for the multicast address. " > > > [major] "generates a DAO for the multicast target" This document is > a standards track specification...we need to be more explicit. I'm > assuming that the Multicast Address is included as the Target Prefix > in the Target Option... Well yes, that's RPL. Let me add a reference. Do we need to uppercase multicast address? " The 6LR acts as a generic MLD querier and generates a DAO with the Multicast Address as the Target Prefix as described in section 12 of [RFC6550]. The lifetime of the DAO is set to be in the order of the Query Interval, yet larger to account for variable propagation delays. " . > > > [major] One Multicast Address per DAO? I think I saw a related > discussion on the list recently. The discussion was for multiple VIOs / TIOs. There can always be multiple targets. But then, since this is triggered by a message for one address, I expect that there will be one DAO at a time. Is there a need for a change? > > > [major] "lifetime of the DAO" The Path Lifetime? > Yep, changed > > [major] "lifetime...is set to be in the order of the Query Interval, > yet larger..." How much is that? Double? Just a few seconds more? > ms? > > " As for the Unicast Host routes, the Path Lifetime associated to the Target is mapped from the Query Interval, and set to be larger to account for variable propagation delays to the Root. " > ... > 1111 Upon a DAO with a multicast target, the RPL Root checks if it is > 1112 already registered as a listener for that address, and if not, it > 1113 performs its own unsolicited Report for the multicast target. > > [major] As above, please be specific. How is the DAO information used > to build a Query? " A registration refresh is pulled periodically by 6LR acting as querier. Note that the message may be sent unicast to all the known individual listeners. Upon the timing out of the Query Interval, the 6LR sends a Multicast Address Specific Query to each of its listeners, for each Multicast Address, and gets a Report back that is mapped into a DAO one by one. Optionally, the 6LR MAY send a General Query, where the Multicast Address field is set to zero. In that case, the 6LR MUST send it as a MAC-Mayer Unicast. Upon a Report, the 6LR generates a DAO with as many Target Options as there are Multicast Address Records in the Report message, copying the Multicast Address field in the Target Prefix of the RPL Target Option. The DAO message is a Storing Mode DAO, passed to a selection of the 6LR's parents. Asynchronously to this, a similar procedure happens between the Root and a router such as the 6LBR that serves multicast flows on the Link where the Root is located. Again the Query and Report messages are source independent. The Root lists exactly once each Multicast Address for which it has at least one active multicast DAO state, copying the multicast address in the DAO state in the Multicast Address field of the Multicast Address Records in the Report message. " > > > 1115 An Address re-Registration is pulled periodically by 6LR acting as > 1116 querier. Note that the message may be sent unicast to all the known > 1117 individual listeners. > > [major] In MLDv2 that is called a Query... > Added "The equivalent of the"; the sentence after that one described the query flow; I augmented it. > > [major] "message may be sent unicast to all the known individual > listeners" The first paragraph in this section says that "the > multicast packet is passed as a Layer-2 unicast to each of the > interested children", so there is no other option, right? > I described that in more details too. > > ... > 1144 Note that any of the functions 6LR, Root and 6LBR might be collapsed > 1145 in a single node, in which case the flow above happens internally, > 1146 and possibly through internal API calls as opposed to messaging. > > [nit] s/Root and/Root, and > > > 1148 12. Security Considerations > > 1150 First of all, it is worth noting that with [RFC6550], every node in > 1151 the LLN is RPL-aware and can inject any RPL-based attack in the > 1152 network. This specification isolates edge nodes that can only > 1153 interact with the RPL routers using 6LoWPAN ND, meaning that they > 1154 cannot perform RPL insider attacks. > > > [major] Because 6LoWPAN ND is used, please add text about the Security > Considerations from rfc6775, rfc8505 apply. > done > [major] Also, let's work in a general pointer to rfc7416 somewhere > (instead of the very specific one below). > Done > > [major ?] Are there attacks that can be injected into the RPL network > through ND? I'm wondering if a RUL can request and inject a > significant number of addresses so that it could hinder the operation > of the LLN. I don't know if that's even an issue...just thinking out > loud. > We went through that already " The LLN nodes depend on the 6LBR and the RPL participants for their operation. A trust model must be put in place to ensure that the right devices are acting in these roles, so as to avoid threats such as black-holing, (see [RFC7416] section 7), Denial-Of-Service attacks whereby a rogue 6LR creates a high churn in the RPL network by advertising and removing many forged addresses, or bombing attack whereby an impersonated 6LBR would destroy state in the network by using the "Removed" Status code. " > > 1156 6LoWPAN ND can optionally provide SAVI features with [AP-ND], > which > 1157 reduces even more the attack perimeter that is available to the edge > 1158 nodes. > > [minor] I think there's some discussion of this in rfc8505...maybe > point to that. Otherwise, this paragraph feels orphan... Nothing much in 8505 but the problem statement. AP-ND is really the place. I provided some family to the orphan: " [AP-ND] updated 6LoWPAN ND with the called Address-Protected Neighbor Discovery (AP-ND). AP-ND protects the owner of an address against address theft and impersonation attacks in a Low-Power and Lossy Network (LLN). Nodes supporting th extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation. [AP-ND] reduces even more the attack perimeter that is available to the edge nodes and its use is suggested in this specification. " > > 1160 The LLN nodes depend on the 6LBR and the RPL participants for their > 1161 operation. A trust model must be put in place to ensure that the > 1162 right devices are acting in these roles, so as to avoid threats such > 1163 as black-holing, (see [RFC7416] section 7) or bombing attack whereby > 1164 an impersonated 6LBR would destroy state in the network by using > the > 1165 "Removed" Status code. > > 1167 This trust model could be at a minimum based on a Layer-2 Secure > 1168 joining and the Link-Layer security. This is a generic 6LoWPAN > 1169 requirement, see Req5.1 in Appendix of [RFC8505]. > > 1171 Additionally, the trust model could include a role validation to > 1172 ensure that the node that claims to be a 6LBR or a RPL Root is > 1173 entitled to do so. > > [major] There was some trust model-related text in > draft-ietf-roll-turnon-rfc8138 that we ended up replacing. Please do > the same here. That was done already, that's the first paragraph. I had to adapt to the different problem, again this is non storing unicast so most of the problems related to flooding are gone. But there's also the 6LoWPAN piece that I had to add. > > [minor] The challenge really comes from the 6LBR (not the Root)...but > only if AP-ND is present. IOW, the use of AP-ND is what adds the > protection, not the specification itself. Is that what we're talking > about here? > > If so, then I have a couple more things to point at: > > - §3.2.3: "This specification does not address how the protection by [AP-ND] > could be extended to RPL." But that is what seems to be claimed above. > > - §7.1: "The RUL SHOULD support [AP-ND] to protect the ownership of its > addresses." If the RUL doesn't, then whatever benefit is claimed/expected > is lost. > I rewrote the text on AP-ND " Section 5.3 of [RFC8505] introduces the Registration Ownership Verifier (ROVR) field of variable length from 64 to 256 bits. The ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was used to identify uniquely an Address Registration with the Link-Layer address of the owner but provided no protection against spoofing. "Address Protected Neighbor Discovery for Low-power and Lossy Networks" [AP-ND] leverages the ROVR field as a cryptographic proof of ownership to prevent a rogue third party from registering an address that is already owned and enables the 6LR to block traffic that is not sourced at a owned address. This specification does not address how the protection by [AP-ND] could be extended for use in RPL. On the other hand, it adds the ROVR to the DAO to build the proxied EDAR at the Root (see Section 6.1), which means that nodes that are aware of the Host route are also aware of the ROVR associated to the Target Address. " > > 1181 13. IANA Considerations > > [major] §14-17 should be sub-sections of this one. > > That was a transient bug > ... > 1191 13.2. Resizing the ARO Status values > > 1193 Section 12 of [RFC6775] creates the Address Registration Option > 1194 Status Values Registry with a range 0-255. > > 1196 This specification reduces that range to 0-63. > > [minor] NEW> > This specification reduces that range to 0-63 (Section 8). > > > 1198 IANA is requested to reduce the upper bound of the unassigned > values > 1199 in the Address Registration Option Status Values Registry from -255 > 1200 to -63. > > [major] NEW> > IANA is requested modify the Address Registration Option Status Values > Registry so that the upper bound of the unassigned values is 63. This > document should be added as a reference. The registration procedure does > not change. Neat! Thanks : ) > > > [major] Because of this change in the registry defined by rfc6775, > that RFC should be formally Updated. Done > > > 1202 14. New DODAG Configuration Option Flag > > 1204 This specification updates the Registry for the "DODAG Configuration > 1205 Option Flags" that was created for [RFC6550] as follows: > > [major] NEW> > IANA is requested to assign a flag from the "DODAG Configuration Option > Flags" registry as follows: > > > 1207 +------------+----------------------------+-----------+ > 1208 | Bit Number | Capability Description | Reference | > 1209 +============+============================+===========+ > 1210 | 1 | Root Proxies EDAR/EDAC (P) | THIS RFC | > 1211 +------------+----------------------------+-----------+ > > [major] Please mark the value (1) as suggested. > > Done > ... > 1215 15. New RPL Target Option Flag > > 1217 Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL > 1218 Target Option Flags" field. IANA is requested to reduce the size of > 1219 the field in the Registry to 4 bits. This specification also defines > 1220 a new entry in the Registry as follows: > > [] Suggestion> > > This document modifies the "RPL Target Option Flags" registry initially > created in Section 20.15 of [RFC6550]. The registry now includes only > 4-bits (Section 9) and should point to this document as an additional > reference. The registration procedure doesn't change. > > The following table shows the initial assignment. > > > [major] This change in the registry should be flagged as an Update to rfc6550. Done > > > ... > 1228 Table 3: New RPL Target Option Flag > > [minor] s/New RPL Target Option Flag/RPL Target Option Registry > Done > > 1230 16. New Subregistry for the RPL Non-Rejection Status values > > 1232 This specification creates a new Subregistry for the RPL Non- > 1233 Rejection Status values for use in RPL DAO-ACK and DCO messages > with > 1234 the 'A' flag reset, under the ICMPv6 parameters registry. > > [nit] s/in RPL/in the RPL > > > [major] The DCO-ACK Status registry is under the RPL registry. Why > isn't this one there too? It is RPL-related. > > Done > ... > 1238 * Registration procedure is "Standards Action" [RFC8126]. > > [major ?] All the other RPL registries have an "IETF Review" > registration procedure. Why is this one different? > > Done > ... > 1242 +-------+------------------------+-----------+ > 1243 | Value | Meaning | Reference | > 1244 +=======+========================+===========+ > 1245 | 0 | Unqualified acceptance | RFC 6550 | > 1246 +-------+------------------------+-----------+ > > [major] Let's also add this document as a reference for this initial allocation. > > Well it is really define in RFC 6550, just remapped here, but OK. > ... > 1250 17. New Subregistry for the RPL Rejection Status values > > 1252 This specification creates a new Subregistry for the RPL Rejection > 1253 Status values for use in RPL DAO-ACK and RCO messages with the 'A' > 1254 flag reset, under the ICMPv6 parameters registry. > > [nit] s/in RPL/in the RPL > Done > > [minor] s/RCO/DCO > Done > > [major] The DCO-ACK Status registry is under the RPL registry. Why > isn't this one there too? It is RPL-related. > > Done > ... > 1258 * Registration procedure is "Standards Action" [RFC8126]. > > [major ?] All the other RPL registries have an "IETF Review" > registration procedure. Why is this one different? > > Done > ... > 1276 19. Normative References > > [minor] The following references can be Informative: > > ... > 1293 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, > "IPv6 > 1294 over Low-Power Wireless Personal Area Networks (6LoWPANs): > 1295 Overview, Assumptions, Problem Statement, and Goals", > 1296 RFC 4919, DOI 10.17487/RFC4919, August 2007, > 1297 <https://www.rfc-editor.org/info/rfc4919>. > ... > 1304 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless > 1305 Address Autoconfiguration", RFC 4862, > 1306 DOI 10.17487/RFC4862, September 2007, > 1307 <https://www.rfc-editor.org/info/rfc4862>. > ... > 1316 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- > 1317 Power and Lossy Networks (RPL) Option for Carrying RPL > 1318 Information in Data-Plane Datagrams", RFC 6553, > 1319 DOI 10.17487/RFC6553, March 2012, > 1320 <https://www.rfc-editor.org/info/rfc6553>. > ... > 1322 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 > 1323 Routing Header for Source Routes with the Routing Protocol > 1324 for Low-Power and Lossy Networks (RPL)", RFC 6554, > 1325 DOI 10.17487/RFC6554, March 2012, > 1326 <https://www.rfc-editor.org/info/rfc6554>. > ... > 1338 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for > 1339 Constrained-Node Networks", RFC 7228, > 1340 DOI 10.17487/RFC7228, May 2014, > 1341 <https://www.rfc-editor.org/info/rfc7228>. > ... > 1353 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, > 1354 "IPv6 over Low-Power Wireless Personal Area Network > 1355 (6LoWPAN) Routing Header", RFC 8138, DOI > 10.17487/RFC8138, > 1356 April 2017, <https://www.rfc-editor.org/info/rfc8138>. > > > ... > 1394 20. Informative References > ... > 1429 [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node > 1430 Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, > 1431 January 2019, <https://www.rfc-editor.org/info/rfc8504>. > > [major] This reference should be Normative. > > All done > ... > 1439 Appendix A. Example Compression > ... > 1455 The difference with the example presented in Figure 19 of [RFC8138] > 1456 is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the > 1457 compressed address of the 6LR as the destination address of the > outer > 1458 IPv6 header. In the original example the destination IP of the outer > 1459 header was elided and was implicitly the same address as the > 1460 destination of the inner header. Type 1 was arbitrarily chosen, and > 1461 the size of 0 denotes a single address in the SRH. > > [minor] Which one is the "original example", this one, or the one in rfc8138? Clarified to the ine in RFC 8138 Whao, it's getting late. Met me post what we have as a new reference so you can observe the diffs on the IETF. This is the deepest and probably the most useful single review I ever has in almost 20 years of IETF! So many thanks! Pascal
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Pascal Thubert (pthubert)
- Re: [Roll] AD Review of draft-ietf-roll-unaware-l… Alvaro Retana