Network Working Group Y. Cui
Internet-Draft J. Wu
Intended status: Standards Track P. Wu
Expires: April 28, 2011 Tsinghua University
C. Metz
Cisco Systems, Inc.
O. Vautrin
A. Durand
Juniper Networks
Y. Lee
Comcast
October 25, 2010
4over6 Access for IPv4 provisioning in IPv6 network
draft-cui-softwire-host-4over6-02
Abstract
This draft proposes a mechanism for bidirectional IPv4 communication
between IPv4 Internet and hosts or IPv4 networks sited in IPv6 access
networks. This mechanism follows the softwire hub & spoke model and
uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network.
By allocating global IPv4 addresses to end hosts/networks in IPv6, it
can achieve IPv4 end-to-end bidirectional communication between IPv4
Internet and these hosts/networks. This mechanism is an IPv4 access
method for hosts and IPv4 networks sited in IPv6.
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 April 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Cui, et al. Expires April 28, 2011 [Page 1]
Internet-Draft 4over6 Access October 2010
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.
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.
Cui, et al. Expires April 28, 2011 [Page 2]
Internet-Draft 4over6 Access October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployment scenario . . . . . . . . . . . . . . . . . . . . . 7
4.1. Scenario description . . . . . . . . . . . . . . . . . . . 7
4.2. Communication requirements . . . . . . . . . . . . . . . . 7
5. Stateless 4over6 Access . . . . . . . . . . . . . . . . . . . 9
5.1. Address allocation and routing . . . . . . . . . . . . . . 9
5.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 9
5.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 10
6. Stateful 4over6 Access . . . . . . . . . . . . . . . . . . . . 12
6.1. Address allocation . . . . . . . . . . . . . . . . . . . . 12
6.2. 4over6 initiator behavior . . . . . . . . . . . . . . . . 12
6.3. 4over6 concentrator behavior . . . . . . . . . . . . . . . 13
6.4. Mapping maintaining methods other than DHCP snooping . . . 14
7. Combination with Dual-Stack Lite . . . . . . . . . . . . . . . 16
7.1. Combination in the CPE . . . . . . . . . . . . . . . . . . 16
7.2. Combination in the DHCPv6 server . . . . . . . . . . . . . 16
7.3. Combination in the concentrator . . . . . . . . . . . . . 16
8. Further Discussion . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Technical advantages of 4over6 Access . . . . . . . . . . 17
8.2. 4over6 Access for direct-connected 4over6 hosts . . . . . 17
8.3. Address configuration issue in home LAN network
situation . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Cui, et al. Expires April 28, 2011 [Page 3]
Internet-Draft 4over6 Access October 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 end users, operators have to
push IPv6 to the front, by building IPv6 networks and providing IPv6
services.
In the future, when IPv6-only network will be widely deployed, users
of those networks could still need IPv4 connectivity. This is
because part of Internet will stay IPv4-only for a long time, and
users in IPv6-only network will probably communicate with network
users sited in the IPv4-only part of Internet. This need could later
decrease with the general Ipv6 adoption eventually.
The IPv4 services that network operators provided to IPv6 users
differs by IPv4 address. If the users can't get global IPv4
addresses (e.g., new network users join an ISP which don't have
enough unused IPv4 addresses for them), they have to use private IPv4
addresses in the client side, and an IPv4-private-to-global
translation is required in the carrier side, as is described in Dual-
stack lite[I-D.ietf-softwire-dual-stack-lite]. Otherwise the IPv6
users can get global IPv4 addresses, they can use them for IPv4
communication, and hence translation shouldn't be involved. Then the
network users and operators can avoid all the problems caused by
translation, such as ALG, NAT traversal, state maintenance, etc.
Note that this situation is actually quite common. There're nearly
2^32 network users who are using global IPv4 addresses or can
potentially get global IPv4 addresses. Most of them will switch to
IPv6 sooner or later, and will require IPv4 services for a
significant period after the switching. This draft focuses on this
situation, i.e., to provide IPv4 access for users in IPv6 network
where IPv4 global addresses are available.
Cui, et al. Expires April 28, 2011 [Page 4]
Internet-Draft 4over6 Access October 2010
2. 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].
Cui, et al. Expires April 28, 2011 [Page 5]
Internet-Draft 4over6 Access October 2010
3. Terminology
4over6 Access: 4over6 Access is the technique proposed by this draft,
which can support bidirectional communication between IPv4 Internet
and hosts in IPv6 access network.
4over6 host: a 4over6 host refers to an end host/server/device
located in IPv6 access network, which has IPv4 protocol stack and
IPv4 applications running on it, and hence desires to get connected
with IPv4 Internet. 4over6 host can be either directly connected to
IPv6 service provider network or behind a CPE device.
4over6 initiator: 4over6 initiator is the IPv4-in-IPv6 tunnel
initiator (based on the hub & spoke softwire model[RFC4925]) in
4over6 Access mechanism. It can be a dual-stack capable, direct-
connected host, or a dual-stack CPE.
4over6 concentrator: 4over6 concentrator is the IPv4-in-IPv6 tunnel
concentrator (based on the hub & spoke softwire model) in 4over6
Access mechanism. It's a dual-stack router which connects to both
the IPv6 service provider network and IPv4 Internet.
4over6 address: 4over6 address is the address allocated to 4over6
initiator and 4over6 host for 4over6 use in stateless 4over6 Access.
The initiator will get the IPv6 4over6 address while the host will
get the corresponding IPv4 4over6 address.
Cui, et al. Expires April 28, 2011 [Page 6]
Internet-Draft 4over6 Access October 2010
4. Deployment scenario
4.1. Scenario description
The general scenario of 4over6 Access is shown in Figure 1. Users in
an IPv6 network take IPv6 as their native service. Some users are
end hosts which face the access network of service provider directly,
while others are local networks behind CPEs, such as a home LAN, an
enterprise network, etc. The access network is IPv6-only rather than
dual-stack, which means that ISP can't provide native IPv4 access to
its users; however, it's acceptable in the carrier side that one or
more routers become dual-stack and get connected to IPv4 Internet.
So if network users want to connect to IPv4, these dual-stack routers
will be their "entrances".
+-------------------------+
| IPv6 Access Network |
+------+ | +-------------+
|4over6| | | |
| host |================ +-------+ | IPv4 |
+------+ |4over6 |---| Internet |
+-------+ | |Concen-| | |
|local | +------+ |trator | | |
|network|-| CPE |================ +-------+ +-------------+
+-------+ +------+ |
| |
+-------------------------+
Figure 1 4over6 Access scenario
4.2. Communication requirements
Before getting into any technical details, the communication
requirements should be stated. The first one is that, 4over6 hosts
require IPv4-to-IPv4 communication with the IPv4 Internet. An IPv4
access service is needed rather than an IPv6-to-IPv4 translation
service.(IPv6-to-IPv4 communication is out of the scope of this
draft.)
Second, end hosts of the network users require to use public IPv4
addresses rather than private addresses. Public IPv4 address means
there's no IPv4 NAT along the path, so the IPv4 service the hosts get
is better. Some hosts may be application servers, in this case
public address works better for reasons like straightforward access,
direct DNS registration, no permanent address mapping on NAT, etc.
We assume the IPv4 global addresses are available, which is quite
common as we covered in section 1.
Cui, et al. Expires April 28, 2011 [Page 7]
Internet-Draft 4over6 Access October 2010
Third, translation is not preferred in this scenario. If this IPv4-
to-IPv4 communication is achieved by translation, it'll needs double
translation along the path, one from IPv4 to IPv6 and the other from
IPv6 back to IPv4. It's quite complicated. Contrarily a tunnel can
achieve the IPv4-over-IPv6 traversing easily. That's the reason this
draft follows the hub & spoke softwire model.
Cui, et al. Expires April 28, 2011 [Page 8]
Internet-Draft 4over6 Access October 2010
5. Stateless 4over6 Access
4over6 Access can be achieved in a stateless way or a stateful way.
In stateless 4over6 the concentrator doesn't need to maintain any
state, at the cost of coupling IPv4 and IPv6 addressing. In stateful
4over6 the concentrator has to maintain the mapping of allocated IPv4
address and the IPv6 address of corresponding initiator.
The principle of stateless 4over6 Access is shown in this section,
and stateful 4over6 Access will be discussed in next section. The
draft will mainly focus on the CPE case since it's more complicated,
and leave the host case as an extension.
5.1. Address allocation and routing
Stateless 4over6 Access has specialized requirement on address
allocation. Besides regular IPv6 address allocation, network
operator should have a network-specific prefix (NSP) and a global
IPv4 address pool (usually aggregated as an IPv4 prefix) for 4over6
Access addressing. A host requiring 4over6 Access service should
acquire an IPv4-Embedded IPv6
address[I-D.ietf-behave-address-format], in which the prefix part is
filled with NSP (the length of NSP is flexible and decided by the
operators), and the IPv4 address part is filled with one 32bit
address from the IPv4 address pool. The 4over6 host will get the
IPv4 address while its CPE will hold the corresponding IPv6 address
for IPv6 reachability.
Besides address allocation, the related 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 packets
from the Internet destined to these addresses can be routed to the
concentrator. In IPv6 scope, the routing in IPv6 network should
support the 4over6 IPv6 address allocation besides the regular IPv6
address allocation.
5.2. 4over6 initiator behavior
In the CPE case, 4over6 initiator represents the dual-stack CPE in
front of the 4over6 hosts. It has an IPv6 interface connected to the
IPv6 SP network, and at least an IPv4 interface connected to the IPv4
local network. Also it will have a tunnel interface supporting IPv4-
in-IPv6 encapsulation and decapsulation.
Before any 4over6 process, 4over6 initiator should have its regular
IPv6 address provisioned, for its regular IPv6 communication.
Cui, et al. Expires April 28, 2011 [Page 9]
Internet-Draft 4over6 Access October 2010
4over6 initiator gets the IPv6 4over6 address by DHCPv6. It acts as
a DHCPv4 server to 4over6 hosts and meanwhile a DHCPv6 client in
IPv6. When a 4over6 host asks for an IPv4 access, it'll start the
DHCPv4 process to acquire an IPv4 4over6 address. 4over6 initiator
deals with this DHCPv4 request and starts the DHCPv6 process to
acquire an IPv6 4over6 address. When getting the IPv6 address, the
initiator will add this address to the address list of its IPv6
interface, and allocate the IPv4 4over6 address, which is embedded in
the IPv6 4over6 address, to the 4over6 host. This way the host gets
the global IPv4 address for its IPv4-IPv4 communication, and the
initiator uses the IPv6 address to support this communication. A new
DHCPv6 option is needed to identify this kind of DHCPv6 request, and
to carry the NSP or NSP length information in DHCPv6 reply.
4over6 initiator performs the IPv4-in-IPv6 encapsulation and
decapsulation for 4over6 hosts which has their IPv4 addresses already
allocated. When a 4over6 host sends an IPv4 packet to the IPv4
Internet, this packet will first arrive at the initiator. The
initiator performs the encapsulation, using the IPv6 4over6 address
as the IPv6 source address. As to the IPv6 destination address,
there're two choices. One is to using the concentrator address which
should be acquired earlier. The other is to use an IPv4-mapped IPv6
address[I-D.ietf-behave-address-format] with NSP followed by the
destination IPv4 address in original IPv4 packet. In this case the
concentrator should advertise a default route for the NSP to collect
the encapsulated IPv6 packets. The decapsulation on 4over6 initiator
is simple. When receiving an IPv4-in-IPv6 packet, the initiator just
drops the IPv6 header and forwards it to the IPv4 local network.
5.3. 4over6 concentrator behavior
4over6 concentrator represents the IPv4-IPv6 border router working as
tunnel endpoint for 4over6 initiators. Its IPv6 interface is
connected to the IPv6 network, and its IPv4 interface is connected to
the IPv4 Internet. Also it will have a tunnel interface supporting
IPv4-in-IPv6 encapsulation and decapsulation.
4over6 concentrator decapsulates the IPv4-in-IPv6 packets coming from
4over6 initiators in IPv6 side. It just drops IPv6 header and
forwards the packets to the IPv4 Internet. The concentrator
encapsulates the IPv4 packets destined to 4over6 hosts. When
receiving an IPv4 packet like that, the concentrator performs an
IPv4-in-IPv6 encapsulation, using the IPv4-embedded address IPv6
address formed by NSP and the IPv4 destination address in the IPv4
packet, as the IPv6 destination address. As to IPv6 source address,
the concentrator can use its regular IPv6 address, or use an IPv4-
mapped IPv6 address formed by the NSP and the IPv4 source address in
the IPv4 packet. After the encapsulation, the concentrator forwards
Cui, et al. Expires April 28, 2011 [Page 10]
Internet-Draft 4over6 Access October 2010
the IPv6 packet on its IPv6 interface to reach an initiator.
As is mentioned earlier, if we use the IPv4-mapped IPv6 address
encapsulation source address in the concentrator and the
encapsulation destination address in the initiators, then the
concentrator should advertise a default route for the NSP in the IPv6
network, to collect the encapsulated IPv6 packets from the
initiators. The choice will be made in the next version of this
draft.
As we can see, there's no need to maintain any IPv4-IPv6 address
mapping on the 4over6 concentrator. So this 4over6 Access mechanism
is stateless. However, operators do have to couple the IPv4 and IPv6
address and plan the address allocating and routing in a specialized
way.
Cui, et al. Expires April 28, 2011 [Page 11]
Internet-Draft 4over6 Access October 2010
6. Stateful 4over6 Access
6.1. Address allocation
Contrary to stateless 4over6 Access, stateful 4over6 Access has no
requirement on the IPv6 address, and has no IPv4-IPv6 address
coupling. IPv4 and IPv6 addressing and routing are separated, which
would be a more common situation.
Without IPv4-IPv6 address coupling, there has to be some address
mapping maintained in the concentrator for correct encapsulation.
There're several ways to achieve this mapping state maintaining,
including DHCPv4 over tunnel with DHCP snooping, DHCPv4 over tunnel
with traffic snooping, IPv4 subnet allocation with BGP or static
mapping, etc. This draft talks about the first way in detail, and
then turn to the other two in section 6.4.
Adopting the first way, the global IPv4 addresses for 4over6 host
will be maintained by the concentrator or dedicated DHCPv4 server
around the concentrator, and allocated by DHCPv4 process over the
IPv6 network, i.e., through the IPv4-in-IPv6 tunnel between the
initiator and the concentrator. Also the CPE initiator should relay
DHCPv4 between 4over6 host and the concentrator.
6.2. 4over6 initiator behavior
Similar to the stateless 4over6 Access, in the CPE case 4over6
initiator represents the CPE in front of the 4over6 hosts with an
IPv6 interface connected to the IPv6 SP network, at least an IPv4
interface connected to the IPv4 local network, and a tunnel interface
supporting IPv4-in-IPv6 encapsulation and decapsulation.
4over6 initiator should learn the 4over6 concentrator's IPv6 address.
For example, if the initiator gets its IPv6 address by DHCPv6, it
should get the 4over6 concentrator's IPv6 address by DHCPv6
option[I-D.ietf-softwire-ds-lite-tunnel-option].
4over6 initiator gets the global IPv4 address for by DHCPv4 on an
IPv4-in-IPv6 tunnel. In the CPE case, when a 4over6 host asks for an
IPv4 access, it'll start the DHCPv4 process to acquire a global IPv4
address. The 4over6 initiator acts as a DHCPv4 relay and relays the
request to the concentrator. Although the network between the
initiator and the concentrator is IPv6, an IPv4-in-IPv6 tunnel can
achieve this DHCPv4 process. All the DHCPv4 packets between the
initiator and the concentrator are encapsulated in IPv6. The
initiator will relay the DHCPv4 reply from the concentrator to the
4over6 host. Then the host can get a global IPv4 address and assign
the address to its IPv4 interface.
Cui, et al. Expires April 28, 2011 [Page 12]
Internet-Draft 4over6 Access October 2010
4over6 initiator performs the IPv4-in-IPv6 encapsulation and
decapsulation for 4over6 hosts which has their IPv4 addresses already
allocated. When a 4over6 host sends an IPv4 packet to the IPv4
Internet, this packet will arrive at the initiator. The initiator
performs the encapsulation, using the IPv6 address of the 4over6
concentrator as the IPv6 destination address, and the IPv6 address of
itself as the IPv6 source address. The encapsulated packet will be
forwarded to the IPv6 network. The decapsulation on 4over6 initiator
is simple. When receiving an IPv4-in-IPv6 packet, the initiator just
drops the IPv6 header and forwards it to the IPv4 local network.
6.3. 4over6 concentrator behavior
4over6 concentrator represents the IPv4-IPv6 border router working as
tunnel endpoint for 4over6 initiators, with its IPv6 interface
connected to the IPv6 network, IPv4 interface connected to the IPv4
Internet, and a tunnel interface supporting IPv4-in-IPv6
encapsulation and decapsulation.
4over6 concentrator maintains an IPv4-IPv6 address mapping table for
IPv4 data packet encapsulation, and a MAC-IPv6 address mapping table
for DHCPv4 encapsulation.
4over6 concentrator is responsible for DHCPv4 address allocation for
the 4over6 hosts. One way to do it is to perform a DHCPv4 server on
the concentrator. Then it should maintain the global IPv4 address
pool, and dynamically allocate addresses according to DHCPv4 request
from 4over6 initiator. After allocating a dynamic IPv4 address to
the 4over6 endpoint, the concentrator should maintain the mapping
between the allocated IPv4 address and the IPv6 address of
corresponding 4over6 initiator. Another way to do it is to perform
DHCPv4 relay functions on the concentrator, and leave the actual
address allocation job to a dedicated DHCPv4 server. In this case
the concentrator still needs to maintain the IPv4-IPv6 address
mapping when relaying DHCP messages.
The DHCP process on IPv6 side is performed in IPv4-in-IPv6 tunnel.
The concentrator receives IPv6 packet containing the DHCPv4 message
coming from a 4over6 host and relayed by the initiator, decapsulate
it to get the DHCPv4 message, add the mapping between the MAC address
in it and the IPv6 address of the initiator to the MAC-IPv6 mapping
table, and then handle it to the DHCPv4 server or relay on the
concentrator. The concentrator sends DHCPv4 message from DHCPv4
server or relay to 4over6 initiator using IPv6 encapsulation. When
encapsulating, the concentrator should use the MAC address in the
DHCPv4 message to look up the MAC-IPv6 mapping table and find the
address as encapsulation destination IPv6 address.
Cui, et al. Expires April 28, 2011 [Page 13]
Internet-Draft 4over6 Access October 2010
4over6 concentrator decapsulates the IPv4-in-IPv6 packets coming from
4over6 initiators in IPv6 side. It just drops IPv6 header and
forwards the packets to the IPv4 Internet. The concentrator
encapsulates the IPv4 packets destined to 4over6 hosts. When
receiving an IPv4 packet like that, the concentrator performs an
IPv4-in-IPv6 encapsulation, using the IPv6 address of itself as the
IPv6 source address. As to IPv6 destination address, the
concentrator will use the IPv4 destination address to look up the
IPv4-IPv6 address mapping table to find the correct IPv6 address.
After the encapsulation, the concentrator forwards the IPv6 packet on
its IPv6 interface to reach an initiator.
The 4over6 concentrator, or its upstream router should advertise the
IPv4 prefix used for 4over6 hosts address allocation on the IPv4
side, to make this hosts reachable on IPv4 Internet.
Since the concentrator has to maintain the IPv4-IPv6 address mapping
table for encapsulation purpose, the concentrator is stateful in IP-
level. Note that this table will be much smaller than a CGN table,
as there is not port involved.
6.4. Mapping maintaining methods other than DHCP snooping
Till now the stateful 4over6 Access is described in a DHCP snooping
way, in which the concentrator snoops on the DHCPv4 process to learn
the IPv4-IPv6 address mapping. Actually, an operator can choose to
learn the mapping through traffic snooping, i.e., when decapsulating
IPv6 packets coming from 4over6 initiators. This way the mappings
are installed based on the actual traffic rather than DHCP. However,
one shortage of this method is that extra procedure may be needed to
support inbound access. This happens when there's no mapping for an
allocated IPv4 address installed on the concentrator yet since
there's no outbound traffic from this IP, and packets from the IPv4
Internet have already arrived on the concentrator and try to reach
the corresponding IP. The extra procedure is simple, though. The
4over6 host or the initiator can just send an arbitrary IPv4 packet
to reach the concentrator through encapsulation and decapsulation,
and hence install the mapping. We suggest the destination IPv4
address of this packet to be the IPv4 interface address of the
concentrator.
In some situations, DHCPv4 for address allocation may be irrelevant.
For example, the local network behind a CPE can be a quite large
enterprise network; then the one-by-one address allocation won't be
efficient. In this case ISP should assign a subnet to the
enterprise, and leave the detailed address allocation to the
enterprise. What the concentrator should learn is the mapping of the
IPv4 subnet and the IPv6 address of the enterprise CPE. A BGP
Cui, et al. Expires April 28, 2011 [Page 14]
Internet-Draft 4over6 Access October 2010
process supporting [RFC5549] extension between the concentrator and
the CPE can achieve that. Actually, if the addresses are stable, the
concentrator can just configure the mappings itself.
Cui, et al. Expires April 28, 2011 [Page 15]
Internet-Draft 4over6 Access October 2010
7. Combination with Dual-Stack Lite
4over6 Access can easily collaborate with Dual-Stack
Lite[I-D.ietf-softwire-dual-stack-lite], for they are trying to solve
the same problem with different type of addresses. 4over6 Access uses
global IPv4 address while Dual-stack Lite uses private IPv4 address.
For situations where global address resource is rare, common users
can use Dual-stack Lite to get IPv4 service, and users with special
requirement like operating an IPv4 server can use 4over6 Access.
7.1. Combination in the CPE
CPE SHOULD run the DHCPv4 server to allocate private addresses for
DS-Lite, and performs DHCPv4 relay for stateful 4over6 Access, or
"DHCPv46"(the DHCPv4 and DHCPv6 procedure described in section 4.2)
for stateless 4over6 Access at the same time. The CPE can
differentiate the two types of DHCP request by MAC configuration.
7.2. Combination in the DHCPv6 server
DHCPv6 server need to allocate IPv6 addresses with the option
containing CGN/4over6 concentrator address, to B4 element and 4over6
initiator respectively.
7.3. Combination in the concentrator
DS-lite and 4over6 Access can use the same concentrator, while 4over6
Access doesn't need the CGN function. The concentrator can
distinguish between outbound packets of Dual-stack Lite and 4over6
Access by the source IPv4 address: if it is global, it is a 4over6
Access packet. Otherwise, it is a Dual-stack Lite packet. Besides,
the concentrator can distinguish inbound IPv4 packets based on IPv4
destination address, since 4over6 Access and Dual-stack lite will use
different global IPv4 address range if they coexist.
Cui, et al. Expires April 28, 2011 [Page 16]
Internet-Draft 4over6 Access October 2010
8. Further Discussion
8.1. Technical advantages of 4over6 Access
4over6 Access provides a method for users in IPv6 network to
communicate with IPv4. In many scenarios, this can be viewed as an
alternative to IPv6-IPv4 translation mechanisms which have well-known
limitations described in [RFC4966] .
Since a 4over6 host uses a global IPv4 address, 4over6 Access
supports full bidirectional communication between IPv4 Internet and
hosts/networks in IPv6 access network. In particular, it supports
the servers in IPv6 network to provide IPv4 application service quite
well.
4over6 Access supports dynamic reuse of a single IPv4 address between
multiple hosts based on their dynamic requirement of communicating
with IPv4 Internet, and hence can improve the reuse rate of IPv4
addresses. When clients or servers need to communicate with IPv4
Internet, they will request a global IPv4 address for a period of
time. This time can be longer for servers and shorter for clients.
4over6 Access is mainly suited for end hosts or networks which can
still get/provide IPv4 services, such as legacy IPv4 users newly
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 4over6 Access way.
8.2. 4over6 Access for direct-connected 4over6 hosts
Section 3 and section 4 only discusses the CPE case since it's a
little more complicated than the direct-connect host case. The
difference in direct-connected host case will be provided here.
For stateless 4over6 Access, When the 4over6 host is the initiator,
by performing DHCPv6 acquiring 4over6 address, the host holds both
the IPv4 4over6 address and the IPv6 4over6 address. No DHCPv4
process is needed. The IPv6 address will be assigned to its IPv6
interface, and the IPv4 address will be assigned to the tunnel
interface. The host will perform the encapsulation and decapsulation
itself, but the operations are similar.
For stateless 4over6 Access, When the 4over6 host is the initiator,
it'll perform the DHCPv4 process with the concentrator itself,
through an IPv4-in-IPv6 tunnel. It'll assign the allocated IPv4
address to the tunnel interface. The host will perform the
encapsulation and decapsulation itself, but the operations are
similar.
Cui, et al. Expires April 28, 2011 [Page 17]
Internet-Draft 4over6 Access October 2010
8.3. Address configuration issue in home LAN network situation
There is one issue not covered yet when the local network is a home
LAN: how do the 4over6 hosts configure the gateway address and the
subnet mask length (usually by DHCPv4 along with address allocation)?
In stateful 4over6 Access, It's tricky since two hosts in one LAN may
get any two addresses in the entire global IPv4 address pool.
Suppose the hosts in one LAN set the subnet mask length equal to the
prefix length of the address pool, in order to achieve one-hop
communication between them, and set the gateway to be the CPE. As a
consequence, they'll drop any IPv4 packet destined to other 4over6
hosts which are not in the same LAN, since they think they' re one-
hop away while the ARP process find no answer.
One solution is to have the CPE work as an ARP proxy which answers to
any ARP request whose IPv4 address is not in this LAN. Then the CPE
can get the packets destined to other 4over6 hosts and deal with them
separately. Another solution is to have the hosts and the CPE narrow
their subnet mask to 32, and have the CPE to configure a /32 route
for every host. Then the CPE will become a "switch" for any two
hosts in this LAN. Note that all the CPEs can use one unique IPv4
address from the address pool.
Due to the IPv6 address planning in stateless 4over6 Access, the IPv4
addresses 4over6 hosts in the same LAN got will be more "close" to
each other. Nevertheless the problem still exists. The above two
solutions both works in stateless 4over6 Access as well, except that
CPE can't use a unique CPE address.
Cui, et al. Expires April 28, 2011 [Page 18]
Internet-Draft 4over6 Access October 2010
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop",
RFC 5549, May 2009.
9.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-10 (work in progress),
August 2010.
[I-D.ietf-softwire-ds-lite-tunnel-option]
Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
draft-ietf-softwire-ds-lite-tunnel-option-05 (work in
progress), September 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 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 April 28, 2011 [Page 19]
Internet-Draft 4over6 Access October 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
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, CA 95134
USA
Email: chmetz@cisco.com
Olivier Vautrin
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA 94089
USA
Email: Olivier@juniper.net
Cui, et al. Expires April 28, 2011 [Page 20]
Internet-Draft 4over6 Access October 2010
Alain Durand
Juniper Networks
1194 N Mathilda Avenue
Sunnyvale, CA 94089-1206
USA
Email: adurand@juniper.net
Yiu L. Lee
Comcast
Email: yiu_lee@cable.comcast.com
Cui, et al. Expires April 28, 2011 [Page 21]