One document matched: draft-cui-softwire-host-4over6-00.txt
Network Working Group Y. Cui
Internet-Draft J. Wu
Intended status: Standards Track P. Wu
Expires: January 6, 2011 Tsinghua University
July 5, 2010
4over6 for IPv6 host connecting IPv4 Internet
draft-cui-softwire-host-4over6-00
Abstract
This draft proposes a mechanism for bidirectional communication
between IPv4 Internet and hosts in IPv6 access networks. Adopting
the Softwire hub & spoke model, this mechanism uses IPv4-over-IPv6
tunnel to traverse the IPv6 networks.
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 January 6, 2011.
Copyright Notice
Copyright (c) 2010 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.
Cui, et al. Expires January 6, 2011 [Page 1]
Internet-Draft Host 4over6 July 2010
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scenario description and analysis . . . . . . . . . . . . . . 6
4. Host 4over6 Framework . . . . . . . . . . . . . . . . . . . . 7
4.1. addressing and routing in Host 4over6 . . . . . . . . . . 7
4.2. 4over6 Initiator . . . . . . . . . . . . . . . . . . . . . 7
4.3. 4over6 Concentrator . . . . . . . . . . . . . . . . . . . 8
5. Further Discussion . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Technical advantage of Host 4over6 . . . . . . . . . . . . 10
5.2. Application Scenario of Host 4over6 . . . . . . . . . . . 10
5.3. Home network consideration . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Cui, et al. Expires January 6, 2011 [Page 2]
Internet-Draft Host 4over6 July 2010
1. Introduction
Global public IPv4 addresses are running out fast. The recent
simulation result by ipv4.potaroo.net says the exact exhaustion date
will be in two years. Meanwhile, the demand for address allocation
is still growing and may even burst in potential situations like the
"Internet of Things". To satisfy the network users, operators have
to push IPv6 to the front, by building IPv6 networks and providing
IPv6 services.
When IPv6 begins to serve the large number of end users as native
network, IPv4 service for these users rises as a critical requirement
simultaneously. This is because before the whole world switch to
IPv6, there'll still be a portion of resources, applications and
users to communicate persisting in IPv4. So the end users in IPv6
network desires to get connected with IPv4 Internet, especially in
the early period when IPv4 is still dominant.
The IPv4 service which network operators provided for IPv6 users
differs IPv4 address. If the IPv6 clients don't have IPv4
addresses(e.g., new network users join this ISP and ISP don't have
enough unused IPv4 address for them), then they have to use private
IPv4 address in client side and an IPv4 private-to-global translation
is required in the carrier side. Otherwise the IPv6 clients can get
global IPv4 addresses, then they can use them for IPv4 communication,
and hence translation shouldn't be involved. Without translation,
the network users and operators can avoid all the problems introduced
by it, such as application translation, port allocation, state
maintenance, etc., and get/provide better IPv4 services. Note that
this situation is actually quite popular. There're up to 2^32
networks users who are using IPv4 global address or can get an IPv4
global IPv4 address. Most of them will switch to IPv6 sooner or
later, and will require IPv4 services after the switching. This
draft will focus on this situation, i.e., to provide IPv4 access for
hosts in IPv6 network where IPv4 global addresses are available.
We can take CERNET(China Education and Research Network) as an
example. CERNET has two backbone using different address families,
the IPv4-only backbone is known as CERNET and the IPv6-only backbone
is known as CERNET2. There are hundreds of Campus networks attaching
to CERNET and some of them have got attached to CERNET2 as well. All
these Campus networks have got their IPv4 prefixes allocated from
CERNET and the end hosts in these networks are using IPv4 global
addresses at present. Now imagine one day all these campus networks
get attached to CERNET2 and turn into IPv6-only. Then the end hosts
in them have to switch to IPv6 accordingly, but they'll naturally
continue to require IPv4 services. In this scenario, the end hosts
can use their previous IPv4 addresses for the new type of IPv4
Cui, et al. Expires January 6, 2011 [Page 3]
Internet-Draft Host 4over6 July 2010
services, since the addresses are already possessed by the campus
network and the clients basically remains the same.
Cui, et al. Expires January 6, 2011 [Page 4]
Internet-Draft Host 4over6 July 2010
2. Terminology
Host 4over6
Host 4over6 is the technology proposed by this draft, to support the
bidirectional communication between IPv4 Internet and a host in IPv6
access network.
4over6 host
The host that supports Host 4over6 in IPv6 access network. 4over6
host is also called 4over6 initiator. 4over6 host is a 4over6 tunnel
endpoint in Host 4over6.
4over6 concentrator
4over6 concentrator is the dual stack router which connecting the
IPv6 access network to IPv4 Internet. 4over6 concentrator is also a
4over6 tunnel endpoint in Host 4over6.
Cui, et al. Expires January 6, 2011 [Page 5]
Internet-Draft Host 4over6 July 2010
3. Scenario description and analysis
The scenario is shown in Figure 1. Hosts in an IPv6 network take
IPv6 as their native service. At the same time, these hosts want to
get IPv4 services as well, i.e., they want to connect to IPv4
Internet. However, the reality is that the network these hosts get
attached to is IPv6-only rather than dual-stack. Fortunately,
network operators can connect a small number of routers to IPv4
Internet, so a large number of end hosts can get IPv4 connectivity
through these v4-v6 border routers. So generally, it's an IPv4-over-
IPv6 Hub & spoke problem[RFC4925].
+-------------------------+
| IPv6 Network |
+-----+ | +-------------+
| H1 | ================ +-------+ | |
+-----+ |v4-v6 | | IPv4 |
| |Border |---| Internet |
+-----+ |Router | | |
| H2 | ================ +-------+ | |
+-----+ // | +-------------+
| // |
| +-----+ |
+---------------| H3 |---+
+-----+
Figure 1 Host 4over6 scenario
Under this scenario, let's make some basic assumptions on the user
expectations. First and the most important one, the end users want
an IPv4 access method, so they expect a tunnel mechanism rather than
a translation mechanism. Second, end users require global IPv4
address. As is analyzed earlier, lack of IPv4 addresses isn't a
concern in this scenario. Third, users expect no translations along
the IPv4 path, so there're no problems like NAT traversing, so the
IPv4 service can be better, various applications can be supported
well. As to network operators, they expect the method to be simple,
useful and scalable. They don't want to maintain state on their
devices unless they have to.
Cui, et al. Expires January 6, 2011 [Page 6]
Internet-Draft Host 4over6 July 2010
4. Host 4over6 Framework
Host 4over6 is a traversing mechanism for hosts in IPv6 network to
reach IPv4 Internet and get IPv4 service. Host 4over6 adopts the Hub
& Spoke model, and uses IP-in-IP tunnel as the encapsulation method.
The IPv6 hosts requiring IPv4 service act as tunnel initiator, and
the IPv4-IPv6 border router acts as tunnel concentrator. Host 4over6
allocates IPv4 global address to the hosts by embedding it in the
IPv6 address of the hosts. This way tunnel concentrator can figure
out the IPv6 encapsulation destination address automatically when
sending an IPv4 packet through 4over6 tunnel, therefore no
information maintenance is required on concentrator.
4.1. addressing and routing in Host 4over6
Host 4over6 has specialized requirement on address allocation.
Network operator should have a network-specific prefix(NSP), and a
global IPv4 address pool(usually aggregated as an IPv4 prefix) for
Host 4over6 usage. The IPv6 hosts requiring Host 4over6 service
should be allocated with IPv4-Embedded IPv6
address[I-D.ietf-behave-address-format], in which the prefix part is
filled with NSP, and the v4 address part is filled with one 32bit
address from the IPv4 address pool. Different hosts get different
IPv6 addresses with the same prefix (i.e. NSP) and different IPv4
addresses. The prefix length is flexible and decided by the
operators. By this IPv6 address allocation process, one host
possesses a global IPv4 address and the corresponding mapped IPv6
address.
Besides address allocation, the corresponding routing should be done.
In IPv4 scope, the 4over6 Concentrator on the IPv4-IPv6 border should
advertise the IPv4 prefix(consists of the addresses allocated to IPv6
hosts) into the IPv4 network on Internet side, so that packet
destined to these addresses can be routed to the concentrator and
then reach the hosts by tunnel. In IPv6 scope, the routing in IPv6
network should support the IPv6 address allocation. This is no
different from regular IPv6 allocation and routing.
4.2. 4over6 Initiator
4over6 initiator represents the IPv6 hosts requiring IPv4 service.
These hosts are in the IPv6-only network, they're not provisioned
with native IPv4 access, but the protocol stack on the hosts supports
IPv4. The protocol stack should have an tunnel interface, supporting
IPv4-in-IPv6 tunnel encapsulation and decapsulation.
4over6 Initiator should get its IPv6 address by DHCPv6. When it
learns the IPv6 address and bind it to the IPv6 interface, it will
Cui, et al. Expires January 6, 2011 [Page 7]
Internet-Draft Host 4over6 July 2010
also extract the IPv4 address from the IPv4-Embedded IPv6 address,
and bind it to the tunnel interface. This address will work as the
native IPv4 address for this host.
When the host want to send an IPv4 packet, this packet will be handed
to the tunnel interface. The tunnel interface will put an IPv6
header on this packet, using the IPv4-Embedded IPv6 address as the
source address and the concentrator IPv6 address as the destination
address. Then the packet will be sent on the IPv6 interface. When
the host receives an encapsulated IPv4-in-IPv6 packet, it will
decapuslate it by dropping the IPv6 header and handed it to the
tunnel interface, and then handed up to higher layer.
4over6 Initiator should learn the NSP(or the NSP length) and the
concentrator IPv6 address before the data process begins. This can
be done by manual configuration, new DHCP option, etc.
Actually, when performing encapsulation, there is another way to form
the destination address. We can use an IPv4-mapped IPv6 address with
NSP as prefix and actual destination IPv4 address as v4 address to be
the IPv6 destination address, and then have the Concentrator
advertise the default route for NSP, so as to route the encapsulated
packet to the Concentrator. However, when there exists multiple
Concentrators, this will leads to asymmetric routing.
This draft mainly discusses the situation that the Initiator is the
IPv6 host. See section 5.3 for the situation where there is an IPv4
home network behind the Initiator.
4.3. 4over6 Concentrator
4over6 Concentrator represents the IPv4-IPv6 border router working as
tunnel endpoint for the IPv6 hosts. Its IPv6 interface is connected
to the IPv6 network, and its IPv4 interface is connected to the IPv4
Internet.
When the Concentrator receives an encapsulated IPv4-in-IPv6 packet
from the IPv6 side, it will decapsulated the packet by dropping the
IPv6 header. If the decapsulated IPv4 packet is destined to the IPv4
Internet, then it'll be sent on the IPv4 interface. Else the packet
is destined to another IPv6 host, then the Concentrator will
encapsulate it by IPv6, using the IPv6 address of itself as the
source address, and use the IPv4 destination address and the NSP to
form the IPv6 destination address automatically. Note that if the
Initiator uses the IPv4-mapped IPv6 address as the destination
address for encapsulation, this type of packets won't go through the
Concentrator.
Cui, et al. Expires January 6, 2011 [Page 8]
Internet-Draft Host 4over6 July 2010
When the Concentrator receives an IPv4 packet from the IPv4 side, it
will check the destination address. For our concern, the destination
will fall into the address pool for IPv6 hosts. Then the 4over6
Concentrator will encapsulate the packet by IPv6, using the IPv6
address of itself as the source address, and use the IPv4 destination
address and the NSP to form the IPv6 destination address
automatically. Then the IPv6 packet will be sent on the IPv6
interface.
Cui, et al. Expires January 6, 2011 [Page 9]
Internet-Draft Host 4over6 July 2010
5. Further Discussion
5.1. Technical advantage of Host 4over6
Since a 4over6 host uses a global IPv4 address, host 4over6 supports
bidirectional communication between IPv4 Internet and a host in IPv6
access network.
By coupling the IPv4 address and the IPv6 address of the IPv6 host,
the encapsulation in the Concentrator can be simple and scalable.
The Concentrator can automatically form the destination IPv6 address
for encapsulation, rather than maintain a table of per-user IPv4-IPv6
address mapping and look it up for every encapsulation.
5.2. Application Scenario of Host 4over6
Since a host 4over6 support bidirectional communication between a
host in IPv6 network and IPv4 Internet, this technology can provide
the solution for data center networks or those hosts which need to
provide IPv4 service in IPv6 access networks.
In order to improve save the reuse rate of IPv4 address, host 4over6
can support dynamically reuse of a single IPv4 address between
multiple hosts based on their dynamical requirement of communicating
with IPv4 Internet. A 4over6 host can use IPv6 protocols (e.g. ND)
to have an ordinary IPv6 address rather than 4over6 address when it
starts up. When it needs to communicate with IPv4 Internet, it then
requires a new 4over6 address from the 4over6 DHCPv6 to have a global
IPv4 address in the short time it needs.
Host 4over6 is mainly suited for IPv6 hosts that can get IPv4
addresses, such as legacy IPv4 users switching to IPv6. Network
operators can take back the IPv4 addresses from the existing users,
have the network switched to IPv6 and re-allocate the IPv4 addresses
to them in a Host 4over6 way
5.3. Home network consideration
Host 4over6 is mainly facing IPv6 hosts. If the Initiator is a CPE
with an IPv4 home network behind it, then the situation will be more
complicated. One solution is to update the home network to support
IPv6, and have each host in this network to get IPv4-Embedded
address(The CPE can require an IPv6 block and distribute the
addresses in home network, or working as an DHCP relay). If this
can't be done, then a normal IPv4 NAT is required on the CPE. Hosts
in home network will use IPv4 private addresses. Packets from home
network will be translated by the IPv4 NAT, so as to use the global
IPv4 address of the CPE as source address, and then use the tunnel
Cui, et al. Expires January 6, 2011 [Page 10]
Internet-Draft Host 4over6 July 2010
between the CPE and the Concentrator to reach IPv4 Internet.
Cui, et al. Expires January 6, 2011 [Page 11]
Internet-Draft Host 4over6 July 2010
6. References
6.1. Normative References
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
6.2. Informative References
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-08 (work in progress),
May 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
Y., and R. Bush, "Dual-Stack Lite Broadband Deployments
Following IPv4 Exhaustion",
draft-ietf-softwire-dual-stack-lite-04 (work in progress),
March 2010.
[I-D.ietf-softwire-ipv6-6rd]
Townsley, M. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", draft-ietf-softwire-ipv6-6rd-10
(work in progress), May 2010.
[I-D.xli-behave-ivi]
Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
CERNET IVI Translation Design and Deployment for the IPv4/
IPv6 Coexistence and Transition", draft-xli-behave-ivi-07
(work in progress), January 2010.
Cui, et al. Expires January 6, 2011 [Page 12]
Internet-Draft Host 4over6 July 2010
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6260-3059
Email: cy@csnet1.cs.tsinghua.edu.cn
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
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: weapon@csnet1.cs.tsinghua.edu.cn
Cui, et al. Expires January 6, 2011 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 09:31:25 |