6LowPAN Network Working Group Hyun K. Kahng Internet Draft Dae-In, Choi Expires: September 30, 2011 Korea University Suyeon, Kim Mobilab March 12, 2011 Global connectivity in 6LoWPAN draft-kahng-6lowpan-global-connectivity-01.txt Abstract This document specifies the translation mechanism mapping IPv6 address with 128 bits to the Adaptation Identifier (AID) with 16 bits. When a device in IEEE 802.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 node will send packets using these AIDs to the gateway, and then the gateway will translate them to normal IPv6 addresses using the mapping table already associated. 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) 2011 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 Hyun-Kook Kahng Expires: September 30, 2011 [Page 1] Internet-Draft Global-connectivity March 2011 Simplified BSD License text as described in Section 4.e of the Trust 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............................... 4 3.1. AID for outbound traffic................................ 4 3.2. AID for inbound traffic................................. 5 3.3. AID Assignment in the Gateway........................... 5 3.4. AID deletion in the Gateway............................. 5 4. Mapping Table Global Connectivity in 6LoWPAN ................. 6 5. Frame Format for AID Assignment.............................. 6 5.1. AID REQUEST frame....................................... 8 5.2. AID REPLY frame......................................... 8 5.3. AID DELETE frame........................................ 9 5.4. LOWPAN_GCHC frame....................................... 9 6. Formal Syntax ............................................... 9 7. Security Considerations...................................... 9 8. IANA Considerations ........................................ 10 9. References ................................................. 10 9.1. Normative References................................... 10 9.2. Informative References................................. 10 Authors' Addresses ............................................ 11 1. Introduction IETF 6LoWPAN Working Group 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. 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. Hyun-Kook Kahng Expires: September 30, 2011 [Page 2] Internet-Draft Global-connectivity March 2011 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 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 also to map unique IPv6 address to AID with short length. The encoding of AID utilizes 2 bytes; 1 byte is used for identifying each node in IEEE 802.15.4. The other 1 byte is used for identifying the external IPV6 node connected with the node of IEEE 802.15.4. How the value of AID is determined in the gateway is out of scope. As a result, this document defines an encoding format, LOWPAN_GCHC, for effective compression of Global IPv6 address based on shared state with AID. In addition, this document also introduces additional frame format over the header compression format defined in [RFC 4944] 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]. The term "byte" is used in its now customary sense as a synonym for "octet". AID : Adaptation Identifier GCHC : Global Connectivity Header Compression Hyun-Kook Kahng Expires: September 30, 2011 [Page 3] Internet-Draft Global-connectivity March 2011 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. The gateway performs new AID assignment operation to be mapped with IPV6 address by the request of IEEE 802.16 node and executes translation operation which maps IPv6 address encoded with 16 bytes to AID with 2 bytes to compress packet header and vice versa. ---+------------------------------------ | Global IPv6 network | | | +-----+ +-----+ | | Gateway(AID translation) | | Outer Node | | | | +-----+ +-----+ | +--------------+ | 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. Hyun-Kook Kahng Expires: September 30, 2011 [Page 4] Internet-Draft Global-connectivity March 2011 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. 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 2 bytes. 1. If the Gateway receives the AID request frame 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. Hyun-Kook Kahng Expires: September 30, 2011 [Page 5] Internet-Draft Global-connectivity March 2011 1. If the Gateway receives the AID delete frame 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 frame. 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 16 bits. +--------------------------------------+ |Global IPv6 address| AID | +--------------------------------------+ Figure 2: Address Mapping Table 5. Frame Format for AID Assignment The format shown in Figure 3 and Figure 4 are the payload in the IEEE 802.15.4 MAC protocol data unit (PDU). The Frame format was used in communications to assign AID between internal nodes and gateway. Each AID will represent its corresponding global IP address. The Frame format is defined in Figure 3. +-----------------------------------------------+ | AID Message Dispatch | AID Message Parameters | +-----------------------------------------------+ Figure 3: A LoWPAN encapsulated AID Assignment Frame The details of AID Message Parameters are defined below in Section 6. The encapsulation format defined in Figure 4 defines LOWPAN_GCHC encoding format for compressing the IPv6 header. To enable effective compression LOWPAN_GCHC relies on AID information pertaining to AID Assignment Frame. Hyun-Kook Kahng Expires: September 30, 2011 [Page 6] Internet-Draft Global-connectivity March 2011 +-------------------------------------------------------------------+ |LOWPAN_GCHC Dispatch | LOWPAN_GCHC(4)| In-line IPv6 Header Fields | +-------------------------------------------------------------------+ Figure 4: LOWPAN_GCHC Frame We defined three kinds of frames related to AID assignment as shown Figure 5: AID REQUEST frame, AID REPLY frame and AID DELETE frame. The document allocates the following 3 dispatch type field values for these frame types and 1 dispatch type field value for LOWPAN_GCHC. Figure 5 shows new dispatch value bit pattern as updating Figure 2 in [RFC 4944]. +-----------------------------------------+ | Pattern | Header Type | +-----------------------------------------+ | 00 xxxxxx | NALP | | 01 000001 | IPv6 | | 01 000010 | LOWPAN_HC1 | | 01 000011 | Reserved | | ... | Reserved | | 01 001111 | Reserved | | 01 010000 | LOWPAN_BC0 | | 01 010001 | AID REQUEST | | 01 010010 | AID REPLY | | 01 010011 | AID DELETE | | 01 010100 | LoWPAN_GCHC | | ... | Reserved | | 01 111110 | Reserved | | 01 111111 | ESC | | 10 xxxxxx | MESH | | 11 000xxx | FRAG1 | | 11 001000 | Reserved | | ... | Reserved | | 11 011111 | Reserved | | 11 100xxx | FRAGN | | 11 101000 | Reserved | | ... | Reserved | | 11 111111 | Reserved | +-----------------------------------------+ Figure 5: Dispatch Value Bit Pattern AID REQUEST : Specifies that the frame is an AID request frame. Hyun-Kook Kahng Expires: September 30, 2011 [Page 7] Internet-Draft Global-connectivity March 2011 AID RESPONSE : Specifies that the frame is an AID response frame. AID DELETE : Specifies that frame is an AID delete frame. LOWPAN_GCHC : Specifies that following header is a LOWPAN_GCHC compressed IPV6 header. 5.1. AID REQUEST frame In case that the node in 6LowPAN needs a new IPV6 connection with the external node in IPV6 network, the node must send AID REQUEST frame to the gateway. The source address and destination address must set to its source address and the destination address of the external node respectively. To get new source AID and destination AID, both AID must be set to zero. The format of AID REQUEST frame is in Figure 6. +-------------------------------------------------------------------+ | 01010001 | Src.address | Src.AID(2) | Dst.Address | Dst. AID(2) | | | (16) | 0x0000 | (16) | 0x0000 | +-------------------------------------------------------------------+ Figure 6: AID REQUEST frame format 5.2. AID REPLY frame As the response of AID REPLY frame, the gateway must reply to the node in 6LowPAN by sending AID REPLY frame. In case of AID REPLY frame, the frame must be sent to the node in 6LowPAN from the gateway. The gateway must assign unique values as the values of source AID and destination AID. How to calculate and decide the values of the source AID and the destination AID is out of scope except that 1 byte is used for identifying each node in IEEE 802.15.4 and the other 1 byte is used for identifying the external IPV6 node connected with the node of IEEE 802.15.4. AID REPLY frame format is in the Figure 7. +-------------------------------------------------------------------+ |01010000| Src.address | Src.AID | Dst.Address | Dst. AID | | | (16) | (2) | (16) | (2) | +-------------------------------------------------------------------+ Figure 7: AID REPLY frame format Hyun-Kook Kahng Expires: September 30, 2011 [Page 8] Internet-Draft Global-connectivity March 2011 5.3. AID DELETE frame The node in 6LowPAN must send AID DELETE frame to the gateway. After the node in 6LowPAN disconnected to the Global IPV6 node, it must send AID DELETE frame to the gateway to inform not to use the values any longer. The format of AID DELETE frame is in the Figure 8. +------------------------------------------------------------------+ |01010011|Src. Address(16)|Src. ADI(2)|Dst. Address(16)|Dst. AID(2)| +------------------------------------------------------------------+ Figure 8: AID DELETE frame format 5.4. LOWPAN_GCHC frame After AID assignment, LOWPAN_GCHC frame indicates that the following header is encoded using AID values. The LOWPAN_GCHC encoding utilizes 4 octets, 2 of which is source AID and 2 of which is Destination AID. Any information from the uncompressed IPv6 header fields is carried in-line following the LOWPAN_GCHC encoding. The format of LOWPAN_GCHC is in the Figure 9. +------------------------------------------------------------------+ |01010100|Src. AID(2)|Dst. ADI(2)| In-line IPv6 Header Fields | +------------------------------------------------------------------+ Figure 9: LOWPAN_GCHC frame format 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [RFC2234]. 7. Security Considerations TBD Hyun-Kook Kahng Expires: September 30, 2011 [Page 9] Internet-Draft Global-connectivity March 2011 8. IANA Considerations TBD 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. Hyun-Kook Kahng Expires: September 30, 2011 [Page 10] Internet-Draft Global-connectivity March 2011 [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 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: September 30, 2011 [Page 11]