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.

Table of Contents

1.  Introduction
2.  New ND messages and options
    2.1.  New ND Registration Option
    2.2.  New ND Registration Message
3.  Router Operation
4.  Host Operation
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

IPv6 Neighbor Discovery [RFC4861] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) 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] (Chakrabarti, S. and E. Nordmark, “LowPan Neighbor Discovery Extensions,” July 2008.) 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.

 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.

 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] (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.).

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] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.). Those RAs SHOULD have the 'N' bit set to cause the hosts to immediately register. This enables a restarting router to quickly 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] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) 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 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] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) 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

7.2. Informative References

Author's Address

Full Copyright Statement

Copyright © 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.