Hi Jonathan Pascal
>-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: Wednesday, July 18, 2007 6:24 PM >To: Pascal Thubert (pthubert) >Cc: Timothy J. Salo; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Subject: Re: [RSN] Re: [6lowpan] "Link-Local Routing" versus "Network-LayerRouting" > > >Pascal Thubert (pthubert) wrote: >> [Pascal] Who knows? One might use a disseminated sensor network as >> access for some signaling, or limited upstream when no other medium is >> available. If we do not need that assumption, let's not make it... > >Looks like we both agree. My point throughout this thread was that >sometimes we can't make certain assumptions even if they may have >significant advantages. > [Pascal] :) >> I understand that a device could roll its 16-bit short address if it >> really wanted to for privacy reasons, correct? > >Correct. But the availability of a short address depends on the >configuration of the link-layer. According to the IEEE 802.15.4 spec, a >PAN coordinator is not obligated to dole out 16-bit short addresses. I >don't know how often we see this in practice, and maybe its okay if, in >these cases, nodes refuse to communicate to preserve privacy. [Pascal] That's fine. If the burnin EUI64 address is used, we all agree that DAD can be skipped or made very very optimistic. > >> If so, what I'd suggest is that when the u/l bit is set to local, we >> force the 16 bits at a given place, say the last bits of the address, >> and leave the rest up to the device. That way, DAD is not necessary and >> the specification is still open for the device to do what it likes with >> the rest of the address, such as a CGA that we would define over 48 bits >> instead of 64. > >The current 6LoWPAN format draft suggests that interface identifiers >derived from short addresses is done similar to RFC2464, by creating a >48-bit Ethernet-style address using the PAN ID and short address. So it >doesn't support creating any form of CGA with a well-defined mapping to >short addresses. But, maybe we should revisit this issue. > [Pascal] Yes, that's specifically what I'm discussing right now. If we want to be open to some CGA or other privacy extension in the future and still avoid DAD, then there is a need to change the draft before it's too late. The proposal was that if we have a short address, we just lock its position in the IID, and leave the rest open. That ensures the uniqueness of the address and whatever game the nodes play in the future with the 46 bits left will be backward compatible. >In general, I am in agreement with Timothy Salo's proposal. Correct me >if I'm wrong, but most, if not all, current 6LoWPAN implementations >assume that the interface identifier and link address (16 and 64-bit) >have a one-to-one mapping, including the Arch Rock implementation. It >does reduce resource requirements in energy and code. I'm playing a bit >of devil's advocate here to vet out that such an assumption don't cause >unwanted constraints in the future. > [Pascal] You can not lock the draft because of early implementations, can you? Anyway, I'm don't see that I'm asking to change that? I'm just proposing to leave the rest of the IID open to the node's support of various upcoming features, as opposed to forcing the draft EUI48 format. At the moment, the draft still assumes that a PAN maps to a link, so the PAN id in the IID is not necessary. If that assumption breaks later, we can always define the PAN ID in the address at that time and be backward compatible; IOW future nodes will be able to insert into a legacy network which obeys the current draft limitation (1 PAN per link) and will interact with legacy nodes that do not know better. OTOH, if the legacy nodes expect the PAN ID in the EUI 48 and do something about it, they will never interwork with a newer device that needs the bits for something else, e.g. CGA. Seems to me that we share the objective is to prevent the nodes from making any unnecessary assumption. So we should agree on this, do I miss something? >> [Pascal] It seems fair to believe that the coordinators and FFDs will >> end up proxying ND and some routing for the RFDs, which this draft >> proposes. At the moment, the IPv6 routers do not talk 6LowPAN and >> there's a gateway that interconnects say, Ethernet and 802.15.4. Should >> there be a specific 6LowPAN ND support in the router? And can we define >> that functionality so that it can be proxyed/snooped in the gateway? > >I believe there should be 6LoWPAN support in routers. It is a better fit >architecturally - it is where router-specific ND mechanisms are intended >to be implemented. It can also open doors for 6LoWPAN specific >extensions to ND at the router. > [Pascal] Things like MLD can be snooped in a switch, and there has been some effort in the past for ND proxy. Depending on how things are done, such things could happen for 6LowPAN or not. We might make it a goal or a non goal. Your answer makes it a non goal. I'm fine with that, I just wanted to make it clear to the lists that there was an option there. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
