TOC 
6LOWPAN WGE. Nordmark
Internet-DraftSun Microsystems, Inc.
Expires: December 18, 2008June 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.



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




 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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.



 TOC 

7.  References



 TOC 

7.1. Normative References

[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” RFC 3971, March 2005 (TXT).
[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 (TXT).
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” RFC 4861, September 2007 (TXT).


 TOC 

7.2. Informative References

[I-D.chakrabarti-6lowpan-ipv6-nd] Chakrabarti, S. and E. Nordmark, “LowPan Neighbor Discovery Extensions,” draft-chakrabarti-6lowpan-ipv6-nd-05 (work in progress), July 2008 (TXT).
[I-D.thubert-6lowpan-backbone-router] Thubert, P., “6LoWPAN Backbone Router,” draft-thubert-6lowpan-backbone-router-01 (work in progress), July 2008 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property