One document matched: draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt
6LoWPAN WG S. Chakrabarti
Internet-Draft IP Infusion
Expires: September 2, 2010 E. Nordmark
Oracle, Inc.
March 1, 2010
IPv6 LoWPAN Neighbor Discovery and Addressing Choices
draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt
Abstract
IETF 6LoWPAN working group defines IPv6 over low-power personal area
network (IEEE 802.15.4). IEEE 802.15.4 and other low-power wireless
networks have limited or no usage of broadcast or multicast signaling
due to energy conservation. Besides the wireless nodes may not
strictly follow traditional concept of IP subnet and IP-links while
connecting nodes and routers. This document describes simple
optimizations to IPv6 Neighbor Discovery protocol(RFC4861), and
addressing mechanisms that are useful for small scale 6LoWPAN
networks in star and mesh topologies.
The optimizations include reducing the amount of Neighbor Discovery
multicast traffic and allowing for a single subnet to span multiple
routers in a "route-over" topology.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 September 2, 2010.
Chakrabarti & Nordmark Expires September 2, 2010 [Page 1]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
1.1. IPv6 Neighbor Discovery shortcomings in low-power
wireless network . . . . . . . . . . . . . . . . . . . . . 3
1.2. Address Allocation Options in 6LoWPAN . . . . . . . . . . 4
1.3. Mesh-under and Route-over Concept and Behavior . . . . . . 4
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 6
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability Statement . . . . . . . . . . . . . . . . . . . 7
5. Autoconfiguration of 6LoWPAN Addresses . . . . . . . . . . . . 8
5.1. Address Assignment in Star Networks . . . . . . . . . . . 8
5.2. Address Assignment in Mesh Network . . . . . . . . . . . . 8
5.3. DHCPv6 Address and Resource Allocation . . . . . . . . . . 8
6. New Neighbor Discovery options . . . . . . . . . . . . . . . . 8
6.1. Authoritative Router option . . . . . . . . . . . . . . . 9
6.2. Node-lifetime option . . . . . . . . . . . . . . . . . . . 10
7. Optimized Neighbor Discovery for 6LoWPANs . . . . . . . . . . 10
7.1. Operations Overview . . . . . . . . . . . . . . . . . . . 11
7.2. Existing Neighbor Discovery Messages . . . . . . . . . . . 11
7.3. 6LoWPAN Optimized Neighbor Discovery Messages . . . . . . 11
7.4. Host Behavior . . . . . . . . . . . . . . . . . . . . . . 12
7.5. 6LBR Behavior . . . . . . . . . . . . . . . . . . . . . . 13
7.6. 6LR Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
8. Remaining Multicast messages . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Chakrabarti & Nordmark Expires September 2, 2010 [Page 2]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
1. Introduction and Overview
The IPv6-over-IEEE 802.15.4 [3] document specifies IPv6 headers
carried over IEEE 802.15.4 network with the help of an adaptation
layer which sits between the MAC layer and the IP network layer. The
LoWPAN network is characterized by low-powered, low bit-rate, short
ranged, low cost nodes. Thus, all-node multicast defined in Neighbor
Discovery [2] may be unsuitable in the LoWPAN network which does not
have direct multicast support at the link-layer. Broadcast messages
could be used in some cases to represent all-node multicast messages,
but periodic broadcast messages should be minimized in the LoWPAN
network in order to conserve energy.
This document provides an overview of IPv6 Neighbor Discovery options
and describes a base mechanism for optimized 6LoWPAN neighbor
discovery mechanism.
The optimizations include reducing the amount of Neighbor Discovery
multicast traffic and allowing for a single subnet to span multiple
routers in a "route-over" topology.
1.1. IPv6 Neighbor Discovery shortcomings in low-power wireless network
IPv6 ND [2] is based on multicast signaling messages on the local
link in order to avoid broadcast messages. Following power-on and
initialization of the network in IPv6 Ethernet networks, a node joins
the solicited-node multicast address on the interface and then
performs duplicate address detection (DAD) for the acquired link-
local address by sending a solicited-node multicast message to the
link. After that it sends multicast router solicitation (RS)
messages to the all-router address to solicit router advertisements.
Once the host receives a valid router advertisement (RA) with the "A"
flag, it autoconfigures the IPv6 address with the advertised prefix
in the router advertisement (RA). Besides this, the IPv6 routers
usually send router advertisements periodically on the network. RAs
are sent to the all-node multicast address. Nodes send Neighbor
Solicitation (NS) and Neighbor Advertisement (NA) messages to resolve
the IPv6 address of the destination on the link. These NS/NA
messages are also often multicast messages and it is assumed that the
node is on the same link and relies on the fact that the destination
node is always powered and generally available.
In 6LoWPAN 802.15.4 network, primarily two types of configurations
are used - 1) Star network and 2) Mesh network. A star network is
similar to regular IPv6 subnet with a router and a set of nodes
connected to it via the same link. But in low-power mesh networks,
the nodes are capable of routing and forwarding packets but due to
lossy nature of wireless communication, the IPv6-link node sets may
Chakrabarti & Nordmark Expires September 2, 2010 [Page 3]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
change due to external physical factors and thus the link and
connection becomes unreliable.
Thus optimizing the regular IPv6 Neighbor Discovery [2] to minimize
total number of related signaling messages without loosing generality
of Neighbor Discovery and autoconfiguration and making host and
router communication reliable, is desirable in 6LoWPAN mesh
configuration.
1.2. Address Allocation Options in 6LoWPAN
As 6LoWPAN and IEEE 802.15.4 technologies are evolving we can
anticipate that regular IPv6 ND [2] might be used in some
configuration where the physical medium and hardware support higher
bandwidth and processing power with low-power consumption.
Thus the following options of address allocations are envisioned in a
6LoWPAN network depending on the configuration and network capacity.
o Address allocation through multicast IPv6 Neighbor Discovery [2]
and IPv6 Autoconfiguration [6] with tuned parameters for 6LoWPAN
usage. The Neighbor Discovery and autoconfiguration parameters
are configurable on the basis of deployment requirement(example:
when all 6LoWPAN nodes are one-hop away from the IPv6 router).
o A simplified DHCPv6 method for IPv6 address allocation in a
6LoWPAN network. This is useful for a star network and mesh
network where all the nodes are in reachable range of the DHCPv6
server. DHCPv6 services SHOULD be used for assigning IPv6-
addresses using 16-bit short MAC addresses described in IEEE
802.15.4 [9] in order to ensure uniqueness of IPv6 addresses.
o An optimized 6LoWPAN Neighbor Discovery is recommended for
efficiency and power savings for the low-power and lossy wireless
mesh networks. The simple optimization of IPv6 Neighbor
Discovery[2] for low-power network in this document. This
mechanism SHOULD be used for efficient handling of signaling
messages in the 6LoWPAN mesh and star networks using nodes with
EUI-64 MAC addresses.
It is noted that all the above address allocation methods MUST follow
the address allocation principles described in [8].
1.3. Mesh-under and Route-over Concept and Behavior
In 6LoWPAN network context, often the link-layer mesh routing
mechanism for carrying IP packets as a data message is referred as
"mesh-under" while routing/forwarding packets using IP-layer
addresses are referred as "route-over". The difference between mesh-
under and route-over networks is similar to a bridged-network and IP-
Chakrabarti & Nordmark Expires September 2, 2010 [Page 4]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
routing network in the Ethernet. Thus, in a mesh-under network all
nodes are considered part of an IPv6 subnet when a 6LoWPAN network is
considered as one IPv6 subnet served by one or more 6LoWPAN border
routers (6LBR). The 6LBR could also be a gateway to the legacy IPv4
or IPv6 network.
In a route-over network, there are multiple IPv6 subnets connecting
to each other in a 6LoWPAN network. However, unlike fixed IP
networks, these subnet members may be changing due to the nature of
the low-power and lossy behavior of wireless LoWPANs. Thus a route-
over network is almost always a flexible set of mesh networks. The
design considerations are based on the above properties. The
optimized 6LoWPAN neighbor discovery are applicable to both "mesh-
under" and "route-over" implementations. However, in "route-over"
networks, we like to define two types of routers - 6LoWPAN border
Routers(6LBR) and 6LoWPAN-routers(6LR). 6LoWPAN border Routers sit at
the boundary of the 6LoWPAN and the backbone network while 6LoWPAN-
routers are inside the 6LoWPAN network and they can not communicate
to a different network routers directly. The 6LoWPAN-routers are
assumed to be running a routing protocol. In "route-over"
configuration, the hosts are unable to take part in routing and
forwarding packets and they are acting as simple IPv6 hosts.
These neighbor discovery optimizations for "mesh-under" configuration
where the 6LBR is acting as the IPv6 router where all the hosts in
6LoWPAN are part of one subnet and they are only one IP hop away and
no 6LR concept exist in "mesh-under" topology. Thus, the IPv6 packet
is carried as the data via a link-layer mesh routing protocol.
When "route-over" configuration is used, the IPv6 Neighbor Discovery
operation takes place between the requesting node and the 6LRs or
6LBRs. The 6LR nodes are able to send and receive Router
Advertisements, Router Solicitations as well as forward and route
IPv6 packets. The packet forwarding happens at the routing layer.
With "route-over" there is a need to allow a host to attach to
different 6LRs over time (e.g., to handle changes in the radio
conditions) while the host keeps the same IPv6 addresses. Thus one
(or more) subnet prefixes (see [8]) should be assigned to the
6LoWPAN. This implies that a 6LRs need to reliably know which IP
addresses are directly reachable from that particular 6LR; this
information will be used by the routing protocol that is used by the
6LRs and 6LBRs.
This document assumes that an implementation will have configuration
knobs to determine whether it is running in "mesh-under" mode or
"route-over" mode if the implementation supports both mechanisms.
Chakrabarti & Nordmark Expires September 2, 2010 [Page 5]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
2. Definition Of Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
6LoWPAN-link:
It is a wireless link determined by single hop reachability of
neighboring nodes.
6LoWPAN-router (6LR):
These are the intermediate routers in the 6LoWPAN network who can
communicate with other 6LoWPAN-routers in the same 6LoWPAN
network. These are also the immediate first-hop router for
6LoWPAN hosts. 6LoWPAN routers are present only in "route-over"
topologies.
6LoWPAN Border Router (6LBR):
It is a border router located at the junction of separate 6LoWPAN
networks or between a 6LoWPAN network and a non-6LoWPAN IP
network. There may be one or more 6LBR at the 6LoWPAN network
border. 6LBR is the responsible authority for IPv6 Prefix
propagation for the 6LoWPAN network it is serving. An isolated
6LoWPAN network also contains a 6LBR in the network, which
provides the prefix(es) for the isolated network.
Host:
A host in 6LoWPAN network is considered a IPv6 node without
routing and forwarding capability.
Mesh-under:
It is a configuration topology where 6LoWPAN hosts are connected
to the 6LBR through a mesh using Layer-2 forwarding. Thus in a
"mesh-under" configuration all IPv6 hosts in a 6LoWPAN network are
only one IP hop away from the 6LBR. This topology simulates the
typical IP-subnet topology with one router with multiple nodes in
the same subnet.
Route-over:
It is a configuration topology where 6LoWPAN hosts are connected
to the 6LBR through the use of intermediate Layer-3 (IP) routing.
Here hosts are typically multiple IP hops away from the 6LBR. The
Route-over topology typically consists of a 6LBR, a set of 6LRs
and possibly some hosts.
3. Assumptions
o 6LBRs are capable of routing/forwarding packets between 6LoWPAN
networks and other networks. The 6LBRs are responsible for
assigning one or more /64 IPv6 prefix to the 6LoWPAN network. It
advertises this/these IPv6 prefixes to the 6LoWPAN network.
Chakrabarti & Nordmark Expires September 2, 2010 [Page 6]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
o The 6LR that are in range of 6LBR use the prefixes advertised by
the the 6LBR. The 6LRs store these prefixes and use them for
forming its own global autoconfigured addresses. When sending
Router Advertisements, 6LRs advertise the same prefix(es). A
6LoWPAN-router SHOULD relay any prefix related options received
from its parent router during Neighbor Discovery procedure.
o The 6LoWPAN hosts either autoconfigure their IPv6 address(es)
based on the prefix(es) received in the Router Advertisement, or
it uses DHCP service for address assignment. It can receive
multiple Router Advertisements and should be able to configure
multiple default routers as its immediate nexthop. The 6LoWPAN
hosts always send their packets to the default router. If one
default router becomes unavailable, it chooses the next available
default router. This behavior is the same as standard IPv6 hosts
behavior.
o In an isolated 6LoWPAN network an ULA prefix and address SHOULD be
generated by the 6LBR. Thus in this topology, 6LBR prefix is
formed according to [11].
o The Prefix Options send by 6LBRs and 6LRs do not set the 'L' flag.
This is necessary to get the hosts to send packets to (one of)
their default router(s).
o The local mobility or mobility within a 6LoWPAN is supported in
this solution by using the same IPv6 prefix across the 6LoWPAN.
4. Applicability Statement
This document aims to guide the implementors to choose an appropriate
IPv6 neighbor discovery and Address configuration procedures suitable
for a 6LoWPAN network. If the 6LoWPAN network does not have
Multicast capability at the link-layer, then it SHOULD use the
Optimized IPv6 Neighbor Discovery for the 6LoWPAN network.
This document does not specify a method for ensuring address
uniqueness across a LoWPAN. In general such a mechanism is needed
for the IPv6 addresses autoconfigured in the subnet prefix(es). In
the general case of ND we use multicast Neighbor Solicitation to
perform Duplicate Address Detection (DAD) [6] but that is both
undesirable in a 6LoWPAN due to the undesirability of multicast
packets, and insufficient in the case of "route-over" when the subnet
prefix spans several links and 6LRs.
The scope of this document is limited to addresses that are
autoconfigured based on EUI-64 based Interface-ids. For such
addresses DAD is not required. Other IPv6 addresses, including those
based on 16-bit IEEE 802.15.4 short addresses, are out of scope.
Potentially DHCPv6 can be used to allocate unique addresses for short
addresses.
Chakrabarti & Nordmark Expires September 2, 2010 [Page 7]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
5. Autoconfiguration of 6LoWPAN Addresses
The following discussion will include address auto-configuration
procedure at the IP-layer.
5.1. Address Assignment in Star Networks
In a star network, all the nodes are one hop away from the IPv6-
router and from each-other. Upon starting a node sends an IPv6 ND
[2] Router Solicitation (RS) to the All-Routers multicast address.
The 6LBR sends unicast Router Advertisement (RA) and the node
configures its IPv6 address using autoconfiguration [6]. If the
nodes are using EUI-64 style MAC address, the Duplicate Address
Detection SHOULD be skipped. The 6LBR is assumed to be the only
router in the 6LoWPAN network - thus it should use a unique id, for
example IEEE 802.15.4 PAN-ID as its subnet-id of the IPv6-address.
If the node uses a short(16-bit) MAC addresses, address assignment
through DHCP is advised.
5.2. Address Assignment in Mesh Network
In a "mesh-under" configuration, the nodes are considered one hop
away. Thus address assignment/auto-configuration happens the same
way as in Star Network configuration. However, 6LBR is acts as an
Prefix authority and initial delegator of that prefix.
In a "route-over" configuration, one or more 6LBR advertise the
global prefix(es) along with a new IPv6 Router Advertisement option
called Authoritative Router option. This option contains information
about the 6LBR IP-address and a sequence number. The next-level 6LR
receive the RA from 6LBR and store/auto-config with the advertised
prefix. The received prefix from 6LBR and the new Authoritative
Router option option are then propagated throughout the 6LoWPAN
network hop by hop. The hosts use the address prefix to configure
the address when they receive the Router Advertisements from their
respective Neighborhood 6LR.
5.3. DHCPv6 Address and Resource Allocation
DHCP address allocation procedure for 6LoWPAN is out of scope of this
document.
6. New Neighbor Discovery options
The optimized ND uses two new Neighbor Discovery options -
Authoritative Router option option and Node-lifetime option.
Chakrabarti & Nordmark Expires September 2, 2010 [Page 8]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
6.1. Authoritative Router option
The Prefix Information options originate at the 6LBRs and are
propagated by the 6LRs. Thus 6LRs receive Prefix Information options
from other 6LRs. This implies that we can't just have the most
recently received RA win. In order to be able to reliably remove
prefixes from the 6LoWPAN we need to carry information from the
authoritative 6LBR. We do that by introducing a sequence number
which the 6LRs propagate as they propagate the prefixes. When there
are multiple 6LBRs they would have a separate sequence number spaces.
Thus we need to carry the IP address of the 6LBR that created the
sequence number.
The Authoritative Router option is included in Router Advertisement
messages. It is required in "route-over" configurations.
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 = 3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 6LBR Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ 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. Always 3.
Reserved: 16-bits. This field is unused. It MUST be
initialized to zero by the sender and MUST be ignored
by the receiver.
Registration Period: 32-bit unsigned integer. The amount of time in
seconds between successive registration messages for
the same IP address.
Chakrabarti & Nordmark Expires September 2, 2010 [Page 9]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
6LBR Address: IP address of 6LBR that is authoritative for the
sequence number.
6.2. Node-lifetime option
The 6LRs need to know the set of IP addresses that are directly
reachable. This needs to be maintained as the radio reachability
changes. We introduce a Node-Lifetime option that is carried in the
unicast NS and NA messages sent by hosts. Thus it can be used on the
unicast NS messages that that a host sends as part of NUD to
determine that it can still reach a default router. This Node-
Lifetime is used by the 6LR to reliably maintain its Neighbor Cache.
The Node-lifetime is required for 6LoWPAN network for reliability and
power saving to minimize frequent need for updating Neighbor status
with the neighboring 6LR for liveliness. Thus the requested Node-
lifetime provides flexibility to the requester to receive an address
which should be usable (continue to be advertised by the 6LR in the
routing protocol etc) during its intended of sleep schedule.
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 = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type: TBD [To be allocated by the IANA.]
Length: 8-bit unsigned integer. The length of the option in
units of 8 octets. Always 1.
Reserved: 16-bits. This field is unused. It MUST be
initialized to zero by the sender and MUST be ignored
by the receiver.
Registration Lifetime: 32-bit unsigned integer. The amount of time
in seconds that the 6LR should retain the Neighbor
Cache entry for the sender of the NS/NA that includes
this option.
7. Optimized Neighbor Discovery for 6LoWPANs
The goal of having an optimized Neighbor Discovery is to basically
use regular IPv6 Neighbor Discovery [2] with some optimization for
low-power networks. The main objective is to minimize the multicast
messages and use unicast messages instead of multicast messages when
possible. Note that IPv6 use multicast messages instead of broadcast
Chakrabarti & Nordmark Expires September 2, 2010 [Page 10]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
messages. But layer-2 technologies that do not support multicast but
provides broadcast support, usually map the IP multicast messages to
L2 broadcast messages. IEEE 802.15.4 networks do this.
7.1. Operations Overview
The mandatory part of the optimized Neighbor Discovery protocol is
described here. Upon starting up, a node figures out whether it is
configured as a router or a simple host. The procedure of
determining this node behavior is local to the system and it is
implementation specific.
The use of subnet and link-local address prefixes is specified in
[8]). In this case, the link-local addresses can only reach the set
of nodes that are reachable from the sender at the time it sends a
packet. We can define that as 6LoWPAN-link.
7.2. Existing Neighbor Discovery Messages
IPv6 Neighbor Discovery [2] protocol operates with Router
Solicitation(RS), Router Advertisement(RA), Neighbor
Solicitation(NS), Neighbor Advertisement (NA), and Redirect messages,
link-layer address options, prefix options, MTU options etc., and a
set of protocol constants. Moreover, duplicate address detection
(DAD) is performed during address assignment.
The following sections describe optimizations (if any) of the above
messages of IPv6 Neighbor Discovery Protocol[2] for 6LoWPAN.
7.3. 6LoWPAN Optimized Neighbor Discovery Messages
1. Router Advertisement(RA): Periodic RAs SHOULD be avoided. Only
solicited RAs are recommended for the 6LBRs (on their 6LoWPAN
interfaces) and 6LRs. An RA MUST contain the Source Link-layer
Address option containing Router's link-layer address (this is
optional in [2]. An RA MUST carry Prefix information option
with L bit being unset, so that hosts do not multicast any NS
messages as part of address resolution. In addition to the
Prefix option the RA should carry Authoritative Router option
option generated by the 6LBR.
2. Router Solicitation(RS): Upon system startup, the node sends a
multicast or link broadcast (when multicast is not supported at
the link-layer) RS to find out the available routers in the
wireless link. An RS may be sent at other times as described in
section 6.3.7 of RFC 4861. A Router Solicitation MUST carry
Source Link-layer Address option. Since no periodic RAs are
allowed in a 6LoWPAN network, the host may restart sending
multicast RS messages after NUD declares a default router
Chakrabarti & Nordmark Expires September 2, 2010 [Page 11]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
unreachable.
3. Default Router Selection: Same as in section 6.3.6 of RFC 4861.
4. Neighbor Solicitation (NS): Neighbor solicitation is used
between the hosts and the default-router as part of NUD and
registering the host's address(es). An NS messages MUST use the
Node-lifetime option in order to accomplish the registration.
5. Neighbor Advertisement (NA): As defined in [2]
6. Redirect Messages: A router in the 6LoWPAN network may send a
Redirect message to a host. When to send the redirect message
is implementation specific; a router may be overloaded or by
some means it can determine the proximity of source and
destination and decide that they should directly talk to each
other. The host behavior is same as described in section 8.3 of
RFC 4861 [2].
7. Message Validation: Same as in RFC 4861[2]
8. MTU option: As per the RFC 4861.
9. Address Resolution: No multicast NS/NA are sent as the prefixes
are treated as off-link. Thus no address resolution is
performed at the hosts. The routers keep track of Neighbor
Solicitations with Node-Lifetime options and create a neighbor
cache of directly reachable addresses. The router also knows
the nexthop link-local address and corresponding link-layer
address when it wants to route a packet.
10. Neighbor Unreachability Detection(NUD): NUD is performed in
"forward-progress" fashion as described in section 7.3.1 of [2].
The unicast Neighbor Solicitation and Advertisement messages
sent by a host as part of NUD include the Node-Lifetime option.
7.4. Host Behavior
A 6LoWPAN host sends Router Solicitation at the system startup and
also when it suspects that one of its default routers have become
unreachable (after NUD fails). The latter part is a behavioral
change from RFC 4861 [2], since RFC 4861 assumes that when NUD fails
for a router there will be some multicast RA messages that will make
the host find out a new set of working default routers. Here we
avoid multicast RA messages completely which implies that the host
needs to send a RS after NUD fails, just as it does in the case when
the interface is reinitialized after a temporary interface failure in
section 6.3.7 in [2]. Thus in essence we treat a NUD failure for a
default router the same way as a temporary interface failure, which
seems consistent with how [2] operates on a wired network.
A host SHOULD be able to autoconfigure its IPv6 addresses and
optionally it can act as a simple DHCPv6 client.
A host always sends packets to (one of) its default router(s). This
is accomplished by the 6LBRs and 6LRs never setting the 'L' flag in
Chakrabarti & Nordmark Expires September 2, 2010 [Page 12]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
the Prefix options. A router can control the host's selection of a
default router by sending Redirect messages, however care must be
taken to ensure that that router is indeed reachable from the host.
Should this not be the case then normal operation of NUD per RFC 4861
will end up deleting the redirect.
The host is unable to forward routes or participate in a routing
protocol.
7.5. 6LBR Behavior
A 6LBR normally has multiple interfaces and connects the 6LoWPAN to
other 6LoWPAN networks or to non-6LoWPAN network(s). The 6LBR is
responsible for distributing one or more /64 prefixes to the 6LoWPAN
nodes to identify a packet belonging to the particular 6LoWPAN
network.
When the 6LBR sends a Router Advertisement it SHOULD include a
Authoritative Router option that includes its own address and a
sequence number. (The Authoritative Router option is required in the
"route-over" configuration.) Each time the information in the RA
changes (such as adding or deleting prefixes, or changing the
lifetime of the prefixes) the sequence number should be increased by
one. The 6LBR SHOULD keep the sequence number in stable storage or
otherwise ensure that after a reboot it will not reuse "old" sequence
numbers.
A 6LBR keeps a cache for all the 6LoWPAN nodes' IP addresses, created
from the routing protocol. The 6LBR may act as a DHCPv6 server for
the 6LoWPAN network as well. It does not send unsolicited Router
Advertisements on 6LoWPAN interfaces. 6LBR holds the authority of
Prefix generation and initial Prefix allocation in the 6LoWPAN
network.
7.6. 6LR Behavior
6LRs are only present in "Route-over" mesh topology. They
participate in forwarding packets in from a host to another host or
to the nexthop router. They may configure their own address based on
the /64-bit prefix(es) they receive in RAs.
A 6LR keeps a cache of neighbor information collected from the Node-
Lifetime options in Neighbor messages. This information is made
available to the routing protocol. When receiving a packet the 6LR
compares the destination against this neighbor cache. If present the
host is directly connected to the 6LR and it can forward the packet
to the host. Otherwise the packet is forwarded using the routing
protocol.
Chakrabarti & Nordmark Expires September 2, 2010 [Page 13]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
A 6LR receives Router Advertisements from 6LBRs and 6LRs and uses the
received Prefix options and Authoritative Router option to construct
the Router Advertisements it sends. The 6LR MUST ignore any RA that
does not contain an Authoritative Router option. When a RA is
received it compares the sequence number and 6LBR Address against a
cache of such information. If it has information for the 6LBR
Address and the received sequence number is less or equal to last
sequence number, then it MUST ignore the received Prefix options.
Otherwise it updates the prefixes and the sequence number to what was
received. This mechanism needs to be able to handle different 6LBRs
advertising different prefixes. Among other things that implies that
a RA sent by the 6LR can only include prefixes (and the Authoritative
Router option) originated from one of the 6LBRs.
Unlike regular routers, 6LRs send multicast RS messages once upon
startup to receive a RA message. After that they are not required to
send RS messages, since they run a routing protocol.
8. Remaining Multicast messages
With the optimizations specified above the only place where Neighbor
Discovery messages are multicast is Router Solicitations. Such
messages must be conceptually multicast, both when a host is powered
on and also when the NUD indicates that a default router is
unreachable, since the host needs to be able to find at least one new
router at that point in time.
Potentially this could be further optimized if there is some L2
mechanism to perform some form of anycast, since all that is needed
is for the host to reach at least one router. However, it isn't
known to the authors whether 6LoWPAN has an L2 anycast address can be
used to reach routers. If such an address can be used, then the RS
messages can be multicast at L3 (sent to the "all-routers" IPv6
multicast address) while being anycast at L2.
9. Security Considerations
These optimizations are not known to introduce any new threats
against Neighbor Discovery beyond what is already documented for IPv6
[RFC 3756]. However, the effect of a rogue router is more severe in
Low-power wireless network than in the network of powered systems.
The 6LoWPAN security analysis [12] discusses possible threats. The
security of 6LoWPAN Neighbor Discovery will be handled in a separate
follow-up IETF publication.
Chakrabarti & Nordmark Expires September 2, 2010 [Page 14]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
10. IANA Considerations
If this document is approved then two Neighbor Discovery option types
need to be allocated.
11. Acknowledgements
The primary idea and inspiration of this document to note different
addressing mechanism and simple ND procedures are from Geoff
Mulligan.
Also thanks to the 6LoWPAN and 6man working group members to provide
ideas on simplification. Part of the ideas are also discussed at the
IETF mailing list as a summary of base 6LoWPAN-ND requirement.
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6", RFC 4861,
September 2007.
[3] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6
Packets over IEEE 802.15.4 networks", RFC 4944, September 2007.
[4] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
Assumptions, Problem Statement and Goals", RFC 4919,
August 2007.
12.2. Informative References
[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6), Specification", RFC 2460, December 1998.
[6] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Autoconfiguration", RFC 4862, September 2007.
[7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure
Neighbor Discovery", RFC 3971, March 2005.
[8] Baccelli, E. and M. Townsley, "IP Addressing Model in Adhoc
Networks", draft-ietf-autoconf-adhoc-addr-model-02.txt (work in
Chakrabarti & Nordmark Expires September 2, 2010 [Page 15]
Internet-Draft 6LoWPAN-ND-SIMPLE March 2010
progress), December 2009.
[9] IEEE Computer Society, "IEEE Std. 802.15.4-2003", ,
October 2003.
[10] Miwakawya, S., "Requirements for Prefix Delegation", RFC 3769,
June 2004.
[11] "Unique Local IPv6 Addresses", RFC 4193.
[12] Park, D., Kim, K., Seo, E., and S. Chakrabarti, "IPv6 over Low
Power WPAN Security Analysis",
draft-daniel-6lowpan-security-analysis-02.txt (work in
progress), January 2007.
Authors' Addresses
Samita Chakrabarti
IP Infusion
1188 Arquest Street
Sunnyvale, CA
USA
Email: samitac@ipinfusion.com
Erik Nordmark
Oracle, Inc.
17 Network Circle
Menlo Park, CA 94025
USA
Email: Erik.Nordmark@Sun.COM
Chakrabarti & Nordmark Expires September 2, 2010 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 04:27:21 |