> > Best case = 48 octets > Worst case = 72 octets > > We have a request from e.g. backbone-router-02 to add a new 16-bit TID field > to ARO, and this is just one example for the future. There may be other > options to be carried in the NS as well. Is there anything we can/should do > to reduce the worst case for NS/NA? Some random thoughts: > > 1. What is Target Address in our unicast NS/NAs actually being used for > right now? Why don't we put the Registered Address there instead of in the > ARO option? That would save 16 octets. > [SC>] It is overloading the NUD operation. It is doable, but then DAD option is not distinguishable by len=4. We have to then introduce some bit for DAD operation.
> 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second > granularity. That frees up 16-bits of reserved space. [SC>] Option 2 is OK w/me. I am reluctant about adventuring on options 3 and 4 below. Thanks, -Samita > > 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save > size in SLLAO for 16-bit addresses at least. Likely would save in other > options as well. > > 4. Make use of the 32-bits of reserved NS/NA space? I would rather not start > to re-define the NS/NA message though... > > Other ideas, thoughts? > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
