Subject: Re: [Efficientnd-dt] My demo at the PlugFest

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Jul 2014 05:59:05 +0000

Hello Samita:

The ARO option should probably be renamed. Its information applies well beyond registration. 
Also, part of the problem we have at 6MAN is linked to the registration process as opposed to the option itself.

If you look at the slides I've passed on to you, you'll see that the option is used over the backbone to detect a stale proxy as well as a duplication.
A good number of the issues related to DAD that Ole listed can be solved by adding the information in the ARO option but not using it as a registration.

The target address is not just a particular advantage. It is consistent with ND in general and in particular avoid putting a SLLA option for a source address that is still optimistic.
I detail all that in the draft I just submitted to 6lo...

Cheers,

Pascal

> -----Original Message-----
> From: Samita Chakrabarti [mailto:[email-masked]]
> Sent: jeudi 3 juillet 2014 23:49
> To: Pascal Thubert (pthubert)
> Cc: Erik Nordmark ([email-masked]); [email-masked]
> Subject: RE: [Efficientnd-dt] My demo at the PlugFest
> 
> Hi Pascal,
> 
> I have some doubts about the proposed text and I think we should discuss
> together with Erik.
> 
> My concern is that the text calls it a DAD (not-registration) and  still includes
> ARO with unspecified IPv6 source address for NS.
> ARO is for address registration -- so this does not make sense to me.
> 
> Also, in the 2nd paragraph, when the source address is specified, it always
> registers the target address but sends the reply to the source-address of NS
> message. I am concerned about security/reliability  of the solution in this
> case (without additional checks).
> 
> I understand your particular usecase for taking advantage of target address
> field. Perhaps we discuss more and come up with a better way of handling it.
> 
> I,e  we can preserve current ARO and NS behavior and if target address is
> present  then we should do some additional checks (bits, options)  to handle
> it for special cases ( mobility, privacy etc. ).
> 
> Thanks,
> -Samita
> 
> 
> 
> 
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Thursday, July 03, 2014 1:02 PM
> To: Samita Chakrabarti
> Cc: Erik Nordmark ([email-masked]); [email-masked]
> Subject: Re: [Efficientnd-dt] My demo at the PlugFest
> 
> Thanks Samita 😊
> 
> Would you agree with the proposed change to the draft that I detailed
> below and implemented?
> 
> Pascal
> 
> > Le 3 juil. 2014 à 21:02, "Samita Chakrabarti"
> <[email-masked]> a écrit :
> >
> > Hi Pascal,
> >
> > Thanks for updating us on the efficient-nd draft implementation. I would
> be very interested in seeing the mobility support as well.
> > Please see more in-line.
> >
> > -----Original Message-----
> > From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> > Sent: Thursday, July 03, 2014 3:33 AM
> > To: Erik Nordmark ([email-masked]); Samita Chakrabarti
> > Cc: [email-masked]
> > Subject: My demo at the PlugFest
> >
> > Dear Erik, Samita and all:
> >
> > At the PlugFest on Sunday morning I'll be demonstrating (again) efficient
> ND as applied for registering a LLN IPv6 devices in a Sensor Network.
> > The novelty is that I now have the backbone router implemented with the
> support of mobility (whereas I only had proxy ND in London).
> >
> > Compared to the draft as it stands (05) I made the following digression:
> >
> > "
> >   When the ARO is sent by a host then, for links which have link-layer
> >   addresses, a SLLA option MUST be included.  The address that is
> >   registered is the IPv6 source address of the Neighbor Solicitation
> >   message.
> > "
> > ->
> > "
> >   The ARO option may be transported in an NS message with the source
> >   IPv6 address set to the unspecified address , in which case, the message
> >   is still a DAD message as opposed to a registration, and in case of a
> >   competing state, the NA message SHOULD carry the ARO option from the
> NS
> >   message with the appropriate status (1 for different UII, 3 for outdated
> TID).
> >
> >   If the source IPv6 address of the NS message in not set to the unspecified
> >   address, then the message is a registration, and for links that have link-
> layer
> >   addresses, a SLLA option MUST be included. The address that is
> >   registered is the Target address of the NS message but the reply NA MUST
> be
> >   addressed to the source of the message. The LLA that is registered for the
> >   Target is that of the SLLA unless a separate TLLA option is also provided
> with
> >   the message.
> > "
> >
> > This change allows the RPL root to register (with its MAC address and its
> LinkLocal as source) the devices in the LLN (targets).
> > The RPL root gets the packets and then routes them. I do not have a use
> case where the TLLA would be necessary.
> >
> > Is that a change that you could make in the spec?
> > [SC>]   You mention that there is no usecase found for TLLA now -- but it is
> still a good idea to include TLLA in the draft as an option for future usage.
> > We discuss the change request before along with Erik.
> >
> > Erik was planning to have an update of 05 draft -- I  sent some editorial
> comments to him as well.
> > Since we are not presenting efficient-nd  this time -- perhaps the update
> can happen after the IETF as well.
> > ----
> >
> > In order to test my code (that is an extension to SAVI support) I made the
> changes as a host to the IOS ND code. Took me less than a week, part time.
> > IOW, implementing efficient from an classical ND stack can be quite simple
> and the delta of code is effectively very small.
> >
> > My implementation conforms the ARO option format for IDS=000. I did not
> add the RAO to the RA yet though. I can parse DAR and DAC but did not add
> support for these either.
> >
> > Would you know if there is a chance to do any interop as we go?
> > [SC>]    That'd have been really nice!   Perhaps by next IETF :-)
> >
> > On the typo side:
> >
> >
> > In 6.3.  Registrar Address Option (RAO) :
> >
> >     IPv6 registratr addresses                  ~
> >   |                        (Num Addresses)
> >
> >
> > For the state loss I still think we need to devise something simpler to
> manage for the device.
> >
> > I suspect that a solution with a redundant 6LBR would help. eg the 6LBR(s)
> would use the RAO to the 6LRs as opposed to the 6LRs to the hosts.
> > Then the 6LR would send a DAR each. And the rebooting 6LR (6LBR) could
> rebuild its state from a sort of lease query to any of the (other) 6LBRs.
> > The 6LBR(s) could also be aware of the VRRP routers and ensure
> synchronization without involving the hosts.
> >
> > [SC>]   This is going into 6LO space.  Is it included in your 6LO presentation?
> >
> > I guess this discussion is not for 06 but I'd love to have it if you can free
> some time in Toronto.
> > [SC>]  Sure. Let's have a chat.
> >
> > -Samita
> >
> >
> > All the bets to you all, hope we meet in Toronto.
> >
> > Pascal
> >
> > _______________________________________________
> > Efficientnd-dt mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/efficientnd-dt