Internet Engineering Task Force C. Sun
Internet-Draft S. Matsushima
Intended status: Informational J. Jiao
Expires: September 8, 2011 Softbank
March 7, 2011
4rd Applicability Statement
draft-sun-intarea-4rd-applicability-00
Abstract
This document discusses the applicability of the IPv4 Residual
Deployment (4rd) protocol, and an address sharing mechanism, NAT44 on
4rd CE side, and IPv6 addressing and routing in 4rd capable Ipv6-only
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 September 8, 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.
Sun, et al. Expires September 8, 2011 [Page 1]
Internet-Draft 4rd Applicability March 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of 4rd . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IPv4 address assignment . . . . . . . . . . . . . . . . . 5
3.2. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . . 5
3.3. Distributing NAT function to CEs . . . . . . . . . . . . . 6
3.4. Routing optimization to provide IPv4 connectivity . . . . 9
3.5. Gateway Redundancy Considerations . . . . . . . . . . . . 10
3.6. NAT Log Considerations . . . . . . . . . . . . . . . . . . 11
4. Constraint Consideration . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Sun, et al. Expires September 8, 2011 [Page 2]
Internet-Draft 4rd Applicability March 2011
1. Introduction
The Internet continues to grow beyond the capabilities of IPv4. The
tremendous success of the Internet has strained the address space,
which is no longer sufficient to support future growth. The IANA
free pool of IPv4 address have been depleted already. With its
increase in the number of available prefixes and addresses in a
subnet, and improvement in address management, IPv6 is the only real
option on the table. During the long transition period from only
IPv4 to IPv6, the networks of Internet Service Providers (ISPs) will
have to offer more than just IPv6 connectivity. Both outgoing and
incoming connections will have to be supported.
IPv4 Residual Deployment (4rd) enables a service provider to share
IPv4 addresses among its customers by combining the well-known
technologies of stateless address mapping and tunneling, NAT44, and
IPv4 in IPv6 encapsulation.
This document discusses the applicability of the IPv4 Residual
Deployment (4rd) protocol, and an address sharing mechanism, NAT44 on
4rd CE side, and IPv6 addressing and routing in 4rd capable IPv6-only
networks.
The 4rd model is built on IPv4 over IPv6 stateless tunnels to reach
4rd CEs where customers will share IPv4 addresses (Section 3.2).
With 4rd, we need not worry that well-known IPv4 addresses (such as
000/8) are generated, because all 4rd CEs generating IPv4 addresses
are in the range of domain 4rd prefix. (Section 3.1). 4rd differs
from other solutions such as Dual-Stack-lite
[I-D.ietf-softwire-dual-stack-lite] since the 4rd CE is used to
implement the NAT44 (Section 3.3). 4rd also can implement Routing
Optimization to Provide IPv4 Connectivity while the 4rd CE
communicates with other 4rd CE (Section 3.4). Given its stateless
tunnel nature, it is superior over a centralized NAT44 solution in
its ability to easily offer redundancy, also in a multi vendor
environment (Section 3.5). Furthermore, 4rd does not require
dedicated NAT44 logging requirements(Section 3.6).
2. Overview of 4rd
If 4rd [I-D.despres-softwire-4rd] is to be actually used across a
IPv6-only network to offer IPv4 connectivity
[I-D.arkko-ipv6-transition-guidelines], the network must have 4rd
Border Relay Router (BR) and 4rd Customer Edge Router (CE). Multiple
CEs are set-up to share an IPv4 address using different port ranges,
and the CE and BR share a 4rd address and port mapping rule.
Sun, et al. Expires September 8, 2011 [Page 3]
Internet-Draft 4rd Applicability March 2011
Figure 1 shows 4rd address mapping, which generates an CE 4rd prefix
from CE IPv6 prefix. As the prerequisite of 4rd, Domain IPv6 prefix
and Domain 4rd prefix must be given to all 4rd CEs and 4rd BRs in a
specified 4rd domain. CE IPv6 prefix for all 4rd CEs in the
specified 4rd domain must be in same Domain IPv6 prefix but must be
unique for each 4rd CE.
<------------ CE IPv6 prefix length (max 64) ------------>
+-------------------------------+------------------------+
| Domain IPv6 prefix | CE index |
+-------------------------------+------------------------+
<-- Domain IPv6 Prefix length --> /\ :
: || :
: \/ :
+-------------------+------------------------+
CE 4rd prefix | Domain 4rd prefix | CE index |
(max 48) +-------------------+------------------------+
Figure 1: 4rd address mapping
4rd CEs obtain their shared IPv4 address and available port ranges by
deriving this information from CE IPv6 prefix.
According to 4rd [I-D.despres-softwire-4rd],each 4rd CE has its
unique port-ranges which is calculated based on the 4rd mapping rule
with their port-prefix. The 4rd port mapping rule uses four port-
range indexes, as shown in the Figure 2 below. This allows 4rd CEs
to avoid using well known (reserved) TCP/UDP ports 0-4095.
Sun, et al. Expires September 8, 2011 [Page 4]
Internet-Draft 4rd Applicability March 2011
<------- Port (16bit) ---------->
Port-range +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Index(0001) |0|0|0|1|1 0 1 0|1 0 1 1| | Port-range:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x1AB0 - 0x1ABF
/ 0xA / 0xB /
Port-range +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Index(001) |0|0|1|1 0 1 0|1 0 1 1| | Port-range:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x3560 - 0x356F
/ 0xA / 0xB /
Port-range +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Index(01) |0|1|1 0 1 0|1 0 1 1| | Port-range:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x6AC0 - 0x6AFF
/ 0xA / 0xB /
Port-range +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Index(1) |1|1 0 1 0|1 0 1 1| | Port-range:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0xD570 - 0xD5FF
/ 0xA / 0xB /
Port Prefix +-+-+-+-+-+-+-+-+
(CE1,0xAB) |1 0 1 0|1 0 1 1|
+-+-+-+-+-+-+-+-+
Figure 2: Port-range calculation example for 4rd CE1
3. Applicability
3.1. IPv4 address assignment
As Figure 1 shows that all 4rd CEs generating IPv4 addresses are in
the range of domain 4rd prefix. This means that it is not necessary
for 4rd operators to pay attention to what IPv4 address is generated
by 4rd CE. In the case of all 32 bits of IPv4 address is mapped to
IPv6 prefix, 4rd CE must not generate well-known IPv4 address (such
as 0/8, 127/8, etc., for example) so that IPv6 prefix assignment
should be taken careful to avoid it. 4rd is recommended to operators
who do not want IPv6 prefix assignment of which takes into account
what IPv4 address generated from IPv6 prefix.
3.2. IPv4 Address Sharing
The 4rd model is built on IPv4 over IPv6 stateless tunnels to reach
4rd CEs where customers will share IPv4 addresses. Figure 3 shows an
example of one IPv4 address being shared by 256 customers.
In the example given, the IPv6 address prefix of the ISP's IPv6
access network is 2001:db8::/32, the delegated IPv6 prefix of each
4rd CE is /56, distributed by DHCP-PD for example, the bit range of
user unique part of IPv6 prefix is 24 bits. According to the rule of
Sun, et al. Expires September 8, 2011 [Page 5]
Internet-Draft 4rd Applicability March 2011
4rd address mapping (Figure 1), the port prefix and the IPv4 address
are derived from user unique part associated with the IPv6 address.
In the example(Figure 3), the IPv4 address that can be shared by 4rd
CEs is 10.255.0.205, '10.255/16' is the common IPv4 prefix for 4rd of
this network, '0.205' is generated from ':00cd:'. The port prefix
that can be used for IPv4 address sharing is 8 bits (eg: AB, EF, A1
is used by 4rd CE1, 4rd CE2, 4rd CEn ), so up to 256 customers can
share the one IPv4 address (2 to 8th power).
+------------------------+
/ \
| IPv4 Internet |
\ /
+------------------------+
|
|
+----------------------+
| 4rd BR |
+----------------------+
|
|
+ --------------------------------+
/ \
| ISP's IPv6 network |
\ 2001:db8::/32 /
---------------------------------
/ | \
/ | \
/ | \
2001:db8:cd:ab00::/56 2001:db8:cd:ef00::/56 2001:db8:cd:a100::/56
+-----------+ +------------+ +------------+
| 4rd CE1 | | 4rd CE2 | *** | 4rd CEn |
+-----------+ +------------+ + -----------+
4rd-delegated 4rd-delegated 4rd-delegated
address: address: address:
10.255.0.205 10.255.0.205 10.255.0.205
port-prefix: port-prefix: port-prefix:
0xAB 0xEF 0xA1
Figure 3: A 4rd network model example
3.3. Distributing NAT function to CEs
4rd technology uses the 4rd CE to implement NAT44. This section
describes 4rd CE Side NAT from the perspectives of management and
cost.
Sun, et al. Expires September 8, 2011 [Page 6]
Internet-Draft 4rd Applicability March 2011
Since 4rd distributes NAT44 function to the 4rd CE, the CE side NAT44
manages user's NATed session in general of each 4rd CE unit.
According to their own infrastructure and management systems, if ISPs
think 4rd CE Side NAT is easier to manage than gateway side NAT, they
can adopt the 4rd technology.
The capex and opex costs of an ISP very from network to network. The
4rd solution is an ideal fit for those where a CE based NAT solution
is acceptable, and where investment in operating and managing of a
centralized NAPT 44 gateway is not desired,
For an CE IPv6 prefix of a given length, e.g. a /56 PD, as more and
more bits are used to express the shared IPv4 address, the less bits
are available to express the port range. It is not 4rd specific
issue, but a method that supports NAT Port Mapping needs to be
devised. For example, 256 ports can be used by 4rd CE, but access to
host A, B, and C requires 100 ports each. If the 4rd CE ports are
distributed when A,B,C are accessed at the same time from the same
4rd CE, Ports 0 - 99 are used to access host A, Ports 100 - 199 are
used to access host B, but host C cannot be accessed because the
remaining ports are not enough. As Figure 4, 4rd can reuse the 4rd
CE Port by terms of recognizing the destination addresses in order to
reduce the aspect of this problem. It is noted that the problem can
not be solved if the multiple users under same 4rd CE access the same
host (e.g. host A) exceed the number of ports.
Sun, et al. Expires September 8, 2011 [Page 7]
Internet-Draft 4rd Applicability March 2011
-----------------------------------
/ \
/ IPv4 Internet \
| +--------+ +--------+ +--------+ |
\ | host A | | host B | | host C | /
\ +--------+ +--------+ +--------+ /
--------------------------------------
|
+---------------------+
| 4rd BR |
+---------------------+
|
+---------------------------------+
/ \
| ISP's IPv6 network |
\ /
+---------------------------------+
|
4rd CE |
+--------------------------------------------------+
| Port number Port number Port number |
| pool for pool for pool for |
| +--host A --+ +--host B --+ +--host C --+ |
| | Port0-255 | | Port0-255 | | Port0-255 | |
| +-----------+ +-----------+ +-----------+ |
+--------------------------------------------------+
Figure 4: Reuse port number on 4rd CE side NAT
Figure 5 quantifies address sharing rates for different port range
lengths, along with the overall number of ports available to a give
CE. The 4rd allows 16 bits to be used by NAPT. In theory, one IPv4
address can be shared by 65536 (2 to 16th power) customers. However,
at least 1 bit is needed for Port-range Index. The greatest bit
range that can be used to share address are 15 bits.
Sun, et al. Expires September 8, 2011 [Page 8]
Internet-Draft 4rd Applicability March 2011
+------------+-------------------------+---------------+------------+
| Port | User numbers that can | # of ports | Relative |
| prefix | share one v4 address | for a 4rd CE | to a /8 |
| length | | | |
+------------+-------------------------+---------------+------------+
| 1 | 1 - 2 | 30720 | /9 |
| 2 | 1 - 4 | 15360 | /10 |
| 3 | 1 - 8 | 7680 | /11 |
| 4 | 1 - 16 | 3840 | /12 |
| 5 | 1 - 32 | 1920 | /13 |
| 6 | 1 - 64 | 960 | /14 |
| 7 | 1 - 128 | 480 | /15 |
| 8 | 1 - 256 | 240 | /16 |
| 9 | 1 - 512 | 120 | /17 |
| 10 | 1 - 1024 | 60 | /18 |
| 11 | 1 - 2048 | 30 | /19 |
| 12 | 1 - 4096 | 15 | /20 |
| 13 | 1 - 8192 | 7 | /21 |
| 14 | 1 - 16384 | 3 | /22 |
| 15 | 1 - 32768 | 1 | /23 |
+------------+-------------------------+---------------+------------+
Figure 5: 4rd CE available port
3.4. Routing optimization to provide IPv4 connectivity
Figure 6 shows that 4rd can implement IPv6 routing with direct IP
forwarding between the two 4rd CEs. In other words, 4rd allows
direct packet forwarding between CEs that share a 4rd domain, without
the need of forwarding such traffic through the gateway.
When V4a under 4rd CE1 send packets to V4b under 4rd CE2, the packets
need not go through the gateway (Hub&Spoke) before going to 4rd CE2,
they can go to 4rd CE2 directly (mesh). This section describes this
in more detail from two perspectives: Network matching and Network
Load.
Sun, et al. Expires September 8, 2011 [Page 9]
Internet-Draft 4rd Applicability March 2011
+------------------------+
/ IPv4 Network \
\ /
+-------------------------+
|
+---------------------+
| gateway |
+---------------------+
|
+------------------------+
/ \ +----------------------+
| ISP's IPv6 access NW | -------| 4rd CE (V4b) |
\ [//]===/========+== >------------------+
+-----------------[//]---+
| [//]
+---------------[//]---+
| 4rd CE (V4a) |
+----------------------+
Figure 6
Taking network matching into account, 4rd should be chosen if the
ISP's IPv6 network allows direct CE-CE traffic forwarding (eg: IPv6
Flat Routing Network).
Compared to Hub & Spoke architecture solutions, mesh architecture
solutions can achieve a smaller network load when the 4rd CE
communicate frequently. If the ISP thinks that its network has
insufficient bandwidth or it wants to lower the load imposed by IPv4
connections, they should choose a mesh architecture solution such as
4rd.
Note: Softwire mesh [RFC5565] is also a mesh architecture solution,
but it does not provide the IPv4 sharing function. Softwire mesh can
be adopted if IPv4 address sharing is not needed.
3.5. Gateway Redundancy Considerations
Since in 4rd the BR side does not implement the NAT function, the BR
can be easily replicated. For instance, there can be N:1 redundant
gateways in the network. Reliable network operation can be
guaranteed because a failed gateway can be immediately and easily
replicated by any one of the N gateways.
If the gateway side implements NAT, 1:1 gateway redundancy is the
choice, and also upstream and downstream traffic from the same user
must go through the same gateway. 4rd easily realizes load balancing
because upstream and downstream traffic from the same user can go
Sun, et al. Expires September 8, 2011 [Page 10]
Internet-Draft 4rd Applicability March 2011
through different gateways.
3.6. NAT Log Considerations
4rd CE uses fixed NAT rules and IPv4 users can be directly identified
by means of their IPv6 address, so the NAT log does not need to be
left. In other words, 4rd allows an operator to save on the need to
perform NAT log collection and retention. On the other hand, other
solutions may achieve higher address sharing ratio than 4rd. If
operators want to reduce NAT log with these solutions, their NATs
have to be configured with [I-D.tsou-behave-natx4-log-reduction], or
allocate fixed port range for NAT rules regardless of the advantage.
It is noted that another logging necessity coming from
[I-D.ietf-intarea-shared-addressing-issues] is described in
[I-D.ietf-intarea-server-logging-recommendations] for Internet facing
servers.
4. Constraint Consideration
This section describes the constraint on user number when addresses
are shared. As Section 3.3 stated, the maximum bit range that can be
used by a public port is 15 bits. In this case, 4rd CE is restricted
to one private port. In fact, it is not able to provide service. So
the customer numbers per IPv4 address that can be shared need to be
considered along with the ports needed by 4rd CE.
It is noted that deriving IPv4 addresses from CE IPv6 prefix
generated by 4rd mapping rule may lead to a low rate of IPv4 address
sharing because it does not allow for statistical multipexing gains.
ISPs who feel that this is not desirable and want to achieve high
sharing rates can select centralized gateway/NAPT solutions, which
can have a high sharing rate because allow for such statistical
multipexing gains.
5. Security Considerations
The sharing of IPv4 address reduces the port selection space per 4rd
CE, so a blind attack can be performed easily. An attack can be
performed if the attacker is able to correctly guess the source
address and source port. Address and Port Dependent Filtering (APDF)
need be implemented in order to counter blind attack. In APDF, not
only source address and source port but also destination address and
destination port need to be checked. Even so, a blind attack that
can be performed against TCP relies on the attacker's ability to
guess the 5-ruple (Protocol, Source address, Destination address,
Sun, et al. Expires September 8, 2011 [Page 11]
Internet-Draft 4rd Applicability March 2011
Source Port, Destination Port). Shared address issues
[I-D.ietf-intarea-shared-addressing-issues] describes a method for
the random selection of TCP Sequence Number, that reduces the ability
of attacker to correctly guess the 5-ruple.
DNS is one of the important protocols to use UDP. In 4rd CE, all DNS
reply packets should be discarded, expect for the packets from
forward destinations. If DNS implements Port Randomization, the
attack success rate can be reduced.
We describe here a method for reducing Spoofing Attack under 4rd CE.
Using the 4rd mapping rule, the IPv4 address can be derived from IPv6
address, so we can check the IPv4 address thus derived and the IPv4
address in the header of received packet. If they are same, the
packet is forwarded, otherwise, it is dropped.
6. Conclusions
This document described the ability of 4rd to support the IPv6-only
access network. We conclude that the 4rd solution is a viable choice
when the ISP desires a stateless IPv4 address sharing option, based
on CE side NAT functionality, along with a high degree of freedom in
terms of redundancy and optimal traffic forwarding. 4rd is also
recommended to operators who do not want IPv6 prefix assignment of
which takes into account what IPv4 address generated from IPv6
prefix. When only one 4rd applicable character is needed, 4rd may be
used to only that purpose with other solutions.
7. Acknowledgements
The authors would like to thank Remi Despres for his enormous effort
to work for 4rd architecture and protocol. The authors also thank to
people who provided encouragements concerning the 4rd approach and
lead to consider 4rd in Japan. In particular, we would like to thank
Toshiya Asaba, Yoshiki Ishida, Tetsuya Innami, Masataka Mawatari,
Akira Nakagawa, Tomoyuki Sahara, Taisuke Sasaki, Katsuyasu Toyama,
Mark Townsley, Wojciech Dec, Yuji Yamazaki, have provided useful
discussion and comments on the document and review.
8. References
8.1. Normative References
[I-D.despres-softwire-4rd]
Despres, R., "IPv4 Residual Deployment across IPv6-Service
Sun, et al. Expires September 8, 2011 [Page 12]
Internet-Draft 4rd Applicability March 2011
networks (4rd) A NAT-less solution",
draft-despres-softwire-4rd-00 (work in progress),
October 2010.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
8.2. Informative References
[I-D.arkko-ipv6-transition-guidelines]
Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment",
draft-arkko-ipv6-transition-guidelines-14 (work in
progress), December 2010.
[I-D.ietf-intarea-server-logging-recommendations]
Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging recommendations for Internet facing servers",
draft-ietf-intarea-server-logging-recommendations-03 (work
in progress), February 2011.
[I-D.ietf-intarea-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing",
draft-ietf-intarea-shared-addressing-issues-03 (work in
progress), February 2011.
[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
post IPv4 exhaustion",
draft-ietf-softwire-dual-stack-lite-03 (work in progress),
February 2010.
[I-D.tsou-behave-natx4-log-reduction]
ZOU), T., Li, W., and T. Taylor, "Port Management To
Reduce Logging In Large-Scale NATs",
draft-tsou-behave-natx4-log-reduction-02 (work in
progress), September 2010.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Sun, et al. Expires September 8, 2011 [Page 13]
Internet-Draft 4rd Applicability March 2011
Reserved for Documentation", RFC 3849, July 2004.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
Authors' Addresses
Chunfa Sun
Softbank
Tokyo Shiodome Building. 22F
1-9-1,Higashi-Shibashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: c-sun at bb dot softbank dot co dot jp
Satoru Matsushima
Softbank
Tokyo Shiodome Building. 22F
1-9-1,Higashi-Shibashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: satoru dot matsushima at tm dot softbank dot co dot jp
Jie Jiao
Softbank
Tokyo Shiodome Building. 12F
1-9-1,Higashi-Shibashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: j-jiao at bb dot softbank dot co dot jp
Sun, et al. Expires September 8, 2011 [Page 14]