On 06/ 7/10 10:12 PM, Reddy, Joseph wrote:
Some more miscellaneous comments/questions on the ND draft ( I
originally sent this email over the weekend but it bounced )
1. If a 6lowpan contains multiple 6LBRs, how should a 6LR reply to a
router solicitation from a host? Should it send multiple router
advertisement messages in response ?
Since we allow 6LRs to send RS messages as part of prefix and context
dissemination, a 6LR can't tell whether the RS was from a host or a
router. Hence, if RA is used for prefix and context dissemination, then
there would be one RA for each ABRO. If RA is not used for prefix and
context dissemination from the 6LBRs to the 6LRs, then AFAIK there
wouldn't be any ABRO options hence everything could put in one RA.
That is what the first paragraph in section 6.3 tries to say.
Suggestions on how to make this more clear?
2. If a context with valid lifetime = 0 is received from another 6LR
or 6LBR, does a 6LR have to delete the context only after completing
the dissemination of the context? How long should this time be (
considering that sleeping devices can sleep for very long times.. ).
In general updating of context information seems unreliable in
presence of sleeping nodes
The 'C' bit is used to robustly be able to remove the context; it needs
to be advertised with C=0 to make all nodes stop using it for
compression. Section 7.2 specifies this and has a min time of 60
seconds. That is too short to handle hosts that might sleep for an
abitrarily long time. To handle that it would make more sense to rely on
not having the "expiration time" move backwards.
For instance, if a context was advertised at time T0 with valid lifetime
V0, at time T1 with valid lifetime V1, etc, then the latest expiration
time any node could have is the max(Ti+Vi). Hence even if hosts can
sleep for an unbounded time the context would expire no later than that
time. This can be used to robustly remove contexts.
3. If a host completes DaD on a global address where the IID is
derived from its link layer address, can it safely assume that a link
local address derived from the same IID is also unique ? That is, can
it automatically configure a LL address based on that IID without
going through the registration process again for that address ?
The answer is completely different if "link layer address" is EUI-64 or
a short address.
For an EUI-64 we do not do any DAD; we merely do registrations.
If applications (running on the neighboring 6LR) might use the host's
link-local address, then the host should register that address with the
6LRs so that the routers have the IPv6->link-layer address mapping in
their Neighbor Cache. But I don't know a case when application usage of
link-locals make any sense since those addresses will be useless should
the topology change.
For IPv6 addresses based on short addresses (or anything but EUI-64) we
need to do DAD across a scope that is consistent with the address scope.
Thus for the global address it is across the 6lowpan, and for the
link-local it is just with the neighboring 6LRs. (I guess the draft
should make it clear that a 6LR doesn't send a ARO towards the 6LBRs for
a link-local address.)
The fact that the interface ID is the same doesn't help since we want to
be consistent with the IPv6 standards. (IPv6 originally did duplicate
IID detection which was later clarified to be duplicate address detection.)
4. Add a new failure status code for the NA ( "neighbor cache at
capacity" ). This will be used if the 6LR has a full neighbor table
and cannot allow another host to register through it. The host can
then attempt registration through another 6LR
OK
Presumably if there is no other reachable 6LR the host should also
continue to keep poking that 6LR, and/or multicast RS messages to try to
find an available 6LR that has capacity. I wonder if we should recommend
some retransmission behaviors for those cases.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
