idnits 2.17.1 draft-chakrabarti-lowpan-ipv6-nd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 67 has weird spacing: '...arrying over ...' == Line 118 has weird spacing: '... to the nodes...' == Line 160 has weird spacing: '...es away from ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2005) is 6863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 221, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 228, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 231, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 234, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-03 -- No information found for draft-montenegro-lowpan-ipv6-over-802 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '4') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '5') (Obsoleted by RFC 4941) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Chakrabarti 3 Internet-Draft E. Nordmark 4 Expires: January 12, 2006 Sun Microsystems, Inc. 5 July 11, 2005 7 LowPan Neighbor Discovery Extensions 8 draft-chakrabarti-lowpan-ipv6-nd-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 12, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 IETF LowPan working group defines IPv6 over low-power personal area 42 network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have 43 multicast support, although it supports broadcast. Due to the nature 44 of LowPan network or sensor networks, broadcast messages should be 45 minimized. This document suggests some alternative to neighbor 46 discovery related multicast messages in order to reduce signaling in 47 the low-cost low-powered network. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Minimizing Multicast or LowPan Broadcast for IPv6 . . . . . . 4 53 3. Neighbor Unreachability Detection . . . . . . . . . . . . . . 6 54 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 60 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 62 Intellectual Property and Copyright Statements . . . . . . . . 13 64 1. Introduction 66 The IPv6-over-IEEE 802.15.4 [2] document has specified IPv6 headers 67 carrying over IEEE 802.15.4 network with the help of a adaptation 68 layer which sits between the MAC layer and the network layer. The 69 LowPan network is characterized by low-powered, low bit-rate, short 70 ranged, low cost network. Thus, all-node multicast defined in 71 Neighbor Discovery [1] is not often desirable in the LowPan network. 72 But IEEE 802.15.4 does not have multicast support, however, it 73 supports broadcast. Broadcast messages could be used in some cases 74 to represent all-node multicast messages, but periodic broadcast 75 messages should be minimized in the LowPan network in order to 76 conserve energy. The goal of this document is to minimize periodic 77 multicast signals used by Neighbor Discovery [1], minimize total 78 number of neighbor discovery related signaling messages without 79 loosing generality of Neighbor Discovery and autoconfiguration. It 80 also aims to identify the default values for periodic advertisements, 81 router and prefix lifetime values that are suitable for LowPan 82 networks. 84 The IPv6-over-IEEE 802.15.4 [2] document provides mesh routing 85 capability at the link layer. Yet each node is configured with IPv6 86 addresses. Thus a IEEE 802.15.4 may look like one single IPv6 subnet 87 to the IP layer. It may be possible that routing advertisements are 88 used only for prefix advertisement purpose for auto-configuration of 89 IPv6 addresses. Yet, neighbor soliciation, neighbor advertisements, 90 neighbor unreachability detection take place as usual for neighbor to 91 neighbor communication. Also, some LowPan networks may use IPv6 92 routing (for example, star topology). Hence minimizing periodic 93 router signaling messages are required for efficient use of IPv6 in 94 the LowPan network. 96 Please note that this version of draft is not complete in determining 97 a solution for reducing the Neighbor Discovery signaling messages; 98 the work is in progress by the authors. 100 2. Minimizing Multicast or LowPan Broadcast for IPv6 102 IPv6 neighbor discovery uses solicited node multicast for duplicate 103 address detection, all-node multicast for unsolicited router 104 advertisement, all-router multicast for the router solicitation 105 messages. An IPv6 node is supposed to join all-node multicast group 106 when the IPv6 interface is configured up. 108 A LowPan network does not have multicast capability in the layer 2. 109 However, the link-layer provides broadcast functionality, supporting 110 IPv6 for broadcast would defeat its purpose. Also the Neighbor 111 Discovery document [1] is designed for regular Internet Network where 112 nodes are sufficiently powered and they are configured in a stable 113 infrastructure of network, unlike LowPan or sensor networks. The 114 strawman idea for this section is to attempt to minimize the 115 multicast Neighbor Discovery signaling packets. 117 If a lowpan node wishes to send Router Solicitation, it should only 118 send the request to the nodes in the local PAN for mesh topology. 119 For star topology, it is likely that the co-ordinator node acts as a 120 IPv6 router if the LowPan network chooses to use L3 routing in this 121 toplogical configuration. In mesh topology all or some nodes have 122 routing or forwarding capabilities. 124 Similarly, the router advertisements should be sent only to the local 125 L2 broadcast address or broadcast PAN ID (0xffff). The default and 126 minimum interval for unsolicited Routing advertisements should change 127 to higher value so that the Lowpan nodes do not need to spend a lot 128 of cycles receiving and processing the signaling messages. 130 Duplicate address detection is sent to the solicited node multicast 131 address which is derived from lower 24bits of the target IPv6 132 address. Should nodes in LowPan network use duplicate address 133 detection ? Avoiding duplicate address detection will save broadcast 134 signalling in the PAN-since 802.15.4 does not have multicast 135 capabilities yet. Besides, each duplicate address detection message 136 is capable of waking up sleeping reduced function devices in the 137 network and making the devices less and less energy efficient. 139 Similarly, sending neighbor soliciation messages for resolving a 140 link-local address for a IPv6 address is also a waste of bandwidth 141 and energy in the LowPan network. Thus the following proposal 142 attempts to distribute the link-layer information of nodes to the PAN 143 co-ordinator which has higher possibility of being a full-functional 144 device. Even if the co-ordinator lives a couple of L2 hops away from 145 the enquiring node (assuming mesh routing at the L2 layer), each 146 neighbor solicitation in this proposal will involve only a few nodes 147 in the path of traversal of the packet. This is an unicast 148 solicitation for resolving address. 150 The strawman proposal is that the prefix advertising router would set 151 a flag, so that all hosts should at least send a packet through the 152 router once for on-link destination nodes. The router sends route- 153 redirect to the sender for direct-host to host path. But the PAN 154 router(s) then keep information on all neighboring nodes L2 155 addresses. A lowpan node. thus sends a neighbor solicitation message 156 to its router or co-ordinator for resolving the L2-address of the 157 neighbor. In most cases, the co-ordinator or prefix advertiser would 158 have an neighbor cache entry for the specified IPv6 target address. 159 More thoughts are needed to specify the protocol behavior when router 160 cache entry becomes stale or when a lowpan node moves away from the 161 PAN. What if the router itself looses power? Should there be 162 multiple routers/co-ordinators who keep the neighbor information in 163 distributed fashion - so that absence or failure of one router will 164 not affect the neighbor solicitation negatively? 166 3. Neighbor Unreachability Detection 168 Using the same essence as above, the IPv6 routers in the LowPan 169 network can reduce Neighbor Unreachability Detection messages. The 170 lowpan nodes may register their L2 and corresponding IPv6 addresses 171 to the designated router/co-ordinators periodically (when they are 172 awake and transmitting) . This will remove the need of frequent 173 neighbor solicitation by the routers to the hosts and vice-versa. 174 The host-to-host NUD frequency should be also reduced and 175 synchronized with the lowpan node's wake-up or radio transmission 176 time only. 178 4. Open Issues 180 o For LowPan nodes, should we say that all NS messages must contain 181 the source link-layer option to avoid triggering a followup 182 neighbor solicitation in reverse direction? 184 o What is the best way to keep the neighbor cache information 185 distributed among different routers/co-ordinators for fault- 186 tolerance? 188 o Should a node de-register itself from router/co-ordinator's 189 neighbor cache if it decides to move away? 191 o What is the default lifetime and interval values for routers and 192 prefixes? 194 o Issues mentioned at the end of section 2 and 3. 196 5. Security Considerations 198 TBD. 200 6. IANA Considerations 202 TBD. 204 7. Acknowledgements 206 TBD 208 8. References 210 8.1 Normative References 212 [1] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor 213 Discovery for IP version 6", draft-ietf-ipv6-2461bis-03.txt 214 (work in progress), May 2005. 216 [2] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6 Packets 217 over IEEE 802.15.4 networks", 218 draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt (work in 219 progress), February 2005. 221 [3] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 222 Assumptions, Problem Statement and Goals", 223 draft-kushalnagar-lowpan-goals-assumptions-00.txt (work in 224 progress), February 2005. 226 8.2 Informative References 228 [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6), 229 Specification", RFC 2460, December 1998. 231 [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless 232 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 234 [6] IEEE Computer Society, "IEEE Std. 802.15.4-2003", , 235 October 2003. 237 Authors' Addresses 239 Samita Chakrabarti 240 Sun Microsystems, Inc. 241 16 Network Circle 242 Menlo Park, CA 95024 243 USA 245 Email: Samita.Chakrabarti@Sun.COM 246 Erik Nordmark 247 Sun Microsystems, Inc. 248 17 Network Circle 249 Menlo Park, CA 95024 250 USA 252 Email: Erik.Nordmark@Sun.COM 254 Intellectual Property Statement 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at 276 ietf-ipr@ietf.org. 278 Disclaimer of Validity 280 This document and the information contained herein are provided on an 281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 283 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Copyright Statement 290 Copyright (C) The Internet Society (2005). This document is subject 291 to the rights, licenses and restrictions contained in BCP 78, and 292 except as set forth therein, the authors retain all their rights. 294 Acknowledgment 296 Funding for the RFC Editor function is currently provided by the 297 Internet Society.