INTERNET-DRAFT Matthias Frank July 2001 Rolf Goepffarth Expires: January 2002 Wolfgang Hansmann Ulrich Mueller University of Bonn Transmission of native IPv6 over Bluetooth (6overBT) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract The Bluetooth technology is intended for a wide range of different user devices and will be employed in various devices such as mobile phones, PDAs and notebooks. To enable communication between these devices and the existing IP world, the transmission of IPv4 and IPv6 packets over Bluetooth has already been addressed in the Bluetooth LAN access profile and the Bluetooth PAN profile. However, these approaches introduce a considerable amount of protocol overhead. To abolish this deficiency, this document specifies the transmission of "native IPv6 over Bluetooth" (6overBT). The term "native IPv6" refers to the transmission of plain IPv6 packets in L2CAP packets. No additional link layer headers are used. draft-hansmann-6overbt-00.txt [Page 1] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 Table of Contents Status of this Memo 1 Abstract 1 1. Introduction 3 2. 6overBT Architecture 3 2.1 6overBT Mobile Device ................................... 4 2.2 6overBT IPv6 Switch ..................................... 4 2.3 6overBT Access Router ................................... 4 3. 6overBT Specification 5 3.1 6overBT Protocol Stack .................................. 5 3.2 Specification of a 6overBT Mobile Device ................ 5 3.2.1 Required Bluetooth Functionality ................. 5 3.2.2 Interface Identifier ............................. 8 3.2.3 Connection State Machine ......................... 8 3.2.4 Disconnected State ............................... 8 3.2.5 Connected State .................................. 9 3.3 Specification of a 6overBT IPv6 Switch .................. 10 3.3.1 Required Bluetooth Functionality ................. 10 3.3.2 General Operation ................................ 13 3.3.3 Binding Records .................................. 13 3.3.4 Connection State Machine ......................... 14 3.3.5 Disconnected State ............................... 15 3.3.6 Unbound/Connected State .......................... 16 3.3.7 Bound/Connected State ............................ 16 3.3.8 Bound/Disconnected State ......................... 16 3.3.9 IPv6 Packet Switching ............................ 16 3.3.10 IPv6 Host Capability ............................. 19 3.4 Specification of a 6overBT Access Router ................ 19 3.4.1 Required Bluetooth Functionality ................. 19 3.4.2 General Operation ................................ 19 3.4.3 IPv6 Requirements ................................ 20 3.5 Service Records ......................................... 20 3.6 Multiple Switches in a Piconet .......................... 21 4. Security Considerations 22 5. Summary 22 6. References 23 7. Author's Addresses 24 draft-hansmann-6overbt-00.txt [Page 2] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 1.0 Introduction The Bluetooth technology is intended for a wide range of different user devices and will be employed in various devices such as mobile phones, PDAs and notebooks. To enable communication between these devices and the existing IP world, the transmission of IPv4 [1] packets over Bluetooth has already been addressed in the Bluetooth LAN access profile [2] and extending this approach to support IPv6 [3] over Bluetooth seems straightforward. However, this approach introduces a considerable amount of protocol overhead and only permits point-point connections between Bluetooth devices. Alternatively, the Bluetooth PAN profile provides a method for the transmission of IPv4 as well as IPv6 over Bluetooth using the Bluetooth Network Encapsulation Protocol (BNEP). This approach too, results in an unnecessary amount of protocol overhead as it introduces an additional link layer protocol above L2CAP and Baseband. The purpose of this document is to specify an efficient method of transmitting IPv6 over Bluetooth, which we refer to as "native IPv6 over Bluetooth" (6overBT). The term "native IPv6" refers to the transmission of plain IPv6 packets in L2CAP packets. No additional link layer or encapsulation protocol headers are used. 2.0 6overBT Architecture In the following the 6overBT architecture is described, which is maintained throughout the present document. It is differentiated between three 6overBT entities, namely the 6overBT mobile device (MD), the 6overBT access router (AR), and the 6overBT IPv6 switch (SW). The usage scenario with these three entities is depicted in Figure 1. As the use (topology, scheduling, routing) of scatternets is still a field of current research, the 6overBT protocol concepts concentrate only on single piconet Bluetooth scenario. Support for scatternet routing may be addressed in a future specification. Two different kind of scenarios are possible. The scenario where the functionality of the access router and the IPv6 switch is separated into two individual devices, or the scenario where a single device must perform the functionality of the access router and the IPv6 switch. draft-hansmann-6overbt-00.txt [Page 3] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 access ._ network _. '._______.' | access +--+ ._ network _. |AR| '._______.' +--+ | | +---+ | |AR | | +---+ +---+ |SW | |SW | +---+ +---+ _/ | \_ _/ | \_ / | \ / | \ +---+ | +---+ +---+ | +---+ |MD | +---+ |MD | |MD | +---+ |MD | +---+ |MD | +---+ +---+ |MD | +---+ +---+ +---+ Figure 1: 6overBT usage scenario 2.1 6overBT Mobile Device In 6overBT, mobile devices participate in a 6overBT scenario by main- taining a single Bluetooth connection to a 6overBT IPv6 switch. The following 6overBT specification enables these mobile devices to com- municate with peer IPv6 hosts using native IPv6 over Bluetooth. 2.2 6overBT IPv6 Switch An IPv6 switch manages IPv6 packet communication for a single piconet. Being a piconet master, the 6overBT IPv6 switch is able to receive and forward data from/to each of its attached slaves, which may be 6overBT mobile devices or 6overBT access routers. Packet switching decisions are based on the destination address of received IPv6 packets. A 6overBT IPv6 switch and a 6overBT access router may be implemented on the same physical entity. It is possible for a switch to function as an IPv6 node, just like a mobile device. The specification of a switch covers two different usage modes: sin- gle-user mode and multi-user mode. In single-user mode, only one mobile device at a time can be connected to the switch. This usage mode requires less Bluetooth functionality and should be implemented, if simultaneous connections to multiple mobile devices are not sup- ported or, a master-slave switch is not available. 2.3 6overBT Access Router The 6overBT access router is the edge device between an existing IPv6 network and the ad-hoc Bluetooth piconet. Thus, it is typically equipped with at least two network interfaces: a Bluetooth transceiver and a non-Bluetooth interface (e.g. Ethernet). This non- draft-hansmann-6overbt-00.txt [Page 4] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 Bluetooth interface connects to an external IPv6 capable network. 3.0 6overBT Specification This section presents the specification of the 6overBT protocol con- cepts of native IPv6 over Bluetooth. After a description of the 6overBT protocol stack, each 6overBT entity is described in an own subsection. 3.1 6overBT Protocol Stack No additional encapsulation protocol between L2CAP and IPv6 will be used. Figure 2 depicts the necessary protocol stack for the 6overBT specification. 6overBT protocol concepts reside between the Bluetooth protocol stack and IPv6, and handle IPv6 based intra-piconet communi- cation. Therefore, 6overBT appears to IPv6 as a multiple access broadcast layer-2 protocol similar to Ethernet. +---------------+ | IPv6 | +---------------+ | 6over | +-------+-------+ | | L2CAP | | HCI +-------+ | | +---------------+ Figure 2: 6overBT protocol stack 3.2 Specification of a 6overBT Mobile Device 3.2.1 Required Bluetooth Functionality 3.2.1.1 Baseband/Link Control/Link Manager The Baseband and Link Control capabilities required by a 6overBT mobile device are shown in Table 1. The requirement levels used in this and the following tables comply with the requirement levels used in Bluetooth profile documents [4], where 'M' denotes a mandatory feature, 'O' an optional feature, and 'X' an excluded feature. Excluded features are features never to be used in the present or future specifications. The 6overBT mobile device must be able to establish an ACL link to a 6overBT IPv6 switch. In order to do this, the mobile device must sup- port the inquiry procedure to receive the IPv6 switch's Bluetooth device address, and the page procedure to establish the definite con- nection. draft-hansmann-6overbt-00.txt [Page 5] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 In order to detect the loss of a connection, the mobile device must support the link supervision timer. The support for multi-slot pack- ets is recommended, but not necessary for 6overBT. +---------------------------------+-----------------------+ | Capability | Support for a 6overBT | | | mobile device | +------------+--------------------+-----------------------+ | | ACL links | M | | Link types +--------------------+-----------------------+ | | SCO links | X | +------------+--------------------+-----------------------+ | | Inquiry | M | | Inquiry +--------------------+-----------------------+ | | Inquiry Scan | O | +------------+--------------------+-----------------------+ | | Paging | M | | Paging +--------------------+-----------------------+ | | Page scan | O | +------------+--------------------+-----------------------+ | | Link supervision | M | | +--------------------+-----------------------+ | | Multi-slot packets | O | | +--------------------+-----------------------+ | | Baseband Broadcast | O | +------------+--------------------+-----------------------+ Table 1: Baseband and Link Control capabilities needed by a 6overBT mobile device. Table 2 shows the necessary Link Manager capabilities a 6overBT mobile device has to support. If the 6overBT device connects to an IPv6 switch in multi-user mode it must support the master-slave- switch procedure. However, when connecting to an IPv6 switch in sin- gle-user mode, the master-slave-switch procedure is not mandatory anymore. Other Link Manager procedures such as the power saving modes, authen- tication, and name requesting are not necessary for the 6overBT spec- ification. draft-hansmann-6overbt-00.txt [Page 6] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 +------------------------------+--------------------------------+ | Procedure | Support for a 6overBT | | | mobile device | +------------------------------+--------------------------------+ | Power saving modes | O | +------------------------------+--------------------------------+ | Authentication / Pairing / | O | | Encryption | | +------------------------------+--------------------------------+ | Name request | O | +------------------------------+--------------------------------+ | Detach | O | +------------------------------+--------------------------------+ | Initiate master-slave switch | X | +------------------------------+--------------------------------+ | Perform master-slave switch | M (Switch in multi-user mode) | | | O (Switch in single-user mode) | +------------------------------+--------------------------------+ Table 2: Link manager procedures required by a 6overBT mobile device 3.2.1.2 L2CAP The L2CAP requirements for a 6overBT mobile device are shown in Table 3. IPv6 packets should be encapsulated in L2CAP packets. For this, a connection-oriented L2CAP channel between the mobile device and the IPv6 switch is required. We strongly recommend reserving a fixed, well known Protocol Switching Multiplexer (PSM) for 6overBT to be used to set up the data connection. This "well-known" PSM should then be used by the mobile device for initiating the channel between the two entities. If a fixed PSM is not available, then an IPv6 switch dependent, dynamic PSM can be used instead. To discover this dynamic PSM, a mobile device has to query the 6overBT SDP service record pro- vided by the IPv6 switch. +---------------------------------------------+-----------------------+ | Procedure | Support for a 6overBT | | | mobile device | +---------------+-----------------------------+-----------------------+ | | Connection-oriented channel | M | | Channel type +-----------------------------+-----------------------+ | | Connectionless channel | O | +---------------+-----------------------------+-----------------------+ | | Connection establishment | M | | Signalling +-----------------------------+-----------------------+ | | Connection termination | M | +---------------+-----------------------------+-----------------------+ | Channel | MTU Configuration | M | | configuration +-----------------------------+-----------------------+ | | QoS | O | +---------------+-----------------------------+-----------------------+ Table 3: L2CAP requirements of a 6overBT mobile device draft-hansmann-6overbt-00.txt [Page 7] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 For the negotiation of the MTU size used between the mobile device and the IPv6 switch, the mobile device must support the L2CAP MTU configuration procedure. Features such as Quality of Service negotia- tions or the use of a connectionless channel, are not considered in the current 6overBT specification. However, they may be used in order to enhance the functionality in later 6overBT specifications. 3.2.1.3 SDP As shown in Table 4, a 6overBT mobile device must have SDP function- ality in order to communicate with an IPv6 switch acting as a SDP server. +-------------+-----------------------+ | SDP feature | Support for a | | | 6overBT mobile device | +-------------+-----------------------+ | SDP client | M | +-------------+-----------------------+ | SDP server | M | +-------------+-----------------------+ Table 4: SDP feature requirements for a 6overBT mobile device 3.2.2 Interface Identifier IPv6 addresses consist of two parts, a prefix and an interface iden- tifier. The interface identifier for 6overBT entities is based on the EUI-64 identifier as in [5] and derives from the 48-bit Bluetooth device address. The interface identifier in 6overBT may be formed in analogy to an EUI-64 identifier deriving from an 48-bit IEEE 802 address (cf. [6]). Alternative interface identifiers should work within 6overBT as well. 3.2.3 Connection State Machine The state machine for a 6overBT mobile device is fairly simple and consists of two states, the disconnected state and the connected state. In the following two subsections these two states and their task within 6overBT are described in detail. 3.2.4 Disconnected State 3.2.4.1 Baseband / Link Manager Operation When activating the 6overBT functionality of a mobile device, the device should initially startup in the disconnect state. In this state the mobile device should attempt to establish a baseband con- nection to a nearby 6overBT IPv6 switch. This should be done by per- forming an inquiry procedure using the general inquiry access code (GIAC). After a successful inquiry procedure, the mobile device knows of Bluetooth device addresses of nearby IPv6 switches. This address should then be used in the page procedure performed by the mobile device to create a definite baseband connection to the IPv6 switch. draft-hansmann-6overbt-00.txt [Page 8] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 After a new Baseband connection has been established, the slave should be prepared to perform a master-slave-switch initiated by the IPv6 switch, if the IPv6 switch operates in multi-user-mode. 3.2.4.2 L2CAP Operation After a baseband connection has been established, the mobile device must initiate a connection-oriented L2CAP channel to the IPv6 switch in order to retrieve the 6overBT IPv6 switch's SDP 6overBT service record. Following this, the L2CAP channel is terminated and a new connection-oriented L2CAP channel for the PSM, as indicated in the retrieved service record, is established. During the channel configu- ration phase, the mobile device and the IPv6 switch should negotiate the L2CAP specific parameters such as MTU size. For more detailed information on the L2CAP operation refer to section 3.3.5.2. 3.2.5 Connected State After a baseband and L2CAP connection have successfully been estab- lished, the mobile device transits from the disconnected state to the connected state. Now, the mobile device has to assign an IPv6 address to its Bluetooth transceiver. For this the mobile should use the information previously retrieved in the 6overBT SDP service record. Alternatively, the mobile device may wait for the next ICMPv6 router advertisement which is sent periodically by the 6overBT access router, or may prompt the access router to send an advertisement by sending an ICMPv6 router solicitation message. When sending a solici- tation message the 6overBT mobile device may use either its link- local address, or the unspecified address :: as the source address. If no router is available, that is to say, if the mobile device does not receive any router advertisement, it may use its link local address for further communication. If the mobile device receives a router advertisement, the advertisement should contain the prefix information option containing the valid network prefixes that a mobile device may use. Such a prefix should be used by the mobile device when forming the IPv6 address it wants to assign to its Blue- tooth interface. We strongly recommend that the IPv6 address is assembled by concatenating the received network prefix with the Blue- tooth devices EUI-64 interface identifier. However, the concepts pre- sented in this specification support also other methods of generating the interface identifier, e.g. for security purposes, if it is desired to hide the Bluetooth device address to the outside world. To prevent duplicate address assignment, neighbor discovery's duplicate address detection procedure must be used before assigning an IPv6 address to an interface. For this, the mobile device must send an ICMPv6 neighbor solicitation message to the solicited-node-multicast address, asking whether some other host already owns its link-local address. The solicitation message in the duplicate address detection procedure should use the source address of ::, to distinguish these solicitation messages from normal neighbor solicitations. If the mobile device does not hear a draft-hansmann-6overbt-00.txt [Page 9] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 response to its solicitation message, then no duplicate address exists and the device may use the corresponding IPv6 address in fur- ther operation. To detect the loss of connectivity to the IPv6 switch, link supervision should be used. The link supervision timer is reset with every received baseband packet. If the supervision timer expires, then the link is regarded as broken and the mobile device should change to the disconnected state again. 3.3 Specification of a 6overBT IPv6 Switch The following section specifies the operation of a 6overBT IPv6 switch. A 6overBT IPv6 switch is an IPv6 interconnection entity for 6overBT mobile devices. It is the core entity in 6overBT, which must be always present for IPv6 over Bluetooth communication. 3.3.1 Required Bluetooth Functionality As required, a 6overBT switch must also be able to act as a 6overBT mobile device. The Bluetooth requirements are more restrictive and form a superset of the functionality required by 6overBT mobile devices. The following section specifies Bluetooth requirements for a 6overBT switch. 3.3.1.1 Baseband/Link Control/Link Manager A 6overBT IPv6 switch must be able to accept baseband ACL links from mobile devices. The ability to actively page other Bluetooth devices is only required when acting as 6overBT mobile device. If running in multi-user mode, a 6overBT switch must be able to maintain several simultaneous connections to slave devices. In order to permit the connection of mobile devices, inquiry scans must be performed regu- larly. However, initiating an inquiry procedure is only required when acting as 6overBT mobile device. Link supervision must be implemented to detect the loss of a connection. Support for multi-slot packets is not required, but strongly recommended. The current 6overBT specifi- cation does not require native baseband broadcast. However, in order to increase multicast performance, later enhancements to the 6overBT specification, as proposed in section 4.1, could benefit from broad- cast support. Table 5 summarizes the required Bluetooth baseband and Link Control functionality for a 6overBT IPv6 switch. draft-hansmann-6overbt-00.txt [Page 10] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 +---------------------------------+------------------------------+ | Capability | Support for a 6overBT switch | +------------+--------------------+------------------------------+ | | ACL links | M | | Link types +--------------------+------------------------------+ | | SCO links | X | +------------+--------------------+------------------------------+ | | Inquiry | M | | Inquiry +--------------------+------------------------------+ | | Inquiry Scan | M | +------------+--------------------+------------------------------+ | | Paging | M | | Paging +--------------------+------------------------------+ | | Page scan | M | +------------+--------------------+------------------------------+ | | Link supervision | M | | +--------------------+------------------------------+ | | Multi-slot packets | O | | +--------------------+------------------------------+ | | Baseband Broadcast | O | +------------+--------------------+------------------------------+ Table 5: Bluetooth link control / Baseband capabilities needed by a 6overBT switch. Table 6 lists necessary link controller procedures for a 6overBT switch. The support of power saving modes, as SNIFF, PARK or HOLD mode is not required by 6overBT. A crucial requirement for 6overBT in multi-user mode is the support of master-slave switch. A 6overBT switch running in multi-user mode must be able to initiate and per- form a master-slave switch. +------------------------------+------------------------------+ | Procedure | Support for a 6overBT switch | +------------------------------+------------------------------+ | Power saving modes | O | +------------------------------+------------------------------+ | Authentication / Pairing / | O | | Encryption | | +------------------------------+------------------------------+ | Name request | O | +------------------------------+------------------------------+ | Detach | O | +------------------------------+------------------------------+ | Initiate master-slave switch | M (multi-user mode) | | | O (single-user mode) | +------------------------------+------------------------------+ | Perform master-slave switch | M (multi-user mode) | | | O (single-user mode) | +------------------------------+------------------------------+ Table 6: Link manager procedures required by a 6overBT switch draft-hansmann-6overbt-00.txt [Page 11] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 The 6overBT specification does not cover link manager based configu- ration for authentication and link encryption. However, later speci- fications could benefit from the presence of this functionality. 3.3.1.2 L2CAP L2CAP connection-oriented channels will be used for service discovery [7] and IPv6 packet transfer. Table 7 summarizes 6overBT requirements to L2CAP. A 6overBT IPv6 switch must be able to accept L2CAP channel requests by mobile devices. The L2CAP implementation should be able to open L2CAP channels on already established HCI connection handles or provide HCI connection handles from already opened L2CAP channels For 6overBT, the reservation of a "well known" PSM is recommended to be used by mobile devices to open L2CAP channels for 6overBT con- trolled IPv6 communication. However, in absence of a global PSM, a dynamical PSM can be configured individually by the SDP 6overBT ser- vice record provided by the 6overBT switch. +---------------------------------------------+----------------+ | Procedure | Support for a | | | 6overBT switch | +---------------+-----------------------------+----------------+ | | Connection-oriented channel | M | | Channel type +-----------------------------+----------------+ | | Connectionless channel | O | +---------------+-----------------------------+----------------+ | | Connection establishment | M | | Signalling +-----------------------------+----------------+ | | Connection termination | M | +---------------+-----------------------------+----------------+ | Channel | MTU Configuration | M | | configuration +-----------------------------+----------------+ | | QoS | O | +---------------+-----------------------------+----------------+ Table 7: L2CAP requirements of a 6overBT switch 3.3.1.3 SDP An IPv6 switch must have both SDP client and SDP server functional- ity. However, if used as a 6overBT mobile device, only SDP client functionality will be used. draft-hansmann-6overbt-00.txt [Page 12] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 +-------------+-----------------+ | SDP feature | Support for a | | | 6overBT switch | +-------------+-----------------+ | SDP client | M | +-------------+-----------------+ | SDP server | M | +-------------+-----------------+ Table 8: SDP feature requirements for a 6over switch 3.3.2 General Operation 3.3.2.1 Advertising A switch must advertise its presence by regular inquiry scans for the GIAC. In the advertised device class field sent to devices performing inquiry a 6overBT switch should report itself as Networking/LAN access router. As specified in [8] the minor device field should rep- resent the current switch load, specifying the current number of con- nected slaves. 3.3.2.2 Service Discovery Apart from the information given in the device class field passed during inquiry, a switch should unambiguously denote its service by providing a SDP service record derived from the 6overBT service class. The information provided by this service record is described in section 3.5. 3.3.3 Binding Records Fundamental data structures operated by the switch are unicast bind- ing records. A binding record stores all known IPv6 addresses, including the link-local address, which can be associated with a sin- gle mobile device. For each connection to a mobile device, a binding record is constructed and updated on each ICMPv6 neighbor advertise- ment message received by this mobile device. Binding records repre- sent soft state, which must be regularly updated in order to prevent it from timeout. Once the connection to the mobile device is lost, the associated binding record still persists until the lifetime of all of its adver- tised IPv6 addresses expire. Keeping the address state for a short while after connection loss speeds up the time in which a mobile device is able to fully participate again on reconnection to the same IPv6 switch (e.g. after recovering from a previous established link break down). Figure 3 shows a unicast binding record. A single Bluetooth Device Address (BD_ADDR) is associated with n > 0 IPv6 unicast addresses. Each IPv6 unicast address has its own timer. draft-hansmann-6overbt-00.txt [Page 13] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 +-------+ 1 n +----------------------+---------+ |BD_ADDR|o--------o| IPv6-unicast-address | timeout | +-------+ +----------------------+---------+ Figure 3: unicast binding record Binding records only contain information on unicast address mappings. To store information about multicast address bindings, a different data structure is used, the multicast binding record. In a multicast binding record, an IPv6 multicast address is mapped to a list of BD_ADDRs with mobile devices subscribed to a particular multicast group. Information on multicast group memberships are learned from ICMPv6 Multicast Listener Discovery (MLD) messages received by mobile devices. Unlike unicast binding records, information on multicast group membership of a particular mobile device is discarded on con- nection loss. +----------------------+ 1 n +--------+--------+ |IPv6 multicast address|o--------o|BD_ADDR | timeout| +----------------------+ +--------+--------+ Figure 4: multicast binding record A multicast binding record as shown in figure 4 is associated with n, n > 0 BD_ADDRs. Each BD_ADDR has its individual timeout after which its association to the multicast address will expire. 3.3.4 Connection State Machine Figure 5 shows the state diagram of the connection to a single mobile device. There are four different states of a connection specified: unbound/disconnected, unbound/connected, bound/ connected and bound/disconnected. Except for the unbound/disconnected state, a binding record is always associated with a connection. draft-hansmann-6overbt-00.txt [Page 14] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 .------------. | unbound/ | conn. created .----------->|disconnected|------------. | `------------' | |binding record ^ | |expired /|\ \|/ | | conn. loss V .-----+------. .___________.---------. | bound/ | |unbound/ | |disconnected|--------. .---------->|connected| `------------' reconn.| |binding `---------' ^ | |record expired | /|\ \|/ | | | V | | |conn. loss .---------. configure| '-------------| bound/ |<-------------' |connected| `---------' Figure 5: 6overBT switch binding record state machine 3.3.5 Disconnected State 3.3.5.1 Baseband / Link Manager Operation A switch should perform regular page scans in order to accept base- band connection attempts by mobile devices. After a new connection has been established, the switch must initialize a master-slave- switch in order to join the mobile device as slave into its piconet. This applies only, if the switch is configured to run in multi-user mode. Running in single-user mode does not require a master-slave- switch. 3.3.5.2 L2CAP Operation After baseband link establishment, a 6overBT switch expects a L2CAP channel request initiated by the mobile device for the PSM, which is advertised in the 6overBT service record. During L2CAP connection configuration, the switch should notify a link MTU of at least 1280 octets. The switch must be able to handle L2CAP datagrams with a payload of at least 1280 octets. However, if information on the actual external link MTU is known (e.g. as given in the MTU option of router advertisements sent by access routers), this MTU value should be used instead to configure the L2CAP link. Both peers must use the default Flush timeout value in order to provide a reliable L2CAP channel. On successful channel configuration, the switch should cre- ate an empty unicast binding record for the mobile device and move the connection into connected/unbound state. If the IPv6 switch does not receive a L2CAP connection attempt to the PSM used by 6overBT within a TBD amount of time, the baseband connection should be released. draft-hansmann-6overbt-00.txt [Page 15] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 3.3.6 Unbound/Connected State Connections in unbound/connected state represent links to mobile devices to which no BD_ADDR to IPv6 interface address mapping already exists. Though mobile devices are able to send packets, the switch is only able to broadcast packets destined to an unknown IPv6 address to all connected mobile devices. After at least one single IPv6 address has been associated with a mobile device, the connection changes to bound/connected state. If the connection is lost, the empty unicast binding record is discarded. 3.3.7 Bound/Connected State For connections in bound/connected state at least one IPv6 address of the mobile device is known. This is the default state for active con- nections. Packets determined to mobile devices, which connections are in bound/connected state can be forwarded without broadcasting. If all known IPv6 addresses of a connected mobile device have expired, the connection changes to unbound/connected state. If the physical loss of the connection to a mobile device has been signalled, its unicast binding record changes to bound/disconnect state. 3.3.8 Bound/Disconnected State In the bound/disconnected state, the switch has lost the physical Bluetooth connection to a mobile device. However, information of associated IPv6 addresses is still maintained in a binding record until the addresses expire. If a mobile device reconnects to the switch and a binding record is still maintained, the baseband link setup step as described in sec- tion 3.3.5 is performed and the connection changes back into bound/connected state. IPv6 packets destined to mobile devices which are not connected to the switch but still have a binding record should be silently dis- carded. If all IPv6 addresses in a binding record have expired, the binding record is released. 3.3.9 IPv6 Packet Switching The following packet switching algorithm is performed each time the switch receives an IPv6 packet from any connection to a mobile device either in unbound/connected or bound/connected state. Switching decision is solely based on the IPv6 destination address of the received packet. A different switching strategy is used for uni- cast and multicast destination addresses. 3.3.9.1 Evaluation of ICMPv6 Messages A switch must evaluate IPv6 neighbor advertisement messages, router draft-hansmann-6overbt-00.txt [Page 16] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 advertisements and MLD messages intercepted from mobile devices. After evaluation, these packets should be forwarded as any other packet. In the following the special treatment of these messages is depicted. Router advertisements A switch must intercept and evaluate router advertisements received by access routers. For each access router, it should store the infor- mation given in the latest router advertisement. This information should be deleted after its lifetime expires, which is given in the router advertisement. One of the connected access routers should be elected as default access router. How to determine this access router is still to be decided. A possibility is to use the access router with the lowest BD_ADDR. Other solutions may take access router capacity into account. The appropriate solution is still TBD. Neighbor advertisements Neighbor advertisements update binding records. If a new address is learned from a mobile device, this address should be added to its binding record, otherwise, the lifetime of the address should be updated. Expired IPv6 unicast addresses should be removed from uni- cast binding records. The lifetime of an IPv6 address in a binding record should be accord- ing to the "Reachable Time" value given in the router advertisement of the access router, which advertised network prefix was used to construct the address. If no router advertisements are available, or an unspecified value is given in the 'Reachable Time' field of the router advertisement, a timeout value of 45 (MAX_RANDOM_FACTOR * REACHABLE_TIME) seconds should be assumed. According to [9], this is the longest time a node can use information from the neighbor cache of an unresponsive target node without performing neighbor unreacha- bility detection (sending neighbor solicitation and expecting a neighbor advertisement). [FIXME: according to our spec the Binding Record of a host times out 45 seconds after the last NA message has passed the switch. However, if a host receives reachability confirmation by other means than NUD (e.g. by progress detection) our Binding Record times out. Should actual usage of an address reset the Binding Cache timeout, too?] Multicast Listener Discovery messages An IPv6 switch should evaluate Multicast Listener Discovery messages sent by mobile devices in order to learn about multicast group mem- berships. Joining a multicast group, a mobile device sends an unso- licited Multicast Listener Report to the all router multicast group of the link. Proper knowledge of group memberships reduces unneces- sary forwarding of multicast packets to unsubscribed mobile devices. draft-hansmann-6overbt-00.txt [Page 17] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 On reception of a Multicast Listener Report message, a switch must check, if an according multicast binding record for the advertised multicast address already exists. If yes, the BD_ADDR of the sending device is added to the multicast binding record. Otherwise, a new multicast binding record is created with the BD_ADDR of the mobile device as single listener. The multicast binding information should time out after 260 seconds as suggested by MLD (cf. [10]). If a Multicast Listener Done message is received from a mobile device, its binding must be immediately removed from the multicast address' multicast binding record. If no mobile devices are regis- tered listeners on a multicast group, the multicast binding record must be discarded. After evaluation, Multicast Listener Discovery messages must be for- warded like normal multicast packets. 3.3.9.2 Unicast Switching Receiving a packet, the switch has to decide, if the destination IPv6 address is on-link, or not. A destination is considered "on-link", if the network prefix matches any of the network prefixes advertised in the intercepted router advertisements. If no router advertisements are available, the destination should be regarded on-link. If a des- tination is not on-link, the packet should be forwarded to the access router, which has advertised the network prefix, from which the source address in the packet has been generated. If several access routers have advertised the same prefix, an arbitrary access router should be chosen. If the destination address has an EUI-64 identifier (contains the BD_ADDR of the destination device), the datagram should be directly forwarded to the connected mobile device. No binding record lookup is necessary for such destination addresses. Otherwise, if a destination is on-link, the associated unicast bind- ing record is looked up and the packet should be forwarded to the appropriate mobile device. If no binding record is found for the des- tination, the packet should be forwarded to all links maintained to mobile devices. 3.3.9.3 Multicast Switching For forwarding of packets destined to a multicast group the following algorithm applies: If the destination multicast group has either global, site-local or organizational local scope AND the destination multicast address matches an existing Multicast Binding Record, THEN a copy of the packet should be forwarded through each L2CAP channel given in the Multicast Binding Record. If the IPv6 destination address is the solicited node multicast draft-hansmann-6overbt-00.txt [Page 18] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 address (FF02::1:FFxx:yyzz), the packet should be forwarded to all mobile devices with matching interface identifier. If according to these rules no destination has already been found, the multicast packet must be forwarded to all mobile devices. 3.3.10 IPv6 Host Capability An IPv6 switch may be configured to operate as an IPv6 capable node just like mobile devices. In this case, a binding record containing the IPv6 switch's own BD_ADDR address must be maintained permanently. As information on the used IPv6 addresses is locally available, the switch may employ means other than intercepting its own neighbor advertisements and MLD messages to learn about its IPv6 addresses and multicast group memberships. For the local IPv6 stack the 6overBT IPv6 switch should appear as a network interface, to which packets can be forwarded. Packets inter- cepted from the local IPv6 stack should be routed, as if a mobile device would have received them. 3.4 Specification of a 6overBT Access Router 6overBT access routers are entities equipped with Bluetooth transceivers and at least another non-Bluetooth link-layer technology over which IPv6 based communication can take place. Access routers may be either fixed or mobile. The 6overBT specification for access routers is quite similar to the specification of a 6overBT mobile device - an access router is a 6overBT mobile device that operates an IPv6 stack configured as router. Optionally, an IPv6 access router can be implemented along with a 6overBT IPv6 switch on the same phys- ical entity. 3.4.1 Required Bluetooth Functionality Implemented as a single entity, a 6overBT access router has the same Bluetooth requirements as a 6overBT mobile device. Combined with a 6overBT IPv6 switch, an access router has the same Bluetooth require- ments as a 6overBT IPv6 switch. 3.4.2 General Operation 3.4.2.1 Inquiry If implemented as a separate entity, an access router could be restricted to connect only to an administratively determined set of known 6overBT IPv6 switches. The list of IPv6 switches allowed to connect to should be configurable. For this, Bluetooth specified means for authentication and security could be incorporated. Details for appropriate means are not within the scope of the current docu- ment. draft-hansmann-6overbt-00.txt [Page 19] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 3.4.3 IPv6 Requirements The IPv6 stack on 6overBT access routers should be properly config- ured as router. The Bluetooth link presented by 6overBT should appear as a network interface for a broadcast multiple access link (e.g. Ethernet). At least one global scope or site local network prefix should be manually configured to the 6overBT link. The interface identifier for this link must be constructed according to the EUI-64 identifier based on the 48-bit BD_ADDR, as described in section 3.2.2. Other methods for building an interface identifier for access routers are not covered by this specification. The IPv6 stack must advertise the network prefix in router advertise- ments. In router advertisements, the 'M' and 'O' flags should be set to zero in order to denote, that no stateful address configuration will take place for configuring a mobile device's IPv6 address. The advertised network prefixes must have the 'L' and 'A' flags set to one, indicating that the network prefixes should be used for on-link address determination and autonomous address configuration. Each router advertisement should contain a MTU Option, in which the recommended MTU of the 6overBT link is advertised. The link MTU should be the same MTU used on the access router's non-Bluetooth link, or 1280 octets, which ever is larger. 3.5 Service Records A 6overBT switch must provide a SDP service record of the 6overBT service class to advertise its service. The information items of that service record are summarized in Table 9. In the Protocol descriptor list 6overBT services are denoted to be built on top on L2CAP. Which PSM actually should be used for L2CAP channel establishment is given as "SpecificParameter0" of the L2CAP protocol description. The service record also provides information that could be obtained by router advertisements, once a 6overBT mobile device is connected to the switch. Providing information on IPv6 network prefixes at this early stage permits a 6overBT mobile device to configure its IPv6 address(es) without sending a router solicitation and expecting sub- sequent router advertisement by 6overBT access routers. The 6overBT_SwitchLoad information item reveals the load situation on the switch in terms of the number of currently connected mobile devices. The 6overBT_SessionDescriptionString information item pro- vides an identification useful to differentiate between 6overBT ses- sions offered by other 6overBT switches. draft-hansmann-6overbt-00.txt [Page 20] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 +--------------------------+-------+-------------------------------+ | Item |Type | Description | +--------------------------+-------+-------------------------------+ | ServiceRecordHandle | | | +--------------------------+-------+-------------------------------+ | ServiceClassIDList | | | +--------------------------+-------+-------------------------------+ | ServiceClass0 |UUID | UUID of 6overBT service class | +--------------------------+-------+-------------------------------+ | ProtocolDescriptorList | | | +--------------------------+-------+-------------------------------+ | Protocol0 |UUID | UUID of L2CAP | +--------------------------+-------+-------------------------------+ | SpecificParameter0 |UInt16 | L2CAP PSM for 6overBT | +--------------------------+-------+-------------------------------+ | Protocol1 |UInt16 | UUID for 6overBT | +--------------------------+-------+-------------------------------+ | SpecificParameter0 |UInt16 | Version 1.0 (0x100) | +--------------------------+-------+-------------------------------+ | 6OVER_NetworkPrefixList | | List of network prefixes for | | | | the 6overBT piconet spanned by| | | | this switch. The list of | | | | prefixes is learned from | | | | Router Advertisements sent | | | | by access routers | +--------------------------+-------+-------------------------------+ | Prefix0 |UInt128| Network prefix 0 | +--------------------------+-------+-------------------------------+ | PrefixLength0 |UInt16 | Network prefix length | +--------------------------+-------+-------------------------------+ | ... | | | +--------------------------+-------+-------------------------------+ | 6OVER_SwitchLoad |UInt16 | Number of 6overBT mobile | | | | devices connected to this | | | | switch | +--------------------------+-------+-------------------------------+ | 6OVER_SessionDescr |String | Human readable string | | | | describing the switch's | | | | service. Useful to | | | | distinguish between the | | | | services of several | | | | available 6overBT switches at | | | | the same place | +--------------------------+-------+-------------------------------+ Table 9: Information elements in a 6overBT service record 3.6 Multiple Switches in a Piconet It is likely that several devices with 6overBT switch capability attempt to participate in a 6overBT piconet. In this case, one device must be selected as 6overBT switch while the other devices take over the role as 6overBT mobile device. The choice of which device to use as 6overBT switch in this situation should be user configurable. draft-hansmann-6overbt-00.txt [Page 21] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 4.0 Security Considerations 6overBT makes excessive use of Neighbor Discovery and thus shares ND's security problems in case of unauthenticated ND messages. The current version of the draft does not address the setup of Blue- tooth link encryption. A future version of the draft should reflect that. No access control has been specified so far. Mobile devices can con- nect at their will to a 6overBT switch. This issue must be addressed in a future version of this draft. 5.0 Summary With 6overBT we have specified a mechanism for efficient transport of IPv6 over Bluetooth. IPv6 packets are transported in the payload of L2CAP with no additional protocol overhead. Being a Bluetooth master device a 6overBT switch is able to provide connectivity for up to 7 slave devices. 6overBT emulates a broadcast access environment using the 6overBT switch as the basic means to organize communication. IP switching is performed at the switch and is based on information gained from intercepted ND messages by the slave devices. This way, the Bluetooth device appears to the IP stack at the switch as single network interface providing capabilities similar to Ethernet. draft-hansmann-6overbt-00.txt [Page 22] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 6.0 References [1] J. Postel, "Internet Protocol", STD 5, RFC 791, IETF, September 1981. [2] Specification of the Bluetooth System, Version 1.0 B, Profiles, Part K:9, "LAN Access Profile", December 1999. [3] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, IETF, December 1998. [4] Specification of the Bluetooth System, Version 1.0 B, Profiles, December 1999. [5] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, IETF, July 1998. [6] M. Crawford, "Transmission of IPv6 Packets over Ethernet Network", RFC 2464, December 1998 [7] Specification of the Bluetooth System, Version 1.0 B, Profiles, Part K:2, "Service Discovery Application Profile", December 1999. [8] Specification of the Bluetooth System, Version 1.0 B, Core, December 1999. [9] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998 [10] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, IETF, October 1999. draft-hansmann-6overbt-00.txt [Page 23] Internet Draft Transmission of native IPv6 over Bluetooth June 2001 7.0 Author's Addresses Matthias Frank University of Bonn Institute of Computer Science IV Roemerstr. 164 Phone: +49 228 73 4550 D-53117 Bonn, Germany Email: matthew@cs.uni-bonn.de Rolf G. Goepffarth University of Bonn Institute of Computer Science IV Roemerstr. 164 Phone: +49 228 73 4549 D-53117 Bonn, Germany Email: rgg@cs.uni-bonn.de Wolfgang Hansmann University of Bonn Institute of Computer Science IV Roemerstr. 164 Phone: +49 228 73 4549 D-53117 Bonn, Germany Email: hansmann@cs.uni-bonn.de Ulrich Mueller University of Bonn Institute of Computer Science IV Roemerstr. 164 D-53117 Bonn, Germany Email: muelleru@cs.uni-bonn.de draft-hansmann-6overbt-00.txt [Page 24]