idnits 2.17.1 draft-cao-lwig-gateway-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 6, 2011) is 4799 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lowpan Working Group Z. Cao 3 Internet-Draft China Mobile 4 Intended status: Informational March 6, 2011 5 Expires: September 7, 2011 7 Considerations for Lightweight IP Gateways 8 draft-cao-lwig-gateway-00 10 Abstract 12 This document discusses several considerations of the gateway that 13 connects the IPv6 smart devices with the non-ready IPv6 Internet. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 7, 2011. 32 Copyright Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Conventions used in this document . . . . . . . . . . . . . 3 51 2. Network Architecture and Scenarios . . . . . . . . . . . . . . 3 52 3. Solution Considerations . . . . . . . . . . . . . . . . . . . . 4 53 3.1. Aggregated Smart Network Gateways . . . . . . . . . . . . . 4 54 3.2. Tunneling IPv6 . . . . . . . . . . . . . . . . . . . . . . 4 55 3.3. IP Family Translation . . . . . . . . . . . . . . . . . . . 5 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 The ultimately goal of enabling IP stack on small devices is to 64 connect them to the global Internet. Many efforts are dedicated to 65 compressing IPv6 header for smart devices [RFC4944] 66 [I-D.ietf-6lowpan-hc] so that the smart objects network is IPv6 67 ready. However the connection from the gateway to the outside 68 network is still evolving to the IPv6; many parts of the network is 69 still IPv4, especially for home users. And many Internet application 70 servers are not IPv6 ready. The IPv6 smart device could not connect 71 to the IPv4 service platform without intermediate boxes. 73 In this situation, it is important to discuss how to connect the IPv6 74 ready smart objects network to the non IPv6 ready global Internet. 75 This document introduces several identified problems and some 76 considerations on solutions to these problems. 78 1.1. Conventions used in this document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Network Architecture and Scenarios 86 Figure 1 depicts the secenario of the interconnection between the 87 smart objects network and the Internet. Several important components 88 within this architecture is analyzed below: 90 1. Node: the smart device. In current IETF efforts, the Node is 91 IPv6 ready and IPv6 only. Numbers of the Nodes constitute the 92 smart objects network, which is IPv6 ready. 93 2. SNG: Smart Network Gateway. The SNG interfaces with the smart 94 objects network and the operators's access network. The SNG 95 should support the wireless technolgies connecting with the Node 96 and the lightweight IPv6 implementation as well. The upper 97 connection from the SNG to the access network depends on the 98 capability provided by the operator. 99 3. ONG: Operator Network Gateway. The ONG may not be visible to 100 users. It is used to apply charging, security and QoS policies. 101 In certain scenarios, the ONG is used to manage an IPv6-in-IPv4 102 tunnel between the SNG and itself. 103 4. Server: the applicatoin server. The server may be IPv4 or IPv6, 104 or dual-stack. It collects information from the smart network 105 and share/push these information to users Internet wide. 107 +--------+ 108 | Server | 109 O +--------+ 110 / \ _______ +------+ | 111 / \ +---+ / \ +-----+ / \ | 112 OIPv6 O----|SNG|---+ Access +-| ONG |--/ Internet \-----+ 113 \ / +---+ \ Netw / +-----+ \ / 114 \ / +-----+ \ / 115 O +------+ 116 Node 118 Figure 1: Smart Network Connecting the Internet 120 3. Solution Considerations 122 When both the access network and the application servers are IPv6 123 enabled, the solution to this problem is trivial as far as we can 124 see. The communication between the Node and the Server is end-to- 125 end. 127 When the server is not IPv6 ready or part of the network is not IPv6 128 ready, several solutions need discussion at the current point. This 129 section discusses several considerations on the solutions. 131 3.1. Aggregated Smart Network Gateways 133 In this sense, the connection between the Node and Server is not end 134 to end. Rather, the SNG aggregates the information collected from 135 the smart devices and sends the aggregated message to the service 136 platform. As long as the SNG is enabled with Server the same IP 137 family, the rest of the work is trivial. 139 Most existing applications follow this non end-to-end architecture. 140 But in this architecture, the SNG should be implemented with service 141 logical and its scalability is challenged. 143 3.2. Tunneling IPv6 145 When the server is IPv6 ready but part of the network is not IPv6 146 ready, tunneling the IPv6 within the IPv4 packets is a direct 147 solution. 149 For example as shown in Figure 2, the access network is IPv4 only and 150 the Internet and Server is dual stack. The SNG and ONG should 151 establish an IPv6-in-IPv4 tunnel. The SNG encapsulates the IPv6 152 packets within the IPv4 header to the ONG and ONG de-capsulates the 153 IPv6 packet and sends to the service platform. Softwire tunnels 155 [I-D.ietf-softwire-dual-stack-lite] may be used in this scenario. 157 +--------+ 158 | Server | 159 O +--------+ 160 / \ _______ +------+ | 161 / \ +---+ / \ +-----+ / \ | 162 OIPv6 O----|SNG|---+ Access +-| ONG |--/ Internet \-----+ 163 \ / +---+ \ Netw / +-----+ \ / 164 \ / | +-----+ | \ / | 165 O | | +------+ | 166 Node | | | 167 IPv6 | IPv6 in IPv4 | IPv6 | 168 -------------|====================|----------------------| 170 Figure 2: Tunneling Solution 172 3.3. IP Family Translation 174 If the service platform is IPv4 only, the need of IPv6 to IPv4 175 translation is indispensable. 177 In Figure 3, the SNG does not translate the IPv6 directly. Rather, 178 SNG tunnels the IPv6 packets to the ONG within the IPv4, and the ONG 179 decapsulates and translates the IPv6 to IPv4, using stateless or 180 stateful translation [I-D.ietf-behave-v6v4-xlate-stateful] 181 [I-D.ietf-behave-v6v4-xlate]. 183 +--------+ 184 | Server | 185 O +--------+ 186 / \ _______ +------+ | 187 / \ +---+ / \ +-----+ / \ | 188 OIPv6 O----|SNG|---+ Access +-| ONG |--/ Internet \-----+ 189 \ / +---+ \ Netw / +-----+ \ / | 190 \ / | +-----+ | \ / | 191 O | | +------+ | 192 Node | | | 193 | IPv6 in IPv4 | IPv4 | 194 |---IPv6-----|====================|----------------------| 196 Figure 3: Translation on ONG 198 In Figure 4, different from the above scenario, the SNG translates 199 the IPv6 to IPv4 directly, using stateless or stateful translation 200 [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate]. 202 +--------+ 203 | Server | 204 O +--------+ 205 / \ _______ +------+ | 206 / \ +---+ / \ +-----+ / \ | 207 OIPv6 O----|SNG|---+ Access +-| ONG |--/ Internet \-----+ 208 \ / +---+ \ Netw / +-----+ \ / | 209 \ / | +-----+ | \ / | 210 O | | +------+ | 211 Node | | | 212 | IPv4 | IPv4 | 213 ----IPv6-----|-------------------------------------------| 215 Figure 4: Translation on SNG 217 4. Security Considerations 219 TBD. 221 5. IANA Considerations 223 This document does not require any IANA actions. 225 6. Normative References 227 [I-D.ietf-6lowpan-hc] 228 Hui, J. and P. Thubert, "Compression Format for IPv6 229 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 230 draft-ietf-6lowpan-hc-15 (work in progress), 231 February 2011. 233 [I-D.ietf-behave-v6v4-xlate] 234 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 235 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 236 progress), September 2010. 238 [I-D.ietf-behave-v6v4-xlate-stateful] 239 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 240 NAT64: Network Address and Protocol Translation from IPv6 241 Clients to IPv4 Servers", 242 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 243 progress), July 2010. 245 [I-D.ietf-softwire-dual-stack-lite] 246 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 247 Stack Lite Broadband Deployments Following IPv4 248 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 249 in progress), March 2011. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 255 "Transmission of IPv6 Packets over IEEE 802.15.4 256 Networks", RFC 4944, September 2007. 258 Author's Address 260 Zhen Cao 261 China Mobile 262 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 263 Beijing 100053 264 China 266 Email: zehn.cao@gmail.com