idnits 2.17.1 draft-nordmark-6lowpan-reg-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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 339. 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 IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 16, 2008) is 5794 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) -- Looks like a reference, but probably isn't: '0' on line 108 -- Looks like a reference, but probably isn't: '1' on line 113 == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 287, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-chakrabarti-6lowpan-ipv6-nd-04 == Outdated reference: A later version (-03) exists of draft-thubert-6lowpan-backbone-router-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LOWPAN WG E. Nordmark 3 Internet-Draft Sun Microsystems, Inc. 4 Expires: December 18, 2008 June 16, 2008 6 Neighbor Discovery Registration Extension 7 draft-nordmark-6lowpan-reg-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 18, 2008. 34 Abstract 36 In order to reduce Neighbor Discovery multicast messages it is useful 37 if the routers on a link can maintain an authoritative list of the 38 IPv6 and layer 2 addresses for all the hosts on the link. 40 This draft specifies an extension to the Router Advertisement 41 messages which trigger to hosts to send periodic registration 42 messages which can be either unicast, multicast, or anycast. The 43 protocol uses a soft-state approach to gather registration 44 information. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. New ND messages and options . . . . . . . . . . . . . . . . . . 3 50 2.1. New ND Registration Option . . . . . . . . . . . . . . . . 3 51 2.2. New ND Registration Message . . . . . . . . . . . . . . . . 4 52 3. Router Operation . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Host Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 Intellectual Property and Copyright Statements . . . . . . . . . . 9 62 1. Introduction 64 IPv6 Neighbor Discovery [RFC4861] relies on multicast packets for 65 much functionality. On links where there are low-powered nodes, such 66 as 6LOWPAN links, the multicast packets are expensive in the sense 67 that they cause the nodes to wake up thereby consuming (battery) 68 power. 70 Some ND multicast packets can be avoided if the routers can track the 71 IPv6 and layer 2 addresses of all the hosts on the link, since that 72 removes the need for multicasting address resolution and duplicate 73 address messages. See [I-D.chakrabarti-6lowpan-ipv6-nd] for 74 potential techniques to avoid other reasons for multicasting ND 75 packets. 77 This document specifies a simple extension to IPv6 Neighbor Discovery 78 that provide a registration mechanism for the hosts. The mechanism 79 allows the routers to specify how and when the hosts should register, 80 which gives flexibility. For instance, the registration messages 81 could be sent periodically to N different unicast address, or sent to 82 a single unicast or anycast address. The messages can also be sent 83 immediately which is useful after a router failure when the router or 84 routers need to rebuild their list of registered hosts. 86 2. New ND messages and options 88 This document defines a new ND registration options which is included 89 in Router Advertisement messages, and it defines a new ND 90 registration message which is sent by the hosts. 92 2.1. New ND Registration Option 94 The ND registration option can be sent in Router Advertisement 95 messages. It specifies a registration period and a list of IP 96 addresses to which Registration messages should be sent. 98 0 1 2 3 99 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Type | Length |N| Reserved | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Registration Period | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | | 106 + + 107 | | 108 + Address[0] + 109 | | 110 + + 111 | | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 ~ Address[1] etc ~ 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Fields: 118 Type: TBD [To be allocated by the IANA.] 120 Length: 8-bit unsigned integer. The length of the option in 121 units of 8 octets. The value 0 is invalid. The 122 length depends on the number of addresses. 124 Registration Period: 32-bit unsigned integer. The amount of time in 125 seconds between successive registration messages for 126 the same IP address. 128 N: NEW. A single bit. When set the receiving host will 129 immediately send registration messages. 131 Address[i]: One or more IP address to which the host should send 132 registration messages. 134 2.2. New ND Registration Message 136 A host will send a registration message for each of its IPv6 137 addresses on the interface. They are send periodically based on the 138 Registration Period in the option, and immediately when receiving a 139 registration option with the 'N' bit. 141 0 1 2 3 142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Type | Code | Checksum | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Reserved | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Options ... 149 +-+-+-+-+-+-+-+-+-+-+-+- 151 IP Fields: 153 Source Address: The IPv6 address which is being registered. MUST be 154 the an address assigned to the interface from which 155 this message is sent. 157 Destination Address: A unicast or multicast address. Typically a 158 link-local address. 160 Hop Limit: 255 162 Fields: 164 Type: TBD [To be allocated by the IANA] 166 Code: 0 168 Checksum: The ICMP checksum. See [RFC4443]. 170 Reserved: This field is unused. It MUST be initialized to zero 171 by the sender and MUST be ignored by the receiver. 173 Possible options: 175 Source link-layer address: The link-layer address for the sender. 176 It MUST be included. 178 3. Router Operation 180 A router is configured with the registration period to use and the 181 set of IP addresses to include in the registration option. Typically 182 the IP addresses are those of all the routers addresses on the link. 184 When the router initializes the interface, for instance, when the 185 router is powered on, it sends three RAs as specified in [RFC4861]. 186 Those RAs SHOULD have the 'N' bit set to cause the hosts to 187 immediately register. This enables a restarting router to quickly 188 discover the set of attached hosts. 190 Subsequent RAs do not have the 'N' bit set. But the hosts will 191 register periodically based on the Registration Period that the 192 router specified. 194 It is expected that all the routers on a link use the same 195 Registration Period and IP addresses in their Registration Options. 196 Routers SHOULD inspect valid Router Advertisements sent by other 197 routers and verify that the routers are advertising consistent 198 information on a link. Detected inconsistencies indicate that one or 199 more routers might be misconfigured and SHOULD be logged to system or 200 network management. 202 Since Registration Messages are not reliably delivered the router 203 should set the Registration Period to a fraction of the time after 204 which it will forget about a registered host. What fraction to use 205 depends on the loss characteristics of the link. On reliable wired 206 networks it would be reasonable to use one fourth i.e., allow two or 207 three consecutive registration messages to be lost without the router 208 declaring the host gone. 210 4. Host Operation 212 A host needs to record the information received in the Registration 213 Option separately for each interface, or optionally, for each 214 interface and advertising router. 216 When a host needs to send a registration it will send one 217 registration message for each of its IP addresses on the interface to 218 each of the IP addresses. Each registration message has the 219 registered IP address in the IP source address field. This means 220 that when there are N IP addresses in the registration option and the 221 host has M IP address, the host will send N*M registration messages. 223 The reason for not including multiple IP addresses in the same 224 registration message is due to the belief that this would make it 225 harder to apply Secure Neighbor Discovery [RFC3971] to the 226 registration messages. 228 When the host receives a Router Advertisement message it records the 229 Registration Period and the list of IP address from a Registration 230 Option in the RA. The received information replaces what it has 231 stored from a previous RA. If the 'N' bit is set it immediately 232 sends out the N*M registration messages. The host maintains a 233 randomized period timer based on the Registration Period. The timer 234 is set to fire between 0.5 and 1.5 times the Registration Period to 235 avoid self-synchronization for the registration messages. Each time 236 the timer fires the host sends the N*M messages, and computes the 237 random time the next timer should fire. 239 If a particular router times out from the default router list then 240 the host SHOULD discard the information it learned from that router's 241 Registration Option. 243 5. Security Considerations 245 The use of Hop Limit = 255 by the senders and verified as such by the 246 receivers prevents off-link attackers from successfully injecting 247 Registration Messages. 249 It should be possible to apply Secure Neighbor Discovery [RFC3971] to 250 the registration messages to guard against other on-link nodes 251 spoofing registration messages. 253 6. IANA Considerations 255 This document needs one ICMPv6 type code assigned for the ND 256 registration message, and one Neighbor Discovery option value 257 assigned to the registration option. 259 7. References 261 7.1. Normative References 263 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 264 Neighbor Discovery (SEND)", RFC 3971, March 2005. 266 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 267 Message Protocol (ICMPv6) for the Internet Protocol 268 Version 6 (IPv6) Specification", RFC 4443, March 2006. 270 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 271 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 272 September 2007. 274 7.2. Informative References 276 [I-D.chakrabarti-6lowpan-ipv6-nd] 277 Chakrabarti, S. and E. Nordmark, "LowPan Neighbor 278 Discovery Extensions", 279 draft-chakrabarti-6lowpan-ipv6-nd-04 (work in progress), 280 November 2007. 282 [I-D.thubert-6lowpan-backbone-router] 283 Thubert, P., "LoWPAN Backbone Router", 284 draft-thubert-6lowpan-backbone-router-00 (work in 285 progress), March 2008. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 Author's Address 292 Erik Nordmark 293 Sun Microsystems, Inc. 294 17 Network Circle 295 Menlo Park, CA 94025 296 USA 298 Phone: +1 650 786 2921 299 Email: Erik.Nordmark@Sun.COM 301 Full Copyright Statement 303 Copyright (C) The IETF Trust (2008). 305 This document is subject to the rights, licenses and restrictions 306 contained in BCP 78, and except as set forth therein, the authors 307 retain all their rights. 309 This document and the information contained herein are provided on an 310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 312 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 313 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 314 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 317 Intellectual Property 319 The IETF takes no position regarding the validity or scope of any 320 Intellectual Property Rights or other rights that might be claimed to 321 pertain to the implementation or use of the technology described in 322 this document or the extent to which any license under such rights 323 might or might not be available; nor does it represent that it has 324 made any independent effort to identify any such rights. Information 325 on the procedures with respect to rights in RFC documents can be 326 found in BCP 78 and BCP 79. 328 Copies of IPR disclosures made to the IETF Secretariat and any 329 assurances of licenses to be made available, or the result of an 330 attempt made to obtain a general license or permission for the use of 331 such proprietary rights by implementers or users of this 332 specification can be obtained from the IETF on-line IPR repository at 333 http://www.ietf.org/ipr. 335 The IETF invites any interested party to bring to its attention any 336 copyrights, patents or patent applications, or other proprietary 337 rights that may cover technology that may be required to implement 338 this standard. Please address the information to the IETF at 339 ietf-ipr@ietf.org.