Internet DRAFT - draft-chen-softwire-gw-init-4over6
draft-chen-softwire-gw-init-4over6
Network Working Group Y. Chen
Internet-Draft J. Wu
Intended status: Standards Track Tsinghua University
Expires: March 01, 2014 X. Tang
G. Zhou
China Unicom Research Institute
August 28, 2013
Gateway-Initiated 4over6 Deployment
draft-chen-softwire-gw-init-4over6-02
Abstract
Gateway-Initiated 4over6 is a variant of Lightweight 4over6. A
Lightweight B4 in Lightweight 4over6 mechanism is a router which acts
as a tunnel initiator for the IPv4-in-IPv6 tunnel. This mechanism
mainly focuses on the scenario in which an IPv4 address and related
configuration information is configured to the device behind
Lightweight B4. Gateway-Initiated 4over6 uses the full IPv4 address
rather than a shared address. This enables an unmodified end server
or host that is behind a Lightweight B4 to get access to the IPv4
Internet through an IPv6 network.
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 March 01, 2014.
Copyright Notice
Copyright (c) 2013 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
Chen, et al. Expires March 01, 2014 [Page 1]
Internet-Draft Gateway-Initiated 4over6 August 2013
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. GI-4over6 Architecture . . . . . . . . . . . . . . . . . . . 3
5. GI-4over6 in ICP Network . . . . . . . . . . . . . . . . . . 4
5.1. Static Configuration to Establish Tunnel . . . . . . . . 4
5.2. Dynamic Configuration to Establish Tunnel . . . . . . . . 5
6. 4over6 Gateway Data Plane Behaviors . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
In typical use case of Lightweight 4over6 (Lw4over6)
([I-D.ietf-softwire-lw4over6]), IPv4 address (and available port set)
is provisioned to the Lightweight B4 (LwB4), the tunnel initiator.
However, there are some cases in which IPv4 address and related
configuration are not be provisioned to LwB4, but the end device
behind it. There is a typical scenario in this case, that is
Lw4over6 is used in an Internet Content Provider (ICP) network, and
the device behind LwB4 is an ICP server.
Gateway-Initiated 4over6 (GI-4over6) is a variant of Lw4over6. It
mainly focuses on the scenario in which an IPv4 address and related
configuration information is provisioned to the device behind LwB4.
Provisioning full address is preferred to provisioning shared address
(port-restricted address) in GI-4over6. It enables an unmodified
IPv4 device that behind the LwB4 to get access to IPv4 Internet
through IPv6 network.
2. Terminology
This document uses the terms defined in [I-D.ietf-softwire-lw4over6].
Chen, et al. Expires March 01, 2014 [Page 2]
Internet-Draft Gateway-Initiated 4over6 August 2013
The other terms used are defined as follows:
o End device: The device in the IPv4 network behind the 4over6
gateway. It can be an IPv4-only or a dual-stack
device.
o End server: The end device in an ICP network is supposed to
be an end server.
o 4over6 gateway: The dual-stack gateway device located at the border
of both IPv4 and IPv6 networks. It should be
configured with an IPv4 address and the IPv6 address
of LwAFTR, and act as the LwB4 on the data plane.
3. Requirements Language
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].
4. GI-4over6 Architecture
The general architecture of GI-4over6 is illustrated as Figure 1.
The 4over6 gateway is a dual-stack gateway device which establishes
IPv4-in-IPv6 tunnel with the Lightweight Address Family Transition
Router (LwAFTR) and performs the LwB4 function on data plane. The
LwAFTR is a dual-stack border router deployed at the edge of the IPv6
network and the Internet. The IPv4 network can be either an ICP
network, or a customer network of an ISP. The IPv6 network can be
either an ICP access network or an ISP access network. Either or
both of these networks could be dual-stack.
+---------------------+ +-------------------------+
| +-------------+ +-+----------+-+ +-+--------+ +----------+
| | | | 4over6 | IPv4-in-IPv6 tunnel | | | |
| | End device +---+ Gateway |=====================| LwAFTR +---+ Internet |
| | | | (LwB4) | | | | |
| +-------------+ +-+----------+-+ IPv6 Network +-+--------+ +----------+
| IPv4 network | | |
+---------------------+ +-------------------------+
Figure 1 GI-4over6 Architecture
The 4over6 gateway is configured with an public IPv4 address on its
Chen, et al. Expires March 01, 2014 [Page 3]
Internet-Draft Gateway-Initiated 4over6 August 2013
"left" side, an IPv6 address on its "right" side, either by static
(in ICP network) or dynamic (in customer network) way. It is also
configured with the IPv6 address of LwAFTR as the address of the
tunnel endpoint. Each end device has a public IPv4 address with all
ports (0-65535) available, hence there is no need to implement NAPT44
on the 4over6 gateway.
One typical scenario of this framework is that using Lw4over6 in an
ICP network. There might be other similar scenarios, and they could
be included in this document in the future.
5. GI-4over6 in ICP Network
Considering an ISP that plans to update its network to IPv6, one of
the major issues it may be faced with is the update of its ICP
network. If the ICP network is to be updated to run IPv6, the server
in the network should also be updated to support IPv6. Obviously it
is not trivial to update upper layer service running on the server to
support a network layer protocol. It's ideal if the ICP access
network is updated to IPv6, but still capable of providing the server
with access to IPv4 Internet, meanwhile the ICP network (and the
servers inside) stay unmodified.
In this scenario, the end server has already been configured with a
full public IPv4 address, and it's expected to stay unchanged during
the update of the network. It has also been configured with other
IPv4 related configurations like the network mask of the IPv4 ICP
network, the IPv4 address of DNS server, etc.
The 4over6 gateway has already been configured with the routing to
the end server. It MUST establish the IPv4-in-IPv6 tunnel with the
LwAFTR, in order to forward the IPv4 traffics between the end server
and the IPv4 Internet. The establishment of the IPv4-in-IPv6 tunnel
could be done either by static - the most likely way - or dynamic
configuration.
5.1. Static Configuration to Establish Tunnel
The LwAFTR is statically configured with the binding of the public
IPv4 address of the end server, the available port set (0-65535), and
IPv6 address of the 4over6 gateway in its binding table statically.
In a more general case, the addresses of servers behind the same
4over6 gateway can aggregate. And as the 4over6 gateway and the
LwAFTR are both managed by the ISP, people who configure the LwAFTR
are usually aware of the routing to the ICP network behind the 4over6
gateway. Hence the LwAFTR can be configured with the following
binding: the network prefix of the ICP network, the available port
Chen, et al. Expires March 01, 2014 [Page 4]
Internet-Draft Gateway-Initiated 4over6 August 2013
set (0-65535), and IPv6 address of the 4over6 gateway.
5.2. Dynamic Configuration to Establish Tunnel
Dynamic configuration could be adopted in case the static
configuration is not feasible or practical.
The 4over6 gateway MUST inform the LwAFTR of all of its IPv4 routing
information (i.e. the whole IPv4 routing table). The detail of this
process could be clarified in related draft in future.
Once the LwAFTR received the routing information from the 4over6
gateway, it should add the entry(s) into its binding table, with the
given routing information. The binding may looks like: the ICP
network prefix, available port set (0-65535), the IPv6 address of the
4over6 gateway.
6. 4over6 Gateway Data Plane Behaviors
The 4over6 gateway must perform the LwB4 function on the data plane.
The data plane behavior of 4over6 gateway uses the description in
section 5.2 of [I-D.ietf-softwire-lw4over6]. However, there is no
need to implement NAPT44 function on 4over6 gateway, because each end
server behind the 4over6 gateway has a public IPv4 address with all
ports available.
7. Security Considerations
TBD
8. IANA Considerations
This document does not include an IANA request.
9. References
9.1. Normative References
[I-D.ietf-softwire-lw4over6]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the DS-Lite
Architecture", draft-ietf-softwire-lw4over6-01 (work in
progress), July 2013.
9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Chen, et al. Expires March 01, 2014 [Page 5]
Internet-Draft Gateway-Initiated 4over6 August 2013
Authors' Addresses
Yuchi Chen
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86 10 6278 5822
Email: chenycmx@gmail.com
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86 10 6278 5983
Email: jianping@cernet.edu.cn
Xiongyan Tang
China Unicom Research Institute
33 Erlong Road, Xicheng District
Beijing 100032
P.R.China
Phone: +86 10 6652 2558
Email: tangxy@chinaunicom.cn
Guangtao Zhou
China Unicom Research Institute
9 Shouti South Road, Haidian District
Beijing 100048
P.R.China
Phone: +86 10 6789 9600
Email: zhouguangtao@chinaunicom.cn
Chen, et al. Expires March 01, 2014 [Page 6]
