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-00.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 . . . . . . . . . . . . . . . . . . 3 3. Gateway Architecture for Interoperability . . . . . . . . . . 4 3.1 Mapping Tables . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1 Internal Device Address Mapping Table . . . . . . . . 5 3.1.2 External Device Address Mapping Table . . . . . . . . 6 3.2 Registration . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Multiple Gateways . . . . . . . . . . . . . . . . . . . . 6 4. Interworking with [I-D.montenegro-lowpan-ipv6-over-802.15.4] . . . . . . . . . . 7 5. Header Compression . . . . . . . . . . . . . . . . . . . . . . 7 5.1 Compressed IPv6 Header Format . . . . . . . . . . . . . . 7 5.2 Transport Layer Header Fields . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 12 Kim, et al. Expires January 10, 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. 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 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", Kim, et al. Expires January 10, 2006 [Page 3] Internet-Draft Interoperability of 6LoWPAN July 2005 "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. NOTE: If it uses 16-bit short address for networking in the internal network, it is efficient for reducing header length, routing table size, and etc as well as [I-D.montenegro-lowpan- ipv6-over-802.15.4]. Thus, this document defines header compression using 16-bit short address in Section 5. 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 Kim, et al. Expires January 10, 2006 [Page 4] Internet-Draft Interoperability of 6LoWPAN July 2005 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. 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 a 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. 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. 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. 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.| +--------------------------------------+ Kim, et al. Expires January 10, 2006 [Page 5] Internet-Draft Interoperability of 6LoWPAN July 2005 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. 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. Kim, et al. Expires January 10, 2006 [Page 6] Internet-Draft Interoperability of 6LoWPAN July 2005 4. Interworking with [I-D.montenegro-lowpan-ipv6-over-802.15.4] As described in Section 1, [I-D.montenegro-lowpan-ipv6-over-802.15.4] provides the transmission of IPv6 packets over IEEE 802.15.4 at the sub-IP layer. Though this draft realizes the IP connectivity over IEEE 802.15.4, it doesn't define interoperability with external IPv6 networks. If a device in internal 6LoWPAN communicates with an external network by the method of this draft, the IPv6 address of a device of the external network cannot be compressed. The gateway architecture described in Section 3 could be effectly used for handling the interoperability with external networks in [I-D.montenegro-lowpan-ipv6-over-802.15.4]. 5. Header Compression [I-D.montenegro-lowpan-ipv6-over-802.15.4] defines a method of header compression by utilizing the link layer addresses at the IEEE 802.15.4 MAC header and defining the sub-IP layer. In this section, we describe a header compression method at the IP layer. In contrast to the work of [I-D.montenegro-lowpan-ipv6-over-802.15.4], the compression at IP layer can have the following advantages. Firstly, 6LoWPAN devices does not need to perform the compression and decompression to handle the lengthy IPv6 header over IEEE 802.15.4 packets. Because the compression at IP layer is done at the gateway, not at the individual 6LoWPAN devices, communication in between 6LoWPAN and external IPv6 networks can only carry 16 bit short addresses instead of lengthy 128 bit IPv6 addresses at IP layer. Secondly, the compression at IP layer does not require to include additional fields such as the final destination fields in [I-D.montenegro-lowpan-ipv6-over-802.15.4], because the final destination and source address could natually be included in IP layer in short address form. 5.1 Compressed IPv6 Header Format The new IPv6 header format is defined in this section. The "IP encoding" field is similar to the "HC1 encoding" field of [I-D.montenegro-lowpan-ipv6-over-802.15.4]. 'IP encoding' has the encoding information about 'non-compressed fields' and source and destination addresses. The Hop Limit cannot be compressed. The reason is described in [I-D.montenegro-lowpan-ipv6-over-802.15.4]. Kim, et al. Expires January 10, 2006 [Page 7] Internet-Draft Interoperability of 6LoWPAN July 2005 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP encoding | Non-compressed fields | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address / Destination Address / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field definitions are as follows: The IP encoding is shown below (from bit 0 to bit 7) : Source Addressing Mode ( bits 0 and 1 ) : 00 : 16-bit short address. 01 : external 16-bit short external address. 10 : 64-bit extended address. 11 : 128-bit IPv6 address. Destination Addressing Mode ( bits 2 and 3 ) : 00 : 16-bit short address. 01 : external 16-bit short external address. 10 : 64-bit extended address. 11 : 128-bit IPv6 address. Traffic Class and Flow Label ( bit 4 ) : 0 : not compressed, full 8 bits for Traffic Class and 20 bits for Flow Label are sent. 1 : Traffic Class and Flow Label are zero. Next Header ( bits 5 and 6 ) : 00 : not compressed, full 8 bits are sent. 01 : UDP. 10 : ICMP. 11 : TCP. TRAN encoding (bit 7 ) : Kim, et al. Expires January 10, 2006 [Page 8] Internet-Draft Interoperability of 6LoWPAN July 2005 0 : No more header compression bits. 1 : IP encoding immediately followed by more header compression bits pre TRAN encoding format. TRAN encoding encodes the compression inforamtion of the transport layer Non-compressed fields : This field includes non-compressed fields following bits 5, 6 and 7 of the IP encoding. Thus, the length of this field is variable from 0 to 36-bit. The order of any IPv6 header non-compressed fields present MUST be the same as the corresponding fields appear in a normal IPv6 header[RFC2460]. Hop Limit : 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. Source Address : 16-bit, 64-bit or 128-bit address of the originator of the packet following the Source Addressing Mode value of the IP encoding field. Destination Address : 16-bit, 64-bit or 128-bit address of the intended recipient of the packet following the Source Addressing Mode value of the IP encoding field. 5.2 Transport Layer Header Fields This document provides 3 transport protocols(TCP, UDP, ICMP) basically as stated at [I-D.montenegro-lowpan-ipv6-over-802.15.4]. First of all, the method compressing UDP header follows [I-D.montenegro-lowpan-ipv6-over-802.15.4] and methods compressing TCP and ICMP is TBD. 6. IANA Considerations There is at the time of this publication no IANA consideration. 7. Security Considerations TBD 8. Acknowledgements Thanks to Prof. Byeong-Hee Roh, Jea Tek Ryu, and Minho Lee for their useful discussions and supports for writing this document. 9. References [EUI64] IEEE http://standards.ieee.org/regauth/oui/tutorials/ Kim, et al. Expires January 10, 2006 [Page 9] Internet-Draft Interoperability of 6LoWPAN July 2005 EUI64.html, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY". [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, Editor 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 10, 2006 [Page 10] 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, Editor 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 10, 2006 [Page 11] 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 10, 2006 [Page 12]