Network Working Group K. Kim, Ed. Internet-Draft S. Shams Intended status: Standards Track picosNet Corp/Ajou Univ. Expires: January 16, 2009 S. Yoo Ajou University S. Park, Ed. SAMSUNG Electronics G. Mulligan July 15, 2008 Commissioning in 6LoWPAN draft-6lowpan-commissioning-02.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 January 15, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The commisioning process defines the startup procedure executed by any 6LoWPAN device. This document defines the startup procedure that should be followed by a 6LoWPAN device in any open or secured network. Kim, Ed., et al. Expires January 16, 2009 [Page 1] Internet-Draft Commissioning in 6LoWPAN July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Resetting the device . . . . . . . . . . . . . . . . . . . 6 3.2. Scanning through channels . . . . . . . . . . . . . . . . 6 3.3. LoWPAN BootStrapping Mechanism . . . . . . . . . . . . . . 6 3.3.1. LoWPAN BootStrapping Protocol message format . . . . . 6 3.3.2. LoWPAN Bootstrapping Information Base . . . . . . . . 8 3.3.3. LBA discovering phase . . . . . . . . . . . . . . . . 9 3.3.4. LoWPAN Bootstrapping Protocol (LBP) . . . . . . . . . 10 3.3.5. Bootstrapping in open 6LoWPAN: . . . . . . . . . . . . 10 3.3.6. LBP in secured 6LoWPAN . . . . . . . . . . . . . . . . 11 3.3.7. Role of Entities in LBP: . . . . . . . . . . . . . . . 12 3.4. Assigning the short address . . . . . . . . . . . . . . . 14 3.5. Obtaining IPv6 address . . . . . . . . . . . . . . . . . . 15 3.6. Configuration Parameters . . . . . . . . . . . . . . . . . 17 4. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Kim, Ed., et al. Expires January 16, 2009 [Page 2] Internet-Draft Commissioning in 6LoWPAN July 2008 1. Introduction 6LoWPAN is a low-power wireless personal area network(LoWPAN) which is comprised of the IEEE 802.15.4-2006 standard [ieee802.15.4] devices. One of the design goal for 6LoWPAN architecture is to ensure minimum human intervention during provisioning a sensor device in a PAN. However, a 6LoWPAN device requires a set of pre-deployed information, called LoWPAN Information Base(LIB), to find the right PAN,to successfully join with the PAN, and to establish communication within the PAN. A device needs specific procedure, what we named as a Bootstrapping protocol for 6LoWPAN device, to collect those information from LoWPAN Bootstrapping Server (LBS) and to start communication in a PAN. This procedure needs to be well defined for interoperability of devices from different vendors. This procedure involves extracting LIB, security credentials,becoming part of existing network, obtaining 16-bit short address, and IP settings. 2. Terminology Active Scan An active scan is used by a device to locate all coordinators transmitting beacon frames within its personal operating space, which is provided by IEEE 802.15.4. It requests other devices to transmit the beacon frame. Association An IEEE 802.15.4 device can be assigned a dynamic 16 bit short address during an association operation with a neighbor device (or router) which is also called as the parent device. After getting the short address, a device can communicate with its parent or child by using only the assigned short address. Coordinator A full-function device (FFD) which is the principal controller of a 6LoWPAN. It is also called as PAN coordinator. It MAY initiate the synchronization of the entire 6LoWPAN by transmitting beacons. ED Scan An ED scan allows a device to obtain a measure of the peak energy in each requested channel, which is provided by IEEE 802.15.4. Full Function Device (FFD) A device implementing the complete protocol set of IEEE 802.15.4. It is capable of operating as a router (multi-hop packet forwarding) for its associated neighbors. Kim, Ed., et al. Expires January 16, 2009 [Page 3] Internet-Draft Commissioning in 6LoWPAN July 2008 Neighbor Table A table which has the information of neighbor devices in a personal operating space. LoWPAN Bootstrapping Information Base (LIB) A set of pre-deployed information that is necessary for a particular 6LoWPAN device to find the desired PAN and to successfully join with the PAN. We categorize this information into two groups; PAN Specific Information (PSI), which is the same for every device in a PAN, (for example, PAN ID), and Device Specific Information(DSI), which is specific for each particular node (for example short address). PSI : PAN Specific Information Inside the LIB, a portion of information, called PSI, is the same for every device in the target PAN. For example, PAN_ID, PAN_Type, etc. DSI : Device Specific Information Inside the LIB, other than PSI, there is some information that may vary from device to device. For example, Role_of_Device, Short_Addr, etc. LoWPAN BootStrapping Device (LBD) LBD is a device that is needed to be deployed in the target network. LBD is assumed to have no priori information about the 6LoWPAN within which it is going to join. The only information it has is the EUI-64 address and a "Join key" (in case of secured PAN). LoWPAN BootStrapping Server (LBS) An entity that contains LIB of each device to be bootstrapped. It indexes this information with the EUI-64 address of each 6LoWPAN device. LBS has two modules in it; Network management & Acccount Module (NAM) and Authentication Module (AM). NAM keeps track of the LIB of each device indexed by EUI-64 address whereas AM participates in authentication process on behalf of LBD using LBD's 'Authentication credentials'. Based on the 'LBP Message', LBS varifies LBD with the help of Authentication server (in case of secured PAN) and sends ACCEPT message with necessary information otherwise it sends DECLINE message. In the case of secured PAN, LBS initiates authentication mechanism issuing Authentication request into appropriate format that is acceptable by particular authentication server. Any challenge or reply message from the Authentication server is encapsulated in the 'LIB message' by LBS and is sent back to the LBD through Kim, Ed., et al. Expires January 16, 2009 [Page 4] Internet-Draft Commissioning in 6LoWPAN July 2008 LBA. LoWPAN BootStrapping Agent (LBA) A FFD that has already joined in the PAN and thus, it is already a member of the PAN. It is also a neighbor of a new LBD, and thus it helps the bootstrapping LBD by receiving LBP message from LBD and forwarding it to LBS. Open 6LoWPAN An open 6LoWPAN is a PAN where any device is welcomed. Close 6LoWPAN A close 6LoWPAN is a PAN where only pre-defined set of devices are allowed to join based on their EUI-64 address. This account is managed by LBS. If close 6LoWPAN is secured, it is called secured 6LoWPAN. Secured 6LoWPAN Secured 6LoWPAN is a Close 6LoWPAN that also maintains secured messange exchange in the PAN. PAN Id The 16 bit 6LoWPAN identifier which is administratively assigned to a 6LoWPAN and is unique within the PAN. Passive Scan A passive scan, like an active scan, is used by an FFD to locate all coordinators transmitting beacon frames within its personal operating space, which is provided by IEEE 802.15.4. The difference is that the passive scan is a receive-only operation and does not request the beacon frame. Personal Operating Space (POS) The area within the reception range of the wireless transmission of a IEEE 802.15.4 packet. Reduced Function Device (RFD) A IEEE 802.15.4 device of 6LoWPAN which does not have the functionality of the router. That is, it can not forward IPv6 packets to the next hop device. It can only be the end device of 6LoWPAN. Short Address A 16 bit address dynamically assigned to a device from the PAN. Kim, Ed., et al. Expires January 16, 2009 [Page 5] Internet-Draft Commissioning in 6LoWPAN July 2008 2.1. Requirements notation 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]. 3. Bootstrapping Bootstrapping is defined as collecting LIB from LBS, obtaining security credentials (optional), associating with the right PAN, obtaining 16-bit short address (optional), and constructing IPv6 address using IPv6 prefix. Specifically, this includes the process of starting the network, associating with other nodes, obtaining the unique IPv6 address, and constructing security credentials for 6LoWPAN. 3.1. Resetting the device After the device is started, it first performs a MAC layer reset. 3.2. Scanning through channels During this phase, functions supported by 802.15.4 are used for scanning channels. Appendix (A.1) shows the scanning process in 802.15.4. For getting the information of other devices within POS, the device should perform scan. The device can use either an active scan or a passive scan. During scanning procedure, the device receive beacon frames from other devices. 3.3. LoWPAN BootStrapping Mechanism This protocol defines mechanism to extract LIB from currently unknown LBS and also defines a message format for LIB message exchange. In this protocol, LBD exchanges LBP message with LBS through its one hop neighbor LBA. So, at the beginning of LBP, it needs to find an LBA using 'LBA discovery phase' that is described in section 3.3.2 3.3.1. LoWPAN BootStrapping Protocol message format In this section we define a message format which is necessary for LBP. Kim, Ed., et al. Expires January 16, 2009 [Page 6] Internet-Draft Commissioning in 6LoWPAN July 2008 3.3.1.1. LBP message 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Code| Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- A_LBD -+ | | +- (EUI-64 Address -+ | of | +- LoWPAN Bootstrapping Device)-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bootstrapping Data ... +-+-+-+-+-+-+-+-+ T : Type of message It defines message type. value '0' represents 'Message from LBD' and '1' represents 'Message to LBD'. Code : 000, 1xx : Reserved. 001 : ACCEPTED. Authentication of LBD has been accepted. 010 : CHALLENGE. It indicates that authentication process has not been finished. Authentication server has sent some challenge that has to be replied by LBD. 011 : DECLINE. In the case of unsecured 6LoWPAN, LBS may send this code to indicate that LBD's EUI-64 address is not allowed to join the PAN.In case of secured 6LoWPAN, LBS may send this code to indicate that LBD's EUI-64 address is not allowed to join the PAN or the authentication of the LBD is failed. Seq : Sequence Number Seq identifies the number of messages transmitted by LBD. Corresponding incomming message from LBS should also have the same Seq. A_LBD : Address of Bootstrapping Device (LBD) Kim, Ed., et al. Expires January 16, 2009 [Page 7] Internet-Draft Commissioning in 6LoWPAN July 2008 64-bit EUI-64 address of LBD. Bootstrapping Data: Format of bootstrapping data is given below. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |M|L| Len | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type : 6-bit represents the ID of the attribute in LIB if 'L' bit is set. Otherwise, this field defines particular authentication type. A list of authentication mechanism and their corresponding 'Type' is TBD. M : Type of the Attribute This field defines the type of the attribute in LIB; whether it is PAN Specific Information (PSI) or Device Specific Information (DSI). 1 represents PSI and 0 represents DSI. Len : 8-bit represents the length of the value in octet. Value : This field represents the corresponding data of the type. 3.3.2. LoWPAN Bootstrapping Information Base One of the important goal of LBP is to receive a set of information from LBS by a joining LBD. This information comprises of PSI and DSI. Following table shows attribute name, attribute ID (attr_ID), purpose of the attribute and type of it. Attribute Name........Attribute ID......Attribute Description PSI/DSI Kim, Ed., et al. Expires January 16, 2009 [Page 8] Internet-Draft Commissioning in 6LoWPAN July 2008 Attribute Name Attr_ID Type Attribute Description -------------- ------- ---- ---------------------- PAN_ID 1 P This is the network identification for the default network PAN_type 2 P Secured/closed/open Address_of_LBS 3 P Address of the LBS. 0x0000 in case of no LBS. For example in open 6LoWPAN. Join_Time 4 P It specifies the time when this node should start trying to join the target PAN. Role_of_Device 5 D Agent/No_Agent Allow_LBA_To_Send_PSI 6 P This attribute allows any SF to provide GI to CD after getting the positive reply from LBS. Short_Addr 7 D 16-bit address for new device which is unique inside the PAN Short_Addr_ Distribution_ 8 P Its Value is either 0 or 1 Mechanism representing central or distributed respectively. If it is central, short address is provided by LBS itself otherwise assigning short address is Other_Device_Specific 15 D Using this attribute, a device and _Info LBS can exchange any types of data or security key required by the device. 3.3.3. LBA discovering phase LBD has to send LBP message to the LBS server under the support of a LBA. To find the LBA, it broadcasts a LBA solicitation message within its one hop neighbors and waits for a LBA advertisement. Any device capable of being LBS/LBA replies to the broadcast specifying its capability as LBS/LBA .If there is any LBS in its neighbor, LBD selects that LBS otherwise it selects one of the LBAs. Kim, Ed., et al. Expires January 16, 2009 [Page 9] Internet-Draft Commissioning in 6LoWPAN July 2008 3.3.4. LoWPAN Bootstrapping Protocol (LBP) LBD sends LBP message to LBA, as it doesn't know the address or path to the LBS of the target PAN. LBA forwards the LBP message to LBS on behalf of LBD. LBS replies with one or multiple LBP messages destined to LBA as LBD still is not part of the network. If the network is secured 6LoWPAN and the LBD is an authentic node, we assume that LBD has necessary pre-deployed keys and the knowledge of the authentication mechanism necessary to authenticate in target PAN. In this case, LBD sends necessary information in the 'bootstrapping data' field so that LBS can initiate the authentication process using that 'authentication credentials'. LBS converts the LBP message into appropriate authentication request for the particular authentication server and sends it. A reply/challenge from the authentication server, for example EAP authenticator or AAA server, is encapsulated in LBP message's 'bootstrapping data' field and is sent back to the LBD through LBA. LBA also keeps track of the successful authentication, failed authentication and incomplete conversation of the authentication process, and maintains a 'black list' of malicious devices to avoid repeated attack. Detecting malicious device based on those 3 information and marking that node as 'Black listed' belongs to the scope of security policy and out of the scope of this draft. Following figure shows a simple example of Bootstrapping mechanism. LBD LBA LBS | LBA solicitation | | | (1 hop broadcast) | | |---------------------->| | | LBA advertisement | | | (unicast to LBD) | | |<----------------------| | | LBP message(JR) | | |---------------------> | LBP Message (JR) | | |-------------------------->| | | LBP Message (JRep) | |LBP Message (JRep only)|<--------------------------| |<--------------------- | | JR= Join Request, JRep= Join Reply 3.3.5. Bootstrapping in open 6LoWPAN: An open 6LoWPAN network, usually welcomes any willing LBD. In this case, it doesn't need to wait for reply from LBS. Instead, LBA can provide GI from its own LIB and can forward LIB request to LBS Kim, Ed., et al. Expires January 16, 2009 [Page 10] Internet-Draft Commissioning in 6LoWPAN July 2008 simultenously. LBD LBA LBS | LBA solicitation | | | (1 hop broadcast) | | |---------------------->| | | LBA advertisement | | | (unicast to LBD) | | |<----------------------| | | LBP message(JR) | | |---------------------->| | | LBP message(PSI only) | | |<--------------------- | LBP Message (Req. for DSI)| | |-------------------------->| | | LBP Message (contains DSI)| |LBP Message (DSI only) |<--------------------------| |<--------------------- | | JR= Join Request. 3.3.6. LBP in secured 6LoWPAN In secured 6LoWPAN, LBD must has to exchange authentication credentials using its join key. Apart from requesting network resources, in the case of secured network, this process may need to exchange several encrypted message between LBD and authentication server. LBA and LBS serves as 'secured tunnel' for authentication message exchange process.Both LBA and LBS keep the account of the last LIB request/reply processed by themselves. Example: LBP with EAP The following figure shows how LBP with other authentication protocol like EAP works. At first LBD broadcasts a LIB request(1 hop) to LBA. LBA already has a secured route to LBP so it just unicasts the LIB request to LBS. LBS sends an EAP packet prepared with LBD's authentication credentials and sends it to authenticator. it is also possible that LBS entity and authenticator entity resides on a single system. As discussed earlier, LBS serves as translator between LBP and EAP message exchange in this authentication process and finally when AM indicates the success of authentication, it sends all network resources along with the ACCEPTED code. In the case of failure in authentication process, DECLINE code is sent to LBD. Kim, Ed., et al. Expires January 16, 2009 [Page 11] Internet-Draft Commissioning in 6LoWPAN July 2008 |-----------------------| | | | | AM |Authenticator | |--------| Module | | | | | NAM | | EAP LBD LBA |-----------------------|Authentication LBS EAP Server | LBA solicitation | | | | (1 hop broadcast) | | | |------------------> | | | | LBA advertisement | | | |<-------------------| | | | LBP message | | | | (Join Req) | LBP message | | |------------------> | (on behalf of LBD) | | | |---------------------->| | | | LBP message | | | LBP message | (challenge from EAP)| | |(challenge from eap)|<----------------------| | |<-------------------| | | | LBP message | | | | (reply for EAP) | LBP message | | |------------------->| (reply for EAP) | | | |---------------------->| EAP reply | | | |------------->| | | |Next challenge| | | |<-------------| . . . . . . . . . one hop Multi-hop |<-------------------|---------------------->|<------------>| LBP EAP 3.3.7. Role of Entities in LBP: Role of LoWPAN Bootstrapping Device (LBD): 1. It selects LBA using LBA discovery phase. 2. If it doesn't find any LBA, it gives up after waiting for certain amount of time. 4. if it receives any LBP message with code "CHALLENGE", it must send Kim, Ed., et al. Expires January 16, 2009 [Page 12] Internet-Draft Commissioning in 6LoWPAN July 2008 another LBP message containing the appropriate value against the challenge/query in the bootstrapping data field. 5. It MUST increment seq for every new LBP message. For retransmission seq should remain same. Role of LoWPAN Bootstrapping Agent (LBA): When LBA receives LBP message from LBD. 1. If the LBD is already in the Black List, discard 2. If the LBD is new, and 6LoWPAN is open network, a) Send 'LBP message' with ACCEPTED along with all PSI from its own LIB b) If there is any LBS in the PAN, Forward the 'LBP message' to LBS for DSI. 3. If the LBD is old, and 6LoWPAN is open network a) if it matches with the last seq no. send the last reply. b) otherwise discard. 4. If the LBD is new, and 6LoWPAN is secured network a) forward the LBP message to LBS 5. If the LBD is old, and 6LoWPAN is secured network a) if it matches with the last seq no. send the previously saved last LBP message 'for LBD'. b) if the LBP has completed, discard. c) if the LBP is 'CHALLENGE' and new seq is right next of the last one, forward the message to LBS. When LBA receives LBP message from LBS (for LBD) 1. if it is ACCEPTED and 16-bit short address is the responsibility of LBA, it calculates and appends the 16-bit short address with the LIB reply. 2. Otherwise, if it is ACCEPTED, DECLINED or CHALLENGE, forward it to the corresponding LBD. Kim, Ed., et al. Expires January 16, 2009 [Page 13] Internet-Draft Commissioning in 6LoWPAN July 2008 3. if it is not ACCEPTED or DECLINED, delete previously saved LBP message and save this LBP message. 3. if it is DECLINED, based on the security policy, mark it as 'Black listed' 4. if there is no activity in some of the flow (LBD-LBS pair), mark the LBD and based on the security policy include it in 'Black list'. Role of LoWPAN Bootstrapping Server (LBS): In the case of open 6LoWPAN 1. if the LBD is 'valid' that means its EUI-64 is in accepted list or not in the rejection list, it sends ACCEPTED code and necessary DSI and 16-bit short address(if the address should be assign centrally). In the case of secured 6LoWPAN 1. AM of LBS determines authentication server for particular EUI address and sends authentication mechanism initiation with the authentication credentials to that authentication server. 2. when it gets reply from authentication server, if it is success, it prepares a success reply if it is failure, it prepares a failure reply f it is challenge/query, it prepares processing reply for LBD and sends to LBA. 3. When AM module receives success from authentication server, it informs success to NAM module and sends the success response to NAM. NAM then, sends DSI along with the response in LBP message. 3.4. Assigning the short address During LBP procedure, LBD may set a short address either by itself or receiving the address from the PAN. The short address must be unique in a PAN and may be given by a centralized or distributed way. One of the approach to distribute the short address among the LBDs is centralized fashion where a centralized entity (eg. LBS) assigns 16- bit short address for LBD. Allocation of short address MAY be based on First-Available-Address-First or randomly choosen one or using any other algorithm. Distributed approach is another way to assign 16-bit short address to LBDs. In this approach, LBA assigns short address to the joining device, LBD. A hierarhical addressing scheme could be used by LBA in this purpose. Following figure describes the address calculation Kim, Ed., et al. Expires January 16, 2009 [Page 14] Internet-Draft Commissioning in 6LoWPAN July 2008 scheme. This scheme requires one parameter MC, the maximum number of addresses a LBA can assign. If the present LBD is the first children, then it gets the short address by following formula, FC = MC * AP + 1 , where FC is the LBD address, and AP is the address of the LBA. If LBD is not the first child of this LBA, it receives the address which is next to the last address assigned by that LBA. For example, if LBA(1) assigned address 6 to its last LBD, it assigns address 7 to its next LBD. MC = 4 (0) <= Coordinator // \\ / | | \ / / \ \ (1) (2) (3) (4) <= Routers // \\ ......... // \\ / / \ \ / / \ \ (5) (6) (7)(8)..(17)(18)(19)(20) // \\ / / \ \ ...........(69) (70)(71) (72)........ Fig. . The assignment scheme of the short address 3.5. Obtaining IPv6 address The IPv6 interface identifier of a device can be obtained as described in Section 6 of [rfc4944]. After having a unique IPv6 interface identifier, the device begins to obtain an IPv6 address prefix. The IPv6 address prefix for a particular 6LoWPAN is stored by the IPv6 router in the 6LoWPAN. ICMPv6 is used to share these parameters. Routers in 6LoWPAN are supposed to broadcast Router Advertisements(RA) messages periodically. The RA message must contain the prefix option which can be used in the 6LoWPAN. Devices wish to obtain IPv6 address prefix may wait for an RA message until RA_WAIT_TIME elapsed. After that, if no RA message is received, they may broadcast Router Solicitation(RS) message for requesting the RA message. Kim, Ed., et al. Expires January 16, 2009 [Page 15] Internet-Draft Commissioning in 6LoWPAN July 2008 The RS and RA messages can have additional option fields as described in [rfc4861]. Source/Target link-layer address option field should contain the EUI-64 address or the combined address with PAN ID and 16bit short address of the source or target device as below. The RS and RA messages can have additional option fields as described in [rfc4861]. Source/Target link-layer address option field should contain the EUI-64 address or the combined address with PAN ID and 16bit short address of the source or target device as below. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- EUI-64 Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Short Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source/Target Link-layer Address option field Multiple IPv6 routers could form a single or multiple 6lowpan(s). If there are multiple routers in a 6LoWPAN, the device should consider which one is to be selected as a default router. One possible way of selection is to compare the hop counts traveled of the RA message of each router. The detailed algorithm for the selection is TBD. Kim, Ed., et al. Expires January 16, 2009 [Page 16] Internet-Draft Commissioning in 6LoWPAN July 2008 3.6. Configuration Parameters This section gives default values for some important parameters associated with the 6LoWPAN commissioning protocol. A particular node may wish to change certain of the parameters. Parameter Name Value ---------------------- ----- CHANNEL_LIST 0xFFFF800 SCAN_DURATION 3 SUPERFRAME_ORDER 15 BEACON_ORDER 15 START_RETRY_TIME 1000 msec JOIN_RETRY_TIME 4000 msec ASSOCIATION_RETRY_TIME 4000 msec 4. IANA Consideration TBD. 5. Security Considerations IEEE 802.15.4 devices is required to support AES link-layer security. MAC layer also provides all keying material necessary to provide the security services. It isn't defined, however, when security shall be used especially combining with Bootstrapping. After the device start and join the network, security services such as key management and device authentication should be done automatically. Detailed algorithm for security on Bootstrapping is TBD. 6. Contributors Thanks to the contribution from MD. Aminul Haque Chowdhury (Ajou Univ) and Chae-Seong Lim (Ajou Univ) for the review and useful discussion for writing this document. 7. Acknowledgments Thanks to Hamid Mukhtar (PicosNet/Ajou Univ), Jae-ho Lee (NIA), and Dong-Gyu Nam (NIA) for their useful discussion and support for writing this document. Kim, Ed., et al. Expires January 16, 2009 [Page 17] Internet-Draft Commissioning in 6LoWPAN July 2008 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006". 8.2. Informative References [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. Authors' Addresses Ki-Hyung Kim (editor) picosNet Corp/Ajou Univ. San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 2433 Email: kkim86@picosnet.com S M Saif Shams picosNet Corp/Ajou Univ. San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 010 8690 8532 Email: saif95bd@gmail.com Kim, Ed., et al. Expires January 16, 2009 [Page 18] Internet-Draft Commissioning in 6LoWPAN July 2008 Seung Wha Yoo Ajou University San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 216 1603 Email: swyoo@ajou.ac.kr Soohong Daniel Park (editor) SAMSUNG Electronics Mobile Platform Laboratory, SAMSUNG Electronics 416 Maetan-3dong Yeongtong-gu, Suwon-si, Gyeonggi-do 442-742 KOREA Phone: +82 31 200 4508 Email: soohong.park@samsung.com Geoffrey Mulligan Email: geoff@mulligan.com Kim, Ed., et al. Expires January 16, 2009 [Page 19] Internet-Draft Commissioning in 6LoWPAN July 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. Kim, Ed., et al. Expires January 16, 2009 [Page 20]