Network Working Group S. Chakrabarti Internet-Draft E. Nordmark Expires: January 12, 2006 Sun Microsystems, Inc. July 11, 2005 LowPan Neighbor Discovery Extensions draft-chakrabarti-lowpan-ipv6-nd-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IETF LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have multicast support, although it supports broadcast. Due to the nature of LowPan network or sensor networks, broadcast messages should be minimized. This document suggests some alternative to neighbor discovery related multicast messages in order to reduce signaling in the low-cost low-powered network. Chakrabarti & Nordmark Expires January 12, 2006 [Page 1] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Minimizing Multicast or LowPan Broadcast for IPv6 . . . . . . 4 3. Neighbor Unreachability Detection . . . . . . . . . . . . . . 6 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Chakrabarti & Nordmark Expires January 12, 2006 [Page 2] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 1. Introduction The IPv6-over-IEEE 802.15.4 [2] document has specified IPv6 headers carrying over IEEE 802.15.4 network with the help of a adaptation layer which sits between the MAC layer and the network layer. The LowPan network is characterized by low-powered, low bit-rate, short ranged, low cost network. Thus, all-node multicast defined in Neighbor Discovery [1] is not often desirable in the LowPan network. But IEEE 802.15.4 does not have multicast support, however, it supports broadcast. Broadcast messages could be used in some cases to represent all-node multicast messages, but periodic broadcast messages should be minimized in the LowPan network in order to conserve energy. The goal of this document is to minimize periodic multicast signals used by Neighbor Discovery [1], minimize total number of neighbor discovery related signaling messages without loosing generality of Neighbor Discovery and autoconfiguration. It also aims to identify the default values for periodic advertisements, router and prefix lifetime values that are suitable for LowPan networks. The IPv6-over-IEEE 802.15.4 [2] document provides mesh routing capability at the link layer. Yet each node is configured with IPv6 addresses. Thus a IEEE 802.15.4 may look like one single IPv6 subnet to the IP layer. It may be possible that routing advertisements are used only for prefix advertisement purpose for auto-configuration of IPv6 addresses. Yet, neighbor soliciation, neighbor advertisements, neighbor unreachability detection take place as usual for neighbor to neighbor communication. Also, some LowPan networks may use IPv6 routing (for example, star topology). Hence minimizing periodic router signaling messages are required for efficient use of IPv6 in the LowPan network. Please note that this version of draft is not complete in determining a solution for reducing the Neighbor Discovery signaling messages; the work is in progress by the authors. Chakrabarti & Nordmark Expires January 12, 2006 [Page 3] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 2. Minimizing Multicast or LowPan Broadcast for IPv6 IPv6 neighbor discovery uses solicited node multicast for duplicate address detection, all-node multicast for unsolicited router advertisement, all-router multicast for the router solicitation messages. An IPv6 node is supposed to join all-node multicast group when the IPv6 interface is configured up. A LowPan network does not have multicast capability in the layer 2. However, the link-layer provides broadcast functionality, supporting IPv6 for broadcast would defeat its purpose. Also the Neighbor Discovery document [1] is designed for regular Internet Network where nodes are sufficiently powered and they are configured in a stable infrastructure of network, unlike LowPan or sensor networks. The strawman idea for this section is to attempt to minimize the multicast Neighbor Discovery signaling packets. If a lowpan node wishes to send Router Solicitation, it should only send the request to the nodes in the local PAN for mesh topology. For star topology, it is likely that the co-ordinator node acts as a IPv6 router if the LowPan network chooses to use L3 routing in this toplogical configuration. In mesh topology all or some nodes have routing or forwarding capabilities. Similarly, the router advertisements should be sent only to the local L2 broadcast address or broadcast PAN ID (0xffff). The default and minimum interval for unsolicited Routing advertisements should change to higher value so that the Lowpan nodes do not need to spend a lot of cycles receiving and processing the signaling messages. Duplicate address detection is sent to the solicited node multicast address which is derived from lower 24bits of the target IPv6 address. Should nodes in LowPan network use duplicate address detection ? Avoiding duplicate address detection will save broadcast signalling in the PAN-since 802.15.4 does not have multicast capabilities yet. Besides, each duplicate address detection message is capable of waking up sleeping reduced function devices in the network and making the devices less and less energy efficient. Similarly, sending neighbor soliciation messages for resolving a link-local address for a IPv6 address is also a waste of bandwidth and energy in the LowPan network. Thus the following proposal attempts to distribute the link-layer information of nodes to the PAN co-ordinator which has higher possibility of being a full-functional device. Even if the co-ordinator lives a couple of L2 hops away from the enquiring node (assuming mesh routing at the L2 layer), each neighbor solicitation in this proposal will involve only a few nodes in the path of traversal of the packet. This is an unicast Chakrabarti & Nordmark Expires January 12, 2006 [Page 4] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 solicitation for resolving address. The strawman proposal is that the prefix advertising router would set a flag, so that all hosts should at least send a packet through the router once for on-link destination nodes. The router sends route- redirect to the sender for direct-host to host path. But the PAN router(s) then keep information on all neighboring nodes L2 addresses. A lowpan node. thus sends a neighbor solicitation message to its router or co-ordinator for resolving the L2-address of the neighbor. In most cases, the co-ordinator or prefix advertiser would have an neighbor cache entry for the specified IPv6 target address. More thoughts are needed to specify the protocol behavior when router cache entry becomes stale or when a lowpan node moves away from the PAN. What if the router itself looses power? Should there be multiple routers/co-ordinators who keep the neighbor information in distributed fashion - so that absence or failure of one router will not affect the neighbor solicitation negatively? Chakrabarti & Nordmark Expires January 12, 2006 [Page 5] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 3. Neighbor Unreachability Detection Using the same essence as above, the IPv6 routers in the LowPan network can reduce Neighbor Unreachability Detection messages. The lowpan nodes may register their L2 and corresponding IPv6 addresses to the designated router/co-ordinators periodically (when they are awake and transmitting) . This will remove the need of frequent neighbor solicitation by the routers to the hosts and vice-versa. The host-to-host NUD frequency should be also reduced and synchronized with the lowpan node's wake-up or radio transmission time only. Chakrabarti & Nordmark Expires January 12, 2006 [Page 6] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 4. Open Issues o For LowPan nodes, should we say that all NS messages must contain the source link-layer option to avoid triggering a followup neighbor solicitation in reverse direction? o What is the best way to keep the neighbor cache information distributed among different routers/co-ordinators for fault- tolerance? o Should a node de-register itself from router/co-ordinator's neighbor cache if it decides to move away? o What is the default lifetime and interval values for routers and prefixes? o Issues mentioned at the end of section 2 and 3. Chakrabarti & Nordmark Expires January 12, 2006 [Page 7] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 5. Security Considerations TBD. Chakrabarti & Nordmark Expires January 12, 2006 [Page 8] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 6. IANA Considerations TBD. Chakrabarti & Nordmark Expires January 12, 2006 [Page 9] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 7. Acknowledgements TBD Chakrabarti & Nordmark Expires January 12, 2006 [Page 10] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 8. References 8.1 Normative References [1] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6", draft-ietf-ipv6-2461bis-03.txt (work in progress), May 2005. [2] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets over IEEE 802.15.4 networks", draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt (work in progress), February 2005. [3] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", draft-kushalnagar-lowpan-goals-assumptions-00.txt (work in progress), February 2005. 8.2 Informative References [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6), Specification", RFC 2460, December 1998. [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [6] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , October 2003. Authors' Addresses Samita Chakrabarti Sun Microsystems, Inc. 16 Network Circle Menlo Park, CA 95024 USA Email: Samita.Chakrabarti@Sun.COM Chakrabarti & Nordmark Expires January 12, 2006 [Page 11] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 95024 USA Email: Erik.Nordmark@Sun.COM Chakrabarti & Nordmark Expires January 12, 2006 [Page 12] Internet-Draft LowPan Neighbor Discovery Extensions July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chakrabarti & Nordmark Expires January 12, 2006 [Page 13]