[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]