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
