idnits 2.17.1 draft-daniel-6lowpan-interoperability-01.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 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 385. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 75 has weird spacing: '...form to the I...' -- 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 6866 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) == Unused Reference: 'RFC2460' is defined on line 310, but no explicit reference was found in the text -- 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: 5 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-01.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 19 have been or will be disclosed, and any of which he or she becomes 20 aware 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 . . . . . . . . . . . . . . . . . . 4 58 3. Gateway Architecture for Interoperability . . . . . . . . . . 4 59 3.1 Mapping Tables . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.1 Internal Device Address Mapping Table . . . . . . . . 6 61 3.1.2 External Device Address Mapping Table . . . . . . . . 6 62 3.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.3 Multiple Gateways . . . . . . . . . . . . . . . . . . . . 7 64 4. Header Compression . . . . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 70 Intellectual Property and Copyright Statements . . . . . . . . 10 72 1. Introduction 74 6LoWPAN is an IPv6 based low-power wireless personal area network 75 which is comprised of devices that conform to the IEEE 802.15.4-2003 76 standard[ieee802.15.4]. As described in [I-D.kushalnagar-lowpan- 77 goals-assumptions], there are several issues to be solved for 78 enabling IP communication between 6LoWPAN devices. The limited 79 packet size of 6LoWPANs is one of them; The PDU size of IEEE 802.15.4 80 is 127 octets while the MTU size of IPv6 packets is 1280 octets. 81 [I-D.montenegro-lowpan-ipv6-over-802.15.4] introduces the adaption 82 layer of fragmentation and reassembly for IPv6 packets, while 83 providing a header compression scheme for reducing the size of the 84 IPv6 header. 86 The issue proposed in this document is about the interoperability 87 between the external IPv6 networks and 6LoWPAN. As shown in 88 [I-D.kushalnagar-lowpan-goals-assumptions], it is obvious that the 89 interoperability is one of the very basic requirements of providing 90 IP connectivity to 6LoWPAN. This document specifies the gateway 91 architecture for the interoperability. The gateway does the 92 compression and decompression of IPv6 packets and performs the 93 mapping between 16 bit short addresses and the IPv6 addresses for 94 both the external IPv6 networks and 6LowPAN, respectively. 96 [I-D.montenegro-lowpan-ipv6-over-802.15.4] didn't define transmission 97 between external IPv6 networks and 6LoWPAN. For external IPv6 98 packets, it cannot compress the address of the packets. So, the 99 mapping between 16-bit short addresses and the IPv6 addresses is 100 necessary in order to communicate with external IPv6 networks. 101 Notice that the mapping is not about 64-bit extend addresses but 16- 102 bit short addresses. The reason is why using 16-bit short addresses 103 is more efficient for the transmission than 64-bit extend addresses. 104 So, this document describes the mapping 16-bit short addresses from 105 the addresses for 6LoWPAN as well as the mapping for external IPv6 106 networks. 108 This document is based on [I-D.montenegro-lowpan-ipv6-over-802.15.4] 109 for the adaptation layer of fragmentation and reassembly, the 110 stateless address auto-configuration based on EUI-64[EUI64], the IPv6 111 link local address, the unicast address mapping, and the encoding of 112 UDP header fields. 114 2. Terminology 115 ET: 116 Expiration Time 117 IID: 118 Interface IDentifier 119 MAC: 120 Media Access Control 121 MTU: 122 Maximum Transmission Unit 123 PAN: 124 Personal Area Network 125 PDU: 126 Protocol Data Unit 128 2.1 Requirements notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Gateway Architecture for Interoperability 136 This section defines the gateway architecture for the 137 interoperability between IPv6 networks and 6LoWPAN. The gateway 138 SHOULD do the fragmentation and reassembly at the sub-IP layer for 139 external IPv6 packets to/from 6LoWPAN. The main function of the 140 fragmentation and reassembly is the same as in [I-D.montenegro- 141 lowpan-ipv6-over-802.15.4] except that the traffic is come from/to 142 the external IPv6 networks. 144 The gateway SHOULD do the compression and decompression of IPv6 145 packets in between IPv6 networks and 6LoWPAN. The compression 146 implies the dettaching the 64-bit address prefix from the destination 147 address of an IPv6 packet coming from external IPv6 networks in order 148 to obtain the EUI-64 identifier for the IEEE 802.15.4 destination. 149 The decompression is the exact opposite operation to the compression. 151 The gateway MAY further compress IPv6 packets by introducing or 152 mapping (16-bit) short addresses for both the external IPv6 networks 153 and 6LoWPAN. The gateway MAY maintain mapping table(s) for this 154 translation. The mapping SHOULD be applied to both the IPv6 155 addresses of external IPv6 networks and 6LoWPAN, while the mapping 156 table entries for them are different from each other. Notice that 157 for 6LoWPAN devices, the mapping of a 16-bit short address is done 158 for the EUI-64 identifier which is obtained by the above mentioned 159 compression, not the 128-bit IPv6 address. In this document, we 160 defines two mapping table types for external IPv6 networks and 161 6LoWPAN which will be described in Section 3.1. 163 For communicating with external IPv6 networks, there are two possible 164 traffic: inbound traffic from an external IPv6 network to an internal 165 6LoWPAN and outbound traffic from an internal 6LoWPAN to an external 166 IPv6 network. 168 Inbound traffic 169 For the destination address of an inbound IPv6 packet, the gateway 170 maps the IID of the destination to the corresponding (16-bit) 171 short address using the internal device address mapping table. In 172 a compressed packet, the short address is put into the 'Address of 173 final destination' field of the final destination field and the 174 'S' field is set 1 in sub-IP. The assignment of the 16-bit short 175 address for an IID depends on the assignment strategy which is out 176 of scope of this document. For the source address, the gateway 177 assigns and maps an external 16-bit short address in the external 178 device address mapping table. The assignment strategy for an 179 external short address is TBD. The external short address will be 180 deleted after the expiration time which will be described in 181 Section 3.1.2. 183 Note: [I-D.montenegro-lowpan-ipv6-over-802.15.4] did not describe 184 about the source address of the originator though do about the 185 final destination field. The context for the source address is 186 valid if and only if it defines the source address of the 187 originator in sub-IP. 189 Outbound traffic 190 The outbound traffic can be classified by the following two 191 categories. First category is the reply traffic for the above 192 mentioned inbound traffic. In this case, a 6LoWPAN device can use 193 16-bit short addresses for both destination and source addresses. 194 Notice that there is an assigned external short address in the 195 external device address mapping table prior to the reply traffic 196 and the definition for the source addressof the originator in 197 sub-IP. The outbound traffic should arrive at the gateway before 198 the expiration time of the external short address. The operation 199 for the outbound traffic after the expiration is TBD. Second 200 category is the originating outbound traffic. Because there is no 201 mapped external short address for the destination of external IPv6 202 networks, there can be no compression for the destination in this 203 case. 205 3.1 Mapping Tables 207 The gateway MAY have the internal and external device address mapping 208 tables. 210 3.1.1 Internal Device Address Mapping Table 212 This table consists of 64-bit interface identifier (IID) and 16-bit 213 short address. This table MUST contain the mapping information of 214 all the devices in 6LoWPAN. The maximum size of the mapping table is 215 2^16 entries. The case of multiple gateways (i.e. multiple mapping 216 tables) is dealt in Section 3.3. 218 64 bits 16 bits 219 +--------------------------------------+ 220 | IID | Short Addr.| 221 +--------------------------------------+ 223 225 Interface Identifier: The 64 bit IID assigned to each 6LoWPAN 226 device. 228 Short Address: The 16 bit short address assigned to each 6LoWPAN 229 device. 231 3.1.2 External Device Address Mapping Table 233 This table consists of 128-bit IPv6 address, 16-bit short address and 234 ET(Expiration Time). 236 128 bits 16 bits 8 bits 237 +-------------------------------------+------------+-------+ 238 | IPv6 Addr. | Short Addr.| ET | 239 +-------------------------------------+------------+-------+ 241 243 IPv6 Address: The IPv6 address of the external device. 245 Short Address: The 16 bit short address for the external IPv6 246 address. 248 ET: The expiration time field. 250 3.2 Registration 252 The gateway maintains the internal device mapping table for the 253 mapping of 16 bit short address for all devices in the 6LoWPAN. In 254 order to setup the table, there should be a registration procedure 255 which is TBD. 257 3.3 Multiple Gateways 259 In this document, we assume that there is one gateway for a 6LoWPAN, 260 even though the number of gateways is not restricted. The more 261 communication with external IPv6 networks, the more overheads the 262 gateway undergo. One of the methods reducing the overheads is 263 distributing the burden over multiple gateways. We will cover such 264 issues as distributed mapping of 16-bit short addresses by multiple 265 gateways and (on-demand or hierarchical) routing and tunneling 266 between gateways, in future revision. 268 4. Header Compression 270 The method of the header compression follows [I-D.montenegro- 271 lowpan-ipv6-over-802.15.4]. The size of the address in the 'M' field 272 is reduced because the gateway maps 64-bit link-layer addresses to 273 16-bit short addresses. 275 5. IANA Considerations 277 There is at the time of this publication no IANA consideration. 279 6. Security Considerations 281 TBD 283 7. Acknowledgements 285 Thanks to Prof. Byeong-Hee Roh, Jea Tek Ryu, and Minho Lee for their 286 useful discussions and supports for writing this document. 288 8. References 290 [EUI64] IEEE 291 http://standards.ieee.org/regauth/oui/tutorials/ 292 EUI64.html, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER 293 (EUI-64) REGISTRATION AUTHORITY". 295 [I-D.kushalnagar-lowpan-goals-assumptions] 296 Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, 297 Assumptions, Problem Statement and Goals", 298 draft-kushalnagar-lowpan-goals-assumptions-00 (work in 299 progress), February 2005. 301 [I-D.montenegro-lowpan-ipv6-over-802.15.4] 302 Montenegro, G., "Transmission of IPv6 Packets over IEEE 303 802.15.4 Networks", 304 draft-montenegro-lowpan-ipv6-over-802.15.4-02 (work in 305 progress), February 2005. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 311 (IPv6) Specification", RFC 2460, December 1998. 313 [ieee802.15.4] 314 IEEE Compure Society, "IEEE Std. 802.15.4-2003", IEEE Std. 315 802.15.4-2003, October 2003. 317 Authors' Addresses 319 Ki-Hyung Kim 320 Ajou University 321 San 5 Wonchun-dong, Yeongtong-gu 322 Suwon-si, Gyeonggi-do 442-749 323 KOREA 325 Phone: +82 31 219 2433 326 Email: kkim86@ajou.ac.kr 328 Seung Wha Yoo 329 Ajou University 330 San 5 Wonchun-dong, Yeongtong-gu 331 Suwon-si, Gyeonggi-do 442-749 332 KOREA 334 Phone: +82 31 219 1603 335 Email: swyoo@ajou.ac.kr 336 Hee Jung Kim 337 Ajou University 338 San 5 Wonchun-dong, Yeongtong-gu 339 Suwon-si, Gyeonggi-do 442-749 340 KOREA 342 Phone: +82 31 219 1895 343 Email: rla81@ajou.ac.kr 345 Soohong Daniel Park 346 Mobile Platform Laboratory, SAMSUNG Electronics 347 416 Maetan-3dong, Yeongtong-gu 348 Suwon-si, Gyeonggi-do 442-742 349 KOREA 351 Phone: +82 31 200 4508 352 Email: soohong.park@samsung.com 354 Jae Ho Lee 355 National Computerization Agency 356 NCA Bldg, 77, Mugyo-dong, Chung-ku 357 Seoul, 100-775 358 KOREA 360 Phone: +82 2 2131 0250 361 Email: ljh@nca.or.kr 363 Intellectual Property Statement 365 The IETF takes no position regarding the validity or scope of any 366 Intellectual Property Rights or other rights that might be claimed to 367 pertain to the implementation or use of the technology described in 368 this document or the extent to which any license under such rights 369 might or might not be available; nor does it represent that it has 370 made any independent effort to identify any such rights. Information 371 on the procedures with respect to rights in RFC documents can be 372 found in BCP 78 and BCP 79. 374 Copies of IPR disclosures made to the IETF Secretariat and any 375 assurances of licenses to be made available, or the result of an 376 attempt made to obtain a general license or permission for the use of 377 such proprietary rights by implementers or users of this 378 specification can be obtained from the IETF on-line IPR repository at 379 http://www.ietf.org/ipr. 381 The IETF invites any interested party to bring to its attention any 382 copyrights, patents or patent applications, or other proprietary 383 rights that may cover technology that may be required to implement 384 this standard. Please address the information to the IETF at 385 ietf-ipr@ietf.org. 387 Disclaimer of Validity 389 This document and the information contained herein are provided on an 390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 392 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 393 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 394 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 397 Copyright Statement 399 Copyright (C) The Internet Society (2005). This document is subject 400 to the rights, licenses and restrictions contained in BCP 78, and 401 except as set forth therein, the authors retain all their rights. 403 Acknowledgment 405 Funding for the RFC Editor function is currently provided by the 406 Internet Society.