One document matched: draft-cui-softwire-host-4over6-01.txt
Differences from draft-cui-softwire-host-4over6-00.txt
Network Working Group Y. Cui
Internet-Draft J. Wu
Intended status: Standards Track P. Wu
Expires: January 11, 2011 Tsinghua University
July 10, 2010
Host 4over6 for IPv6 host connecting IPv4 Internet
draft-cui-softwire-host-4over6-01
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. Particularly, this mechanism
allocates a global IPv4 address to each endpoint (CPE or host), so
bidirectional communication can be achieved between IPv4 Internet and
hosts in IPv6 access 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 11, 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
Cui, et al. Expires January 11, 2011 [Page 1]
Internet-Draft Host 4over6 July 2010
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.
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 with stateless address mapping . . . . . 7
4.1. addressing and routing in Host 4over6 . . . . . . . . . . 7
4.2. 4over6 Initiator . . . . . . . . . . . . . . . . . . . . . 7
4.3. 4over6 Concentrator . . . . . . . . . . . . . . . . . . . 8
5. Host 4over6 Framework with stateful address mapping . . . . . 10
6. Further Discussion . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Technical advantage of Host 4over6 . . . . . . . . . . . . 11
6.2. Application Scenario of Host 4over6 . . . . . . . . . . . 11
6.3. Home network consideration . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Cui, et al. Expires January 11, 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, which has two backbones using different address
families, the CERNET IPv4-only backbone and the CERNET2 IPv6-only
backbone. There are hundreds of Campus networks attaching to CERNET
and some of them have 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 original IPv4 end hosts
in the campus networks 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
Cui, et al. Expires January 11, 2011 [Page 3]
Internet-Draft Host 4over6 July 2010
new type of IPv4 services, since the addresses are already possessed
by the campus network and the clients basically remains the same.
Cui, et al. Expires January 11, 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 endpoint
The end host or CPE that supports Host 4over6 in IPv6 access network
is called 4over6 endpoint, which is also the 4over6 initiator. 4over6
endpoint 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 11, 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 Access Network |
+-----+ | +-------------+
| H1 | ================ +-------+ | |
+-----+ |4over6 | | IPv4 |
| |Concen-|---| Internet |
+-----+ |trator | | |
| 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 analyzed earlier, existing IPv4 users/operators have
still had their original IPv4 addresses when they update the network
to IPv6. Third, users expect no translations along the IPv4 path, so
there're no problems like NAT traversing and 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 the
per flow state on their device unless they have to.
Cui, et al. Expires January 11, 2011 [Page 6]
Internet-Draft Host 4over6 July 2010
4. Host 4over6 Framework with stateless address mapping
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 11, 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 11, 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 11, 2011 [Page 9]
Internet-Draft Host 4over6 July 2010
5. Host 4over6 Framework with stateful address mapping
In some senarios, network operators may prefer to decouple the
address allocation of IPv4 address and IPv6 address. In this case,
the operator will not use NSP to have the automatic mapping between
IPv4 address and IPv6 address. Instead, when an IPv6 host in the
access IPv6 network needs to communication with IPv4 Internet, the
4over6 endpoint starts the DHCPv4 process to the Host 4over6
concentrator over the IPv6 access network. After allocating a
dynamic IPv4 address to the 4over6 endpoint, the 4over6 concentrator
should maintain the mapping state between the endpoint IPv6 address
and the new allocated IPv4 address for this endpoint.
When the 4over6 concentrator receives an inbound IPv4 packet from
IPv4 Internet, it needs to lookup the mapping table to find the
corresponding IPv6 address, which should be the IPv6 destination in
the encapsulation header.
Cui, et al. Expires January 11, 2011 [Page 10]
Internet-Draft Host 4over6 July 2010
6. Further Discussion
6.1. Technical advantage of Host 4over6
Since a 4over6 endpoint uses a global IPv4 address, host 4over6
supports bidirectional communication between IPv4 Internet and a host
in IPv6 access network.
In the scheme of stateless address mapping, by coupling the IPv4
address and the IPv6 address of the 4over6 endpoint, 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.
6.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. Although the IPv4
addresses are allocated by DHCPv6 or tunneled DHCPv4, Dynamic DNS may
be combined to support providing IPv4 service based on domain names.
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 endpoint 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. Moreover, the 4over6 concentrator may provide
the IPv4 address only for the short time by setting a propriate timer
in DHCP in order to increase the reuse rate of IPv4 address.
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.
6.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
Cui, et al. Expires January 11, 2011 [Page 11]
Internet-Draft Host 4over6 July 2010
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
between the CPE and the Concentrator to reach IPv4 Internet.
Cui, et al. Expires January 11, 2011 [Page 12]
Internet-Draft Host 4over6 July 2010
7. Acknowledgements
The authors would like to give special thanks to Yiu Lee for his
valuable input.
Cui, et al. Expires January 11, 2011 [Page 13]
Internet-Draft Host 4over6 July 2010
8. References
8.1. Normative References
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
8.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-09 (work in progress),
July 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.
Cui, et al. Expires January 11, 2011 [Page 14]
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: yong@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 11, 2011 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 03:12:06 |