I think there are two separate cases where more than one 6LBR may be
visible on a 15.4 PAN. Other MACs may reach point (2) sooner if they
don't have the concept of a PAN ID.
(1) 6LBRs are acting together to provide redundancy. Their context and
prefix information is synchronised by an "out of scope method". In this
case, wouldn't it be better if all the 6LBRs all advertise using the
same identifier (i.e. the current 6LBR Address identifies the network
rather than an individual 6LBR).
(2) Two networks that were intended to be kept separate but use the same
PAN and channel have grown out and come into range of each other. In
this case, the 6LR and hosts of one network are not interested in the
context and prefix information from the other network. Using the
context / prefix from the other network would only result in confusion.
I think both cases would be better covered by the 6LR selecting a 6LBR
(or set of redundant 6LBRs) and only forwarding the ABRO messages from
the network that it is participating in.
I agree that we need an error code for when the 6LR has reached capacity
and rules for retry. I think the host should send multicast RS rather
than poking that particular 6LR as another router may come into range
before the one that is full drops a child.
Do we also need a separate code for when the DAD table on the 6LBR
becomes full?
Daniel.
Erik Nordmark wrote:
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
--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
