idnits 2.17.1 draft-daniel-6lowpan-interoperability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 485. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 79 has weird spacing: '...form to the I...' == Line 283 has weird spacing: '...dresses inste...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2005) is 6837 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Normative reference to a draft: ref. 'I-D.kushalnagar-lowpan-goals-assumptions' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kim, Ed. 3 Internet-Draft S. Yoo 4 Expires: January 10, 2006 H. Kim 5 Ajou University 6 S. Daniel Park, Ed. 7 SAMSUNG Electronics 8 J. Lee 9 NCA 10 July 9, 2005 12 Interoperability of 6LoWPAN 13 draft-daniel-6lowpan-interoperability-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware have 19 been or will be disclosed, and any of which he or she becomes aware 20 will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 10, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 This document specifies the gateway architecture for the 47 interoperability between 6LoWPAN and external IPv6 networks. The 48 gateway does the compression and decompression of IPv6 packets and 49 performs the mapping between 16 bit short addresses and the IPv6 50 addresses for both the external IPv6 networks and 6LowPAN, 51 respectively. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1 Requirements notation . . . . . . . . . . . . . . . . . . 3 58 3. Gateway Architecture for Interoperability . . . . . . . . . . 4 59 3.1 Mapping Tables . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.1 Internal Device Address Mapping Table . . . . . . . . 5 61 3.1.2 External Device Address Mapping Table . . . . . . . . 6 62 3.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.3 Multiple Gateways . . . . . . . . . . . . . . . . . . . . 6 64 4. Interworking with 65 [I-D.montenegro-lowpan-ipv6-over-802.15.4] . . . . . . . . . . 7 66 5. Header Compression . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1 Compressed IPv6 Header Format . . . . . . . . . . . . . . 7 68 5.2 Transport Layer Header Fields . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 74 Intellectual Property and Copyright Statements . . . . . . . . 12 76 1. Introduction 78 6LoWPAN is an IPv6 based low-power wireless personal area network 79 which is comprised of devices that conform to the IEEE 802.15.4-2003 80 standard[ieee802.15.4]. As described in [I-D.kushalnagar-lowpan- 81 goals-assumptions], there are several issues to be solved for 82 enabling IP communication between 6LoWPAN devices. The limited 83 packet size of 6LoWPANs is one of them; The PDU size of IEEE 802.15.4 84 is 127 octets while the MTU size of IPv6 packets is 1280 octets. 85 [I-D.montenegro-lowpan-ipv6-over-802.15.4] introduces the adaption 86 layer of fragmentation and reassembly for IPv6 packets, while 87 providing a header compression scheme for reducing the size of the 88 IPv6 header. 90 The issue proposed in this document is about the interoperability 91 between the external IPv6 networks and 6LoWPAN. As shown in 92 [I-D.kushalnagar-lowpan-goals-assumptions], it is obvious that the 93 interoperability is one of the very basic requirements of providing 94 IP connectivity to 6LoWPAN. This document specifies the gateway 95 architecture for the interoperability. The gateway does the 96 compression and decompression of IPv6 packets and performs the 97 mapping between 16 bit short addresses and the IPv6 addresses for 98 both the external IPv6 networks and 6LowPAN, respectively. 100 This document is based on [I-D.montenegro-lowpan-ipv6-over-802.15.4] 101 for the adaptation layer of fragmentation and reassembly, the 102 stateless address auto-configuration based on EUI-64[EUI64], the IPv6 103 link local address, the unicast address mapping, and the encoding of 104 UDP header fields. 106 2. Terminology 108 ET: 109 Expiration Time 110 IID: 111 Interface IDentifier 112 MAC: 113 Media Access Control 114 MTU: 115 Maximum Transmission Unit 116 PAN: 117 Personal Area Network 118 PDU: 119 Protocol Data Unit 121 2.1 Requirements notation 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Gateway Architecture for Interoperability 129 This section defines the gateway architecture for the 130 interoperability between IPv6 networks and 6LoWPAN. The gateway 131 SHOULD do the fragmentation and reassembly at the sub-IP layer for 132 external IPv6 packets to/from 6LoWPAN. The main function of the 133 fragmentation and reassembly is the same as in [I-D.montenegro- 134 lowpan-ipv6-over-802.15.4] except that the traffic is come from/to 135 the external IPv6 networks. 137 The gateway SHOULD do the compression and decompression of IPv6 138 packets in between IPv6 networks and 6LoWPAN. The compression 139 implies the dettaching the 64-bit address prefix from the destination 140 address of an IPv6 packet coming from external IPv6 networks in order 141 to obtain the EUI-64 identifier for the IEEE 802.15.4 destination. 142 The decompression is the exact opposite operation to the compression. 144 The gateway MAY further compress IPv6 packets by introducing or 145 mapping (16-bit) short addresses for both the external IPv6 networks 146 and 6LoWPAN. The gateway MAY maintain mapping table(s) for this 147 translation. The mapping SHOULD be applied to both the IPv6 148 addresses of external IPv6 networks and 6LoWPAN, while the mapping 149 table entries for them are different from each other. Notice that 150 for 6LoWPAN devices, the mapping of a 16-bit short address is done 151 for the EUI-64 identifier which is obtained by the above mentioned 152 compression, not the 128-bit IPv6 address. In this document, we 153 defines two mapping table types for external IPv6 networks and 154 6LoWPAN which will be described in Section 3.1. 156 NOTE: If it uses 16-bit short address for networking in the 157 internal network, it is efficient for reducing header length, 158 routing table size, and etc as well as [I-D.montenegro-lowpan- 159 ipv6-over-802.15.4]. Thus, this document defines header 160 compression using 16-bit short address in Section 5. 162 For communicating with external IPv6 networks, there are two possible 163 traffic: inbound traffic from an external IPv6 network to an internal 164 6LoWPAN and outbound traffic from an internal 6LoWPAN to an external 165 IPv6 network. 167 Inbound traffic 168 For the destination address of an inbound IPv6 packet, the gateway 169 maps the IID of the destination to the corresponding (16-bit) 170 short address using the internal device address mapping table. 171 The assignment of the 16-bit short address for an IID depends on 172 the assignment strategy which is out of scope of this document. 173 For the source address, the gateway assigns and maps a external 174 16-bit short address in the external device address mapping table. 175 The assignment strategy for an external short address is TBD. The 176 external short address will be deleted after the expiration time 177 which will be described in Section 3.1.2. 179 Outbound traffic 180 The outbound traffic can be classified by the following two 181 categories. First category is the reply traffic for the above 182 mentioned inbound traffic. In this case, a 6LoWPAN device can use 183 16-bit short addresses for both destination and source addresses. 184 Notice that there is an assigned external short address in the 185 external device address mapping table prior to the reply traffic. 186 The outbound traffic should arrive at the gateway before the 187 expiration time of the external short address. The operation for 188 the outbound traffic after the expiration is TBD. Second category 189 is the originating outbound traffic. Because there is no mapped 190 external short address for the destination of external IPv6 191 networks, there can be no compression for the destination in this 192 case. 194 3.1 Mapping Tables 196 The gateway MAY have the internal and external device address mapping 197 tables. 199 3.1.1 Internal Device Address Mapping Table 201 This table consists of 64-bit interface identifier (IID) and 16-bit 202 short address. This table MUST contain the mapping information of 203 all the devices in 6LoWPAN. The maximum size of the mapping table is 204 2^16 entries. The case of multiple gateways (i.e. multiple mapping 205 tables) is dealt in Section 3.3. 207 64 bits 16 bits 208 +--------------------------------------+ 209 | IID | Short Addr.| 210 +--------------------------------------+ 212 214 Interface Identifier: The 64 bit IID assigned to each 6LoWPAN 215 device. 217 Short Address: The 16 bit short address assigned to each 6LoWPAN 218 device. 220 3.1.2 External Device Address Mapping Table 222 This table consists of 128-bit IPv6 address, 16-bit short address and 223 ET(Expiration Time). 225 128 bits 16 bits 8 bits 226 +-------------------------------------+------------+-------+ 227 | IPv6 Addr. | Short Addr.| ET | 228 +-------------------------------------+------------+-------+ 230 232 IPv6 Address: The IPv6 address of the external device. 234 Short Address: The 16 bit short address for the external IPv6 235 address. 237 ET: The expiration time field. 239 3.2 Registration 241 The gateway maintains the internal device mapping table for the 242 mapping of 16 bit short address for all devices in the 6LoWPAN. In 243 order to setup the table, there should be a registration procedure 244 which is TBD. 246 3.3 Multiple Gateways 248 In this document, we assume that there is one gateway for a 6LoWPAN, 249 even though the number of gateways is not restricted. The more 250 communication with external IPv6 networks, the more overheads the 251 gateway undergo. One of the methods reducing the overheads is 252 distributing the burden over multiple gateways. We will cover such 253 issues as distributed mapping of 16-bit short addresses by multiple 254 gateways and (on-demand or hierarchical) routing and tunneling 255 between gateways, in future revision. 257 4. Interworking with [I-D.montenegro-lowpan-ipv6-over-802.15.4] 259 As described in Section 1, [I-D.montenegro-lowpan-ipv6-over-802.15.4] 260 provides the transmission of IPv6 packets over IEEE 802.15.4 at the 261 sub-IP layer. Though this draft realizes the IP connectivity over 262 IEEE 802.15.4, it doesn't define interoperability with external IPv6 263 networks. If a device in internal 6LoWPAN communicates with an 264 external network by the method of this draft, the IPv6 address of a 265 device of the external network cannot be compressed. The gateway 266 architecture described in Section 3 could be effectly used for 267 handling the interoperability with external networks in 268 [I-D.montenegro-lowpan-ipv6-over-802.15.4]. 270 5. Header Compression 272 [I-D.montenegro-lowpan-ipv6-over-802.15.4] defines a method of header 273 compression by utilizing the link layer addresses at the IEEE 274 802.15.4 MAC header and defining the sub-IP layer. In this section, 275 we describe a header compression method at the IP layer. In contrast 276 to the work of [I-D.montenegro-lowpan-ipv6-over-802.15.4], the 277 compression at IP layer can have the following advantages. Firstly, 278 6LoWPAN devices does not need to perform the compression and 279 decompression to handle the lengthy IPv6 header over IEEE 802.15.4 280 packets. Because the compression at IP layer is done at the gateway, 281 not at the individual 6LoWPAN devices, communication in between 282 6LoWPAN and external IPv6 networks can only carry 16 bit short 283 addresses instead of lengthy 128 bit IPv6 addresses at IP layer. 284 Secondly, the compression at IP layer does not require to include 285 additional fields such as the final destination fields in 286 [I-D.montenegro-lowpan-ipv6-over-802.15.4], because the final 287 destination and source address could natually be included in IP layer 288 in short address form. 290 5.1 Compressed IPv6 Header Format 292 The new IPv6 header format is defined in this section. The "IP 293 encoding" field is similar to the "HC1 encoding" field of 294 [I-D.montenegro-lowpan-ipv6-over-802.15.4]. 'IP encoding' has the 295 encoding information about 'non-compressed fields' and source and 296 destination addresses. 298 The Hop Limit cannot be compressed. The reason is described in 299 [I-D.montenegro-lowpan-ipv6-over-802.15.4]. 301 1 2 3 302 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | IP encoding | Non-compressed fields | Hop Limit | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Source Address / Destination Address / 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 311 Field definitions are as follows: 313 The IP encoding is shown below (from bit 0 to bit 7) : 315 Source Addressing Mode ( bits 0 and 1 ) : 317 00 : 16-bit short address. 318 01 : external 16-bit short external address. 319 10 : 64-bit extended address. 320 11 : 128-bit IPv6 address. 322 Destination Addressing Mode ( bits 2 and 3 ) : 324 00 : 16-bit short address. 325 01 : external 16-bit short external address. 326 10 : 64-bit extended address. 327 11 : 128-bit IPv6 address. 329 Traffic Class and Flow Label ( bit 4 ) : 331 0 : not compressed, full 8 bits for Traffic Class and 20 bits 332 for Flow Label are sent. 333 1 : Traffic Class and Flow Label are zero. 335 Next Header ( bits 5 and 6 ) : 337 00 : not compressed, full 8 bits are sent. 338 01 : UDP. 339 10 : ICMP. 340 11 : TCP. 342 TRAN encoding (bit 7 ) : 344 0 : No more header compression bits. 345 1 : IP encoding immediately followed by more header compression 346 bits pre TRAN encoding format. TRAN encoding encodes the 347 compression inforamtion of the transport layer 349 Non-compressed fields : This field includes non-compressed fields 350 following bits 5, 6 and 7 of the IP encoding. Thus, the length of 351 this field is variable from 0 to 36-bit. The order of any IPv6 352 header non-compressed fields present MUST be the same as the 353 corresponding fields appear in a normal IPv6 header[RFC2460]. 355 Hop Limit : 8-bit unsigned integer. Decremented by 1 by each node 356 that forwards the packet. The packet is discarded if Hop Limit is 357 decremented to zero. 359 Source Address : 16-bit, 64-bit or 128-bit address of the originator 360 of the packet following the Source Addressing Mode value of the IP 361 encoding field. 363 Destination Address : 16-bit, 64-bit or 128-bit address of the 364 intended recipient of the packet following the Source Addressing 365 Mode value of the IP encoding field. 367 5.2 Transport Layer Header Fields 369 This document provides 3 transport protocols(TCP, UDP, ICMP) 370 basically as stated at [I-D.montenegro-lowpan-ipv6-over-802.15.4]. 371 First of all, the method compressing UDP header follows 372 [I-D.montenegro-lowpan-ipv6-over-802.15.4] and methods compressing 373 TCP and ICMP is TBD. 375 6. IANA Considerations 377 There is at the time of this publication no IANA consideration. 379 7. Security Considerations 381 TBD 383 8. Acknowledgements 385 Thanks to Prof. Byeong-Hee Roh, Jea Tek Ryu, and Minho Lee for their 386 useful discussions and supports for writing this document. 388 9. References 390 [EUI64] IEEE 391 http://standards.ieee.org/regauth/oui/tutorials/ 392 EUI64.html, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER 393 (EUI-64) REGISTRATION AUTHORITY". 395 [I-D.kushalnagar-lowpan-goals-assumptions] 396 Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 397 Assumptions, Problem Statement and Goals", 398 draft-kushalnagar-lowpan-goals-assumptions-00 (work in 399 progress), February 2005. 401 [I-D.montenegro-lowpan-ipv6-over-802.15.4] 402 Montenegro, G., "Transmission of IPv6 Packets over IEEE 403 802.15.4 Networks", 404 draft-montenegro-lowpan-ipv6-over-802.15.4-02 (work in 405 progress), February 2005. 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 411 (IPv6) Specification", RFC 2460, December 1998. 413 [ieee802.15.4] 414 IEEE Compure Society, "IEEE Std. 802.15.4-2003", IEEE Std. 415 802.15.4-2003, October 2003. 417 Authors' Addresses 419 Ki-Hyung Kim, Editor 420 Ajou University 421 San 5 Wonchun-dong, Yeongtong-gu 422 Suwon-si, Gyeonggi-do 442-749 423 KOREA 425 Phone: +82 31 219 2433 426 Email: kkim86@ajou.ac.kr 428 Seung Wha Yoo 429 Ajou University 430 San 5 Wonchun-dong, Yeongtong-gu 431 Suwon-si, Gyeonggi-do 442-749 432 KOREA 434 Phone: +82 31 219 1603 435 Email: swyoo@ajou.ac.kr 436 Hee Jung Kim 437 Ajou University 438 San 5 Wonchun-dong, Yeongtong-gu 439 Suwon-si, Gyeonggi-do 442-749 440 KOREA 442 Phone: +82 31 219 1895 443 Email: rla81@ajou.ac.kr 445 Soohong Daniel Park, Editor 446 Mobile Platform Laboratory, SAMSUNG Electronics 447 416 Maetan-3dong, Yeongtong-gu 448 Suwon-si, Gyeonggi-do 442-742 449 KOREA 451 Phone: +82 31 200 4508 452 Email: soohong.park@samsung.com 454 Jae Ho Lee 455 National Computerization Agency 456 NCA Bldg, 77, Mugyo-dong, Chung-ku 457 Seoul, 100-775 458 KOREA 460 Phone: +82 2 2131 0250 461 Email: ljh@nca.or.kr 463 Intellectual Property Statement 465 The IETF takes no position regarding the validity or scope of any 466 Intellectual Property Rights or other rights that might be claimed to 467 pertain to the implementation or use of the technology described in 468 this document or the extent to which any license under such rights 469 might or might not be available; nor does it represent that it has 470 made any independent effort to identify any such rights. Information 471 on the procedures with respect to rights in RFC documents can be 472 found in BCP 78 and BCP 79. 474 Copies of IPR disclosures made to the IETF Secretariat and any 475 assurances of licenses to be made available, or the result of an 476 attempt made to obtain a general license or permission for the use of 477 such proprietary rights by implementers or users of this 478 specification can be obtained from the IETF on-line IPR repository at 479 http://www.ietf.org/ipr. 481 The IETF invites any interested party to bring to its attention any 482 copyrights, patents or patent applications, or other proprietary 483 rights that may cover technology that may be required to implement 484 this standard. Please address the information to the IETF at 485 ietf-ipr@ietf.org. 487 Disclaimer of Validity 489 This document and the information contained herein are provided on an 490 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 491 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 492 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 493 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 494 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 495 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 497 Copyright Statement 499 Copyright (C) The Internet Society (2005). This document is subject 500 to the rights, licenses and restrictions contained in BCP 78, and 501 except as set forth therein, the authors retain all their rights. 503 Acknowledgment 505 Funding for the RFC Editor function is currently provided by the 506 Internet Society.