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]