Internet Engineering Task Force G. Bajko
Internet Draft T. Savolainen
Intended Status: Proposed Standard Nokia
Expires: May 2, 2009 November 2, 2008
Port Restricted IP Address Assignment
draft-bajko-v6ops-port-restricted-ipaddr-assign-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
With the foreseen scarcity of public IPv4 addresses and the
hesitation and technical difficulties to deploy IPv6, the transition
scenarios which assumed that migration to IPv6 happens before the
run-out of IPv4 addresses, need to be revisited.
This document defines a method to allocate the same IPv4 address to
multiple hosts, thus prolonging the availability of public IPv4
addresses for as long as it takes for IPv6 to take over the demand
for IPv4. The document also describes the deployment scenarios where
this method is applicable.
Bajko & Savolainen Expires May 2, 2009 [Page 1]
Port restricted IP address assignment November 2008
Conventions used in this document
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 RFC-2119.
Terminology and abbreviations used in this document
Port restricted IPv4 address: an IP address which can only be used
in conjunction with the specified ports. Port restriction refers to
all transport addresses.
ASN GW Access Service Network Gateway
CGN Carrier Grade Network Address Translator
CPE Consumer Premises Equipment, a device that resides
between internet service provider's network and
consumers' home network.
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
OPR Offered Port Restricted IP Address
PDN GW Packet Data Network Gateway
PDSN Packet Data Serving Node
RPR Requested Port Restricted IP Address
Table of Content
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .3
2. Usage of port-restricted IPv4 addresses in various scenarios . .3
2.1 Point-to-point links with L2 IPv4 support . . . . . . . . . 4
2.2 Point-to-point tunneled links . . . . . . . . . . . . . . . 4
2.3 NAT in a host . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Distributed Network Address Translation function . . . . . .6
2.5 Relationship to other proposals . . . . . . . . . . . . . . 7
2.5.1 Dual-Stack Lite . . . . . . . . . . . . . . . . . . . 7
2.5.2 Address and Port Borrowing Protocol . . . . . . . . . 7
2.6 Efficiency issues in dynamic and static port allocation
methods . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. DHCPv4 Option for allocating port restricted public IPv4 addr. .8
3.1 Option for offering port restricted IPv4 address . . . . . .8
3.2 Option for requesting port restricted IPv4 address . . . . .9
4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . .9
4.1 Client Behaviour . . . . . . . . . . . . . . . . . . . . . .9
4.2 Server Behaviour . . . . . . . . . . . . . . . . . . . . . 10
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . .11
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . .11
7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . .12
8. Security considerations . . . . . . . . . . . . . . . . . . . .12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
10. Informative References . . . . . . . . . . . . . . . . . . . .12
11. Author's Addresses . . . . . . . . . . . . . . . . . . . . . .14
Bajko & Savolainen Expires May 2, 2009 [Page 2]
Port restricted IP address assignment November 2008
1. Introduction
There are a number of possible solutions to deal with the problem of
transitioning from IPv4 to IPv6; however none of them is a one fits
all solution. Different solutions fit different deployment scenarios
(see also [ARKK2008]). See [WING2008] for comparison.
As a possible alternative solution for the IPv4-IPv6 coexistence
period, this document describes a method, using newly defined DHCPv4
[RFC2131] options, that allows servers to assign port restricted
IPv4 addresses to clients. By assigning the same IPv4 address to
multiple clients, the availability of IPv4 addresses can be
prolonged for as long as it takes for IPv6 to take over the demand
for IPv4.
The solution described in this document is intended to be used by
large ISPs, who as of the date of writing this document, have a
large enough IPv4 address pool to be able to allocate one public
IPv4 address for each and every client. They expect though that the
situation is unsustainable and they will soon not be able to provide
every client with a public IPv4 address. Such ISPs have two
possibilities to choose from:
- deploy Network Address Translators (NAT), which can be a
significant investment for ISPs not having NATs yet. The address
space limitations of [RFC1918] may even force these large ISPs to
deploy double NATs, which come with all the harmful behaviour of
Carrier Grade NATs (CGN), as described in [MAEN2008]; or
- allocate fragments of the same public IPv4 address directly to
multiple clients (which can be CPEs or end hosts), thus avoid the
cost of deploying multiple layers of, or carrier grade NATs. It is
however assumed, that the demand for IPv4 addresses will decrease in
the not so distant future, being taken over by IPv6, as the proposal
in this draft is not by any means a permanent solution for the IPv4
address exhaustion problem. In fact, some presented deployment
scenarios require existence of IPv6 access network.
For ISPs not having NATs yet, a solution not requiring NATs would
probably be preferred. For some other ISPs, who already have NATs in
place, increasing the capacity of their NATs might be the preferred
solution.
2. Usage of port-restricted IPv4 addresses in various scenarios
This chapter depicts the scenarios where port restricted IPv4
addresses can be used, and what kind of assumptions have to be made.
Relationships to various IPv4-IPv6 transition proposals being
currently discussed in IETF are also considered.
Bajko & Savolainen Expires May 2, 2009 [Page 3]
Port restricted IP address assignment November 2008
2.1 Point-to-point links with L2 IPv4 support
In point-to-point links it can be assumed that there are only two
communicating parties on the link, and thus IP address collisions
are easy to avoid.
In wireless cellular networks host attaches to an access router,
such as 3GPP PDN GW [3GP23401] or WiMAX ASN GW [WMFS21.2], over a
point-to-point link providing layer 2 IPv4 transport capability.
In order to be able to allocate a port-restricted IP addresses to a
host, the access router needs to implement DHCPv4 server [3GP23401]
or at least act as a DHCPv4 relay or DHCPv4 proxy [WMFS31.2], while
a DHCPv4 server exists in the backend. These setups are illustrated
in figure 1.
+--------+ |
3GPP ---Point to Point link--| 3GPP |------|
host <-IPv4 EPS bearer--> | PDN GW | |
+--------+ |
| IPv4 Internet
+--------+ |
WiMAX ---Point to Point link--| WiMAX |------|
host <-----IPv4 CS------> | ASN GW | |
+--------+ |
Figure 1 Point-to-point physical links
As each host is attaching to the access router with an individual
link, both modified and unmodified hosts can be supported
simultaneously. This enables incremental deployment of modified
hosts that are supporting public IPv4 address conservation by using
DHCP port restricted IPv4 address assignment, while continuing to
support the legacy hosts using DHCP as currently specified.
In this scenario IPv6 addresses can be used in parallel with any
IPv4 address, therefore no tunneling is necessary.
2.2 Point-to-point tunneled links
From DHCPv4 point of view tunneled link scenario does not differ
very much from L2 point-to-point links as described in 2.1, although
there are general concerns regarding tunnels (e.g. decreased MTU).
It is expected by authors that the tunneling would be done over
IPv6, but other mechanisms can also be thought of.
Tunnel is established between a host (or a CPE) and a tunnel
endpoint in the host operator's network. In different scenarios the
tunnel endpoint may be placed at different locations. The tunnel
endpoint can be at the first hop router such as 3GPP2 PDSN
[3G2X0011] or 3GPP PDN-GW, or farther off in the network such as at
Bajko & Savolainen Expires May 2, 2009 [Page 4]
Port restricted IP address assignment November 2008
Dual-Stack Lite Carrier Grade NAT (see 2.5.1). These example setups
are illustrated in figure 2.
Having the tunnel endpoint at the first hop router can be beneficial
in setups where arrangement of native dual-stack transport for the
last mile is not feasible or cost-effective approach. This can be
the case e.g. in current 3GPP networks where a PDP context
[3GP23060] is capable of transporting only IPv4 or IPv6 packets, and
for dual-stack access two parallel PDP contexts are required.
Tunnel endpoints,
implementing DHCPv4
server/relay/proxy
+-------------+
Host ====IPv4 over IPv6==== | 3GPP2 | |
<---PPP & IPv6CP ----> | PDSN |------|
(point-to-point) +-------------+ |
|
+-------------+ |
Host ====IPv4 over IPv6==== | 3GPP |------| IPv4 Internet
<--IPv6 PDP context--> | GGSN | |
(point-to-point) +-------------+ |
|
+-------------+ |
Host ====IPv4 over IPv6==== | IETF |------|
<---- IPv6-only -----> | DS-Lite CGN | |
network +-------------+
Figure 2 Point-to-point links as IPv4 over
IPv6 tunnels over three different accesses
For networks which use IP(v6)CP to configure an IPv4 and IPv6
address to the host, allocating a port-restricted IPv4 address to
the host to prevent running out of available IPv4 addresses, can
also be a feasible solution. In these deployment scenarios IPv6CP
would be used to configure an IPv6 address to the host. The host
would then set up the tunnel and use the DHCPv4 extensions defined
in this document to request a port-restricted IPv4 address. Examples
of such networks include 3GPP2 and BRAS.
2.3 NAT in a host
When a host which is capable of handling a port-restricted IP
address, but some of the applications on the host may have trouble
using those addresses (e.g. they require a specific port to
operate), as an implementation choice, the host may hide the port
restricted nature of the allocated address by implementing an
internal NAT as illustrated in figure 3 below:
Bajko & Savolainen Expires May 2, 2009 [Page 5]
Port restricted IP address assignment November 2008
Host
+---------------------+
+ Applic +
+ | +
+ | IPv4p +-----+ + Port Restricted IPv4 address
+ |-------| NAT | +---------------------------------
+ +-----+ +
+ +
+---------------------+
Figure 3 Internal NAT in a host
2.4 Distributed Network Address Translation function
One deployment model for port restricted IPv4 addresses is the
distributed Network Address Translation, as shown in figure 4. This
deployment scenario is preferred for the cases when:
1 the port-restricted IPv4 address is not supported by all hosts
connected to the CPE
2 Applications may have trouble understanding port restricted
public IPv4 addresses, but are familiar with RFC1918 addresses
3 Centralized NAT (Carrier Grade NAT) function may be expensive
to deploy
IPv6-only network
+----+ +------+
|home| + AR+ + +-------------+
IPv4 host--------+CPE +=====tunnel======+DHCP +--+IPv4 Internet|
+----+ +Server+ +-------------+
+------+
<---private v4---> <--- v4 over v6 --> <---public v4---->
Figure 4 Distributed NAT scenario illustrated
With distributed NAT model, the home CPE is assigned a port
restricted public IPv4 address and it provides NATed addresses to
the legacy devices attached to it. This setup allows avoidance of
Carrier Grade NAT and enables customers' control on NAT with e.g.
protocols such as UPnP and NAT-PMP, and also makes it easier to
optimize sending of keep-alive messages.
The distributed NAT model can be used in both physical and tunneled
point-to-links.
Alternatively, a CPE may choose to subdivide the port-restricted
IPv4 address, in cases when all hosts connected to the CPE support
port-restricted IPv4 address assignment.
Bajko & Savolainen Expires May 2, 2009 [Page 6]
Port restricted IP address assignment November 2008
2.5 Relationship to other proposals
This chapter describes how the new DHCPv4 options for port
restricted IPv4 address assignment can be seen to relate to some
recent IETF proposals on this subject.
2.5.1 Dual-Stack Lite
Dual-Stack Lite [DURA2008] describes a setup where a Dual-Stack Lite
enabled device tunnels IPv4 over IPv6 to a Carrier Grade NAT. For
the address mapping purposes, the CGN uses Dual-Stack Lite device's
unique IPv6 address as an identifier in addition to any private IPv4
address device may be using. Dual-Stack Lite client side
functionality can be implemented into a home router or a host.
The DHCPv4 port-restricted addresses can be used in combination with
Dual-Stack Lite environment, as defined in [DURA2008], by simply
incorporating the port-restricted IPv4 address allocation mechanism
into the CGN entity. The benefit of doing so is to both enable
distribution of the NAT function and to allow updated devices and
applications to make good use of public, but port-restricted, IPv4
addresses. The setup is illustrated in figure 5.
Alternatively, the Carrier Grade NAT can just act as a tunnel
endpoint and DHCP relay, while the DHCPv4 server is a separate
entity. Collocating DHCPv4 server and tunnel endpoint is preferred
approach to avoid introduction of control interfaces between DHCPv4
server and tunnel endpoint.
+------------------+ +---------------+
|Dual-Stack Lite | +---+ +------+
|host |==IPv4 over IPv6===|NAT|----| |
+------------------+ +---+ | |
|+----+ |Multi |
||IPv4| |plexer|--- IPv4
||pool| | | Internet
|+----+ +------+
+------------------+ +------+ | |
| Host with port |==IPv4 over IPv6===|DHCPv4|----+ |
|restricted IP addr| +------+ |
| (&internal NAT) | +---------------|
+------------------+ Carrier Grade NAT
Figure 5 Using port-restricted IPv4 addresses in
Dual-Stack Lite environment
2.5.2 Address and Port Borrowing Protocol
The architecture of address and port borrowing protocol (APBP) is
described in [DESP2008]. The new DHCPv4 options can be used by APBP
enabled CPE, or host, to request public IPv4 address with port range
Bajko & Savolainen Expires May 2, 2009 [Page 7]
Port restricted IP address assignment November 2008
from APBP server. The APBP server can also act as a IPv4-over-IPv6
tunnel endpoint. This is illustrated in figure 1 of [DESP2008].
Again the DHCPv4 client can be either CPE implementing the
distributed NAT, or a host having internal NAT.
2.6 Efficiency issues in dynamic and static port allocation methods
With the port-restricted IPv4 address allocation method, ports are
allocated statically providing benefits as described, while carrier
grade NAT based proposals, such as DS-Lite [DURA2008], have a
dynamic port mapping, but require NATs. The obvious result is that
DS-Lite is more efficient in sharing single public IPv4 address for
multiple hosts, but with related downsides. Thus there is a trade-
off that has to be taken into account when making deployment
decisions.
The seriousness of efficiency difference is decreased when more
services become available in IPv6 and thus will cease to consume
IPv4 address and port space. In this regard it is important to have
very port consuming services directly IPv6-accessible.
3. DHCPv4 Options for allocating port restricted public IPv4 address
This section defines new dhcpv4 options, which would allow
allocation of port restricted IPv4 addresses.
3.1 Option for offering port restricted IPv4 address
The option layout is depicted below:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | length | IPv4 address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... IPv4 address | beginning port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ending port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv4-OPR (TBD) - 1 byte
Length
1 byte, value=8
IP address
Public IPv4 address
Bajko & Savolainen Expires May 2, 2009 [Page 8]
Port restricted IP address assignment November 2008
Beginning port range
beginning source port number, which can be used in
conjunction with the IP address
Ending port range
last source port number, which can be used in conjunction
with the IP address
3.2 Option for requesting port restricted IPv4 address
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | length | IPv4 address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... IPv4 address | beginning port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ending port range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv4-RPR (TBD) - 1 byte
Length
1 byte, value=8
IP address
Public IPv4 address
Beginning port range
beginning source port number, which can be used in
conjunction with the IP address
Ending port range
last source port number, which can be used in conjunction
with the IP address
4. Option Usage
4.1 Client Behaviour
A client which supports the extensions defined in this document,
SHOULD insert the option OPTION-IPv4-RPR, by setting the IPv4
address field to 0.0.0.0, the beginning and ending port numbers to
Bajko & Savolainen Expires May 2, 2009 [Page 9]
Port restricted IP address assignment November 2008
zero, into a DHCPDISCOVER message, to explicitly let the server know
that it supports port restricted IPv4 addresses.
When a client, which supports the options defined in this document,
receives a DHCPOFFER with the 'yiaddr' (client IP address) field set
to 0.0.0.0, it SHOULD check for the presence of OPTION-IPv4-OPR
option field. If such an option is present, the client MAY send a
DHCPREQUEST message and insert the option OPTION-IPv4-RPR with the
IP address and port ranges received in the OPTION-IPv4-OPR option of
the previous DHCPOFFER. The client MUST NOT include a 'Requested IP
Address' DHCP option (code 50) into this DHCPOFFER.
The client MUST NOT insert the IP address received in OPTION-IPv4-
OPR into the 'Requested IP Address' DHCP option (code 50).
When the client receives a DHCPACK message with an OPTION-IPv4-OPR
option, it MAY start using the specified IP address in conjunction
with the source ports specified. The client MUST NOT use the IP
address with different source port numbers, as that may result in a
conflict, since the same IP address with a different source port
range may be assigned to a different client. Furthermore, the client
MUST notice the situation where an outgoing IP packet has the same
IP address as destination address than the client itself has, but
the port number is not belonging to the allocated range. In this
case the client MUST detect that the packet is not destined for
itself, and it MUST send it forward.
In case the initial port range received by the client from the
server is exhausted and the client needs additional ports, it MAY
request so by sending a new DHCPDISCOVER message.
A client MUST NOT include an OPTION-IPv4-OPR option field into any
DHCP message it generates.
4.2 Server Behaviour
When a server, which supports the options defined in this document,
receives a DHCPDISCOVER message, it SHOULD check the presence of the
OPTION-IPv4-RPR option. If that option is present, the server SHOULD
allocate port restricted IPv4 address to the client, and save the
unrestricted addresses for clients which do not support the
extensions defined in this document. If OPTION-IPv4-RPR is not
present in DHCPDISCOVER, the server SHOULD allocate full
unrestricted public or private [RFC1918] IPv4 address to the client,
whenever available, by generating a DHCPOFFER as described in
[RFC2131].
When a server, which supports the options defined in this document,
receives a DHCPDISCOVER message and can only offer port restricted
IP address to the client, it MUST set the 'yiaddr' (client IP
address) field of the DHCPOFFER message to 0.0.0.0 and SHOULD insert
Bajko & Savolainen Expires May 2, 2009 [Page 10]
Port restricted IP address assignment November 2008
the OPTION-IPv4-OPR option field by specifying the IP address and
allowed port range.
When a server, which supports the options defined in this document,
receives a DHCPDISCOVER message from a client without the OPTION-
IPv4-RRP, and knows by means outside the scope of this document,
that the client supports the usage of port-restricted IPv4 addresses
(or it is only entitled to be provisioned with such addresses), MUST
set the 'yiaddr' (client IP address) field of the DHCPOFFER message
to 0.0.0.0 and SHOULD insert the OPTION-IPv4-OPR option field by
specifying the IP address and allowed port range.
When the server receives a DHCPREQUEST message from the client with
an OPTION-IPv4-RPR option field containing the IP address and port
range it has previously offered to the client, the server MUST send
a DHCPACK, where the 'yiaddr' (client IP address) field is set to
0.0.0.0 and the server MUST include the OPTION-IPv4-OPR option
including the IP address and port range the client requested.
When the server receives a DHCPREQUEST message from the client with
an OPTION-IPv4-RPR option field containing an IP address and port
range it has previously not offered to the client, the server MUST
send a DHCPNAK to the client.
When the server detects that a client with a specific hardware
address, having already been allocated with a port restricted IP
address, sent another DHCPDISCOVER, it MAY, based on local policy,
offer the client with additional port restricted IP address.
A server MUST NOT include an OPTION-IPv4-RPR option field into any
DHCP message it generates. A server MUST ignore any OPTION-IPv4-OPR
options in DHCP messages generated by clients.
A server SHOULD ensure the client is residing on an access link
where usage of port-restricted addresses are not causing problems,
before allocating it a port restricted IPv4 address.
5. Applicability
The immediate applicability of such a solution is in 3GPP [3GP23401]
or WiMAX [WMFS21.2] compliant mobile networks, where cellular hosts
can directly utilize the option without separate gateway or consumer
premises gateway being present. The new options can be utilized both
in point-to-point links and/or IPv4-over-IPv6 tunnels.
This document does not address the issue of how clients configured
with port restricted IP addresses would handle protocols that run
directly over IP (e.g. ICMP). That problem needs further
consideration.
The server leasing the port restricted IP address, or a gateway in
the network, (e.g. the first hop router of a point-to-point link)
Bajko & Savolainen Expires May 2, 2009 [Page 11]
Port restricted IP address assignment November 2008
MUST enforce the restricted port range policy by filtering out
packets sent using out of range source ports.
6. IANA considerations
This document defines two new DHCPv4 options as described in section
2.
Offered Port Restricted IP Address Option for DHCPv4 (OPTION-IPv4-
OPR) TBD
Requested Port Restricted IP Address Option for DHCPv4 (OPTION-IPv4-
RPR) TBD
7. Open issues
Handling ICMP and other protocols running natively on top of IP is a
challenge when multiple hosts share the same IP address.
As the new DHCP options are designed only for point-to-point links,
usage of these options on shared mediums such as Ethernet is not
recommended, as there would be possible problems with ARP. If port-
restricted IP addresses are going to be taken into use, it MUST be
ensured that they are only used in environments where their usage
does not interfere with standard IP communication.
8. Security considerations
The solution is vulnerable to DoS when used in shared medium or when
access network authentication is not a prerequisite to IP address
assignment. The solution SHOULD only be used on point-to-point
links, tunnels, and/or in environments where authentication at link
layer is performed before IP address assignment, and not shared
medium.
9. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC2131, March 1997
10. Informative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de
Groot, G., Lear, E., "Address Allocation for Private
Internets", RFC1918, February 1996
[WING2008] Wing, D., Ward, D., Durand, A. "A Comparison of
Proposals to Replace NAT-PT", September 2008, draft-
wing-nat-pt-replacement-comparison-00
[DESP2008] Despres, R., "A Scalable IPv4-IPv6 Transition
Architecture Need for an address-port-borrowing-
Bajko & Savolainen Expires May 2, 2009 [Page 12]
Port restricted IP address assignment November 2008
protocol (APBP) ", July 2008, draft-despres-v6ops-apbp-
01
[ARKK2008] Arkko, J., Townsley, M., "IPv4 Run-Out and IPv4-IPv6
Co-Existence Scenarios", September 2008, draft-arkko-
townsley-coexistence-00
[DURA2008] Durand, A., Droms, R., Haberman, B., Woodyatt, J.
"Dual-stack lite broadband deployments post IPv4
exhaustion", September 2008, draft-durand-softwire-
dual-stack-lite-00
[MAEN2008] Maennel, O., Bush, R., Cittadini, L., Bellovin, S., "A
Better Approach than Carrier-Grade-NAT", 2008,
Technical Report CUCS-041-08
[WMFS21.2] WiMAX Forum, "WiMAX Forum Network Architecture, (Stage
2: Architecture Tenets, Reference Model and Reference
Points)", January 2008, Release 1, Version 1.2
[WMFS31.2] WiMAX Forum, "WiMAX Forum Network Architecture, (Stage
3: Detailed Protocols and Procedures)", January 2008,
Release 1, Version 1.2
[3GP23401] 3rd Generation Partnership Project (3GPP), Technical
Specification Group Services and System Aspects,
"General Packet Radio Service (GPRS) enhancements for
Evolved Universal Terrestrial Radio Access Network (E-
UTRAN) access (Release 8)", September 2008, 3GPP TS
23.401 V8.3.0
[3GP23060] 3rd Generation Partnership Project (3GPP), Technical
Specification Group Services and System Aspects,
"General Packet Radio Service (GPRS); Service
description; Stage 2 (Release 8)", September 2008, 3GPP
TS 23.060 V8.2
[3G2X0011] 3rd Generation Partnership Project 2 (3GPP2), "cdma2000
Wireless IP Network Standard: Introduction", August
2003, 3GPP2 X.S0011-001-C version 1.0.0
11. Author's Addresses
Gabor Bajko
Email: gabor(dot)bajko(at)nokia(dot)com
Teemu Savolainen
Hermiankatu 12 D
FI-33720 TAMPERE
FINLAND
Bajko & Savolainen Expires May 2, 2009 [Page 13]
Port restricted IP address assignment November 2008
Email: teemu.savolainen@nokia.com
Bajko & Savolainen Expires May 2, 2009 [Page 14]
Port restricted IP address assignment November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bajko & Savolainen Expires May 2, 2009 [Page 15]