Internet Engineering Task Force A. Ripke
Internet-Draft J. Quittek
Intended status: Informational M. Brunner
Expires: January 7, 2010 NEC Laboratories Europe
July 6, 2009
Dynamic Port Range Re-Assignments for Address Sharing
draft-rqb-dynamic-port-ranges-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 January 7, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document proposes an extension regarding dynamic port range re-
assignment to an IPv4 address sharing framework (SHARA), to overcome
Ripke, et al. Expires January 7, 2010 [Page 1]
Internet-Draft Dynamic Port Ranges July 2009
IPv4 address shortage. It allows an entity which is responsible for
address and port distribution to apply a more flexible handling of
already assigned port ranges. An adjustment of number of ports per
customer according to the current consumption pattern is possible
with this enhancement.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Dynamic port range re-assignments . . . . . . . . . . . . . . . 4
4. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Initialization . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Detecting the change point . . . . . . . . . . . . . . . . 5
4.3. Assigning a new port range . . . . . . . . . . . . . . . . 5
4.4. Ongoing port consumption . . . . . . . . . . . . . . . . . 6
4.5. Final deallocation of a port range . . . . . . . . . . . . 6
5. Location of the address and port manager . . . . . . . . . . . 6
5.1. Mobile networks . . . . . . . . . . . . . . . . . . . . . . 6
6. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Service Management . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Server policy . . . . . . . . . . . . . . . . . . . . . . . 7
8.2. Client policy . . . . . . . . . . . . . . . . . . . . . . . 7
9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
12. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Ripke, et al. Expires January 7, 2010 [Page 2]
Internet-Draft Dynamic Port Ranges July 2009
1. Introduction
The IETF starts discussing a scheme for enlarging the usable IP
address space in [I-D.ymbk-aplusp] or [I-D.boucadair-port-range]
using parts of the port numbers, similar to what Network Address
Translators (NAT) do. This allows to assign the same IP address to
several customers or hosts. The IP address together with the port
bits extension differentiate the routing and forwarding of that
communication.
So far within the IETF DHCP extensions [I-D.boucadair-dhc-port-range]
and PPP extensions [I-D.boucadair-pppext-portrange-option] to assign
IP addresses and port ranges to hosts and sites have been proposed.
However, since the deployments are very different for different
users, customers with several users etc., more means for managing
port assignments appear to be required. Measurements showed that
different clients need different range sizes at different times
[flow-counting].
This implies that dynamic port range assignment seems to be needed
for
o assigning clients larger port ranges when the current one becomes
too small,
o assigning clients smaller port ranges, when the current one is
underused,
o changing clients port ranges for reducing fragmentation of the
port space,
o balancing port consumption for a shared IPv4 address.
The existing means are sufficient to assign and re-assign port
ranges. However, a client cannot immediately switch from one port
range to another one, because most applications cannot change port
numbers while using them. Without interrupting existing connections,
a client can only start allocating new ports in a new range and wait
until ports in an old range are not used anymore. Consequently, a
client needs to wait until applications have closed all ports in the
old port range. Existing means allow to assign more than one port
ranges to a client ([I-D.boucadair-port-range]), but not to identify
one or more ranges that should not be used anymore by the client.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Ripke, et al. Expires January 7, 2010 [Page 3]
Internet-Draft Dynamic Port Ranges July 2009
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Dynamic port range re-assignments
This draft proposal provides a way for a port range assignment server
to tag a port range with an attribute that signals the client not to
allocate any more ports in this range. Such a signal can be sent
when a server signals more than one port range to a client. A most
simple implementation would be adding a flag to one or more port
ranges during the (re-)assignment process that marks these ranges as
not to be used anymore. A client receiving the signal would then
stop allocating port numbers in the marked ranges. When the client
does not use an address range anymore, it signals back that the port
range is not in use anymore and can be re-assigned. This can be done
individually for each range as soon as it is not used anymore or at
once when all marked ranges are not used anymore.
The method can also be used for reducing (trimming) already assigned
port ranges. For this purpose, the server divides the single port
range into two or more consecutive port ranges and re-assigns the
single port range as a set of port ranges to the client with one or
more of the port ranges marked as not to be used anymore. Again, the
client would signal back that one or more ranges are not used
anymore.
This new technique allows to postpone the deallocation of port ranges
until the respective ports are closed (lazy deallocation). The
client has the possibility to actively confirm the release of port
ranges.
4. Usage scenario
The following usage scenario describes the impact of the proposed
method from the initialization phase till final deallocation of port
ranges.
A broadband operator manages IP address and port range manager for
broadband access provisioning at a BRAS (Broadband Remote Access
Server). The client would be a home router, a single host or the
gateway of a large enterprise, allocating port numbers when acting as
NAT for the respective devices.
Ripke, et al. Expires January 7, 2010 [Page 4]
Internet-Draft Dynamic Port Ranges July 2009
4.1. Initialization
When a client requests an IP address with a port range including the
number of ports, the BRAS assigns it and signals the assigned port
range to the client. The port range specified by the client could be
a preferred port range indicated by a minimum value and a maximum
value or just the number of ports.
4.2. Detecting the change point
While the client is using the port range, several reasons may occur
that make it desirable to change the port assignment.
o The client may observe that there are only few unused numbers left
in the used range and that it may soon happen that no further
ports would be available for requesting applications. In order to
avoid this situation, the client requests an assignment of more
port numbers at the BRAS.
o A user can actively close all ports in anticipation of an
exceeding demand of ports from new applications to be started.
All ports are released voluntarily in expectation of goodwill to
get a larger port range assigned.
o The BRAS may monitor usage of port numbers by the clients and
detect that there are only a few unused port numbers left in the
range assigned to the client. It decides to assign a wider range
to the client before port numbers run out.
o The BRAS may detect that the client is only using a small part of
the port range assigned to him and decide to assign the client a
smaller port range.
o The BRAS may identify a need to re-assign the port range of the
client in order to reduce fragmentation of the port space.
Therefore, the port range change request can be both client and
server initiated.
4.3. Assigning a new port range
The BRAS sends a message to the client. The message contains two
port ranges, the originally assigned one with a mark not to use it
anymore and a new range to be used from now on.
Optionally, it can also give a time until when the old port range is
still valid, before it will definitely expire.
Ripke, et al. Expires January 7, 2010 [Page 5]
Internet-Draft Dynamic Port Ranges July 2009
4.4. Ongoing port consumption
The client only allocates new port numbers of the new range.
4.5. Final deallocation of a port range
Either the BRAS detects that no port number of the initial port range
is in use anymore (through monitoring) and signals to the client that
the initially assigned range is not anymore assigned to the client.
Or the client send an explicit signal that it is not using the
initial range anymore and the BRAS can assign it to other clients.
Alternatively, the client can carry out a partial release of a
requested port range, hence splitting the port range in used and
unused ports.
5. Location of the address and port manager
In the above usage scenario it is implied that the IP address and
port range management service is supplied with a BRAS.
Alternatively, the IP address and port range manager can be located
at a MSAN (Multi Service Access Node), DSLAM (Digital Subscriber Line
Access Multiplexer), or any other infrastructure equipment.
5.1. Mobile networks
The scheme might also apply to mobile networks, where the server is
located on the SGSN (Serving GPRS (General Packet Radio Service)
Support Node) or GGSN (Gateway GPRS Support Node), and the client on
a user equipment.
6. Signaling
The signaling between client and server can be done through different
protocols including DHCP extensions, PPP extensions, Web Services,
TR-069, or a novel protocol for address and port pool management.
7. Fragmentation
According to [I-D.boucadair-pppext-portrange-option] and
[I-D.boucadair-dhc-port-range] it is possible to assign more than one
port range to a customer (using a port mask and a port locator). It
is expected that continuous port range allocation will be the
preferred procedure. However, together with the introduced technique
Ripke, et al. Expires January 7, 2010 [Page 6]
Internet-Draft Dynamic Port Ranges July 2009
to enlarge or to reduce individual port ranges the port range manager
might have to deal with heavily fragmented port mapping tables.
Besides administration overhead this may lead to problems if new
continuous port ranges are requested. Dynamic port range re-
assignment provides a technique that can both amplify and rectify
this problem.
8. Service Management
As already mentioned in [I-D.levis-behave-ipv4-shortage-framework] a
management station assigns the number of ports to the customer upon
preconfigured policies which might depend on the individual contract
with the customer or on the customer's usage profile.
8.1. Server policy
The process on the BRAS for deciding on how many ports to give away
is based on policies configured into the BRAS from a management
station. That might depend on the customer status. Good customers,
customer paying more, might request higher numbers. It can also
depend on the current level of free addresses and ports. When there
are only a few ports left the IP address and port range manager might
be more restrictive with port allocations. In general, the
mechanisms described above in the usage scenario requires
configuration on the BRAS to behave in one or the other way, also
including the configuration of the client.
8.2. Client policy
The policies will also be configured into the client. Those policies
tell the client how large of a space he is allowed to request, and at
what usage level the client should ask for more port space. For
example, that can be if only 80% of the ports are used, the client
asks already for more, or the client only asks for more if he fully
used up his space.
9. Open issues
Dynamic port range re-assignment has several open issues to be solved
or clarified:
o Modifications are required to both the DHCP and the PPP protocol
in addition to the extensions described in
[I-D.boucadair-dhc-port-range] and
[I-D.boucadair-pppext-portrange-option] respectively.
Ripke, et al. Expires January 7, 2010 [Page 7]
Internet-Draft Dynamic Port Ranges July 2009
o What strategy should be chosen to solve a potential port mapping
table fragmentation?
o The constant port monitoring which the port range manager has to
carry out might impose problems.
o How to handle expiration timers when requesting port ranges to be
cleared?
o The processing of port overflow caused by exceeding port number
requests might become a delicate problem. If available port
numbers for a specific IPv4 address do not match a client's
request it would be necessary to assign a new IPv4 address.
Eventually, the price to be paid for more flexible port range
management is complexity.
10. Acknowledgements
The authors are supported by Trilogy
(http://www.trilogy-project.org), a research project (ICT-216372)
partially funded by the European Community under its Seventh
Framework Program. The views expressed here are those of the
author(s) only. The European Commission is not liable for any use
that may be made of the information in this document.
11. IANA Considerations
This document includes no request to IANA.
12. Security Considerations
TBD.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Ripke, et al. Expires January 7, 2010 [Page 8]
Internet-Draft Dynamic Port Ranges July 2009
13.2. Informative References
[I-D.boucadair-dhc-port-range]
Boucadair, M., Grimault, J., Levis, P., and A.
Villefranque, "DHCP Options for Conveying Port Mask and
Port Range Router IP Address",
draft-boucadair-dhc-port-range-01 (work in progress),
October 2008.
[I-D.boucadair-port-range]
Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
"IPv4 Connectivity Access in the Context of IPv4 Address
Exhaustion: Port Range based IP Architecture",
draft-boucadair-port-range-02 (work in progress),
July 2009.
[I-D.boucadair-pppext-portrange-option]
Boucadair, M., Levis, P., Grimault, J., and A.
Villefranque, "Port Range Configuration Options for PPP
IPCP", draft-boucadair-pppext-portrange-option-01 (work in
progress), July 2009.
[I-D.levis-behave-ipv4-shortage-framework]
Levis, P., Boucadair, M., Grimault, J., and A.
Villefranque, "IPv4 Address Shortage: Needs and Open
Issues", draft-levis-behave-ipv4-shortage-framework-02
(work in progress), June 2009.
[I-D.ymbk-aplusp]
Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L.
Cittadini, "The A+P Approach to the IPv4 Address
Shortage", draft-ymbk-aplusp-03 (work in progress),
March 2009.
[flow-counting]
WAND, Network Research Group, "Flow Counting", <http://
www.wand.net.nz/~salcock/someisp/flow_counting/
result_page.html>.
Ripke, et al. Expires January 7, 2010 [Page 9]
Internet-Draft Dynamic Port Ranges July 2009
Authors' Addresses
Andreas Ripke
NEC Laboratories Europe
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342 252
Email: andreas.ripke@nw.neclab.eu
Juergen Quittek
NEC Laboratories Europe
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342 115
Email: juergen.quittek@nw.neclab.eu
Marcus Brunner
NEC Laboratories Europe
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342 129
Email: marcus.brunner@nw.neclab.eu
Ripke, et al. Expires January 7, 2010 [Page 10]