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]