6Lowpan Working Group Z. Cao Internet-Draft China Mobile Intended status: Informational March 6, 2011 Expires: September 7, 2011 Considerations for Lightweight IP Gateways draft-cao-lwig-gateway-00 Abstract This document discusses several considerations of the gateway that connects the IPv6 smart devices with the non-ready IPv6 Internet. 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." This Internet-Draft will expire on September 7, 2011. 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 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. Cao Expires September 7, 2011 [Page 1] Internet-Draft LWIP Gateway March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 2. Network Architecture and Scenarios . . . . . . . . . . . . . . 3 3. Solution Considerations . . . . . . . . . . . . . . . . . . . . 4 3.1. Aggregated Smart Network Gateways . . . . . . . . . . . . . 4 3.2. Tunneling IPv6 . . . . . . . . . . . . . . . . . . . . . . 4 3.3. IP Family Translation . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Cao Expires September 7, 2011 [Page 2] Internet-Draft LWIP Gateway March 2011 1. Introduction The ultimately goal of enabling IP stack on small devices is to connect them to the global Internet. Many efforts are dedicated to compressing IPv6 header for smart devices [RFC4944] [I-D.ietf-6lowpan-hc] so that the smart objects network is IPv6 ready. However the connection from the gateway to the outside network is still evolving to the IPv6; many parts of the network is still IPv4, especially for home users. And many Internet application servers are not IPv6 ready. The IPv6 smart device could not connect to the IPv4 service platform without intermediate boxes. In this situation, it is important to discuss how to connect the IPv6 ready smart objects network to the non IPv6 ready global Internet. This document introduces several identified problems and some considerations on solutions to these problems. 1.1. Conventions used in this document 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]. 2. Network Architecture and Scenarios Figure 1 depicts the secenario of the interconnection between the smart objects network and the Internet. Several important components within this architecture is analyzed below: 1. Node: the smart device. In current IETF efforts, the Node is IPv6 ready and IPv6 only. Numbers of the Nodes constitute the smart objects network, which is IPv6 ready. 2. SNG: Smart Network Gateway. The SNG interfaces with the smart objects network and the operators's access network. The SNG should support the wireless technolgies connecting with the Node and the lightweight IPv6 implementation as well. The upper connection from the SNG to the access network depends on the capability provided by the operator. 3. ONG: Operator Network Gateway. The ONG may not be visible to users. It is used to apply charging, security and QoS policies. In certain scenarios, the ONG is used to manage an IPv6-in-IPv4 tunnel between the SNG and itself. 4. Server: the applicatoin server. The server may be IPv4 or IPv6, or dual-stack. It collects information from the smart network and share/push these information to users Internet wide. Cao Expires September 7, 2011 [Page 3] Internet-Draft LWIP Gateway March 2011 +--------+ | Server | O +--------+ / \ _______ +------+ | / \ +---+ / \ +-----+ / \ | OIPv6 O----|SNG|---+ Access +-| ONG |--/ Internet \-----+ \ / +---+ \ Netw / +-----+ \ / \ / +-----+ \ / O +------+ Node Figure 1: Smart Network Connecting the Internet 3. Solution Considerations When both the access network and the application servers are IPv6 enabled, the solution to this problem is trivial as far as we can see. The communication between the Node and the Server is end-to- end. When the server is not IPv6 ready or part of the network is not IPv6 ready, several solutions need discussion at the current point. This section discusses several considerations on the solutions. 3.1. Aggregated Smart Network Gateways In this sense, the connection between the Node and Server is not end to end. Rather, the SNG aggregates the information collected from the smart devices and sends the aggregated message to the service platform. As long as the SNG is enabled with Server the same IP family, the rest of the work is trivial. Most existing applications follow this non end-to-end architecture. But in this architecture, the SNG should be implemented with service logical and its scalability is challenged. 3.2. Tunneling IPv6 When the server is IPv6 ready but part of the network is not IPv6 ready, tunneling the IPv6 within the IPv4 packets is a direct solution. For example as shown in Figure 2, the access network is IPv4 only and the Internet and Server is dual stack. The SNG and ONG should establish an IPv6-in-IPv4 tunnel. The SNG encapsulates the IPv6 packets within the IPv4 header to the ONG and ONG de-capsulates the IPv6 packet and sends to the service platform. Softwire tunnels Cao Expires September 7, 2011 [Page 4] Internet-Draft LWIP Gateway March 2011 [I-D.ietf-softwire-dual-stack-lite] may be used in this scenario. +--------+ | Server | O +--------+ / \ _______ +------+ | / \ +---+ / \ +-----+ / \ | OIPv6 O----|SNG|---+ Access +-| ONG |--/ Internet \-----+ \ / +---+ \ Netw / +-----+ \ / \ / | +-----+ | \ / | O | | +------+ | Node | | | IPv6 | IPv6 in IPv4 | IPv6 | -------------|====================|----------------------| Figure 2: Tunneling Solution 3.3. IP Family Translation If the service platform is IPv4 only, the need of IPv6 to IPv4 translation is indispensable. In Figure 3, the SNG does not translate the IPv6 directly. Rather, SNG tunnels the IPv6 packets to the ONG within the IPv4, and the ONG decapsulates and translates the IPv6 to IPv4, using stateless or stateful translation [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate]. +--------+ | Server | O +--------+ / \ _______ +------+ | / \ +---+ / \ +-----+ / \ | OIPv6 O----|SNG|---+ Access +-| ONG |--/ Internet \-----+ \ / +---+ \ Netw / +-----+ \ / | \ / | +-----+ | \ / | O | | +------+ | Node | | | | IPv6 in IPv4 | IPv4 | |---IPv6-----|====================|----------------------| Figure 3: Translation on ONG In Figure 4, different from the above scenario, the SNG translates the IPv6 to IPv4 directly, using stateless or stateful translation [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate]. Cao Expires September 7, 2011 [Page 5] Internet-Draft LWIP Gateway March 2011 +--------+ | Server | O +--------+ / \ _______ +------+ | / \ +---+ / \ +-----+ / \ | OIPv6 O----|SNG|---+ Access +-| ONG |--/ Internet \-----+ \ / +---+ \ Netw / +-----+ \ / | \ / | +-----+ | \ / | O | | +------+ | Node | | | | IPv4 | IPv4 | ----IPv6-----|-------------------------------------------| Figure 4: Translation on SNG 4. Security Considerations TBD. 5. IANA Considerations This document does not require any IANA actions. 6. Normative References [I-D.ietf-6lowpan-hc] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in Low Power and Lossy Networks (6LoWPAN)", draft-ietf-6lowpan-hc-15 (work in progress), February 2011. [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in progress), September 2010. [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-12 (work in progress), July 2010. [I-D.ietf-softwire-dual-stack-lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Cao Expires September 7, 2011 [Page 6] Internet-Draft LWIP Gateway March 2011 Stack Lite Broadband Deployments Following IPv4 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work in progress), March 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. Author's Address Zhen Cao China Mobile Unit2, 28 Xuanwumenxi Ave,Xuanwu District Beijing 100053 China Email: zehn.cao@gmail.com Cao Expires September 7, 2011 [Page 7]