One document matched: draft-bajko-v6ops-port-restricted-ipaddr-assign-00.txt
Internet Engineering Task Force G. Bajko
Internet Draft T. Savolainen
Intended Status: Proposed Standard Nokia
Expires: March 24, 2009 September 24, 2008
Dynamic Host Configuration Protocol (DHCP) Options for Port Restricted
IP Address Assignment
draft-bajko-v6ops-port-restricted-ipaddr-assign-00
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 March 24, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines two Dynamic Host Configuration Protocol for
IPv4 [RFC2131] options that allow servers to assign port restricted
IPv4 addresses to clients. Port restriction may be necessary in
cases when one public IPv4 address is assigned to multiple clients
because of scarcity of the available IPv4 addresses.
Bajko & Savolainen Expires March 24, 2009 [Page 1]
DHCPv4 Options for port-restricted IP address September 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.
OPR Offered Port Restricted IP Address
RPR Requested Port Restricted IP Address
Table of Content
1. Introduction
As a possible solution for the IPv4-IPv6 coexistence period this
document describes Dynamic Host Configuration Protocol for IPv4
[RFC2131] options that allow servers to assign port restricted IPv4
addresses to clients, when public IPv4 addresses are expected to be
scarce resources, while the need to communicate using IPv4-only
remains.
There are a number of possible solutions to deal with this problem;
however none of them offers a satisfactory solution for all possible
use cases. See [WING2008] for comparison.
Some of the large ISPs, 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 each client with a public IPv4 address. There are two
possibilities:
- deploy Network Address Translators. The address space limitations
of [RFC1918] may force large ISPs to deploy double NATs.
- allocate the same public IPv4 address to multiple clients, thus
avoid the cost of deploying NATs.
Note, that for some other ISPs, who already have NATs in place,
increasing the capacity of their NAT devices might be the preferred
solution.
2. DHCPv4 Options for allocating port restricted public IPv4 address
This section describes the options used to allocate a port
restricted IPv4 address using DHCPv4, and which are meant to be used
only in point-to-point links such as in IPv4-over-IPv6 tunnels.
Bajko & Savolainen Expires March 24, 2009 [Page 2]
DHCPv4 Options for port-restricted IP address September 2008
2.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
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
2.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
Bajko & Savolainen Expires March 24, 2009 [Page 3]
DHCPv4 Options for port-restricted IP address September 2008
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
3. Option Usage
3.1 Client Behaviour
A client MAY insert the option OPTION-IPv4-RPR, by setting the IPv4
address field to 0.0.0.0, the beginning and ending port numbers to
zero, into a DHCPDISCOVER message, to explicitly let the server know
that it supports port restricted IPv4 address.
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, 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 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.
Bajko & Savolainen Expires March 24, 2009 [Page 4]
DHCPv4 Options for port-restricted IP address September 2008
3.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.
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
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-OPR 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-OPR 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.
4. Applicability
The immediate applicability of such a solution is in 3GPP or WiMAX
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.
The new DHCPv4 options proposed in this document would be used as
the APBP component of the architecture described in [DESP2008] and
in fractional IP address scenarios described in [ARKK2008].
This document does not address the issue of how clients configured
with port restricted IP addresses would handle protocols that run
directly over IP (eg ICMP). That problem needs further
consideration.
Bajko & Savolainen Expires March 24, 2009 [Page 5]
DHCPv4 Options for port-restricted IP address September 2008
The server leasing the port restricted IP address, or a gateway in
the network, (eg the first hop router of a point-to-point link) MUST
enforce the restricted port range policy by filtering out packets
sent using out of range source ports.
5. 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
6. 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
and not shared medium, and/or in environments where authentication
at link layer is performed before IP address assignment.
7. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC2131, March 1997
8. 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-
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
9. Author's Addresses
Bajko & Savolainen Expires March 24, 2009 [Page 6]
DHCPv4 Options for port-restricted IP address September 2008
Gabor Bajko
Email: gabor dot bajko at nokia dot com
Teemu Savolainen
Hermiankatu 12 D
FI-33720 TAMPERE
FINLAND
Email: teemu.savolainen@nokia.com
Bajko & Savolainen Expires March 24, 2009 [Page 7]
DHCPv4 Options for port-restricted IP address September 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 March 24, 2009 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 03:25:30 |