6lowpan D. Culler Internet-Draft Arch Rock Intended status: Informational G. Mulligan Expires: May 15, 2008 Proto6 JP. Vasseur Cisco November 12, 2007 Architecture for IPv6 Communication over IEEE 802.15.4 subnetworks using 6LoWPAN draft-culler-6lowpan-architecture-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 May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes the architecture incorporating IEEE 802.15.4 subnetworks utilizing the 6LoWPAN adaptation layer into the family of Internet standards. Culler, et al. Expires May 15, 2008 [Page 1] Internet-Draft 6LoWPan Architecture November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Terms used . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. PAN Organization . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Complete broadcast domain . . . . . . . . . . . . . . . . 6 5.2. Mesh Under . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Route Over . . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Routed Mesh . . . . . . . . . . . . . . . . . . . . . . . 9 6. IEEE 802.15.4 Architectural Issues . . . . . . . . . . . . . . 10 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Stateless Auto-configuration . . . . . . . . . . . . . . . 12 7.2. Link Local Well Known Multicast Addresses . . . . . . . . 13 7.3. Short Addresses . . . . . . . . . . . . . . . . . . . . . 13 7.4. Link Local Multicast . . . . . . . . . . . . . . . . . . . 14 7.5. Scopes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Normative references . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Culler, et al. Expires May 15, 2008 [Page 2] Internet-Draft 6LoWPan Architecture November 2007 1. Introduction The IEEE 802.15.4 standard [ieee802.15.4] specifies a wireless link for low power personal area networks (WPAN). This link is widely used in applications involving large numbers of embedded devices, such as instrumentation, monitoring, automated metering, home and building automation, security, machine monitoring, and open-loop control. It is also utilized in human-centered applications, including health monitoring, device interconnection, active badges, fitness, and entertainment. It differs from wireless local area networks (WLAN) in several regards: small MTU size (127 bytes), low bandwidth (250 kbps in the 2.4 GHz band, less in the lower ISM bands), short (16 bit) link addresses, in addition to the 64-bit EUID, low radio transmit power (i.e., short range) and built-in AES- 128 encryption and authentication. These elements are present in order to enable low cost implementations with reasonable packet loss rates and long-lived operation on modest power sources, especially battery powered devices. However, they present challenges for utilizing the link to carry IP packets. At the same time, the short range of IEEE 802.15.4 wireless links and the common embedding of nodes in a specific physical environment and interconnected via IEEE 802.15.4 link leads to networks where many nodes share a great deal of context. For example, often they form, collectively, a single monitoring application under a common administrative domain. In addition to being part of a common network infrastructure, with the associated address assignments, management, etc., they may be parts of a common physical infrastructure, such as a building HVAC or lighting facility. This shared context is leveraged to overcome the challenges of efficiently supporting IP on constrained devices. RFC4944 [2] defines how IPv6 [3] communication is carried efficiently in 802.15.4 frames and specifies key elements of an adaptation layer. 6LoWPAN has three primary elements: o Header Compression: RFC4944 [2] provides extensive compression of IPv6 headers by eliding fields that can be derived from the link- level information carried in the IEEE 802.15.4 frame based on simple assumptions of shared context. IPv6 link-local and statelessly auto-configured addresses can be elided for intra-PAN communication, since they can be derived from either the short (2 octet) or long (8 octet) link level source and destination addresses. Global addresses that utilize a PAN-wide prefix could similarly be compressed. UDP transport headers are compressed for a limited set of ports. o Fragmentation: Because IPv6 mandates that the link layer be capable of supporting minimum MTU of 1280 bytes, RFC4944 [2] provides fragmentation of IPv6 packets into multiple link-level frames to accommodate the minimum MTU requirement of IPv6. Culler, et al. Expires May 15, 2008 [Page 3] Internet-Draft 6LoWPan Architecture November 2007 o Intra-PAN forwarding: 6LoWPAN accommodates subnetworks of physical extent that exceeds the radio range or for other reasons do not form a single broadcast domain. Often the physical deployment of a LoWPAN network comprises a number of nodes at points of interest in a physical space (e.g., thermal or air quality monitor points throughout a building) or attached to particular objects of interest (e.g., motor bearings, electric meters, or flow gauges). Such points do not necessarily form a fully connected broadcast domain at the link level, but do form a contiguous mesh of such links. To support a network organization in which such a mesh of devices, interconnected by means of IEEE 802.15.4 links, appears as a single IP link, the adaptation layer can carry link-level addresses for the ends of an IP hop, in addition to the link-level source and destination fields in the 802.15.4 frame used for each link hop that forms the Layer 2 path. Alternatively, following the IPv6 generalizations of the subnet concept, such a mesh can also be viewed as a multicast domain with a common prefix, in which case intra-pan routing may be accomplished by multiple IP hops, each of which may potentially be one or more Layer 2 hops. RFC4944 [2] defines how these capabilities are represented in terms of the IEEE 802.15.4 frame format. However, the implementation of those capabilities is out of the scope of that document. The dependences of adaptation layer on the specific operations defined in the IEEE 802.15.4 MAC protocol are minimal. It could potentially be implemented on essentially any MAC protocol that provided the IEEE 802.15.4 frame format. Similarly, the format does not specify how IPv6 capabilities, such as neighbor discovery, are orchestrated in order to configure the PAN to be consistent with the 6LoWPAN adaptation layer. This document provides such an operational framework. It outlines the key components of an IPv6 6LoWPAN network and how those components are composed. 2. Requirements Language 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 RFC2119 [1]. 3. Terms used PAN: Personal Area Network. A collection of contiguously connected IEEE 802.15.4 devices sharing a common PAN-ID and compatible MAC protocol such that any constituent device can potentially communicate with any other through a series of consecutive packet exchanges. Culler, et al. Expires May 15, 2008 [Page 4] Internet-Draft 6LoWPan Architecture November 2007 FFD: Full Function Device. IEEE 802.15.4 term identifying a class of device that can forward link-level packets. It also has specific role in 802.15.4 protocols that utilize superframes comprising guaranteed time slots and collision slots, including the regular transmission of beacon packets that define the temporal structure and allocation of the superframe. RFD: Reduced Function Device. IEEE 802.15.4 term identifying a class of device that cannot forward packets and can only communicate with FFDs. It has specific responsibilities in 802.15.4 protocols that utilize superframes, including powering its radio in receive mode to receive beacons and transmitting only in allocated slots. PAN-ID: IEEE 802.15.4 term defining a 8-bit field that partitions potential communication. Communication between two 802.15.4 device can occur only if they utilize a common PAN-ID. MTU: Maximum Transmission Unit MAC: Media Access Control CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance ISM: The industrial, scientific and medical (ISM) radio bands were originally reserved for industrial, scientific and medical purposes other than communications. Mesh Under: Route Over: 4. Background IEEE 802.15.4 2003 radios units are typically connected to or integrated in microcontroller devices, which have limited memory capacity and processing bandwidth, although they may be connected to more capable microprocessors. The IEEE specification defines sixteen (16) communication channels in the 2.4 GHz band at a bandwidth of 250 kbps and 10 channels in 915 MHz band at 40 kpbs and one channel in the 868 MHz band. (IEEE802.15.4-2006 increases the bandwidth of sub 1GHz bands by optionally allowing alternative modulation mechanisms.) The frame consists of a preamble plus a length octet, frame header, payload and check code. The maximum packet length from the length octet to check code is 128 octets, inclusive. The MTU is limited to ensure that reasonable packet receive rates (PRR) can be obtained on cost-effective implementations that have non-negligible bit-error rates (BER). It also reflects the limited memory for buffering and routing structures that are expected to be present on microcontroller class devices. 6LoWPAN specifically addresses the small MTU and avoids placing any potentially heavy memory requirements on the nodes. IEEE 802.15.4 provides a rich set of mechanisms for various aspects of media arbitration, packet forwarding, addressing, and power Culler, et al. Expires May 15, 2008 [Page 5] Internet-Draft 6LoWPan Architecture November 2007 management. Mechanisms are defined for both CSMA and TDMA media access protocols, as well as hybrids that utilize a superframe structure. These are intended to mediate potential collisions due to multiple overlapping transmissions in a localized geographic area. However, low-power operation requires additional mechanisms to place the radio into sleep or idle modes when no receptions are to occur. Many such schemes can be supported by the MAC, including beacon-based coordination among FFDs and RFDs. In practice, most PANs utilize simpler mechanisms that provide media arbitration and power management but do not use the specific capabilities of FFDs or the superframe structure defined in the IEEE 802.15.4 specification [IEEE802.15.4]. Many utilize a backbone of line powered forwarding devices (FFDs) supporting leaf nodes (RFDs) that turn off their radios much of the time. Others utilize centralized or localized formation of communication schedules, orchestrated using standard data frames, to duty-cycle low power forwarding nodes. Still others utilize transmission of wakeup packets in advance of payload exchanges and sampled listening to detect an impending transmission. Some MAC protocols use a single channel throughout the PAN, while others alternate among multiple channels for greater frequency diversity than is provided by the DSSS coding. Some utilize the link level acknowledgment support specified by IEEE 802.15.4, others disable acknowledgments, while others generate customized acknowledgments as data frames. RFC 4944 [2] defines how IPv6 communication is carried in IEEE 802.15.4 frames and assumes mutually compatible link protocols to transport those frames. However, it does not stipulate which such link protocol is utilized. It is potentially usable across a wide range of such protocols. Obviously, interoperability is limited by the compatibility of the underlying link protocols, even when identical frame formats are utilized. 5. PAN Organization A spectrum of topologies are in existence for the PAN, ranging from a conventional link that comprises a single complete broadcast domain to ones that require multihop communication within the PAN. Here we outline the range of topologies to establish a basis for how the broader aspects of the IP architecture are supported within the 6LoWPAN setting. 5.1. Complete broadcast domain The simplest organizational of a LoWPAN is one that forms a single complete broadcast domain. This case is particularly useful for establishing how IPv6 concepts are represented in a 802.15.4 setting, Culler, et al. Expires May 15, 2008 [Page 6] Internet-Draft 6LoWPan Architecture November 2007 while the PAN behaves most like a conventional IP link. The link local scope is identical to the Layer 2 PAN. To function as a single broadcast domain all the hosts in the PAN must be in sufficiently close physical proximity that each is in range of the others, and they share a common IEEE 802.15.4 PAN ID. Furthermore, the underlying data link layer must utilize IEEE 802.15.4 channels so that a transmission by any one may be received by all others, the power management protocol must allows such reception to occur, and the MAC protocol must be compatible. Such is the case, for example, if all the hosts are on a single channel, continuously powered, and utilizing a simple CSMA MAC. Note that a large physical extent is not the only factor that undermines the single broadcast domain behavior, other aspects of the link management protocol may as well. 6LoWPAN does not dictate a particular link management protocol. Regardless of the link management protocol, it defines how the link frame format is used to carry compressed and conventional IPv6 packets. 5.2. Mesh Under Where the LoWPAN forms only a partial broadcast domain, some measures must be taken to allow it to function as an IP link. A Mesh Under organization seeks to mask the lack of full broadcast by transparently forwarding packets within the PAN. The most common case is where the physical extent is such that not all nodes are within radio range of all others. Assuming compatible link protocols, a transmission by a node is received by the subset of nodes that are in physical proximity. Power management or frequency hopping strategies may further restrict this link level single hop neighborhood. Nodes that are in very close physical proximity may fail to receive a transmission if their radio is not powered on when the transmission occurs of if a different channel is selected at that time. For communication directed to a particular link address, either EUID64 or SA16, a neighboring node must retransmit the packet to move it closer to the destination. As multiple layer 2 hops are required to accomplish a single IP hop, this organization is termed Mesh Under. If the destination is the link broadcast address, neighboring nodes must retransmit the packet until it is disseminated to all nodes in the PAN. Such PAN-wide broadcasts are logically a flood, although sophisticated retransmission scheduling or selective retransmission may be used to implement it effectively. As such, each node will typically receive multiple packets for the same logical broadcast and must suppress repeated retransmissions for the flood to terminate. Culler, et al. Expires May 15, 2008 [Page 7] Internet-Draft 6LoWPan Architecture November 2007 6LoWPAN introduces the concept of Originator and Final Address to describe the source and destination nodes of a single IP hop within the PAN. These addresses are carried in the mesh subheader. If the IP hop is accomplished by a single link layer transmission, the link source address is the same as Originator Address and the link destination address is the same as Final Address. Where multiple link hops are required, Originator Address is the link source address of the first and Final Address is the link destination address of the last. The 802.15.4 frame carries the link hop Source and Destination addresses. Logically, an IP hop in 6LoWPAN always traverses from the link Originator address to the link Final address, and in the case that this is accomplished in a single link layer transmission the Originator is identical to the Source and the Final is identical to the Destination, thus the mesh header is elided. To support dissemination to all nodes in the PAN, the LOWPAN_BC0 subheader carries a sequence number which facilitates duplicate detection and termination of the flood. RFC4944 defines the field in the frame used for detecting the duplicates that are potentially received as a result of multiple predecessors in the flood, multiple siblings, or multiple decendents. However, it does not define the particular retransmission policy, scheduling, or suppression. Where the LoWPAN is a stub network, and not a transit network, in a Mesh Under organization, IP routing is not required within the LoWPAN. It behaves likes a conventional subnet with all nodes appearing to be a single IP hope from the entry or exit device(s). Routing is involved in entering or exiting the PAN through devices with multiple interfaces. The 6LoWPAN mesh header assumes that carrying the Originator and Final link addresses is sufficient to determine the forwarding action at each layer two hop. In can be assumed that mesh tables are configured and maintained much like routing tables, but all actions are carried out using link layer packet exchanges. The protocols to enable mesh under forwarding are not defined in 6LoWPAN, but are implementable within 6LoWPAN and several have been proposed [Dymo, Load, DymoLo, Tymo]. It is expected that many of the capabilities utilized for IP routing, such as topology determination, probing, echo, neighbor discovery, unreachability detection, route repair, and path optimization will need to be established and standardized for use within the 6LoWPAN link for independently implemented interoperable Mesh Under forwarding to be demonstrated. Culler, et al. Expires May 15, 2008 [Page 8] Internet-Draft 6LoWPan Architecture November 2007 5.3. Route Over Alternatively, a LoWPAN may be organized in a manner that allows multiple broadcast domains in the logical IP subnet. The simplest case is the extreme point where each individual node defines a broadcast domain and thereby an IP link. In this case, no link layer measures are taken to mask the partial broadcast nature of the LoPAN. Instead the LoWPAN forms a collection of overlapping link local scopes, each of which are 1-1 with a link layer broadcast domain. Each link layer hop is an IP hop. IP routing supports the forwarding of packets between such links. Such forwarding utilizes IP routing tables and IPv6 hop-by-hop options. This organization relies heavily on the IPv6 generalization of subnet to multicast group(s). Typically, the PAN will be contained in one or more common prefix and will behave as a subnet. The same series of retransmissions from the same physical nodes are required to communicate information from a given source to a given set of destinations. The distinction lies in how those forwarding actions are determined and how routing is established. In Mesh Under, inter-PAN routing and forwarding is performed at the link layer using information in the 802.15.4 frame or the 6LoWPAN header. In Route Over, it is performed at the IP layer using the additional, encapsulated IP header. The 6LoWPAN adaptation layer establishes a direct mapping between the frame header and the IP header, so Router Over can utilize the link Source and Destination addresses as a compact form of the IP address, but also has access to routing options, ICMP actions, and so on, which are logically at the next layer. IP routing within the LoWPAN may be used to cross link-defined broadcast domains, such as distinct PAN-IDs or incompatible channel allocation, channel scheduling, or MAC protocols. The router node has an interface in each domain, even though they utilize the same physical medium, the stacks are distinct. Although 6LoWPAN only deals with the transmission of IPv6 packets over IEEE 802.15.4. links, IP routing can be used to interconnect devices by means of a variety of Layer 1/2 protocols. 5.4. Routed Mesh In general, Mesh Under and Route Over can be combined in a hybrid organization. IP routing occurs between meshed links, such as in single hop broadcast domains whereas the mesh under function is responsible for relaying packets within portions of the LoPAN emulating the IP link as a single broadcast domain. Note that such a Culler, et al. Expires May 15, 2008 [Page 9] Internet-Draft 6LoWPan Architecture November 2007 hybrid approach involving packet routing and forwarding at layer 2 and layer 3 is likely to lead to routing inconsistency because, the layer 2 path selection process is opaque to the layer 3 routing component, thus not allowing for optimal end to end path selection, and layer 2 is oblivious to routing associated with ingress and egress to the LoPAN. At the same time, Layer 3 routing within the LoPAN is likely to need to be more cognizant of link layer phenomena, such as transient link fading due to environmental factors that are independent of contention, than is typical. Multi-layer recovery presents additional concerns because a network element failure may be handled at multiple layers. In some cases the layer 2 path may be recomputed by the Mesh Under component whereas in other cases such path recovery may only be performed by the Router Over component. In situations where fast recovery is needed (e.g. Industrial process application such "Safety: Class 0: Emergency action") the adoption of a multi-layer recovery technique is very challenging. Indeed, the most common approach consisting of adopting a timer-based approach is cumbersome and implies unnecessary delays when the failure cannot be restored by the upper layer. 6. IEEE 802.15.4 Architectural Issues IEEE 802.15.4 links present a number of pragmatic issues that have significant architectural impact, beyond the small MTU, dual addressing, and short communication range addressed directly in the 6LoWPAN format. Some of these were touched on briefly in the discussion above. Collections of nodes that communicate must share a common 16-bit PAN_ID. Packets arriving at a node that do not match the PAN_ID are discarded. The logical links associated with distinct PAN_ID are not entirely isolated as they all participate in broadcast PAN ID. Generally, nodes with distinct PAN_IDs will not be in a common broadcast domain at the link level, regardless of physical proximity. The 6LoWPAN format does not explicitly define a position on the use of PAN_ID; it is expected that a single 6LoWPAN IP link will share a common PAN_ID. If this were not the case, retransmissions would be required to cross PAN_IDs in addition to those required to reach nodes beyond the local link physical connectivity. The PAN_ID limits the scope of the link. Whether organized as a single physical broadcast domain, mesh under, or route over, crossing PAN_IDs can be accomplished as an IP hop, much as routing might be performed among distinct SSIDs in 802.11 or some bridging option must be employed. Explicitly, the PAN_ID appears in the formation of an Autoconf IP Culler, et al. Expires May 15, 2008 [Page 10] Internet-Draft 6LoWPan Architecture November 2007 address from the IEEE 802.1.4 16-bit short address in order to make IP addresses for a given short address on different PAN-IDs distinct. Since the PAN_IDs must match for communication to occur over 802.15.4, any completion of the IP address that is unique to the link would be sufficient. The IEEE 802.15.4-2003 specification defines 16 communication channels in the 2.4 GHz region at a bandwidth of 250 kbps, 10 channels in 915 MHz band at 40 kpbs and one channel in the 868 MHz band. Typically a node is configured to transmit or receive on a single channel at a time, and nodes on distinct channels cannot communicate regardless of physical proximity. 802.15.4 channels are relatively narrow, considerably narrower than 802.11 channels, for example, so some link management protocols utilize a channel hopping schedule over multiple channels to increase the frequency diversity. The IEEE 802.15.4 specification does not standardize the use of such multiple channels or define management protocols to establish and maintain such hopping schedules. The IEEE specification defines a MAC protocol for use in star and mesh configurations. It identifies two classes of devices, FFDs and RFDs and associated power management mechanisms. RFDs can only communicate with FFDs, so PANs are expected to form clusters with FFDs as the cluster heads and to coordinate their associated RFDs. A superframe protocol is defined contention slots. With short range (low transmit power) radios, power consumption is dominated by the controller and back end, rather than the amplifier, so the power consumption is roughly the same whether the device is transmitting, receiving, or just powered on ready to receive. RFDs are intended to power their radios in receive mode during beacon slots to maintain time synchronization with their FFD and to be allocated communication slots. No power management is defined for FFD to FFD communication. Many commercial implementations and industrial standards built on 802.15.4 forego the power management mechanisms defined in the specification and utilize only a small subset of the MAC features. Many utilize a powered backbone with unscheduled duty cycling of leaf nodes. Others use sampled listening techniques to wake up for eminent transmissions, while still others use network wide time slotting. Thus, while 6LoWPAN is defined in terms of the 802.15.4 frame format, it avoids requiring particular features of the MAC. The quality of the wireless link between any pair of nodes is a complicated, time varying function of the transmission signal strength, the receive sensitivity, path loss due to distance and environmental factors, multipath effects, interference, collisions, and other sources of noise. Even nodes in very close proximity may experience several percent packet loss rates. Packet receive rates of 70-90% are not uncommon - significantly less than in most current Culler, et al. Expires May 15, 2008 [Page 11] Internet-Draft 6LoWPan Architecture November 2007 Internet link. Thus, link level error detection and retransmission schemes are typically needed to make the 15.4 link suitable for best effort delivery [cite 99% RFC], especially if multiple IEEE 802.15.4 hops are involved. In addition, the ability to select among multiple candidate receivers at intermediate hops is very beneficial to improve reliability and efficiency. Therefore, visibility into detailed link behavior is typically required by the routing component (mesh under or route over). In many PAN applications, there is significant mobility of devices within the PAN, giving rise to additional time varying connectivity relationships, in addition to the variation induced by changing environmental factors. This is not IP mobility in the traditional sense, as node may remain in close physical proximity and be connected within the PAN. However, if IP routing is utilized, such variations require the routing components to adapt to underlying changes in the connectivity topology. Similar adaptation is required of the meshing components to adapt to changes in the topology of connectivity. Finally, 6LoWPAN stacks will, in many cases, be implemented on microcontrollers with very modest RAM capacity. Thus, in addition to an explicitly small MTU, it is advantageous to be able to utilize small packet buffers, reassembly buffers, and tables. Measures to compress headers also reduce the memory requirements imposed by the associated packets in the node. Given this background of issues, the remainder of this document outlines how the components of an IPv6 subnet are realized within the 6LoWPAN Architecture. 7. Addressing RFC 4944 defines packet formats that support a mapping between the two forms of link layer addresses and certain IP addresses for the node. 7.1. Stateless Auto-configuration Each host generates a Link Local IPv6 Unicast Address from its IEEE 802.15.4 EUID64 of the form FE80::EUID64/10. The host is not required to run a Duplicate Address Detection (DAD) RFC 2462 [4] process for this to be a validated address. When this address is utilized as an IP source or destination address it will be elided via HC1 [2]. Stateless auto-configuration using a randomly generated Interface Culler, et al. Expires May 15, 2008 [Page 12] Internet-Draft 6LoWPan Architecture November 2007 Identifier requires some additional care to manage the complexity of the neighbor cache and/or destination cache, and is discussed below. 7.2. Link Local Well Known Multicast Addresses The host, or more specifically its LoWPAN interface, implicitly joins the following multicast groups: Link Local All Nodes (FF02::1), Link Local All Routers (FF02::2), and Link Local All DHCP Agents (FF02::1:2). Starting from these basic multicast groups, each host can establish its role in the network, as described below. 7.3. Short Addresses The IEEE 802.15.4 link permits the use of 16-bit short addresses for the source or destination of a packet. These short addresses SHOULD be unique throughout the PAN. A 6LoWPAN network SHOULD provide a mechanism for establishing an IP address for each interface, in addition to the auto-configured address, that is easily translated to the short address for the host of the interface. The Format Document RFC4944 specifies that the mapping between the alternative autoconf interface identifier and the 16-bit short address as given by: 16_bit_PAN:8_zero_bits:FF:FE:8_zero_bits:16_bit_short_address. This use of the specific 48-bit pseudo-MAC and extension to 64 bits according to RFC2464 somewhat over constrains the mapping, as the PAN_ID must match in order for packets to be delivered by the link and the necessary condition is that there is a consistent mapping to and from the 16-bit short address. A more general formulation would have been to allow a random 48 bits to be utilized for the autoconf address, or even a random 64 bits, the lower 16 of which is xor'd with the short address. The mapping in RFC4944 is sufficient to accomplish this. A 6LoWPAN network should provide a means of generating unique 16 bit short addresses. Of course, this could be done manually. If the network utilizes stateful DHCPv6, the DHCP server can provide a unique short address. Stateless DHCPv6 can be used to assign short addresses, if the hostnames for the nodes in the PAN are constructed such that there is a simple mapping to unique short addresses, say by extracting the last two characters. Alternatively, if a router is present and a DHCP agent is present, the short address assignment can be performed by a remote DHCP server acting through the DHCP agent. Alternative to IP mechanisms for assigning short addresses, the IEEE 802.15.4 specification introduces the concept of a PAN coordinator that is responsible for assigning unique short addresses. If such a Culler, et al. Expires May 15, 2008 [Page 13] Internet-Draft 6LoWPan Architecture November 2007 capability is present from the link management protocol, the IPv6 autoconf address can be retrieved from the link level PAN coordinator. Such a PAN coordinator would need to be accessible over potentially multiple hops, so in the bootstrapping process most of the multihop communications capability, either mesh under or route must be operational before short addresses can be obtained. v Unique short addresses can be assigned without the use of DHCP or PAN cordinators if Duplicate Address Detection (RFC4429) is supported. A host may generate a tentative IP address associated with an arbitrary short address. It joins the Link Local Solicited Node multicast group (FF02::1:XXXX:XXXX), where XXXX:XXXX is interface ID associated with the proposed short address, and issues a Neighbor Solicitation message with an all-zero source address. Conventional DAD serves to establish the uniqueness of the short address ID. When IP communication occurs using such a canonical interface identifier associated with the unique link short address, the address can be elided using HC1 RFC4944 for the link local prefix or HC1g [HC1G-ID] for the commom global prefix. Additional IP address can be assigned to the interface as well, however, 6LoWPAN will not elide those source or destination addresses. The IEEE 802.15.4 specification allows only one 16-bit short address to be associated with given radio and current implementations only support one such identifier. 7.4. Link Local Multicast Whereas there is a natural mapping between layer 3 communication using link local IPv6 unicast addresses and the corresponding layer 2 operations on link addresses (the EUID64 or SA16 of the host providing the interface), the implementation mapping from communication on IPv6 multicast addresses to layer 2 operations is less clear. o In the case of a single broadcast domain, communication to any link local multicast address is implemented directly by transmitting with the link short broadcast address, FFFF, as the destination field. o The same action is taken in the Route Over design, although the link local scope may include only a portion of the PAN. o In a Mesh Under design communication to any link local multicast address requires dissemination to all nodes in the PAN. If the the LOWPAN_BC0 in RFC4944 is used to reference the multicast group, every host in the PAN will receive the packet and those not within the group will need to discard it. If this mechanism is not used, some other means of dissemination and duplication suppression is needed. In all cases, HC1 compression is able to elide the link local IP Culler, et al. Expires May 15, 2008 [Page 14] Internet-Draft 6LoWPan Architecture November 2007 source address, but the link local multicast address must be carried in line in order to represent the scope in the prefix (FF01) and the group in the interface identifier (e.g., 1 for all nodes). HC1g defines a 16-bit short address form (section 4) for common multicast group addresses containing a 3-bit range identifier, 4-bit scope, and 9-bit mapped group identifier, so most of the 128-bit multicast address can be elided. However, HC1g does not permit the IP source address to be elided if it utilizes the link local prefix. (This could be fixed by providing the link local variant of the HC1g prefix, say HC1l, but none has yet been proposed.] 7.5. Scopes The primary difference in the three basic LoWPAN topologies is the scope of link local communication. In the single broadcast domain, it has the conventional meaning &mdash the entire PAN which is identical to the set of nodes that are reached by a transmission from any node. If the PAN is not a single broadcast domain and Route Over is employed, a similar link local scope is defined for each node, but they are not identical. If the PAN is not a single broadcast domain and Mesh Under is employed, the link local scope is defined to be the entire PAN and multiple mesh hops are required to implement operation of this scope. 7.6. Routing In order to communicate with hosts external to the PAN, a router must be present in the PAN and hosts within the PAN must be assigned a routable prefix, i.e., a prefix of global scope. Such routing ability does not imply that the PAN is connected to the Internet, it may be an isolated network, on an intra-net or inter-network within administrative boundaries. IPv6 defines two scopes &mdash link local for use when no router is present or known to be present and global. Conventional ICMPv6 mechanism (or manual actions) are utilized to perform the assignment. Routers announce their presence with Router Advertisements. Hosts discover routers by issuing Router Solicitations to the Link Local All Routers multicast address. The Interface Identifier produced by stateless autoconf can be utilized to provide a globally routable address. Stateless DHCPv6 can associate a convenient hostname with the IPv6 address and stateful DHCPv6 can be used to assign global IPv6 addresses as desired. In either case, DNS can be used to register the hostname to IP address mapping. With HC1 header compression, such global IPv6 addresses for interfaces within the PAN will be carried in line, even if they utilize the cannonical interface identifiers, because they do not carry the link local prefix. Culler, et al. Expires May 15, 2008 [Page 15] Internet-Draft 6LoWPan Architecture November 2007 Common global prefix. IPv6 addresses contain a global routing prefix, subnet ID, and Interface ID. A 6LoWPAN network is typically contained within a subnet. Where a router is present in the 6LoWPAN network, it is natural to elide the global routing prefix and subnet ID, i.e., the prefix, that is used throughout the PAN. Although an interface can have multiple IP addresses, either due to multiple interface identifiers or multiple prefixes, by establishing a canonical prefix, in addition to the two canonical interface indentifiers, the prefix portions of IP source and destination addresses can be elided using HC1g. Such addresses can be utilized for intra-PAN communication as well, even though such communication may not traverse any router, as long as there is some means, manual or automated, for establishing the prefix. Typically, such a prefix is established by the Router Advertisement. Stateful configuration allows DHCPv6 to provide such a prefix with the IP addresses it assigns. If no router is present, the prefix is essentially arbitrary. Communication to the common multicast group address using the common global prefix for the source address using HC1g per destination multicast address to be elided. For example, a Neighbor Solicitation sent to the Link Local All Nodes address is expected to result in a solicited Neighbor Advertisement from each of the hosts on the PAN destined for the interface that sent the solicitation. Unsolicited Neighbor Advertisements are typically sent to the Link Local All Nodes address, as are Router Advertisements. A Router Solicitation is typically sent to the Link Local All Routers address. If no routers are present there will be no response. If stateless or stateful DHCP is used to establish hostnames, IP addresses, or other configuration parameters, the Link Local ALL DHCP Agents is utilized. In practice, where LoWPAN networks consist of many hosts with limited network bandwidth and even more limited energy resources, such PAN- wide solicitations should be kept to a minimum. 8. Normative references [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Culler, et al. Expires May 15, 2008 [Page 16] Internet-Draft 6LoWPan Architecture November 2007 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. Authors' Addresses David Culler Arch Rock San Francisco, CA USA Phone: Email: dculler@archrock.com Geoff Mulligan Proto6 Colorado Springs, CO 80920 USA Phone: 719.593.2992 Email: geoff@proto6.com JP Vasseur Cisco USA Phone: Email: Culler, et al. Expires May 15, 2008 [Page 17] Internet-Draft 6LoWPan Architecture November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Culler, et al. Expires May 15, 2008 [Page 18]