Subject: [6lo] rgding 6775-update/EARO

From: Rahul Jadhav <[email-masked]>
Date: Wed, 19 Jul 2017 16:21:48 +0200

Hello Pascal,

This is the same query as what i raised during the 6lo session. Like it was
pointed out, better to take it on ML.

The new mechanism described in the draft allows a proxy registration on
behalf of the "target node" using EARO.
My question is: Will de-registration be possible for such targets,
especially considering that state information (in the form of TID) is
maintained for such registrations?
It will be helpful to clarify in the document.

Thanks,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Jul 2017 15:51:15 +0000

Hello Rahul :

You are right, all this went down the sink with the RPL reference to the path lifetime operation.

I’ll add text extracted from RPL to explain the TID behvoour and make the specification self-contained as discussed at the WG meeting, unless someone shows up now on the list arguing we should do otherwise.

Thanks for the heads up!

Take care,

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Rahul Jadhav
Sent: mercredi 19 juillet 2017 16:22
To: lo <[email-masked]>
Subject: [6lo] rgding 6775-update/EARO

Hello Pascal,

This is the same query as what i raised during the 6lo session. Like it was pointed out, better to take it on ML.

The new mechanism described in the draft allows a proxy registration on behalf of the "target node" using EARO.
My question is: Will de-registration be possible for such targets, especially considering that state information (in the form of TID) is maintained for such registrations?
It will be helpful to clarify in the document.

Thanks,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 28 Jul 2017 17:21:26 +0000

Hello Rahul :

I am reintroducing the TID freshness evaluation now copied from RPL, as we discussed at the meeting.

About cleaning up, the current text has:
«
   A node that ceases to use an address SHOULD attempt to deregister
   that address from all the 6LRs to which it has registered the
   address, which is achieved using an NS(EARO) message with a
   Registration Lifetime of 0.

   A node that moves away from a particular 6LR SHOULD attempt to
   deregister all of its addresses registered to that 6LR.

   Upon receiving a NS(EARO) message with a Registration Lifetime of 0
   and determining that this EARO is the freshest for a given NCE (see
   Section 4.2), a 6LR cleans up its NCE.  If the address was registered
   to the 6LBR, then the 6LR MUST report to the 6LBR, through a DAR/DAC
   exchange with the 6LBR, or an alternate protocol, indicating the null
   Registration Lifetime and the latest TID that this 6LR is aware of.

   Upon the DAR message, the 6LBR evaluates if this is the freshest EARO
   it has received for that particular registry entry.  If it is, then
   the entry is scheduled to be removed, and the DAR is answered with a
   DAC message bearing a Status of 0 "Success".  If it is not the
   freshest, then a Status 2 "Moved" is returned instead, and the
   existing entry is conserved.  The 6LBR SHOULD conserve the address in
   a DELAY state for a configurable period of time, so as to protect a
   mobile node that deregistered from one 6LR and did not register yet
   to a new one.

«

Is there anything missing ?

Take care,

Pascal

Hello Pascal,

Thanks,
Rahul