Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Rahul Jadhav <> Tue, 14 April 2020 09:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF02C3A092D for <>; Tue, 14 Apr 2020 02:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id isl_0Q2UoAYN for <>; Tue, 14 Apr 2020 02:44:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDEB53A092B for <>; Tue, 14 Apr 2020 02:44:26 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=RJ3Ec6Ke5kXf6EAZsLuctSPBRAo3BkCTKV431I16CYo2wxwjk0gJvzM/zKlZwxckG4DfEPWGX/OhcilsFudpckFo1UeKDYiYdMUCSfmtKONhy3FCyN7Lmxts/aUgpqwyLiOAl0yGaXUBCr9iEvnof+fGt69bBcc4s07gET6Sa0pDgKoFRr7G1f3bgJK0Zvi/ertOR4FvezSR2LtnuxPY1SWWDztDz+3+kNxHnw0QyRIc8r2LR4cRNWuRK/ccpTQW8aDqxciCrgP42CZqEFTS/HC0ixB8H4TFwbET5P4l1qtQbGYRO3kJ3giolhwQ3qEcAhu9nltOC4iVuRph29TGbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sA6uGhQdE29ElHzF4ZXciI0lgf0NgX4rBb/tvl7bTAI=; b=UFBgsfV7MzqRUarE5In928Ly1ZbR47pDsBRnk0G1mhslWwqza0Y3YCcYxKyU+laBCJe7C0FHS79NHSFcbqAZbxa7d1Dj9WqPTb+c1GcyKM++xsvtXKJm6D0MUYht1c0fl4TWz24drlr9ZnmhxiaFFZLCRaWMAXpc2wvWiPLn7OnXjjqt1360lD87rMop10L89Um7Q1fIqNK+NGweFkniItJLvfy5PL47lyVtKApXfNEvVxdKnG5NakjOvbFiakQ5sOHLqgcHRCewIpEj3DayJyVY+yuZOhyp+gI1HNYS/fgvTvHGWcLDBm9p4B3CMjHDcuEcguvuCVhUBlJJRe7tSA==
ARC-Authentication-Results: i=1; 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sA6uGhQdE29ElHzF4ZXciI0lgf0NgX4rBb/tvl7bTAI=; b=HeUuikvaKMXdGBGaAcoFm+5/2dErg4pKvAIyN+yaRBiBVrEK9xJNdzS+jdqjw35U4D1WJNa+IaTX5ROqi00osfRvfcyA7i3JUaFCtNuZftsO56szKDCkWdpu0O4A5MyV0fMtfYZbC7GXvTxRrcXe+8EuUx1+1MI9h/AL1gZy8oeAAA9NnkPPV/If5viltIXPfMtq9Z+dl8r3Yw61u8M7R0o2vEiPmuvbWoQtAvY+pYPrV+CG5MOeqXG5fY3PYP7c9nvxQm39IohgjGSth/I0zP8J2NiRrRllR2lZow1myTBdz5WdHAfPqUDLz0g5rh4T4BMvNj3gG2LZcU0vh9Nb8A==
Received: from (2a01:111:e400:7ebd::4b) by (2a01:111:e400:7ebd::380) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18; Tue, 14 Apr 2020 09:44:23 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Tue, 14 Apr 2020 09:44:23 +0000
Received: from BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::a1ff:5c53:dc37:c050]) by BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM ([fe80::a1ff:5c53:dc37:c050%6]) with mapi id 15.20.2900.028; Tue, 14 Apr 2020 09:44:23 +0000
From: Rahul Jadhav <>
To: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] unaware leaves - graceful shutdown of attached-6LR
Date: Tue, 14 Apr 2020 09:44:23 +0000
References: <BM1PR01MB4020A5C1C43CDC700477C39EA9DA0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>, <>
In-Reply-To: <>
Accept-Language: en-IN, en-US
Content-Language: en-IN
x-incomingtopheadermarker: OriginalChecksum:97BC2FBA5E3C91CD206A73546ECF5EB9726530DEFDCD18417F3F2F27AFECF30D; UpperCasedChecksum:8BD7AA9C03E8056C84E491C49A58D99A24BA6C67241FCB35BD7116354EFFB231; SizeAsReceived:7030; Count:44
x-tmn: [4MJLMKINgLfineTwltpCSluiiOgjXTub]
x-ms-publictraffictype: Email
x-incomingheadercount: 44
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 49870dbd-98d4-487f-91ae-08d7e05869f7
x-ms-traffictypediagnostic: SG2APC01HT109:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: i+j8JB6Ftk+JIdkHyk/xc3O68CKGyee9flEr4ZiCRu5VqTpTBKPnQ9mcv/dXg7/2iPFq8J2In2R4DEwBpEIxxNTNjdgJ0rWeF/an6wZnEQo0nnSwiokrDd1eZsJcJngaKzqkQcxLb6mZv2CWH38RYj/5AmY9xeykVy16lXe8fbW93tlwgYPcbntbsev7ne+WAEPW0t/oKDHn/ifSETMBKx1PRbB7zrPqiees6+iRVwg=
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901;
x-ms-exchange-antispam-messagedata: N3kmHVP3OO3UBaYIoNtCR63/O1nnNsgW/IZhgumRt0djxRTe3e2O+bJnbixBQX5ci0goxpoXQanLwCUwr+Uugrl1c9qyz5YP7y862BT9BsJRvWLX/KWvkaGfSkYMdqBw5/YHJB9czvNLtmSA5Gn9bw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB4020DBE40E76D2EAE97C9611A9DA0BM1PR01MB4020INDP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 49870dbd-98d4-487f-91ae-08d7e05869f7
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2020 09:44:23.3771 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT109
Archived-At: <>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Apr 2020 09:44:30 -0000

Thanks for the detailed response. Please find my response inline.

One key point you mentioned is that EARO parameters are managed by 6LBR. The initial registration happens using EDAR/EDAC through 6LBR and using EDAC(EARO-lifetime) the 6LBR can control the lifetime in the NA(EARO).
But during lifetime refresh, the keepalive NS sends a lifetime and the 6LR replies directly using NA using the same lifetime. Won't this lifetime create problems? Is it expected that the 6LR remembers the lifetime sent from 6LBR and uses it in the subsequent refresh NA(EARO) reply?

To instantiate this point, consider Figure 10 which shows that DAO is created from NS(EARO) and the lifetime of EARO is converted to lifetime in DAO-transit option. This DAO results in anonymous EDAR from Root to 6LBR and a response EDAC. The response EDAC status value is used in the DAO-ACK but the (possibly updated) lifetime from EDAC is dropped.

From: Roll <> on behalf of Pascal Thubert (pthubert) <>
Sent: 14 April 2020 04:25 PM
To: Routing Over Low power and Lossy networks <>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Hello Rahul

For the lifetime I do not necessarily agree with your wording. My reading is that the registration lifetime is requested by the 6LN and granted by the 6LBR. What the 6LBR returns might be less than what the 6LN requested. This might not be very explicit in RFC 6775 but “5.5.2.  Processing a Neighbor Advertisement” says


   The host saves the Registration Lifetime from the ARO

   for use to trigger a new NS well before the lifetime expires.


Which tells you that the network has the ultimate control, which is good in a managed network.

[RJ] This makes sense to me now.

Then “8.2.3.  6LR Sending a Duplicate Address Request” says


      The EUI-64 and Registration Lifetime are copied from the ARO

      received from the host.


Which tells you that the 6LR is just an transmission but has no say in the story.


- If the 6LR stops being a router at all the signal is a final RA. We could actually mandate to unicast it to all registered nodes.

- If the 6LR accepts a registration it should keep it as long as it is a router so ‘removed’ comes from above.

- if the 6LR keeps the registration but stops being a router, then signal is the ‘R’ flag only.

So we are talking about a unexpected case where the 6LR would drop an NCE on its own but continue being a router, IOW break its contract with the 6LN.

I see the value of using status “Removed” there. The problem I have here is to clarify what comes from the 6LBR which means that the address is not usable at all vs what comes from the 6LR, which means that this 6LR is not useable, but the 6LN can try with another 6LR. I thought the lifetime helped but on second thought it does not. “Removed” and lifetime are both 6LBR decisions.

If that’s a problem with the 6LR only, we need to signal that. RFC 8505 helps us there. Section “5.7.  Maintaining the Registration States” indicates that


   space is exhausted.  In that situation, the EARO is returned in an NA

   message with a status code of "Neighbor Cache Full" (Status 2; see

   [RFC6775<>] and Table 1), and the Registering Node may attempt to

   register to another 6LR.

   If the registry in the 6LBR is full, then the 6LBR cannot decide

   whether a registration for a new address is a duplicate.  In that

   case, the 6LBR replies to an EDAR message with an EDAC message that

   carries a new status code indicating "6LBR Registry Saturated"

   (Table 1).  Note: This code is used by 6LBRs instead of "Neighbor

   Cache Full" when responding to a Duplicate Address message exchange

   and is passed on to the Registering Node by the 6LR.  There is no

   point in the node retrying this registration via another 6LR, since

   the problem is network-wide.  The node may abandon that address,

   de-register other addresses first to make room, or keep the address

   "tentative" [RFC4861<>] and retry later.


So I’d suggest that we mandate unicast final RA if the router goes away, and if the router just drops that NCE then use "Neighbor Cache Full" in the NA.


[RJ] So essentially NA(EARO) is strictly controlled by the 6LBR. Using 'Neighbor Cache Full' will tell the 6LN to move to other 6LR, and this should work, even though the status code does represent the appropriate reason.

I understand mandating final RA but why only unicast? Can't a multicast final RA be sent by a 6LR who is about to go down and has several RULs connected via it?

Note: The 6BBR draft uses it for the 6LBR to clean up a state in the old 6BBR when registering to a new 6BBR. As a second thought it appears that ‘moved’ would be better. That’s what 6BBRs do with one another when it’s a different 6LBR. I’ll fix that unless someone raises an issue.



Le 14 avr. 2020 à 04:05, Rahul Jadhav <> a écrit :

Please find my response inline.


From: Roll <> on behalf of Pascal Thubert (pthubert) <>
Sent: 13 April 2020 11:14 PM
To: Routing Over Low power and Lossy networks <>
Subject: Re: [Roll] unaware leaves - graceful shutdown of attached-6LR

Great point Rahul.

Normally this is done using a final RA. But the RA is broadcast so unicasting a NA with ‘R’ flag off is a great idea. This is the exact signal that this router does not serve this node. Lifetime 0 would indicate that the router removes the NCE.

Status removed indicates an error. I’d rather use status 0, lifetime 0, ‘R’ off. Don’t you think?

[RJ] Imo, Lifetime is something that is controlled by the target/owner. There has never been (?) a case where someone else changes lifetime on behalf of the target node.

RFC 8505 states: "Removed: The binding state was removed.  This Status MAY be placed in an NA(EARO) message that is sent as the rejection of a proxy registration to an IPv6 ND Registrar, or in an asynchronous NA(EARO), at any time."

I still feel using Status="Removed", 'R' off may be applicable more.

Keep safe.


Le 13 avr. 2020 à 15:07, Rahul Jadhav <> a écrit :

Hello Pascal/Authors,

In the event that the attached 6LR needs to gracefully shutdown, it needs to inform the RUL(s) to detach and possibly move to another 6LR.

I believe this could be done using NA(EARO, Status="Removed"); from the attached-6LR. Can this NA be multicasted if the attached-6LR has more than one RULs attached to it?

Is this correct/allowed? For RPL we have route-poisoning using which a 6LR does a graceful shutdown, but the route-poisoning is not applicable to RULs.. I believe this should be clarified in the text.



Roll mailing list

Roll mailing list