[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

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