Hello, <Pascal> I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 </Pascal>
Yes of course! I guess though what I really meant is that according to the draft, save for the 6LR(s) address(es), a link-local address based on the EUI-64 is the only address a 6LN could send to directly. This is a limitation of the 6lowpan-nd draft, if I am reading this correctly. I'm not trying to argue for or against such a limitation, just everyone should be aware of it, and if this is not acceptable look for a solution. It would be good to have some confirmation from the authors to ensure I'm not just being stupid, something we can never rule out ;-) Regards, -Colin O'Flynn -----Original Message----- From: Pascal Thubert (pthubert) [mailto:[email protected]] Sent: March 8, 2011 2:03 PM To: [email protected]; Stok, Peter van der Cc: 6lowpan 6lowpan Subject: RE: [6lowpan] nd-15 for isolated network Hi: <Colin> The link-local address based on EUI-64 can always be mapped directly to a L2 address. This is a special case, no other address can be mapped that way according to the spec. </Colin> <Pascal> I'm sure you mean addresses that are formed using a link-layer address, not just Link Local. More in section 5.7 </Pascal> <Peter> In the applications I am involved, the bulk (say >90%) will be messages > to one hop neighbors and possibly two-hop neighbors. Actually, I expect that the quality of the link between source and destination can be better than the link quality between source and 6LBR. (people may argue that this is bad network engineering, but given costs and knowledge today it looks a very probable situation) </Peter> <Pascal> What's more troubling for Peter's point about 1-hop neighbors is in 6.1: " A router MUST NOT set the 'L' (on-link) flag in the Prefix Information options, since that might trigger hosts to send multicast Neighbor Solicitations. " This text prevents a node from checking whether another node is visible at L2. I think that this recent addition is a mistake. Though clearly costly on a mesh under, this could be reasonable in some route over cases, as long as the multicast is not forwarded. What this spec should mandate is whether and how to enforce the registration for a given prefix as opposed to classical ND. The 'L' bit does not say that. We need a new bit. </Pascal> Cheers, Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
