On 07/ 6/10 01:52 AM, Zach Shelby wrote:
Looking through ND-10 I think we are getting pretty close to our limits in the
size of NS/NA+ARO+SLLAO.
NS/NA = 24 octets
ARO = 16-32 octets
This is fixed at 16 for registrations. 32 is only for multi-hop DAD. If
we want to optimize the multi-hop DAD case then I suggest we do a
separate message instead of reusing NS/NA. (The target address is
effectively unused in the special multi-hop DAD use of NS/NA.)
SLLAO = 8-16 octets
Best case = 48 octets
Worst case = 72 octets
If we ignore multihop DAD, then the worst case is 56.
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.
A TID doesn't seem to solve the problem; seems to need a 3-way
handshake. But I get the general question about understanding how things
might be extended.
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.
True for multi-hop DAD. But for the normal registrations the registered
address is in the IPv6 source field.
We could create a NS' and NA' messages that do not contain the target
address and save 16 bytes for the NS/NA registrations. But that means a
new pair of message types and less interoperability with 4861.
We could go back to that approach, but first we need to make sure we
would be converging instead of oscillating if we go back.
2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10
second granularity. That frees up 16-bits of reserved space.
Doesn't hurt to change this.
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.
No more ND interoperability.
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...
I think you already in essence proposed that in #1 ;-)
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
