Hi Colin, Thanks for the clarifications.
Sending packets to destinations using mesh-under still remains a bit vague to me. Given a LOWPAN with a 6LBR connected to DHCP, DNS, etc, nodes will use the prefix of the LOWPAN in the IP address. According to 5.6 a packet with a non link-local IP address is assumed to be off-link and sent to 6LBR. However, when the prefix of the destination is the same as the prefix of the source, source and destination are hosts in the same LOWPAN. In this case the packet can be sent over the link with mesh-under routing to the destination. In my view sending the packet to 6LBR contradicts the mesh-under concept, because the packet is first routed to 6LBR. To send the packet without passing via the 6LBR, the source needs the Link address of the destination, but this link address is only available to the 6LBR. A solution is configuring every host as a 6LR, but that defeats the purpose of the 6LR. What have I missed? If the above reasoning is correct, a mechanism is lacking in which a host can ask the 6LBR the link address of a given IP address with the LOWPAN prefix to allow proper mesh-under routing. Looking forward to your reaction. Peter From: Colin O'Flynn [mailto:[email protected]] Sent: Tuesday 1 March 2011 14:03 To: Stok, Peter van der; '6lowpan 6lowpan' Subject: RE: [6lowpan] nd-15 for isolated network Hi Peter, I think you are basically correct, with some additional constraints or clarifications: The 6LN NC will have entries for routers it has registered with, so it's not always empty. Section 5.6 allows you to use the MAC extraction only if the link-local address is EUI-64 based. This basically means if the U/L bit is set, indicating the address in question was generated from a known-unique MAC address. 802.15.4 for example has 16-bit addresses you could be using instead. I think most networks would have the 6LBR, although obviously if you have a very specific situation as you outlined you could skip it. The 6LBR at minimum would manage the compression context (if required) and serve as an alternative way to reach a node by a default route. From a maintenance/deployment/management perspective the 6LBR is an easy way to see what nodes are alive on your network too by checking its tables. Regards, -Colin From: [email protected] [mailto:[email protected]] On Behalf Of Stok, Peter van der Sent: March 1, 2011 1:21 PM To: 6lowpan 6lowpan Subject: [6lowpan] nd-15 for isolated network Dear authors, The document looks rather complete and comprehensive. There are a few questions: Do I understand correctly that contrary to RFC 4861, the neighbor cache is always empty in 6LN. If true, this remark may be added to Registration term of section 2. >From that do I deduce correctly that access to the link for link-local >addresses (LLA) involves extracting the MAC address from the LLA. MUST a 6LBR be present in an isolated LOWPAN? (6LBR text in section 2 seems to imply this) Assuming an isolated LOWPAN without 6LR or 6LBR, then there will be no answer to the RS message, but the node can continue sending messages to LLA, where the MAC address is again extracted from the LLA. Is that correct? Peter Peter van der Stok Philips Research Laboratories Eindhoven High Tech Campus HTC 34 (WB) 1-067 5656 AA Eindhoven The Netherlands phone +31 40 2749657 Fax: + 31 40 2746321 mailto: [email protected] ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
