Daniel,
I'm not sure that we need a new error code for DAD table full. If the
DAD table is full on the 6LBR it should deal with that problem - it
could flash some error code or send some message.
geoff
On Wed, 2010-06-09 at 09:33 +0100, Daniel Gavelle wrote:
> Erik,
>
> I agree that a host that gets a DAD full error won't be able to retry
> another 6LBR. Administrative action is required on the 6LBR to solve
> this problem.
>
> However, a DAD table full error code is still useful in communicating
> the error to the human who needs to take action. If the host has a GUI
> (or LED that can flash a fault code), it would be better for it to
> indicate a "DAD table full" error than a "failure to register address".
> Even without such help from the host, an installer working on a large
> commissioned network with a packet sniffer would be able to home in on
> the problem more quickly with the additional error code.
>
> Daniel.
>
>
> Erik Nordmark wrote:
> > On 06/ 8/10 03:21 AM, Daniel Gavelle wrote:
> >> 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).
> >
> > As long as they also synchronize the sequence numbers used in the ABRO
> > they can do that. In essence this might look like one master 6BLR which
> > owns the sequence number space, and the others are slaves that have
> > their configuration kept in synch with the master.
> >
> >> (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.
> >
> > "confusion" is a fairly mild statement, since the compression contexts
> > would now be different hence packets that are compressed would not
> > decompress correctly.
> >
> >> 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.
> >
> > Not only would the 6LRs need to be configured with the ABRO to accept,
> > but all the hosts would need the same configuration.
> >
> > Using ABRO for this really sounds like solving the problem at the wrong
> > level. Wouldn't there be potential security issues since a router in one
> > lowpan could fake an ABRO pretending to be part of the other lowpan?
> > Wouldn't one want to use some L2 security mechanisms to keep the two
> > networks apart?
> >
> >> 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?
> >
> > What would a 6LR do to recover from such an error? The assumption is
> > there there is some external out-of-scope mechanism to keep the DAD
> > tables on multiple 6LBRs in synch, thus doing multihop DAD against
> > another 6LBR would still get back to the overloaded 6LBR.
> >
> > Erik
> >
> >> 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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
