6LowPAN Network Working Group Hyun K. Kahng Internet Draft Dae-In, Choi Expires: March 31, 2011 Korea University Suyeon, Kim Mobilab October 14, 2010 Global connectivity in 6LoWPAN draft-kahng-6lowpan-global-connectivity-00.txt Abstract This document specifies the translation mechanism mapping IPv6 address with 128 bits to the Adaptation Identifier (AID) with shorter length. When a device in IEEE802.15.4 domain needs to communicate with other nodes in IPv6 domain, it should acquire source AID and destination AID corresponding to source IPv6 address and destination IPv6 address, respectively from an IPv6 translation-capable gateway. The device will send packets using those AIDs to the gateway, and then the gateway will translate them to normal IPv6 addresses. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. 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." Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Hyun-Kook Kahng Expires: March 31, 2011 [Page 1] Internet-Draft Global-connectivity October 2010 Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 2 2. Terminology ................................................. 3 3. Global Connectivity in 6LoWPAN .............................. 3 3.1. AID for outbound traffic ............................... 4 3.2. AID for inbound traffic ................................ 4 3.3. AID Assignment in the Gateway .......................... 5 3.4. AID deletion in the Gateway ............................ 5 4. Mapping Table Global Connectivity in 6LoWPAN ................ 5 5. Messages for AID Assignment ................................. 6 6. Formal Syntax ............................................... 6 7. Security Considerations ..................................... 6 8. IANA Considerations ......................................... 6 9. References .................................................. 7 9.1. Normative References ................................... 7 9.2. Informative References ................................. 7 Authors' Addresses ............................................. 8 1. Introduction IETF 6LoWPAN is an IPv6 based low-power wireless area network and has been working for IPv6 packets to be sent to and received from over IEEE 802.15.4 based networks for applications which require wireless internet connectivity at lower data rates for devices. However it is well known that the management of addresses for devices that communicate across the two dissimilar domains of IPv6 and IEEE802.15.4 is complicated. Routing itself is another problem especially between the IPv6 domain and the IEEE802.15.4 domain. IEEE802.15.4 standard packet size is 127 bytes, among which IEEE 64 bit extended addresses may be used. After an association, 16 bits are used as a unique ID in a PAN L2, Still only 102 bytes are available for payload at MAC layer. Now considering the devices need to communicate with other nodes via IPv6 domain, 256 bits of the source and destination addresses seem to be cumbersome in a limited MAC payload fields. It is obvious that the IP connectivity between 6LowPANs and the global IPv6 networks is necessary. For this connectivity, [I- D.6lowpan-interoperability] proposes the mapping of 16 bits short Hyun-Kook Kahng Expires: March 31, 2011 [Page 2] Internet-Draft Global-connectivity October 2010 address and the interoperability between 6LowPAN devices and the external IPV6 networks. However this document does not specify multiple network prefix address but does single network prefix address to use 16 bit short addresses. In the case of the network configuration for the connectivity between 6LowPANs and the external IPv6 networks, multiple network prefix address must be considered for several connections between them. So this document describes the AID assignment mechanism in the gateway not only to support multiple network prefix address but to map unique IPv6 address to AID with short length. This document is based on [Interoperability of 6LoWPAN] for the adaptation layer of fragmentation and reassembly, the stateless address auto-configuration based on EUI-64[EUI64]. 2. Terminology 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]. Readers are expected to be familiar with all the terms and concepts that are discussed in "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919], and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" [RFC4944]. AID : Adaptation IDentifier 3. Global Connectivity in 6LoWPAN This section defines the gateway architecture for the Global Connectivity between the global IPv6 nodes and 6LowPANs. Figure 1 shows the example of the IPv6 connection between the gateway and the external IPv6 nodes. ---+------------------------------------ | Global IPv6 network | | | +-----+ +-----+ | | Gateway | | Outer Node | | | | +-----+ +-----+ Hyun-Kook Kahng Expires: March 31, 2011 [Page 3] Internet-Draft Global-connectivity October 2010 | +--------------+ | o | | o o o o | | o o o o o | Inner Node (IEEE 802.15.4) | o o o o | | o o o | +--------------+ Figure 1: Gateway and node 3.1. AID for outbound traffic Outbound traffic means the traffic from the inner node to the outer nodes. 1. Each node in 6LowPAN checks if it has an AID identifying its own global IPv6 address. 2. Each node can use the AID if it has. Unless, it should request the new AID to the gateway. 3. Each node in 6LowPAN checks if it has an AID identifying its corresponding global IPv6 address. 4. Each node can use the AID if it has. Unless, it should request to new AID to the gateway. 5. Each node should request to the gateway to delete both AIDs if they didn't use during a certain time. 3.2. AID for inbound traffic Inbound traffic means the traffic from the outer node to the inner nodes. 1. The Gateway checks if it has an AID identifying Source IPv6 address of the received inbound traffic. 2. The Gateway can use the AID if it has. Unless, it should assign the new AID for Source IPv6 address in the inbound traffic. Hyun-Kook Kahng Expires: March 31, 2011 [Page 4] Internet-Draft Global-connectivity October 2010 3. The Gateway checks if it has an AID identifying Destination IPv6 address of the received inbound traffic. 4. The Gateway can use the AID if it has. Unless, it should assign the new AID for Destination IPv6 address in the inbound traffic. 5. Each node should request to the gateway to delete both AIDs if they didn't use during a certain time. 3.3. AID Assignment in the Gateway An AID must be assigned by the Gateway according to the following assignment method. The length of an AID being assigned is not defined in this document. 1. If the Gateway receives the AID request message for the specific IPv6 address, it looks up its own address mapping table for the specific IPv6 address. 2. If the Gateway finds the AID matched with the specific IPv6 address, it will return the AID. Otherwise, it will generate and return the new AID not to be duplicated. 3.4. AID deletion in the Gateway An AID must be deleted by the Gateway according to the following deletion method. 1. If the Gateway receives the AID delete message for the specific AID, it looks up its own address mapping table for the AID. 2. If the Gateway finds the AID, it will delete the AID. Otherwise, it neglects the messages. 4. Mapping Table Global Connectivity in 6LoWPAN Gateway has the address mapping table as shown in Figure 2. The length of Global IPv6 address field is 128 bits. The length of AID is TBD. +--------------------------------------+ |Global IPv6 address| AID | +--------------------------------------+ Figure 2: Address Mapping Table Hyun-Kook Kahng Expires: March 31, 2011 [Page 5] Internet-Draft Global-connectivity October 2010 5. Messages for AID Assignment The format shown in Fig 3 was used in communications to assign AID between internal nodes and gateway. We defined three kinds of messages related to AID assignment: AID REQUEST message, AID REPLY message and AID DELETE message. Each AID will represent its corresponding global IP address. The packets will be defined as follows: Message Types IPv6 dispatch value AID REQUEST 01010001 AID REPLY 01010010 AID DELETE 01010011 Figure 3: Message Types for AID Assignment 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [RFC2234]. 7. Security Considerations TBD 8. IANA Considerations TBD Hyun-Kook Kahng Expires: March 31, 2011 [Page 6] Internet-Draft Global-connectivity October 2010 9. References 9.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version6 (IPv6) Specification", RFC 2460, December 1998. [ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003. [RFC4919] N. Kushalnagar, G. Montenegro, C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC4919, August 2007. [RFC4944] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC4944, September 2007. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 9.2. Informative References [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE, http://standards.ieee.org/regauth/oui/tutorials/EUI64.html. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC4862, September 2007. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003. [RFC3684] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)", RFC 3684, February 2004. [I-D.6lowpan-interoperability] Ki-Hyung Kim, Seung Wha Yoo, Hee Jung Kim, Soohong Daniel Park, Jae Ho Lee, "Interoperability of 6LoWPAN", draft-daniel-6lowpan-interoperability-01, July 2005 [I-D. 6lowpan-backbone-router] Pascal Thubert, "6LoWPAN Backbone Router", draft-thubert-6lowpan-backbone-router-02, June 2010 Hyun-Kook Kahng Expires: March 31, 2011 [Page 7] Internet-Draft Global-connectivity October 2010 Authors' Addresses Hyun K. Kahng Korea University Electronic Information Engineering Seoul, Korea Email: kahng@korea.ac.kr Dae-In Choi Korea University Electronic Information Engineering Seoul, Korea Email: nbear@korea.ac.kr Suyeon, Kim Mobilab Daegu, Korea Email: sykim@mobilab.co.kr Acknowledgement Funding for the RFC Editor function is currently provided by the Telecommunication Technology Association (TTA) Hyun-Kook Kahng Expires: March 31, 2011 [Page 8]