Network Working Group K. Kim, Ed. Internet-Draft S. Yoo Expires: January 10, 2006 H. Kim Ajou University S. Daniel Park, Ed. SAMSUNG Electronics J. Lee NCA July 9, 2005 Interoperability of 6LoWPAN draft-daniel-6lowpan-interoperability-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies the gateway architecture for the Kim, et al. Expires January 10, 2006 [Page 1] Internet-Draft Interoperability of 6LoWPAN July 2005 interoperability between 6LoWPAN and external IPv6 networks. The gateway does the compression and decompression of IPv6 packets and performs the mapping between 16 bit short addresses and the IPv6 addresses for both the external IPv6 networks and 6LowPAN, respectively. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Requirements notation . . . . . . . . . . . . . . . . . . 4 3. Gateway Architecture for Interoperability . . . . . . . . . . 4 3.1 Mapping Tables . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1 Internal Device Address Mapping Table . . . . . . . . 6 3.1.2 External Device Address Mapping Table . . . . . . . . 6 3.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Multiple Gateways . . . . . . . . . . . . . . . . . . . . 7 4. Header Compression . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 10 Kim, et al. Expires January 16, 2006 [Page 2] Internet-Draft Interoperability of 6LoWPAN July 2005 1. Introduction 6LoWPAN is an IPv6 based low-power wireless personal area network which is comprised of devices that conform to the IEEE 802.15.4-2003 standard[ieee802.15.4]. As described in [I-D.kushalnagar-lowpan- goals-assumptions], there are several issues to be solved for enabling IP communication between 6LoWPAN devices. The limited packet size of 6LoWPANs is one of them; The PDU size of IEEE 802.15.4 is 127 octets while the MTU size of IPv6 packets is 1280 octets. [I-D.montenegro-lowpan-ipv6-over-802.15.4] introduces the adaption layer of fragmentation and reassembly for IPv6 packets, while providing a header compression scheme for reducing the size of the IPv6 header. The issue proposed in this document is about the interoperability between the external IPv6 networks and 6LoWPAN. As shown in [I-D.kushalnagar-lowpan-goals-assumptions], it is obvious that the interoperability is one of the very basic requirements of providing IP connectivity to 6LoWPAN. This document specifies the gateway architecture for the interoperability. The gateway does the compression and decompression of IPv6 packets and performs the mapping between 16 bit short addresses and the IPv6 addresses for both the external IPv6 networks and 6LowPAN, respectively. [I-D.montenegro-lowpan-ipv6-over-802.15.4] didn't define transmission between external IPv6 networks and 6LoWPAN. For external IPv6 packets, it cannot compress the address of the packets. So, the mapping between 16-bit short addresses and the IPv6 addresses is necessary in order to communicate with external IPv6 networks. Notice that the mapping is not about 64-bit extend addresses but 16- bit short addresses. The reason is why using 16-bit short addresses is more efficient for the transmission than 64-bit extend addresses. So, this document describes the mapping 16-bit short addresses from the addresses for 6LoWPAN as well as the mapping for external IPv6 networks. This document is based on [I-D.montenegro-lowpan-ipv6-over-802.15.4] for the adaptation layer of fragmentation and reassembly, the stateless address auto-configuration based on EUI-64[EUI64], the IPv6 link local address, the unicast address mapping, and the encoding of UDP header fields. 2. Terminology Kim, et al. Expires January 16, 2006 [Page 3] Internet-Draft Interoperability of 6LoWPAN July 2005 ET: Expiration Time IID: Interface IDentifier MAC: Media Access Control MTU: Maximum Transmission Unit PAN: Personal Area Network PDU: Protocol Data Unit 2.1 Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Gateway Architecture for Interoperability This section defines the gateway architecture for the interoperability between IPv6 networks and 6LoWPAN. The gateway SHOULD do the fragmentation and reassembly at the sub-IP layer for external IPv6 packets to/from 6LoWPAN. The main function of the fragmentation and reassembly is the same as in [I-D.montenegro- lowpan-ipv6-over-802.15.4] except that the traffic is come from/to the external IPv6 networks. The gateway SHOULD do the compression and decompression of IPv6 packets in between IPv6 networks and 6LoWPAN. The compression implies the dettaching the 64-bit address prefix from the destination address of an IPv6 packet coming from external IPv6 networks in order to obtain the EUI-64 identifier for the IEEE 802.15.4 destination. The decompression is the exact opposite operation to the compression. The gateway MAY further compress IPv6 packets by introducing or mapping (16-bit) short addresses for both the external IPv6 networks and 6LoWPAN. The gateway MAY maintain mapping table(s) for this translation. The mapping SHOULD be applied to both the IPv6 addresses of external IPv6 networks and 6LoWPAN, while the mapping table entries for them are different from each other. Notice that for 6LoWPAN devices, the mapping of a 16-bit short address is done for the EUI-64 identifier which is obtained by the above mentioned compression, not the 128-bit IPv6 address. In this document, we defines two mapping table types for external IPv6 networks and 6LoWPAN which will be described in Section 3.1. Kim, et al. Expires January 16, 2006 [Page 4] Internet-Draft Interoperability of 6LoWPAN July 2005 For communicating with external IPv6 networks, there are two possible traffic: inbound traffic from an external IPv6 network to an internal 6LoWPAN and outbound traffic from an internal 6LoWPAN to an external IPv6 network. Inbound traffic For the destination address of an inbound IPv6 packet, the gateway maps the IID of the destination to the corresponding (16-bit) short address using the internal device address mapping table. In a compressed packet, the short address is put into the 'Address of final destination' field of the final destination field and the 'S' field is set 1 in sub-IP. The assignment of the 16-bit short address for an IID depends on the assignment strategy which is out of scope of this document. For the source address, the gateway assigns and maps an external 16-bit short address in the external device address mapping table. The assignment strategy for an external short address is TBD. The external short address will be deleted after the expiration time which will be described in Section 3.1.2. Note: [I-D.montenegro-lowpan-ipv6-over-802.15.4] did not describe about the source address of the originator though do about the final destination field. The context for the source address is valid if and only if it defines the source address of the originator in sub-IP. Outbound traffic The outbound traffic can be classified by the following two categories. First category is the reply traffic for the above mentioned inbound traffic. In this case, a 6LoWPAN device can use 16-bit short addresses for both destination and source addresses. Notice that there is an assigned external short address in the external device address mapping table prior to the reply traffic and the definition for the source addressof the originator in sub-IP. The outbound traffic should arrive at the gateway before the expiration time of the external short address. The operation for the outbound traffic after the expiration is TBD. Second category is the originating outbound traffic. Because there is no mapped external short address for the destination of external IPv6 networks, there can be no compression for the destination in this case. 3.1 Mapping Tables The gateway MAY have the internal and external device address mapping tables. Kim, et al. Expires January 16, 2006 [Page 5] Internet-Draft Interoperability of 6LoWPAN July 2005 3.1.1 Internal Device Address Mapping Table This table consists of 64-bit interface identifier (IID) and 16-bit short address. This table MUST contain the mapping information of all the devices in 6LoWPAN. The maximum size of the mapping table is 2^16 entries. The case of multiple gateways (i.e. multiple mapping tables) is dealt in Section 3.3. 64 bits 16 bits +--------------------------------------+ | IID | Short Addr.| +--------------------------------------+ Interface Identifier: The 64 bit IID assigned to each 6LoWPAN device. Short Address: The 16 bit short address assigned to each 6LoWPAN device. 3.1.2 External Device Address Mapping Table This table consists of 128-bit IPv6 address, 16-bit short address and ET(Expiration Time). 128 bits 16 bits 8 bits +-------------------------------------+------------+-------+ | IPv6 Addr. | Short Addr.| ET | +-------------------------------------+------------+-------+ IPv6 Address: The IPv6 address of the external device. Short Address: The 16 bit short address for the external IPv6 address. Kim, et al. Expires January 16, 2006 [Page 6] Internet-Draft Interoperability of 6LoWPAN July 2005 ET: The expiration time field. 3.2 Registration The gateway maintains the internal device mapping table for the mapping of 16 bit short address for all devices in the 6LoWPAN. In order to setup the table, there should be a registration procedure which is TBD. 3.3 Multiple Gateways In this document, we assume that there is one gateway for a 6LoWPAN, even though the number of gateways is not restricted. The more communication with external IPv6 networks, the more overheads the gateway undergo. One of the methods reducing the overheads is distributing the burden over multiple gateways. We will cover such issues as distributed mapping of 16-bit short addresses by multiple gateways and (on-demand or hierarchical) routing and tunneling between gateways, in future revision. 4. Header Compression The method of the header compression follows [I-D.montenegro- lowpan-ipv6-over-802.15.4]. The size of the address in the 'M' field is reduced because the gateway maps 64-bit link-layer addresses to 16-bit short addresses. 5. IANA Considerations There is at the time of this publication no IANA consideration. 6. Security Considerations TBD 7. Acknowledgements Thanks to Prof. Byeong-Hee Roh, Jea Tek Ryu, and Minho Lee for their useful discussions and supports for writing this document. 8. References [EUI64] IEEE http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY". Kim, et al. Expires January 16, 2006 [Page 7] Internet-Draft Interoperability of 6LoWPAN July 2005 [I-D.kushalnagar-lowpan-goals-assumptions] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview, Assumptions, Problem Statement and Goals", draft-kushalnagar-lowpan-goals-assumptions-00 (work in progress), February 2005. [I-D.montenegro-lowpan-ipv6-over-802.15.4] Montenegro, G., "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", draft-montenegro-lowpan-ipv6-over-802.15.4-02 (work in progress), February 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [ieee802.15.4] IEEE Compure Society, "IEEE Std. 802.15.4-2003", IEEE Std. 802.15.4-2003, October 2003. Authors' Addresses Ki-Hyung Kim Ajou University San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 2433 Email: kkim86@ajou.ac.kr Seung Wha Yoo Ajou University San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 1603 Email: swyoo@ajou.ac.kr Kim, et al. Expires January 16, 2006 [Page 8] Internet-Draft Interoperability of 6LoWPAN July 2005 Hee Jung Kim Ajou University San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 1895 Email: rla81@ajou.ac.kr Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-742 KOREA Phone: +82 31 200 4508 Email: soohong.park@samsung.com Jae Ho Lee National Computerization Agency NCA Bldg, 77, Mugyo-dong, Chung-ku Seoul, 100-775 KOREA Phone: +82 2 2131 0250 Email: ljh@nca.or.kr Kim, et al. Expires January 16, 2006 [Page 9] Internet-Draft Interoperability of 6LoWPAN July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kim, et al. Expires January 16, 2006 [Page 10]