Hi Alex, I can't comment on the cache/table, but at least on the NS/NA problem.
The NS/NA are not used as actual advertisements for the node, but instead as a way to carry an extra "payload", in this case the ARO. The way they are used now means if you had a 6lowpan-ND host send messages to a host which isn't using 6lowpan-ND it won't break anything. A big part of 6lowpan-ND is ensuring you don't have duplicate addresses. If you send a NA with the address you want to use, a non 6lowpan-ND node may just update its neighbor cache per standard RFC4861 processing. If this address was in fact a duplicate this would be bad! Using the NS means you will get an NA back immediately, but it will have no 6lowpan-ND options, so you know the node doesn't support 6lowpan-ND and to try with someone else. Regards, -Colin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Alexandru Petrescu Sent: September 25, 2010 12:00 AM To: [email protected] Subject: Re: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-13 I will need to read this in more detail and reply. I now have a quick comment bothering me since some time. Le 24/09/2010 01:01, Geoff Mulligan a écrit : > We have been reviewing 6lowpan Neighbor Discovery for quite some time > and have feedback on the list and from implementors. > > We will now start Working Group Last Call on: > > http://tools.ietf.org/html/draft-ietf-6lowpan-nd-13: > Registration: > The process during which a LoWPAN node sends an Neighbor > Solicitation message with an Address Registration option to a > Router creating a Neighbor Cache entry for the LoWPAN node with a > specific timeout. This sounds as a NA (not NS) with a lifetime field. I wonder why isn't it an NA. It does not solicit anything but it advertises. > Thus for 6LoWPAN Routers the Neighbor Cache > doesn't behave like a cache. Instead it behaves as a registry of > all the host addresses that are attached to the Router. This bothers me: it is not a cache but it is called a cache. Alex > > The document is intended to be submitted by this Working Group to the > IESG for publication as a Standards-Track Document. > > This is a two-week Working-Group Last-Call, ending on Friday, October 8, > 2010 at 2359 UTC. > > Please review the changes to the document carefully, and send your > comments to the 6lowpan list. > > Thanks, > geoff > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
