idnits 2.17.1 draft-sun-dhc-port-set-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2013) is 3843 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6842' is defined on line 387, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6269 ** Downref: Normative reference to an Experimental RFC: RFC 6346 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-01 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-07 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Q. Sun 3 Internet-Draft Tsinghua University 4 Intended status: Standards Track Y. Lee 5 Expires: April 15, 2014 Comcast 6 Q. Sun 7 China Telecom 8 G. Bajko 9 Nokia 10 M. Boucadair 11 France Telecom 12 October 12, 2013 14 Dynamic Host Configuration Protocol (DHCP) Option for Port Set 15 Assignment 16 draft-sun-dhc-port-set-option-02 18 Abstract 20 Because of the exhaustion of the IPv4 address space, several 21 techniques have been proposed to share the same IPv4 address among 22 several uses. As an alternative to introducing a level of NAT in the 23 provider's core network, this document provides a mechanism to assign 24 non-overlapping layer 4 port sets to users assigned with the same 25 IPv4 address: Port Set DHCPv4 Option. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 15, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 3. DHCPv4 Port Set Option . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Port Set Option Format . . . . . . . . . . . . . . . . . . 3 65 3.2. Port Set Option Example . . . . . . . . . . . . . . . . . 5 66 4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 7 70 6.2. Port Randomization . . . . . . . . . . . . . . . . . . . . 7 71 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7 72 8. Contributors List . . . . . . . . . . . . . . . . . . . . . . 7 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 Currently some large ISPs still have a large enough IPv4 address pool 81 to be able to allocate public IPv4 addresses for their subscribers. 82 However, due to the exhaustion of the global IPv4 address space, 83 these ISPs expect the situation is unsustainable and they will not be 84 able anymore to assign to every requesting host a public IPv4 85 address. 87 Two solutions have been proposed so far: (1) Deploy Network Address 88 Translation (NAT) or (2) Allocate the same public IPv4 address with 89 non-overlapped layer 4 port sets directly to multiple connected 90 devices (which can be CPEs or end hosts). This document focuses on 91 the second solution. 93 This document describes a new DHCPv4 option which allows the DHCPv4 94 server to assign a set of ports to a user device during the IPv4 95 address provisioning process. By assigning the same IPv4 address 96 with non-overlapped port sets to multiple clients, the clients is 97 enabled to share the IPv4 address and continue to deliver IPv4 98 services to subscribers. 100 When using this DHCPv4 option, the underlaying forwarding carrier 101 should be other than IPv4 to avoid affecting the current IPv4-only 102 architecture, for example IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6], 103 [I-D.ietf-dhc-dhcpv4-over-dhcpv6], etc. The server has to manage to 104 forward DHCP responses to the right client. 106 The Port Set Option described in this document can be used in various 107 deployment scenarios, some of which are described in [RFC6346] 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. DHCPv4 Port Set Option 117 3.1. Port Set Option Format 119 The format of Port Set Option is shown in Figure 1. 121 0 1 122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 123 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 124 | OPTION_PORT_SET | option-length | 125 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 126 | Port Set Index | 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 128 | Port Set Mask | 129 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 131 Figure 1 Port Set Option Format 133 o option-code: OPTION_PORT_SET (TBD) 135 o option-length: An 8-bit field indicating the length of the option 136 excluding the 'Option Code' and the 'Option Length' fields. In 137 this option, the option-length is 4 octets. 139 o Port Set Index: Port Set Index identifies a set of ports assigned 140 to a device. The first k bits on the left of the 2-octet field is 141 the Port Set Index value, with the rest of the field right padding 142 zeros. 144 o Port Set Mask: Port Set Mask indicates the position of the bits 145 used to build the mask. The first k bits on the left is padding 146 ones while the remained (16-k) bits of the 2-octet field on the 147 right is padding zeros. 149 In the context of Port Set Option, the port number should consist of 150 port set prefix and port number suffix. The port set prefix can be 151 got from Port Set Index and Port Set Mask, while port number suffix 152 can change continuously. The format of port number is shown in 153 Figure 2. 155 0 15 156 +-----------------------+-----------------------------+ 157 | port set prefix | port number suffix | 158 +-----------------------+-----------------------------+ 159 |<-------k bits-------->|<--------(16-k) bits-------->| 161 Figure 2 Bit Representation of a port number 163 In order to exclude the system ports ([I-D.ietf-tsvwg-iana-ports]) or 164 ports saved by SPs, the former port-sets that contains well-known 165 ports SHOULD NOT be assigned. 167 For example: If k is 10 (the left 10 bits of Port Set Mask is '1'), 168 the first 16 port sets is located in well-known port space, which 169 should not be allocated. Or, 171 For example: If k is 4 (the left 4 bits of Port Set Mask is '1'), the 172 first port set (0 - 4095) contains the well-know port space. It 173 should be perceived as well. 175 3.2. Port Set Option Example 177 The Port Set Option is used to specify one contiguous port set 178 pertaining to the given IP address. 180 Concretely, this option is used to notify a remote DHCP client about 181 the port set prefix to be applied when selecting a port value as a 182 source port. The Port Set Option is used to infer a set of allowed 183 contiguous port values. Two port numbers are said to belong to the 184 same Port Set if and only if, they have the same port set prefix. 186 The following Port Set Index and Port Set Mask are conveyed using 187 DHCP to assign a contiguous port set with excluding well-know ports 188 (with Port Set Index not zero): 190 Port Set Index: 0001 0100 0000 0000 (5120) 192 Port Set Mask: 1111 1100 0000 0000 (64512) 194 The device will get a contiguous port set: 5120 - 6143 196 4. Server Behavior 198 The server will not reply with the option until the client has 199 explicitly listed the option code in the Parameter Request List 200 (Option 55). 202 Server MUST reply with Port Set Option if the client requested 203 OPTION_PORT_SET in its Parameter Request List. In order to achieve 204 the dynamic management of IPv4 address and port set in the address 205 sharing environment, the server MUST run an address & port-set pool 206 that plays the same role as address pool in regular DHCP server. The 207 address and port-set pool MUST follow the Port-Mask-format port-set. 208 The server MUST use a combination of address & port-set as a key to 209 maintain the state of a lease, and look for an available lease for 210 assignment. The leasing database MUST also include the information 211 of the address and port-set. 213 When a server receives a DHCPDISCOVER message with OPTION_PORT_SET in 214 the Parameter Request List from a client, the server chooses an IPv4 215 address and a port-set for the requesting client. The logic of 216 choosing is similar to that in Section 4.3.1 of [RFC2131], while the 217 difference is the server looks for the client's binding or an 218 available lease in the server's pool of addresses & port-sets. After 219 selecting an available combination of an address and a port-set, the 220 server puts the address into the 'yiaddr' field and the port-set (in 221 the Port-Mast-format) into the Port Set Option. 223 If the server receives a DHCPDISCOVER message containing a Port Set 224 Option, this means the client is requesting a specific port set. The 225 Port Set Mask field in the option indicates the size of port set that 226 the client requests. The server MAY reply with a Port Set Option 227 whose Port Set Mask is as requested, if the server has such one port 228 set. Or the server can ignore the request and just assign a port set 229 from the pool. 231 When a server receives a DHCPREQUEST message with Port Set Option, 232 the server MUST determine the client's state according to related 233 parameters (Section 4.3.2 of [RFC2131]) and the value of Port Set 234 Option. 236 Upon reception of a DHCPRELEASE message with Port Set Option, the 237 server looks for the lease using the address and the value in the 238 Port Set Option, and marks it as unallocated. 240 The port-set assignment MUST be coupled with the address assignment 241 process. Therefore server MUST assign the address and port set in 242 the same DHCP messages. And the lease information for the address is 243 applicable to the port-set as well. 245 5. Client Behavior 247 The DHCP client applying for a port-set MUST include the 248 OPTION_PORT_SET code in the Parameter Request List (Option 55). The 249 client retrieves a Port Set Option and use the Port Set Index and 250 Port Set Mask to perform the port mask algorithm to get the 251 contiguous port set. 253 When the client renews or releases the DHCP lease, it MUST put its 254 Port Set Index and Port Set Mask into the Port Set Option, and send 255 to the server within corresponding DHCPv4 messages. 257 The client MAY include a Port Set Option in the DHCPDISCOVER message, 258 in which the Port Set Mask field indicates the requested size of a 259 port set from the client. 261 6. Security Consideration 263 6.1. Denial-of-Service 265 The solution is generally vulnerable to DoS when used in shared 266 medium or when access network authentication is not a prerequisite to 267 IP address assignment. The solution SHOULD only be used on point-to- 268 point links, tunnels, and/or in environments where authentication at 269 link layer is performed before IP address assignment, and not shared 270 medium. 272 6.2. Port Randomization 274 Preserving port randomization [RFC6056] may be more or less difficult 275 depending on the address sharing ratio (i.e., the size of the port 276 space assigned to a CPE). The host can only randomize the ports 277 inside a fixed port range [RFC6269]. 279 More discussion to improve the robustness of TCP against Blind In- 280 Window Attacks can be found at [RFC5961]. Other means than the 281 (IPv4) source port randomization to provide protection against 282 attacks should be used (e.g., use [I-D.vixie-dnsext-dns0x20] to 283 protect against DNS attacks, [RFC5961] to improve the robustness of 284 TCP against Blind In-Window Attacks, use IPv6). 286 A proposal to preserve the entropy when selecting port is discussed 287 in [I-D.bajko-pripaddrassign] 289 7. IANA Consideration 291 IANA is kindly requested to allocate DHCP option code to the 292 OPTION_PORT_SET. The code should be added to the DHCP option code 293 space. 295 8. Contributors List 297 Many thanks for valuable comments and great efforts from the 298 following contributors: 300 Peng Wu 301 Tsinghua University 303 peng-wu@foxmail.com 304 Teemu Savolainen 305 Nokia 307 teemu.savolainen@nokia.com 309 Ted Lemon 310 Nominum, Inc. 312 mellon@nominum.com 314 Tina Tsou 315 Huawei Technologies 317 tena@huawei.com 319 Pierre Levis 320 France Telecom 322 Email: pierre.levis@orange.com 324 Cong Liu 325 Tsinghua University 327 Email: gnocuil@gmail.com 329 9. References 331 9.1. Normative References 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 337 RFC 2131, March 1997. 339 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 340 Robustness to Blind In-Window Attacks", RFC 5961, 341 August 2010. 343 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 344 Protocol Port Randomization", BCP 156, RFC 6056, 345 January 2011. 347 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 348 Roberts, "Issues with IP Address Sharing", RFC 6269, 349 June 2011. 351 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 352 IPv4 Address Shortage", RFC 6346, August 2011. 354 9.2. Informative References 356 [I-D.bajko-pripaddrassign] 357 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 358 "Port Restricted IP Address Assignment", 359 draft-bajko-pripaddrassign-04 (work in progress), 360 April 2012. 362 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 363 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 364 Farrer, "DHCPv4 over DHCPv6 Transport", 365 draft-ietf-dhc-dhcpv4-over-dhcpv6-01 (work in progress), 366 July 2013. 368 [I-D.ietf-dhc-dhcpv4-over-ipv6] 369 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 370 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-07 (work in 371 progress), September 2013. 373 [I-D.ietf-tsvwg-iana-ports] 374 Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 375 Cheshire, "Internet Assigned Numbers Authority (IANA) 376 Procedures for the Management of the Service Name and 377 Transport Protocol Port Number Registry", 378 draft-ietf-tsvwg-iana-ports-10 (work in progress), 379 February 2011. 381 [I-D.vixie-dnsext-dns0x20] 382 Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to 383 Improve Transaction Identity", 384 draft-vixie-dnsext-dns0x20-00 (work in progress), 385 March 2008. 387 [RFC6842] Swamy, N., Halwasia, G., and P. Jhingran, "Client 388 Identifier Option in DHCP Server Replies", RFC 6842, 389 January 2013. 391 Authors' Addresses 393 Qi Sun 394 Tsinghua University 395 Department of Computer Science, Tsinghua University 396 Beijing 100084 397 P.R.China 399 Phone: +86-10-6278-5822 400 Email: sunqi@csnet1.cs.tsinghua.edu.cn 402 Yiu L. Lee 403 Comcast 404 One Comcast Center 405 Philadelphia PA 19103 406 USA 408 Phone: 409 Email: yiu_lee@cable.comcast.com 411 Qiong Sun 412 China Telecom 413 Room 708, No.118, Xizhimennei Street 414 Beijing 100035 415 P.R.China 417 Phone: +86-10-58552936 418 Email: sunqiong@ctbri.com.cn 420 Gabor Bajko 421 Nokia 423 Phone: 424 Email: gabor.Bajko@nokia.com 425 Mohamed Boucadair 426 France Telecom 427 2330 Central Expressway 428 Rennes 35000 429 France 431 Phone: 432 Email: mohamed.boucadair@orange.com