2009 First International Conference on Evolving Internet
Anticipate IPv4 Address Exhaustion
A Critical Challenge for Internet Survival
M. Boucadair, J-L. Grimault, P. Lévis, A. Villefranque and P. Morand
France Telecom R&D
42, Rue des Coutures
14066 Caen
e-mail: {mohamed.boucadair, jeanluc.grimault, pierre.levis, alain.villefranque, pierrick.morand}@orange-ftgroup.com
Abstract—This paper introduces a novel solution to face the
IPv4 public address exhaustion. The paper presents a new
architecture using port extended IP address and describes how
it can be used to overcome the IPv4 address shortage. It also
provides a mock-up implementation together with the results
of the tests that assess the applicability of the proposed concept
to various applications.
Keywords-component; IPv4 address shortage, IPv6, double
NAT
I. INTRODUCTION
The Internet community has reached the consensus that
the number of public IPv4 addresses is bound to end [2][16].
Various alarms have been emitted by the IETF and regular
reports were presented within the GROW (Global Routing
Operations Working Group) meetings. Moreover, the
community was mobilized in the past to adopt IPv6 [1]
which supports a larger IP address space as well as several
enhancements compared to IPv4. IPv6 specifications are
mature and current standardisation work is exclusively
dedicated to operational aspects. Despite this effort, IPv6 is
not globally deployed by service providers for both financial
and strategic reasons. However, even if a service provider
activates IPv6, it will be confronted with the problem to
ensure a global connectivity towards today's Internet v4.
Mechanisms such as NAT-PT (Network Address Translation
Protocol Translation, [7]) were introduced to ensure the
interconnection between two heterogeneous realms (i.e.
IPv4/IPv6). These solutions are stateful and are not suitable
to interconnect an IPv6 domain with a dominant IPv4-only
Internet realm. Further work should be undertaken within
IETF to elaborate lightweight and hopefully stateless
solutions to ease IPv4-IPv6 interworking. Moreover, service
providers should adopt clear strategies so as to ease the
adoption of IPv6 and to decrease the complexity related to
IPv4-IPv6 interworking [7][8][9],one of the critical issues to
be taken into account when designing service platforms.
IPv6 is the long term solution to offer IP connectivity
services to a large number of customers. From this
perspective, service providers should avoid introducing new
functions and nodes which could become problematic when
migrating to IPv6. This critical requirement should be taken
into account not only during the technical engineering phase,
but also when provisioning required CAPEX (Capital
978-0-7695-3748-1/09 $26.00
$25.00 © 2009 IEEE
DOI 10.1109/INTERNET.2009.11
Expenditure) and OPEX (Operational Expenditure)
estimation to activate solution coping with the IPv4 address
shortage.
In order to solve this depletion problem, service
providers need to investigate and enable means to ensure the
deployment of their service offerings and their delivery to
end-users. This paper focuses on this technical challenge
which conditions the survival of the Internet. Other
challenges may be found at [3].
This paper specifies a promising solution which aims at
solving the depletion problem as encountered by current
service providers. The proposed concept, called Port Range
solution is stateless session and does not alter the various
services offered. The solution presented in this paper does
not require severe modifications of current engineering
practices as adopted by service providers. Furthermore, the
solution is scalable and can be deployed in several variants to
prepare the migration towards IPv6. The scalability of this
solution is similar to current deployed IP architectures. No
session-related (UDP or TCP) states are maintained in core
nodes operated by a given service provider.
This paper is structured as follows. Section II describes
in depth the IPv4 shortage challenge and presents the Carrier
Grade NAT approach. Section III focuses on the proposed
port-range solution. Overview and illustration example are
also provided in Section III. Section IV describes the
configuration of the testbed. Finally, Section V presents the
conducted tests and obtained results.
II. IPV4 SHORTAGE CHALLENGE
There is a global hierarchical structure that manages the
IP address space. The top level authority is called Internet
Assigned Numbers Authority (IANA), IANA allocates /8
blocks to the Regional Internet Registries (RIRs). A /8 block
contains 2 to the power of 24 IPv4 addresses, or 16,777,216
addresses. There is one RIR per region of the world; for
example, the one in charge of Europe is the RIPE NCC. Each
RIR then allocates /8 blocks of addresses to the Local
Internet Registries (LIRs), basically the service providers.
Eventually, the service providers allocate addresses to their
customers.
The theoretical total IPv4 addressing space is 2^8 /8
blocks, or 256 /8 blocks. Taking into consideration the IPv4
public address pool currently available at IANA (32 /8 at the
time of writing), it is expected that the RIRs will have no
27
more public IPv4 addresses to allocate in the short term by
2012. At the exhaustion date, service providers will wind up
with public address pools that cannot grow. They will enter
an IPv4 address shortage management phase.
As mentioned above, IPv6 is the long term solution to
solve the IPv4 public address exhaustion, because it is the
only solution available that can provide a sufficient
addressing space to cope with the global IP growth expected
during the next decades. However, there will be a more or
less long period during which offering only an access to the
IPv6 Internet won't be satisfactory for customers, because a
lot of services will remain IPv4-only accessible - a full IPv6
world requires universal adoption.
Therefore, service providers must develop solutions allowing
their clients to communicate with their IPv4 correspondents
in this context of IPv4 address shortage and IPv6 growth.
So far, the current practice has been to give a unique
IPv4 public address to each customer. Current designs assign
a global IPv4 address to the Customer Premises Equipment
(CPE), whereas hosts connected through the CPE are
privately-addressed. Therefore, CPE devices activate a
Network Address and Port Translator (NAPT) [6] capability
by default, sourcing IPv4 traffic based upon this sole global
IPv4 address. In this context, an address that can be seen in
any IP packet always refers to a unique customer. This kind
of practice is no more affordable nor suitable to solve the
IPv4 address shortage. Therefore service providers are bound
to allocate the same IPv4 public address to several customers
at the same time. In this new context, an IPv4 address, seen
in an IP packet, can refer to several customers. In addition to
the IP address, the port information must be considered as
well, in order to be able to unambiguously identify the
customer pointed by that shared address. In particular, the
port information along with the address information must
eventually be taken into account by the routing infrastructure
so that it reaches its intended destination. A port-driven
routing process may be required.
All IPv4 address shortage mechanisms extend the address
space in adding port information. They differ on the way
they manage the port value.
The first category of these solutions proposes the
introduction of a NAPT function in the service provider
network, denoted as Carrier Grade NAT (CGN) [13] or
Provider NAT. The CGN is responsible for translating IP
packets issued with private addresses to ones with
publicly routable IPv4 addresses. These solutions may
have significant impacts:
• on the applications that establish inbound
communications such as P2P, or servers behind a
CPE [5], mainly because port forwarding facility
(which opens a “door” for incoming packets) may
not be available on the CGN equipment as today in
the CPE;
• on cost and hardware/software resources, due to the
huge number of sessions (UDP, TCP) dynamically
handled by the CGN (all sessions from all CGN-
aggregated users);
28
• on the large amount of the sessions-related data to be
stored for legal obligations (typically kept during
one year).
Two main CGN-based flavors can be distinguished. (1)
Double NAT, in which two levels of NAT are cascaded: one
in the CPE and one in the network (i.e. CGN), this solution is
compliant the large majority of CPEs. (2) And DS-lite [12]
which gets rid of the CPE NAT level. This solution requires
a Dual Stack (i.e. IPv4 and IPv6) CPE. A given CPE is
assigned with an IPv6 prefix. The IPv4 Internet traffic is
encapsulated into IPv6 packets between the CPE and the DS-
lite CGN.
To illustrate the behaviour of a Double NAT architecture,
let's consider the example shown in Figure 1. When PC1
wants to contact RM, IP packets are issued with an IP source
address equal to 10.0.0.1 and source port 1234. These
packets are then transmitted to the “Home NAT” which
proceeds to a NAT operation. When exiting the “Home
NAT”, the source IP address is positioned to 10.0.1.1 and
source port number 5678. These packets are then transferred
across the private service provider network and routed to
“Provider NAT” (CGN). This node proceeds to a second
NAT operation. When exiting the “Provider NAT” box, the
IP source address becomes 25.25.25.25 and the source port
number is 9123. The packets are then routed to RM. The
response from RM will also cross the “Provide NAT” box
and the entry (10.0.1.1, 5678, 25.25.25.25, 9123) will be
used by the CGN to issue the packet toward the CPE.
Figure 1. CGN: Double NAT Illustration Example.
Alternatively to the Provider NAT solution [13], with
several drawbacks, a second alternative is proposed in this
paper. The motivations for introducing this solution are
mainly:
• Not to alter IPv4-based services current delivery and
not to impact the introduction of future services [1].
• Optimize CAPEX and OPEX (due to the absence of
session-based handling in the core network).
 • Be transparent to end-users (e.g., Port forwarding at
CPE is still possible provided the port is within the
allocated Port Range).
• Ease the implementation of legal requirements (no
session related data need to be stored).
III. PORT RANGE BASED SOLUTION
A. Overview
The main principle of the port-range solution is to assign
the same IP address (called Primary IP Address) to several
end-users' devices (called port-restricted devices) and to
constrain the source port numbers to be used by each port-
restricted device. In addition to the assigned IP address, an
additional parameter, called Port Range, is also assigned to
the customer's device. This parameter indicates the allowed
port values to be used by a given port-restricted device.
For outbound communications, a given port-restricted
device proceeds with its classical operations except that it
constrains the source port number to fit within the Port
Range. The traffic is then routed, without any specific
treatment, inside the service provider's domain and delivered
to its final destination. For inbound communications, the port
information needs to be eventually taken into account so that
it reached its proper destination. The traffic is handled by a
dedicated function called: Port Range Router (PRR). This
function may be embedded in current routers or hosted by
new nodes integrated in the IP infrastructure of service
providers. PRR is a mandatory function that must be applied
to all incoming packets. At that end, appropriate routing
tuning policies are enforced so as to drive the inbound traffic
to cross a PRR. Each PRR extracts the Primary IP Address
and the port value in order to retrieve or compute a specific
identifier called: routing identifier (e.g., Private IPv4 address
[10], IPv6 address, point-to-point link identifier, etc).
Information required to route inbound traffic is stored and
maintained in a dedicated table in the PRR referred to as
binding table.
Several modes can be envisaged to assign the
aforementioned routing identifier, such as using a Secondary
IP address or using source routing facilities. If a Secondary
IP address is used, the PRR consults its binding table and
retrieves the corresponding Secondary IP address associated
with the (Destination IP, Port Mask) matching the received
packet. Once retrieved, the PRR encapsulates the original
packets in an IPv4 one with a destination IP address equal to
Secondary IP. This packet is then routed according to
selected IGP (Interior Gateway Protocol) routes. Once
received by the CPE, a de-encapsulation operation is
achieved. The original packet is then handled locally. If the
destination port of the packet is within the Port Range
assigned to the CPE, the packet is accepted and passed to
classical NAT operation process. Otherwise, the packet is
dropped.
B. Required Modifications
In order to activate the port-range solution, some
modifications are required to be supported by port-restricted
devices (e.g., CPEs). Indeed, port-restricted devices must
29
enforce configuration data received from the service
providers so as to constrain their Port Range. More
particularly, if DHCP [11] is used to convey configuration
data, a specific DHCP option (to be assigned by IANA) [14]
has to be supported by that port-restricted device.
Furthermore, port-restricted devices constrain their NAT
operations to use source port numbers within the allocated
Port Range only. If an IP packet is received by a given port-
restricted device, with a destination port number outside the
assigned Port Range, the packet is discarded.
C. Multiplicative factor
The purpose of sharing IPv4 addresses is to increase the
addressing space. A key parameter is the factor by which
service providers want or need to multiply their IPv4 public
address space; and the consequence is the number of
customers sharing the same public IPv4 address. It is
expected that IPv6 communications will take an increasing
part during the years to come, at the expense of IPv4
communications. A safety point should be reached in the
future, where the number of IPv4 public addresses, in use at
the same time, will begin to decrease. From a service
provider point of view, this multiplicative factor must be
large enough so as to survive until the safety point event
occurs for its own customers. Most likely a one digit factor
should be sufficient. Whereas the potential is huge, -if we
allocate each customer (one IP address, 1000 ports) we
multiply by 64 the total IPv4 address space-, trying to devise
solutions that can increase the IPv4 space might mean
constantly pushing back IPv6 deployment.
D. Provisioning Considerations
Port-restricted devices are provisioned with the port
range to be used. A Port Range is defined by a Port Mask
specified itself by a Port Range Value and a Port Range
Mask [14]:
• The Port Range Value indicates the value of the
significant bits of the Port Mask. The significant bits
may take a value of 0 or 1. All the other bits (non
significant ones) are set to 0.
• The Port Range Mask indicates, by the bit(s) set to 1,
the position of the significant bits of the Port Range
Value.
Two port numbers are said to belong to the same Port
Range if they have the same Port Mask.
At a bootstrapping phase, a given port-restricted device
issues a DHCP_DISCOVER message. This message is
broadcasted. It may be relayed by a DHCP Client Relay [15]
or be received directly by a DHCP Server. Once received by
a DHCP Server, the latter answers the requester with a
dedicated DHCP_OFFER message containing a
configuration offer including particularly a Port Mask
Option. Then, the port-restricted device constrains its NAT
operations to the provisioned Port Range.
E. Illustration Example
As shown in Figure 2, the same Primary IP address
25.25.25.25 is assigned to “Home NAT” (e.g., CPE) of PC1
(Resp. PC2 and PC3) and to PC4. Together with this IP
address, secondary addresses IP_Sec_1 (Resp. IP_Sec_2 and
IP_Sec_3) and IP_Sec_4 are assigned to the “Home NAT” of
PC1 (Resp. PC2 and PC3) and PC4. Distinct Port Masks are
also assigned to all port-restricted devices. In this example,
these masks are such that the “Home NAT” of PC1 (Resp.
PC2 and PC3) can use a range of port numbers up to 10000
(Resp. 10001 to 20000 and 20001 to 30000) and PC4 itself
can use a range of port numbers from 30001 to 40000.
Figure 2. Port Range Illustration Example.
When PC1 issues an IP packet to RM, the source IP
address is equal to 10.0.0.1 and the source port number is
positioned to 1234. Once received by the “Home NAT”, it
proceeds to its NAT operations and assigns a port number in
its provisioned port range. In this example, a source port
number equal to 9123 is assigned. The packet is then routed
towards its final destination (i.e. RM). RM can send traffic to
25.25.25.25:9123. The traffic is intercepted by the PRR node
which proceeds to a port-driven routing. Concretely, PRR
retrieves both destination IP address and destination port
number from the received packet. Then, it checks its binding
table (i.e. list of [public IP address, Mask_Port, Secondary IP
address] entries) and retrieves the secondary IP address. The
initial packet is encapsulated and sent to IP_Sec_1. Packets
are routed until the “Home NAT” in front of PC1 which
proceeds to a de-encapsulation operation. At this stage, it
retrieves a packet destined to 25.25.25.25:9123. Finally, it
checks its mapping table in order to find which local IP
address and port number have to be used. In this example, an
entry is already instantiated, 10.0.0.1 and 1234 are returned
and the packet is translated and routed to PC1. All these
operations are similar to classical NAT operations except the
operations undertaken by the PRR and the constrained port
numbers assignment process.
IV. A PROOF-OF-CONCEPT TESTBED
To assess the validity of the proposed solution, a proof-
of-concept testbed has been set-up. Various tests have been
performed to assess the behaviour of the port-range solution
and its level of transparency to well-known applications
30
(e.g., HTTP, P2P, FTP, etc.). Only TCP and UDP transport
protocols have been considered in this version of the testbed.
A. Testbed setup and configuration
All the components of the testbed (e.g., CPEs and PRR)
are Linux-based PCs (except the terminals which may be of
any OS). The testbed relies only upon Linux configurations.
No software development has been necessary.
Figure 3 provides an overview of the testbed architecture
and its components, particularly:
• CPE-1 and CPE-2 are two port-restricted devices
which share the same IPv4 address (i.e. IP_pub);
• a PRR node which is connected via Ethernet to the
CPEs.
1) CPEs configuration
In the remaining part, “x” suffix designates either “1” or
“2” (e.g., “CPE-x” refers either to CPE-1 or CPE-2).
As shown in Figure 3, each CPE has two Ethernet
interfaces, each one being set-up with a private IPv4 address:
• Eth_INT: the interface towards the LAN the CPE
serves. This LAN may host terminal(s) and/or
server(s). The private address
[private_addr_INT_CPE-x] is assigned to this
interface.
• Eth_EXT: the interface towards the PRR. The
private address [private_addr_EXT_CPE-x] is
configured on this interface.
Netfilter features are used to control the NAT embedded
in Linux OS. To force each CPE to send all its outbound IP
packets within the assigned port range, dedicated Netfilter
features have been configured through “iptables” commands,
as shown below for TCP:
/sbin/iptables -t nat -A POSTROUTING -p tcp -o
[Eth_EXT] -j SNAT --to-source [IP_pub]:[port_range-x]
With:
• IP_pub: the shared public address.
• ports-range-x: the port range assigned to each CPE.
For UDP, a similar command has been executed.
Note that the CPE has no interface set with the shared IP
public address (IP-pub). This latter is only present at the
NAPT settings level. With this method, direct
communications (through PRR) between two CPEs (CPE-1
and CPE-2) sharing the same IP-pub address but with
distinct port ranges, are feasible. This is because our NAT
rules do not refer to any address of local Ethernet interfaces.
2) PRR configuration and behaviour
To enforce a port-driven routing on the PRR, Linux
Netfilter capabilities [17] are also used. Inbound packets are
marked depending on their destination address and
destination port number. Particularly, the following iptables
command is executed (e.g., for TCP):
/sbin/iptables -t mangle -A PREROUTING -p tcp --
destination [IP_pub] --dport [port_range-x] -j MARK --set-
mark [x]
In Netfilter configuration, [x] marking is associated with
a routing table dedicated for [x] marked packets. This table
contains only one entry: the one pointing to the private
address of the CPE-x [private_addr_EXT_CPE-x]. Of course
in the PRR, there is a mark setting line with a corresponding
routing table for each of the CPEs the PRR serves (i.e. CPE-
1 and CPE-2).
This marking is purely at Netfilter level and does not
entail any marking of IP packets.
Upon receipt of an inbound packet at the outside
interface of the PRR (e.g., coming from the Internet):
• The packet is marked relatively to the destination
address and port range in which the destination port
number falls. This is done at pre-routing level, as
shown in the iptables command listed above.
• Owing to this mark ([x] for CPE-x), the packet
passes through a routing table which points to
[private_addr_EXT_CPE-x]. This address is seen by
the PRR as the first hop of the route towards the
CPE-x. The PRR proceeds to an ARP (Address
Resolution Protocol) -if not already achieved
previously- and matches this private address with the
MAC (Media Access Control) address of
Eth_EXT_CPE-x.
• The packet is then encapsulated into an Ethernet
frame and transmitted to Eth_EXT_CPE-x.
V. TESTS AND RESULTS
A. Conducted tests and overall results
The objective of the testing activity was to assess the
transparency of the port range solution for well-known
applications, such as: HTTP, FTP, e-mail, Instant messaging,
P2P and Voice over IP. The results obtained confirmed the
validity of the port range solution: all tested services worked
normally through the testbed. Tests have also been
performed between a client under CPE-1 and a server under
CPE-2. Again, no failure to establish the communications
has been experienced. The results show that the tested
services are fully compatible with the port range solution.
Figure 3. Testbed Architecture
31
The slight limitations observed upon one application
(described in sub-section C) do not concern the port range
solution.
B. Port forwarding
In today’s practices, a static NAT entry was configured
to accept incoming P2P traffic. This practice is motivated by
the fact that Linux NAT is not by default an “independent
endpoint filtering”. This means that an outbound connection
with a remote machine does not allow another machine to
enter through the created NAT entry. As usual, a port
forwarding setting in CPEs is necessary to allow such
inbound connections. The port range solution brings only the
constraint that the port value must be configured to be within
the allowed port range. Any port-restricted CPE in the future
would need to take care of that in displaying Web menus to a
user who wants to open a port manually. As for the UPnP
IGD protocol -which allows to automate this port forwarding
process- the next version (2.0) should provide a means to
answer the request terminal with another port number than
that which was originally requested by the terminal.
C. Limitation
Through the tests campaign performed, two limitations
were experienced. The first limitation occurs when two
BitTorrent clients sharing the same IP address want to
retrieve simultaneously the same file located in a single
remote peer server. This limitation is due to the default
BitTorrent configuration on the remote peer server which
does not permit sending the same file to multiple ports of the
same IP address. However, provided clients sharing the same
IP address can find each other through a common tracker -
DHT or Peer Exchange- they could exchange portions. Even
if they could not, we observed that the remote peer began
serving portions of the file automatically to the pending
client as soon as the other client (sharing the same IP
address) had finished downloading. This limitation is
eliminated if the remote peer is configured with
“bt.allow_same_ip == TRUE”. The second limitation occurs
when a BitTorrent client tries to download a file located on
several seeders, when those seeders share the same IP
address. This is because the clients by default enforce
“bt.allow_same_ip” parameter to FALSE. The client will
only be able to connect to one seeder, among those having
the same IP address, to download the file (note that the client
can retrieve the file from other seeders having distinct IP
addresses). Again, this limitation is eliminated if the local
client is configured with “bt.allow_same_ip == TRUE”,
which is somewhat likely as those clients will directly
experience better throughput by changing their own
configuration. Mutual file sharing between hosts having the
same IP address has been checked. Indeed, machines having
the same IP address can share files with no alteration
compared to current IP architectures.
These limitations are not specific to the port-range
solution itself but to the restriction implemented by software
developers to restrict the access based on IP addresses.
D. Run servers behind a port-restricted device
The port range solution allows also a server to be
installed behind a port-restricted CPE (e.g., CPE-2). The
CPE NAT must be configured to redirect the traffic to the
server. The used port must belong to the Port Range assigned
to the CPE. A remote client (or a client behind CPE-1)
succeeds to connect normally to the server, provided that the
client specifies the address and port of the server when
launching the connection. Further investigations may be
undertaken such as using DynDNS and SRV records so that,
through DNS, the client can retrieve the port number and
address to access the service.
VI. CONCLUSION AND FUTURE WORK
In this paper we have presented a solution to solve the
IPv4 address exhaustion problem. We have described a
lightweight architecture that may be deployed by IP network
providers to offer IP connectivity services to their current or
future customers. Compared to CGN, this solution can
achieve CAPEX/OPEX reduction because the NAT
resources are still hosted in the CPEs (as today), instead of
being centralized in network equipments (CGN). The results
of the performed tests prove the validity of the proposed
solution. This paper didn’t make any recommendation on the
implementation scenario. Service providers are free to
enforce their own engineering rules based on their internal
policies and available technological means as activated in
their IP infrastructure. The solution is flexible enough to be
set up in various contexts.
As for future work, the focus will be put on IPv6 variant
of the port-range solution since the ultimate target is to
migrate to IPv6 and to ease the interconnection between
heterogonous realms. A stateless IPv4-IPv6 interworking
solution, based on Port Range, is currently under
specification [18].
32
VII. REFERENCES
[1] Muller, A. Carle, G. Klenk, A., Behavior and classification of NAT
devices and implications for NAT traversal, IEEE Network, IEEE,
September-October 2008, Volume: 22, Issue: 5, On page(s): 14-19
[2] Francis, P., Is the Internet going NUTSS?, Internet Computing, IEEE,
Nov.-Dec. 2003, Volume: 7 , Issue: 6, page(s): 94 – 96, ISSN: 1089-
7801
[3] Greenstein, S., Slouching Toward a Dystopian Internet, Micro, IEEE,
Sept.-Oct. 2008, Volume: 28 , Issue: 5, page(s): 6 – 7, ISSN: 0272-
1732
[4] S. Deering , R. Hinden, Internet Protocol, Version 6 (IPv6)
Specification, RFC 2460, 1998
[5] M. Holdrege , P. Srisuresh, Protocol Complications with the IP
Network Address Translator, RFC 3027, 2001
[6] P. Srisuresh , K. Egevang, Traditional IP Network Address Translator
(Traditional NAT), RFC 3022, 2001
[7] G. Tsirtsis , P. Srisuresh, Network Address Translation - Protocol
Translation (NAT-PT), RFC 2766, 2000
[8] E. Nordmark, Stateless IP/ICMP Translation Algorithm (SIIT), RFC
2765, 2000
[9] H. Kitamura, A SOCKS-based IPv6/IPv4 Gateway Mechanism, RFC
3089, 2001
[10] Y. Rekhter , B. Moskowitz , D. Karrenberg , G. J. de Groot , E. Lear,
Address Allocation for Private Internets, RFC1918, 1996
[11] Droms, R., Dynamic Host Configuration Protocol, RFC 2131, March
1997
[12] Durand, A., Droms, R., Haberman, B., Woodyatt, J., Dual-stack lite
broadband deployments post IPv4 exhaustion, Work in progress,
draft-ietf-softwire-dual-stack-lite-00, March 2009
[13] Maennel, O., Bush, R., Cittadini, L., Bellovin, S., A Better Approach
than Carrier-Grade-NAT, 2008, Technical Report CUCS-041-08
[14] Bajko, G., Savolainen , T., Boucadair, M., and P. Levis, Dynamic
Host Configuration Protocol (DHCP) Option for Port Range
Assignment, Work in progress, January 2009
[15] Patrick, M., DHCP Relay Agent Information Option, RFC 3046,
January 2001
[16] http://www.potaroo.net/tools/ipv4/index.html [last access: May 11,
2009]
[17] http://www.netfilter.org/ [last access: May 11, 2009]
[18] Boucadair, M. Levis, P., Grimault, J-L., Villefranque, A., Kassi-
Lahlou, M., Flexible IPv6 Migration Scenarios in the Context of IPv4
Address Shortage, Work in progress, March 2009