Erik,I agree that it is very important to keep the contexts in sync within a network. I can also see that the L2 security can be used to separate networks. Given these two conditions, when would there be a need for two 6LBRS in a network to have different addresses / version number spaces?
Daniel. Erik Nordmark wrote:
On 06/ 9/10 01:28 AM, Daniel Gavelle wrote:If the L2 takes care of multiple overlapping networks, I think the protocol could be simplified and context distribution made safer by removing the 6LBR address field from the ABRO and requiring all 6LBRS to use the same version number.>For example:- 6LBR1 has address aaaa. It has been running for a while and is on version 10. 6LBR2 is brought on line with address bbbb. It is loaded with the same context information as aaaa and is on version 1. The administrator decides to update the contexts. 6LBR2 receives the update OK but 6LBR1 doesn't. I'll call the old contexts ctx1 and the new contexts ctx2 although in reality there will be no way of telling from the contexts themselves which is the newer set. A 6BR sees two messages: aaaa v2 with ctx 2 and bbbb v10 with ctx1. In the existing spec, it must store both (aaaa v2 ctx2) and (bbbb v10 ctx1). This takes up more memory and means the 6LR can't just use its own context tables for storing context information as more than one set must be stored. When a host sends 6BR an RS, 6BR must generate two separate RAs: (aaaa v2 ctx2) and (bbbb ctx1 v10). Both the 6LR and the host need to decide which context to use based only on the above information. If they pick differently, their contexts won't be in sync and they won't be able to communicate.I think the network is more broken that that, because presumably 6LBR1 will use the contexts it advertised and 6LBR2 the ones it advertised. Thus even if we could get the 6LRs and hosts to agree on one set of context information (e.g., ctx2), the packets being routed out via 6LBR2 would not decompress correctly; ditto for packets arriving in via 6LBR2.However, the gradual introduction and change of contexts specified in nd-09 means that as long as the new context are propagated to 6LBR2 and distributed with its ABRO before the C bit is changed, there will be no incorrect decompressions. Thus the out-of-scope mechanism which keeps 6LBR1 and 6LBR2 in synch with respect to the contexts need to be able to update both of them before the next update (which might change the C bit) or otherwise the network will fall apart.If the address were removed and the requirement was made to update the version number at the same time as the contexts, aaaa would send (v11 ctx2) and bbbb would send (v10 ctx1). The 6LR would only need to store a single version number and could read out the context information from its tables when responding to an RS. It would respond to an RS with a single RA with the most up to date context info.But the packets being forwarded via LBR2 would still use the old compression context, hence would be turned into garbage.Thus while I can see that using a single logical 6LBR (that feeds via multiple actual 6LBRs) reduces the memory requirements, and might be a good deployment practice, it doesn't remove the need for all the 6LBRs to be updated with the compression contexts.ErikErik 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 samePAN 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 thecontext 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 capacityand 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. ErikDaniel. 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 nodesThe '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 6LROK 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
