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]