6LOWPAN WG E. Nordmark Internet-Draft Sun Microsystems, Inc. Expires: December 18, 2008 June 16, 2008 Neighbor Discovery Registration Extension draft-nordmark-6lowpan-reg-00.txt 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 December 18, 2008. Abstract In order to reduce Neighbor Discovery multicast messages it is useful if the routers on a link can maintain an authoritative list of the IPv6 and layer 2 addresses for all the hosts on the link. This draft specifies an extension to the Router Advertisement messages which trigger to hosts to send periodic registration messages which can be either unicast, multicast, or anycast. The protocol uses a soft-state approach to gather registration information. Nordmark Expires December 18, 2008 [Page 1] Internet-Draft ND Registration Extension June 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. New ND messages and options . . . . . . . . . . . . . . . . . . 3 2.1. New ND Registration Option . . . . . . . . . . . . . . . . 3 2.2. New ND Registration Message . . . . . . . . . . . . . . . . 4 3. Router Operation . . . . . . . . . . . . . . . . . . . . . . . 5 4. Host Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Nordmark Expires December 18, 2008 [Page 2] Internet-Draft ND Registration Extension June 2008 1. Introduction IPv6 Neighbor Discovery [RFC4861] relies on multicast packets for much functionality. On links where there are low-powered nodes, such as 6LOWPAN links, the multicast packets are expensive in the sense that they cause the nodes to wake up thereby consuming (battery) power. Some ND multicast packets can be avoided if the routers can track the IPv6 and layer 2 addresses of all the hosts on the link, since that removes the need for multicasting address resolution and duplicate address messages. See [I-D.chakrabarti-6lowpan-ipv6-nd] for potential techniques to avoid other reasons for multicasting ND packets. This document specifies a simple extension to IPv6 Neighbor Discovery that provide a registration mechanism for the hosts. The mechanism allows the routers to specify how and when the hosts should register, which gives flexibility. For instance, the registration messages could be sent periodically to N different unicast address, or sent to a single unicast or anycast address. The messages can also be sent immediately which is useful after a router failure when the router or routers need to rebuild their list of registered hosts. 2. New ND messages and options This document defines a new ND registration options which is included in Router Advertisement messages, and it defines a new ND registration message which is sent by the hosts. 2.1. New ND Registration Option The ND registration option can be sent in Router Advertisement messages. It specifies a registration period and a list of IP addresses to which Registration messages should be sent. Nordmark Expires December 18, 2008 [Page 3] Internet-Draft ND Registration Extension June 2008 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address[0] + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Address[1] etc ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type: TBD [To be allocated by the IANA.] Length: 8-bit unsigned integer. The length of the option in units of 8 octets. The value 0 is invalid. The length depends on the number of addresses. Registration Period: 32-bit unsigned integer. The amount of time in seconds between successive registration messages for the same IP address. N: NEW. A single bit. When set the receiving host will immediately send registration messages. Address[i]: One or more IP address to which the host should send registration messages. 2.2. New ND Registration Message A host will send a registration message for each of its IPv6 addresses on the interface. They are send periodically based on the Registration Period in the option, and immediately when receiving a registration option with the 'N' bit. Nordmark Expires December 18, 2008 [Page 4] Internet-Draft ND Registration Extension June 2008 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address: The IPv6 address which is being registered. MUST be the an address assigned to the interface from which this message is sent. Destination Address: A unicast or multicast address. Typically a link-local address. Hop Limit: 255 Fields: Type: TBD [To be allocated by the IANA] Code: 0 Checksum: The ICMP checksum. See [RFC4443]. Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Possible options: Source link-layer address: The link-layer address for the sender. It MUST be included. 3. Router Operation A router is configured with the registration period to use and the set of IP addresses to include in the registration option. Typically the IP addresses are those of all the routers addresses on the link. When the router initializes the interface, for instance, when the router is powered on, it sends three RAs as specified in [RFC4861]. Those RAs SHOULD have the 'N' bit set to cause the hosts to immediately register. This enables a restarting router to quickly Nordmark Expires December 18, 2008 [Page 5] Internet-Draft ND Registration Extension June 2008 discover the set of attached hosts. Subsequent RAs do not have the 'N' bit set. But the hosts will register periodically based on the Registration Period that the router specified. It is expected that all the routers on a link use the same Registration Period and IP addresses in their Registration Options. Routers SHOULD inspect valid Router Advertisements sent by other routers and verify that the routers are advertising consistent information on a link. Detected inconsistencies indicate that one or more routers might be misconfigured and SHOULD be logged to system or network management. Since Registration Messages are not reliably delivered the router should set the Registration Period to a fraction of the time after which it will forget about a registered host. What fraction to use depends on the loss characteristics of the link. On reliable wired networks it would be reasonable to use one fourth i.e., allow two or three consecutive registration messages to be lost without the router declaring the host gone. 4. Host Operation A host needs to record the information received in the Registration Option separately for each interface, or optionally, for each interface and advertising router. When a host needs to send a registration it will send one registration message for each of its IP addresses on the interface to each of the IP addresses. Each registration message has the registered IP address in the IP source address field. This means that when there are N IP addresses in the registration option and the host has M IP address, the host will send N*M registration messages. The reason for not including multiple IP addresses in the same registration message is due to the belief that this would make it harder to apply Secure Neighbor Discovery [RFC3971] to the registration messages. When the host receives a Router Advertisement message it records the Registration Period and the list of IP address from a Registration Option in the RA. The received information replaces what it has stored from a previous RA. If the 'N' bit is set it immediately sends out the N*M registration messages. The host maintains a randomized period timer based on the Registration Period. The timer is set to fire between 0.5 and 1.5 times the Registration Period to Nordmark Expires December 18, 2008 [Page 6] Internet-Draft ND Registration Extension June 2008 avoid self-synchronization for the registration messages. Each time the timer fires the host sends the N*M messages, and computes the random time the next timer should fire. If a particular router times out from the default router list then the host SHOULD discard the information it learned from that router's Registration Option. 5. Security Considerations The use of Hop Limit = 255 by the senders and verified as such by the receivers prevents off-link attackers from successfully injecting Registration Messages. It should be possible to apply Secure Neighbor Discovery [RFC3971] to the registration messages to guard against other on-link nodes spoofing registration messages. 6. IANA Considerations This document needs one ICMPv6 type code assigned for the ND registration message, and one Neighbor Discovery option value assigned to the registration option. 7. References 7.1. Normative References [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 7.2. Informative References [I-D.chakrabarti-6lowpan-ipv6-nd] Chakrabarti, S. and E. Nordmark, "LowPan Neighbor Discovery Extensions", draft-chakrabarti-6lowpan-ipv6-nd-04 (work in progress), Nordmark Expires December 18, 2008 [Page 7] Internet-Draft ND Registration Extension June 2008 November 2007. [I-D.thubert-6lowpan-backbone-router] Thubert, P., "LoWPAN Backbone Router", draft-thubert-6lowpan-backbone-router-00 (work in progress), March 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA Phone: +1 650 786 2921 Email: Erik.Nordmark@Sun.COM Nordmark Expires December 18, 2008 [Page 8] Internet-Draft ND Registration Extension June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Nordmark Expires December 18, 2008 [Page 9]