idnits 2.17.1 draft-sajjad-6lo-wban-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2363 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 378, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group MS. Akbar 3 Internet-Draft Bournemouth University 4 Intended status: Informational AR. Sangi 5 Expires: May 3, 2018 Huaiyin Institute of Technology 6 M. Zhang 7 J. Hou 8 Huawei Technologies 9 C. Perkins 10 Futurewei 11 A. Petrescu 12 CEA, LIST 13 R.N.B.Rais 14 Ajman University 15 October 30, 2017 17 Transmission of IPv6 Packets over Wireless Body Area Networks (WBANs) 18 draft-sajjad-6lo-wban-01 20 Abstract 22 Wireless Body Area Networks (WBANs) intend to facilitate use cases 23 related to medical field. IEEE 802.15.6 defines PHY and MAC layer 24 and is designed to deal with better penetration through the human 25 tissue without creating any damage to human tissues with the approved 26 MICS (Medical Implant Communication Service) band by USA Federal 27 Communications Commission (FCC). Devices of WBANs conform to this 28 IEEE standard. 30 This specification defines details to enable transmission of IPv6 31 packets, method of forming link-local and statelessly autoconfigured 32 IPv6 addresses on WBANs. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 3, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Frame Format and Addressing Modes . . . . . . . . . . . . 3 69 1.2. Why 6lo is required for IEEE 802.15.6 . . . . . . . . . . 4 70 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 71 3. Topology and Scope of Communication . . . . . . . . . . . . . 5 72 4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . . . 7 74 6. Specification of IPv6 over WBAN . . . . . . . . . . . . . . . 7 75 6.1. Stateless Address Autoconfiguration . . . . . . . . . . . 8 76 6.2. IPv6 Link-Local Address . . . . . . . . . . . . . . . . . 8 77 6.3. Unicast and Multicast Address Mapping . . . . . . . . . . 8 78 6.4. Header Compression . . . . . . . . . . . . . . . . . . . 8 79 6.5. Fragmentation and Reassembly . . . . . . . . . . . . . . 9 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 8. Security and Privacy Considerations . . . . . . . . . . . . . 9 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 9.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Appendix A. Patient monitoring use case - Spoke Hub . . . . . . 10 86 Appendix B. Patient monitoring use case - Connected . . . . . . 12 87 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Wireless Body Area Networks (WBANs) are comprised of devices that 93 conform to the [IEEE802.15.6], standard by the IEEE. IEEE 802.15.6 94 provides specification for the MAC layer to access the channel. The 95 coordinator divides the channel into superframe time structures to 96 allocate resources [SURVEY-WBAN] [MAC-WBAN]. Superframes are bounded 97 by equal length beacons through the coordinator. Usually beacons are 98 sent at beacon periods except inactive superframes or limited by 99 regulation. 101 Task group for 802.15.6 was established by IEEE in November 2007 for 102 standardisation of WBANs and it was approved in 2012. This standard 103 works in and around human body and focus on operating at lower 104 frequencies and short range. The focus of this document is to design 105 a communication standard for MAC and physical layer to support 106 different applications, namely, medical and no-medical applications. 107 Medical applications refer to collection of vital information in real 108 time (monitoring) for diagnoses and treatment of various diseases 109 with help of different sensors (accelerometer, temperature, BP and 110 EMG etc.). It defines a MAC layer that can operate with three 111 different PHY layers i.e. human body communication (HBC), ultra- 112 wideband (UWB) and Narrowband (NB). IEEE 802.15.6 provides 113 specification for MAC layer to access the channel. The coordinator 114 divides the channel into superframe time structures to allocate 115 resources. Superframes are bounded by equal length beacons through 116 coordinator. The purpose of the draft is to highlight the need of 117 IEEE 802.15.6 for WBASNs and its integration issues while connecting 118 it with IPv6 network. The use cases are provided to elaborate the 119 scenarios with implantable and wearable biomedical sensors. 6lowpan 120 provides IPv6 connectivity for IEEE 802.15.4; however, it does not 121 work with IEEE 802.15.6 due to the difference in frame format in 122 terms of size and composition. 124 1.1. Frame Format and Addressing Modes 126 Figure 1 shows the general MAC frame format consisting of a 56-bit 127 header, variable length frame body, and 18-bit FrameCheck Sequence 128 (FCS). The maximum length of the frame body is 255 octets. The MAC 129 header further consists of 32-bit frame control, 8-bit recipient 130 Identification (ID), 8-bit sender ID, and 8-bit WBAN ID fields. The 131 frame control field carries control information including the type of 132 frame, that is, beacon, acknowledgement, or other control frames. 133 The recipient and sender ID fields contain the address information of 134 the recipient and the sender of the data frame, respectively. The 135 WBAN ID contains information on the WBAN in which the transmission is 136 active. The first 8-bit field in the MAC frame body carries message 137 freshness information required for nonce construction and replay 138 detection. The frame payload field carries data frames, and the last 139 32-bit Message Integrity Code (MIC) carries information about the 140 authenticity and integrity of the frame. The IEEE 802.15.6 standard 141 supports two kinds of addresses: 143 1. 8-bit short address, which is the sender ID. This address is 144 located in the MAC header used for communication. 146 2. 48-bit EUI-48 address, which is used for the association process. 147 For some certain frame types, e.g. Security Association frames, 148 this MAC address exists inside the MAC payload, for the node 149 joining process. 151 Octets 7 0-255 2 152 +--------+------------------+--------+ 153 | MAC | MAC frame body | | 154 | header |Variable length: | FCS | 155 | | 0-255 bytes | | 156 +--------+------------------+--------+ 157 <--MHR--><--------X--------><---FTR--> 158 / \ 159 / \ 160 / \ 161 +---------+------------+-------------+--------------+ 162 | Frame | Recipient | Sender | Ban | 163 | control | ID | ID | ID | 164 +---------+------------+-------------+--------------+ 165 Octets <---4----><-----1-----><------1-----><-------1------> 167 Figure 1: The general MAC frame format of IEEE 802.15.6 169 1.2. Why 6lo is required for IEEE 802.15.6 171 Based on the characteristics defined in the overview section, the 172 following sections elaborate on the main problems with IP for WBANs. 174 The requirement for IPv6 connectivity within WBANs is driven by the 175 following: 177 o The number of devices in WBANs makes network auto configuration 178 and statelessness highly desirable. And for this, IPv6 has 179 (default auto-configuration as a) ready solutions. 181 o The large number of devices poses the need for a large address 182 space, moreover a WBAN may consist of 256 nodes maximum and IPv6 183 is helpful to solve this address space limitation. 185 o Given the limited packet size of WBANs, the IPv6 address format 186 allows subsuming of IEEE 802.15.6 addresses if so desired. 187 Applications within WBANs are expected to originate small packets. 188 Adding all layers for IP connectivity should still allow 189 transmission in one frame, without incurring excessive 190 fragmentation and reassembly. Furthermore, protocols must be 191 designed or chosen so that the individual "control/protocol 192 packets" fit within a single 802.15.6 frame. Along these lines, 193 IPv6's requirement of sub-IP reassembly may pose challenges for 194 low-end WBANs healthcare devices that do not have enough RAM or 195 storage for a 1280-octet packet [RFC2460]. 197 o Simple interconnectivity to other IP networks including the 198 Internet. 200 o However, given the limited packet size, headers for IPv6 and 201 layers above must be compressed whenever possible. 203 2. Conventions and Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 3. Topology and Scope of Communication 211 This is a standard for short-range, wireless communication in the 212 vicinity of, or inside, a human body (but not limited to humans). It 213 uses existing industrial scientific medical (ISM) bands as well as 214 frequency bands approved by national medical and/or regulatory 215 authorities. Support for quality of service (QoS), extremely low 216 power, and data rates from 10Kbps to 10 Mbps is required while 217 simultaneously complying with strict non-interference guidelines 218 where needed. The Table 1 shows a comparison of WBAN and other 219 available technologies in terms of data rate and power consumption. 221 +----------------+---------------+-----------------+----------------+ 222 | Standard | Provided data | Power | Battery | 223 | | rate | requirement | lifetime | 224 +----------------+---------------+-----------------+----------------+ 225 | 802.11 ac | 700 Mbps | 100 mW - 1000 | Hours - days | 226 | (WiFi) | | mW | | 227 | | | | | 228 | Bluetooth | 1Mbps - 10 | 4 mW - 100 mW | Days - weeks | 229 | | Mbps | | | 230 | | | | | 231 | Wibree | 600 Kbps | 2 mW - 10 mW | Weeks - months | 232 | | maximum | | | 233 | | | | | 234 | ZigBee | 250 Kbps | 3 mW - 10 mW | Weeks - months | 235 | | | | | 236 | 802.15.4 | 250 Kbps | 3 mW - 10 mW | Weeks - months | 237 | | maximum | | | 238 | | | | | 239 | 802.15.6 | 1Kbps - 10 | 0.1 mW - 2 mW | Months - years | 240 | | Mbps | | | 241 +----------------+---------------+-----------------+----------------+ 243 Table 1: Comparison of WBAN 245 Data rates, typically up to 10Mbps, can be offered to satisfy an 246 evolutionary set of entertainment and healthcare services. Current 247 personal area networks (PANs) do not meet the medical (proximity to 248 human tissue) and relevant communication regulations for some 249 application environments. They also do not support the combination 250 of reliability, QoS, low power, data rate, and non-interference 251 required to broadly address the breadth of body area network (BAN) 252 applications. 254 The IEEE 802.15.6 working group has considered WBANs to operate in 255 either a one-hop or two-hop star topology with the node in the centre 256 of the star being placed on a location like the waist. Two feasible 257 types of data transmission exist in the one-hop star topology: 258 transmission from the device to the coordinator and transmission from 259 the coordinator to the device. The communication methods that exist 260 in the star topology are beacon mode and non-beacon mode. In a two- 261 hop start WBAN, a relay-capable node may be used to exchange data 262 frames between a node and the hub. 264 4. Protocol Stack 266 The IPv6 over IEEE 802.15.6 protocol stack is presented in Figure 2. 267 It contains six elements from bottom to top including IEEE 802.15.6 268 PHY layer, IEEE 802.15.6 MAC layer, Adaptation layer for IPv6 over 269 IEEE 802.15.6, IPv6 layer, TCP/UDP layer and Application layer.The 270 adaptation layer supports the mechanisms like stateless address auto- 271 configuration, header compression and fragmentation and reassembly. 273 +----------------------------------------+ 274 | Application Layer | 275 +----------------------------------------+ 276 | TCP/UDP | 277 +----------------------------------------+ 278 | | 279 | IPv6 | 280 | | 281 +----------------------------------------+ 282 | Adaptation layer for IPv6 over 802.15.6| 283 +----------------------------------------+ 284 | MAC Layer | 285 | (IEEE 802.15.6) | 286 +----------------------------------------+ 287 | PHY Layer | 288 | (IEEE 802.15.6) | 289 +----------------------------------------+ 291 Figure 2: Protocol stack for IPv6 over IEEE 802.15.4 293 5. Maximum Transmission Unit (MTU) 295 The IPv6 packets have the MTU of 1280 octects and its expects from 296 every link layer to send data by following this MTU or greater. Thus 297 maximum Transmission Unit (MTU) of MAC layer describes the 298 implementation of fragmentation and reassembly mechanism for the 299 adaption IPv6 layer over IEEE 802.15.6. 301 The IEEE 802.15.6 has the MTU of 256 octects, if we consider link 302 layer security overhead (16 octects for AES-128) leaves 240 octects 303 which is not sufficient to complete a IPv6 packet.Therefore, an 304 adaption layer below IP layer is required to manage fragmentation and 305 reassembly issues. 307 6. Specification of IPv6 over WBAN 309 Due to stringent QoS requirements in WBAN, a 6lo adaption layer is 310 needed to support the transmission of IPv6 packets.6 LoWPAN standards 311 [RFC4944], [RFC6775] and [RFC6282] provides useful information 312 including link-local IPv6 address,stateless address auto- 313 configuration, unicast and multicast address mapping,header 314 compression and fragmentation and reassembly. These standards are 315 reffered in the specifications of 6lo adaptation layer which is 316 illustrated in the following following subsections: 318 6.1. Stateless Address Autoconfiguration 320 An IEEE 802.15.6 device performs stateless address autoconfiguration 321 to obtain an IPv6 Iterface Identifier(IID). The IPv6 EUI-64 format 322 address is obtained through the EUI-48 bit MAC address of IEEE 323 802.15.6 node.The 64-bit IID SHALL be derived by utilizing 8-bit node 324 address and 8-bit BAN ID (part of MAC header) as follows: 326 ID: 0xYY00:00FF:FE00:00XX 328 Where YY is the BAN ID, XX is the node address. As this generated 329 IID is not golbally unique, the "Universal/Local" (U/L) bit (7th bit) 330 SHALL be set to zero. 332 6.2. IPv6 Link-Local Address 334 The IPv6 link-local address [RFC4291] for an IEEE 802.15.6 interface 335 is generated by appending the interface identifier to the prefix 336 FE80::/64. 338 10 bits 54 bits 64 bits 339 +----------+-----------------------+----------------------------+ 340 |1111111010| (zeros) | Interface Identifier | 341 +----------+-----------------------+----------------------------+ 343 Figure 3: IPv6 Link Local Address in IEEE 802.15.6 345 6.3. Unicast and Multicast Address Mapping 347 The address resolution procedure for mapping IPv6 unicast addresses 348 into IEEE 802.15.6 link-layer addresses follows the general 349 description in section 7.2 of [RFC4861], unless otherwise specified. 350 Multicast address mapping is not supported in IEEE 802.15.6. 352 6.4. Header Compression 354 The IEEE 802.15.6 PHY layer supports a maximum PSDU (PHY Service Data 355 Unit) of 256 octets. Because of the limited PHY payload, header 356 compression at 6lo adaptation layer is of great importance and MUST 357 be applied. The compression of IPv6 datagrams within IEEE 802.15.6 358 frames refers to [RFC6282], which updates [RFC4944].Multiple header 359 compression stacks are defined in RFC6282 which specifies the 360 fragmentation methods for IPv6 datagrams on top of IEEE 361 802.15.4;however, for IEEE 802.15.6, a LoWPAN encapsulated LoWPAN_HC1 362 compressed IPv6 datagram can be used as IEEE 802.15.6 does not 363 require mesh header due to IEEE 802.15.6 communication 364 scope.Moreover, static header compression techniques of [RFC7400] can 365 also be used as header compression. 367 6.5. Fragmentation and Reassembly 369 IEEE 802.15.6 provides Fragmentation and reassembly (FAR) for payload 370 of 256 bytes. FAR as defined in [RFC4944], which specifies the 371 fragmentation methods for IPv6 datagrams on top of IEEE 802.15.4 MUST 372 be adapted to work with IEEE 802.15.6. All headers MUST be 373 compressed according to [RFC4944] encoding formats, but the default 374 MTU of IEEE 802.15.6 is 256 bytes which MUST be considered. 376 7. IANA Considerations 378 [TBD] 380 8. Security and Privacy Considerations 382 IPv6 over WBAN's applications often require confidentiality and 383 integrity protection. This can be provided at the application, 384 transport, network, and/or at the link.IEEE 802.15.6 considers the 385 security as a key requirement for healthcare applications and defines 386 a complete framework. This framework defines three levels of 387 security which can be used according to requirements.Overall, it 388 covers privacy, confidentiality, encryption and authentication.AES-64 389 is preffered for encryption due to its efficiency. 391 9. References 393 9.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, 398 . 400 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 401 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 402 December 1998, . 404 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 405 "Transmission of IPv6 Packets over IEEE 802.15.4 406 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 407 . 409 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 410 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 411 DOI 10.17487/RFC4861, September 2007, 412 . 414 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 415 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 416 2006, . 418 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 419 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 420 DOI 10.17487/RFC6282, September 2011, 421 . 423 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 424 IPv6 over Low-Power Wireless Personal Area Networks 425 (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 426 2014, . 428 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 429 Bormann, "Neighbor Discovery Optimization for IPv6 over 430 Low-Power Wireless Personal Area Networks (6LoWPANs)", 431 RFC 6775, DOI 10.17487/RFC6775, November 2012, 432 . 434 9.2. Informative References 436 [IEEE802.15.6] 437 "IEEE Standard, 802.15.6-2012 - IEEE Standard for Local 438 and metropolitan area networks - Part 15.6: Wireless Body 439 Area Networks", 2012, 440 . 443 [SURVEY-WBAN] 444 Diffie, W., Samaneh Movassaghi, Mehran Abolhasan, Justin 445 Lipman, David Smith, and Abbas Jamalipour, "Wireless body 446 area networks: A survey", Communications Surveys and 447 Tutorials, IEEE , vol. 16, no. 3, pp. 1658-1686, 2014. 449 [MAC-WBAN] 450 Minglei Shu, Dongfeng Yuan, Chongqing Zhang, Yinglong 451 Wang, and Changfang Chen, "A MAC Protocol for Medical 452 Monitoring Applications of Wireless Body Area Networks.", 453 Sensors , vol. 15, no. 6, 2015. 455 Appendix A. Patient monitoring use case - Spoke Hub 457 Refer following diagram: 459 ######## 460 # @ EEG # 461 ## | @ # Hearing 462 # | | # 463 # | |# 464 # | #| 465 ##### | |## ### 466 # | | @ ## Motion Sensor 467 Positioning# @ | / / # 468 # \ |ECG / / # 469 # \ | @ | / # 470 # \ | / / / # 471 # ## \ |/ // ## # 472 # ## \ ||// ## # 473 # # # \ |||| # # @ # BP 474 # # # \|||| # # / ## 475 # ## # |||| # #/ ## 476 SPO2# @ ## # Coordinator # /## # 477 # \ ## ## +-+ / ## ## 478 # ------+--------| |-------/ # # # 479 ## ## # +-+ ## # ## 480 ## ## # //\ # # ## 481 ### # # // \ # ## ### 482 ## # # // \ # # ## ## 483 # # # // \ # # # 484 ### # # # // ## \ # # ### 485 # ### # // # # \ # # # ### 486 ### # // # # | # # ### 487 # // # ## | # 488 Glucose Sensor # @ / # # | # 489 ## | ## # | # 490 # / # # | # 491 #/ # # | # 492 Emg#@ # # | # 493 # # ## | # 494 ## # | # 495 # # # | # 496 # # #\ # 497 # # # | # 498 # # # @ # Motion Sensor 499 ## # ## ## 500 ## # 502 Figure 4: Patient monitoring use case - Spoke Hub 504 Appendix B. Patient monitoring use case - Connected 506 Refer following diagram: 508 ######## 509 # @ EEG # 510 ## |\-----@ # Hearing 511 # | \# 512 # | # | 513 # | ## |Motion Sensor 514 ####### | ##|#### 515 # | | ## 516 Positioning# @ | @ # 517 # /\ ECG| \ # 518 # / \----------@ \ # 519 # / | # 520 # / ## ## | # 521 # / # # # # @ # BP 522 #/ ## # # ## | ## 523 SPO2# @ ## # # ## | # 524 # \ # # # #| # 525 ## ## \ # ## | # ## 526 ## # \ # # | # ## ## 527 ### # # # \ ## # | # ### 528 # ### # \ # # # | # # ### 529 ### # | # # # | # ### 530 # | # ## # | 531 Glucose Sensor # @ # # # | 532 # / # # # / 533 #| ## # #/ 534 #/ # # #| 535 Emg#@ # # #| 536 # \ # # #| 537 # \ # # #| 538 # \# ## #| 539 ## \ # #| 540 # #\ # #| 541 # # \ # #| 542 # # \ # #| 543 # # \ ## #/ 544 # # \ ## / 545 # # \ ## /# 546 ## # \ | # 547 # # # \/ # 548 # # # @ # Motion Sensor 549 ## # 551 Figure 5: Patient monitoring use case - Connected 553 Appendix C. Changes 555 Compared with version-00, this updated draft is no longer all 556 informative. Two main changes have been made as below: 558 1. Introduction part of 802.15.6 is simplified and more focused on 559 the features that relates to the 6lo-WBAN adaptation layer, e.g. 560 MAC frame format including MAC address and MTU, topology and 561 scope of communication, and why the 6lo-WBAN adaptation layer is 562 needed. 564 2. The 6lo-WBAN adaptation layer is specified in this draft titled 565 as "Specification of IPv6 over WBAN" that lists the main features 566 needs to be added in the 6lo adaptation layer including the 567 formation of IID, IPv6 link-local address, unicast address 568 mapping, header compression, and fragmentation and reassembly. 569 These parts have never been mentioned in other documents related 570 to WBAN, and in this version, we provide a guidance for such IPv6 571 enabled WBAN implementations. 573 Authors' Addresses 575 Muhammad Sajjad Akbar 576 Bournemouth University 577 Fern Barrow, Dorset 578 Poole BH12 5BB 579 United Kingdom 581 Email: makbar@bournemouth.ac.uk 583 Abdur Rashid Sangi 584 Huaiyin Institute of Technology 585 No.89 North Beijing Road, Qinghe District 586 Huaian 223001 587 P.R. China 589 Email: sangi_bahrian@yahoo.com 591 Mingui Zhang 592 Huawei Technologies 593 No. 156 Beiqing Rd. Haidian District 594 Beijing 100095 595 China 597 Email: zhangmingui@huawei.com 598 Jianqiang Hou 599 Huawei Technologies 600 101 Software Avenue 601 Nanjing 210012 602 China 604 Phone: +86 15852944235 605 Email: houjianqiang@huawei.com 607 Charles E. Perkins 608 Futurewei 609 2330 Central Expressway 610 Santa Clara 95050 611 Unites States 613 Email: charliep@computer.org 615 Alexandre Petrescu 616 CEA, LIST 617 CEA Saclay 618 Gif-sur-Yvette, Ile-de-France 91190 619 France 621 Phone: +33169089223 622 Email: alexandre.petrescu@cea.fr 624 Naveed Bin Rais 625 Ajman University 626 University Street,Al jerf 1 627 Ajman 346 628 United Arab Emirates 630 Email: naveedbinrais@gmail.com