idnits 2.17.1 draft-ietf-dhc-dynamic-shared-v4allocation-09.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 28, 2015) is 3249 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) == Outdated reference: A later version (-08) exists of draft-ietf-dhc-anonymity-profile-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC WG Y. Cui 3 Internet-Draft Q. Sun 4 Intended status: Standards Track Tsinghua University 5 Expires: November 29, 2015 I. Farrer 6 Deutsche Telekom AG 7 Y. Lee 8 Comcast 9 Q. Sun 10 China Telecom 11 M. Boucadair 12 France Telecom 13 May 28, 2015 15 Dynamic Allocation of Shared IPv4 Addresses 16 draft-ietf-dhc-dynamic-shared-v4allocation-09 18 Abstract 20 This memo describes the dynamic allocation of shared IPv4 addresses 21 to clients using DHCPv4. Address sharing allows a single IPv4 22 address to be allocated to multiple active clients simultaneously, 23 each client being differentiated by a unique set of transport layer 24 source port numbers. The necessary changes to existing DHCPv4 client 25 and server behavior are described and a new DHCPv4 option for 26 provisioning clients with shared IPv4 addresses is included. 28 Due to the nature of IP address sharing, some limitations to its 29 applicability are necessary. This memo describes these limitations 30 and recommends suitable architectures and technologies where address 31 sharing may be utilized. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 29, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 69 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 70 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4 72 6. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4 73 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 74 7.1. Restrictions to Client Usage of a Shared IPv4 Address . . 6 75 8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 76 8.1. Leasing Shared and Non-Shared IPv4 Addresses from a 77 Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 8 78 9. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 8 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 10.1. Port Randomization . . . . . . . . . . . . . . . . . . . 10 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 13.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 The shortage of available public IPv4 addresses means that it is not 91 always possible for operators to allocate a full IPv4 address to 92 every connected device. This problem is particularly acute whilst an 93 operator is migrating from their existing, native IPv4 network to a 94 native IPv6 network with IPv4 provided as an overlay service. During 95 this phase, public IPv4 addresses are needed to provide for both 96 existing and transition networks. 98 Two main types of solutions have emerged to address the problem (see 99 Appendix A of [RFC6269]): 101 1. Deploying Carrier Grade Network Address Translation devices 102 (CGNAT, [RFC6888]). 103 2. Distributing the same public IPv4 address to multiple clients 104 differentiated by non-overlapping layer 4 port sets. 106 This memo focuses on the second category of solutions. 108 [RFC7341] introduces a "DHCP 4o6 Server", which offers dynamic 109 leasing for IPv4 addresses to clients as in DHCPv4 [RFC2131] but 110 transported within a DHCPv6 message flow. This memo specifies a new 111 DHCPv4 option: OPTION_V4_PORTPARAMS, and describes how it can be used 112 for the dynamic leasing of shared IPv4 addresses. 114 Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4 115 transport mechanism throughout this document, OPTION_V4_PORTPARAMS as 116 a DHCPv4 option may also be used in other solutions, if required. 118 2. Applicability Statement 120 The solution allows multiple hosts to be simultaneously allocated the 121 same IP address. As the IP address is no longer a unique identifier 122 for a host, this extension is only suitable for specific 123 architectures based on the Address plus Port model (A+P) [RFC6346]. 124 Specifically, this document presents a solution that applies to 125 [I-D.ietf-softwire-lw4over6] and certain configurations of 126 [I-D.ietf-softwire-map] (e.g., EA-bit length set to 0). 128 The solution should only be used on point-to-point links, tunnels, 129 and/or in environments where authentication at the link layer is 130 performed before IP address assignment. It is not suitable for 131 network access over shared media, including Ethernet, WLAN, cable, 132 etc.. 134 3. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 4. Terminology 142 This document makes use of the following terms: 144 Shared IPv4 address: An IPv4 address with a restricted layer 4 port 145 set. 147 Port Set ID (PSID): Identifier for a range of ports assigned to a 148 DHCP client. 150 5. Functional Overview 152 Functionally, the dynamic allocation of shared IPv4 addresses by the 153 DHCP 4o6 Server is similar to the dynamic allocation process for 154 'full' IPv4 addresses described in [RFC2131]. The essential 155 difference is that the DHCP 4o6 Server can allocate the same IPv4 156 address to more than one DHCP 4o6 client simultaneously, providing 157 that each shared address allocation also includes a range of layer 4 158 source ports unique to that address (i.e., the combined tuple of IPv4 159 address and Port Set ID is to be unique for each active lease). 161 The DHCP 4o6 client implements OPTION_V4_PORTPARAMS (described 162 below), which is a DHCPv4 option containing PSID (Port Set ID) 163 information. The client includes this option within the Parameter 164 Request List option [RFC2132] in its DHCPv4 DHCPDISCOVER and 165 DHCPREQUEST messages, indicating its support for shared, dynamic 166 address leasing to the DHCP 4o6 server. 168 OPTION_V4_PORTPARAMS is also implemented by the server to identify 169 clients that support shared, dynamic address leasing. With this 170 option, the server can dynamically allocate PSIDs to clients and 171 maintain shared IPv4 address leases. The server then manages unique 172 client leases based the IPv4 address and PSID tuple, instead of using 173 only the IPv4 address. 175 In the event that a dynamic, shared addressing capable client 176 receives more than one DHCP 4o6 offer, where a received offer does 177 not contain OPTION_V4_PORTPARAMS (i.e., is an offer for a full IPv4 178 address), then the client SHOULD prefer the full IPv4 offer over the 179 shared IPv4 address offer(s), unless specifically configured 180 otherwise. 182 6. Client-Server Interaction 184 The following DHCPv4 message flow is transported within the 185 DHCPv4-query and DHCPv4-response messages as in DHCPv4 over DHCPv6 186 [RFC7341]. 188 1. When the client constructs the DHCPv4 DHCPDISCOVER message to be 189 transported within the DHCPv4-query message, the DHCPDISCOVER 190 message MUST include the client identifier option (constructed as 191 per [RFC4361]) and the Parameter Request List (PRL) option with 192 the code of OPTION_V4_PORTPARAMS. The client MAY insert an 193 OPTION_V4_PORTPARAMS with preferred values in related fields as a 194 suggestion to the DHCP 4o6 Server. 196 2. DHCP 4o6 Servers that receive the DHCPDISCOVER message and 197 support shared IPv4 addresses respond with a DHCPOFFER message 198 with the shared IPv4 address in the 'yiaddr' field and MUST add 199 an OPTION_V4_PORTPARAMS option containing an available restricted 200 port set. If the DHCPDISCOVER included an OPTION_V4_PORTPARAMS 201 option containing a non-zero PSID-Len field, the DHCP 4o6 Server 202 MAY allocate a port set of the requested size to the client 203 (depending on policy). The DHCPOFFER message is then 204 encapsulated in the DHCPv4-response message and sent to the 205 client. 206 3. The client evaluates all received DHCPOFFER messages and selects 207 one (e.g., based on the configuration parameters received, such 208 as the size of the offered port set). The client then sends a 209 DHCPREQUEST encapsulated in the DHCPv4-query message containing 210 the corresponding OPTION_V4_PORTPARAMS received in the DHCPOFFER 211 message. 212 4. The server identified in the DHCPREQUEST message creates a 213 binding for the client. The binding includes the client 214 identifier, the IPv4 address and the PSID. These parameters are 215 used by both the server and the client to identify a lease in any 216 DHCP message. The server MUST respond with a DHCPACK message 217 containing OPTION_V4_PORTPARAMS for the requesting client. 218 5. On receipt of the DHCPACK message with the configuration 219 parameters, the client MUST NOT perform an in-use probe on the 220 address, such as ARPing for a duplicate allocated address. 221 6. If the client chooses to relinquish its lease by sending a 222 DHCPRELEASE message, the client MUST include the leased network 223 address and OPTION_V4_PORTPARAMS (with the allocated PSID) to 224 identify the lease to be released. 226 In the case that the client has stored the previously allocated 227 address and restricted port set, the logic described in Section 3.2 228 of [RFC2131] MUST be followed on the condition that the client's 229 source IPv6 address for DHCP 4o6 does not change. Note, this 230 corresponds to the INIT-REBOOT state defined in [RFC2131]. The 231 client MUST include the OPTION_V4_PORTPARAMS with the requested port 232 set information in the message flow, which starts with a DHCPREQUEST 233 message. If the client's DHCP 4o6 IPv6 source address is changed for 234 any reason, the client MUST re-initiate the DHCP 4o6 shared-address 235 provisioning process by sending a DHCPDISCOVER message. 237 7. Client Behavior 239 A DHCP 4o6 client sending a DHCPDISCOVER message for a shared IPv4 240 address MUST include the OPTION_V4_PORTPARAMS option code in the 241 Parameter Request List option. If a client has been successfully 242 allocated an IPv4 address and PSID previously, the client's 243 DHCPDISCOVER message MAY include the 'requested IP address' option 244 along with an OPTION_V4_PORTPARAMS to request that a specific IPv4 245 address and PSID be re-assigned. Alternatively, the client MAY omit 246 the 'requested IP address' option, but include an 247 OPTION_V4_PORTPARAMS with a non-zero value in only the PSID-Len 248 field, as a hint to the server for the preferred size of the port 249 set. 251 A client that requests OPTION_V4_PORTPARAMS, but receives DHCPOFFER 252 and DHCPACK messages without OPTION_V4_PORTPARAMS SHOULD proceed as 253 defined in [RFC7341] and configure a full IPv4 address with no 254 address sharing (see Section 8.1 for the server's behavior). 256 When receiving a DHCPACK message containing OPTION_V4_PORTPARAMS, the 257 client MUST use the received explicit PSID for configuring the 258 interface for which the DHCP 4o6 request was made. 260 The client MUST NOT probe a newly received IPv4 address (e.g., using 261 ARP) to see if it is in use by another host. 263 When the client renews or releases its DHCP lease, it MUST put the 264 values of offset, PSID length and PSID into OPTION_V4_PORTPARAMS, and 265 send it to the server within corresponding DHCPv4 messages that are 266 conveyed through DHCPv4-query message. 268 In the event that the client's DHCP 4o6 IPv6 source address is 269 changed for any reason, the client MUST re-initiate the DHCP 4o6 270 shared-address provisioning process by sending a DHCPDISCOVER 271 message. 273 7.1. Restrictions to Client Usage of a Shared IPv4 Address 275 As a single IPv4 address is being shared between a number of 276 different clients, the allocated shared address is only suitable for 277 certain uses. The client MUST implement a function to ensure that 278 only the allocated layer 4 ports of the shared IPv4 address are used 279 for sourcing new connections, or accepting inbound connections. 281 The client MUST apply the following rules for all traffic destined to 282 or originating from the shared IPv4 address: 284 o The client MUST use only port-aware protocols (e.g., TCP, UDP, 285 DCCP etc.) or ICMP implementing [RFC5508]. 286 o All connections originating from the shared IPv4 address MUST use 287 a source port taken from the allocated restricted port set. 288 o The client MUST NOT accept inbound connections on ports outside of 289 the allocated restricted port set. 291 In order to prevent addressing conflicts which could arise from the 292 allocation of the same IPv4 address, the client MUST NOT use the 293 received restricted IPv4 address to perform ARP operations. 295 The mechanism by which a client implements the above rules is out of 296 the scope of this document. 298 In the event that the DHCPv4 over DHCPv6 configuration mechanism 299 fails for any reason, the client MUST NOT configure an IPv4 link- 300 local address [RFC3927] (taken from the 169.254.0.0/16 range). 302 8. Server Behavior 304 The DHCP 4o6 Server MUST NOT reply with OPTION_V4_PORTPARAMS unless 305 the client has explicitly listed the option code in the Parameter 306 Request List (Option 55) [RFC2132]. 308 The DHCP 4o6 Server SHOULD reply with OPTION_V4_PORTPARAMS if the 309 client includes OPTION_V4_PORTPARAMS in its Parameter Request List. 310 In order to achieve the dynamic management of shared IPv4 addresses, 311 the server is required to implement an address and port-set pool that 312 provides the same function as the address pool in a regular DHCP 313 server. Also, the server uses the combination of address and PSID as 314 the key for maintaining the state of a lease, and for searching for 315 an available lease for assignment. The leasing database is required 316 to include the IPv4 address, PSID and client identifier of the 317 requesting client. 319 When a server receives a DHCPDISCOVER message with 320 OPTION_V4_PORTPARAMS in the Parameter Request List option, the server 321 determines an IPv4 address with a PSID for the requesting client. If 322 an IPv4 address with a PSID is available, the server SHOULD follow 323 the logic below to select which specific address and PSID to 324 provision to the client. The logic is similar to that in 325 Section 4.3.1 of [RFC2131]. 327 o The client's current address with the PSID as recorded in the 328 client's current lease binding, ELSE 329 o The client's previous address with PSID as recorded in the 330 client's (expired or released) binding, if that address with PSID 331 is in the server's pool of available addresses and PSIDs, and not 332 already allocated, ELSE 333 o The address requested in the 'Requested IP Address' option along 334 with the PSID parameters requested in the OPTION_V4_PORTPARAMS, if 335 that pair of address and PSID is valid and not already allocated, 336 ELSE 337 o A new address with a PSID allocated from the server's pool of 338 available addresses and PSIDs. 340 Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, the 341 server searches for the lease using the address in the 'ciaddr' field 342 and the PSID information in the OPTION_V4_PORTPARAMS, and marks the 343 lease as unallocated if a record (matching that PSID) is maintained 344 by the server for that client. 346 The port-set assignment MUST be coupled with the address assignment 347 process. Therefore the server MUST assign the address and port set 348 in the same DHCP message. 350 When defining the pools of IPv4 addresses and PSIDs which are 351 available to lease to clients, the server MUST implement a mechanism 352 to reserve some port ranges (e.g., 0-1023) from allocation to 353 clients. The reservation policy SHOULD be configurable. 355 8.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 356 4o6 Server 358 A single DHCP 4o6 server may serve clients that do not support 359 OPTION_V4_PORTPARAMS as well as those that do. As the rules for the 360 allocation of shared addresses differ from the rules for full IPv4 361 address assignment, the DHCP 4o6 server MUST implement a mechanism to 362 ensure that clients not supporting OPTION_V4_PORTPARAMS do not 363 receive shared addresses. For example, two separate IPv4 addressing 364 pools could be used, one of which allocates IPv4 addresses and PSIDs 365 only to clients that have requested them. 367 If the server is only configured with address pools for shared 368 address allocation, it MUST discard requests that do not contain 369 OPTION_V4_PORTPARAMS in the Parameter Request List option. 371 A server configured with non-shared address pools can be instructed 372 to honor received requests that contain OPTION_V4_PORTPARAMS in the 373 Parameter Request List option (that is ignore OPTION_V4_PORTPARAMS 374 and serve the requesting clients with non-shared IPv4 addresses). 376 9. DHCPv4 Port Parameters Option 378 The meaning of 'offset', 'PSID-len', and 'PSID' fields of the DHCPv4 379 Port Parameters Option is identical to that of 'offset', 'PSID-len', 380 and 'PSID' fields of the S46 Port Parameters Option (Section 4.5 of 381 [I-D.ietf-softwire-map-dhcp]). The use of the same encoding in both 382 options is meant to ensure compatibility with existing port set 383 implementations. 385 The format of OPTION_V4_PORTPARAMS is shown in Figure 1. 387 0 1 388 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 389 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 390 | option-code | option-len | 391 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 392 | offset | PSID-len | 393 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 394 | PSID | 395 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 397 Figure 1: DHCPv4 Port Parameters Option 399 o option-code: OPTION_V4_PORTPARAMS (TBA) 400 o option-len: 4 401 o offset: (PSID offset) 8 bits long field that specifies the numeric 402 value for the excluded port range/offset bits (A-bits), as per 403 section 5.1 of [I-D.ietf-softwire-map]. Allowed values are 404 between 0 and 15, with the default value being 6 for MAP based 405 implementations. This parameter is unused by a Lightweight 4over6 406 client and should be set to 0. 407 o PSID-len: Bit length value of the number of significant bits in 408 the PSID field (also known as 'k'). When set to 0, the PSID field 409 is to be ignored. After the first 'a' bits, there are k bits in 410 the port number representing the value of PSID. Subsequently, the 411 address sharing ratio would be 2^k. 412 o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value 413 algorithmically identifies a set of ports assigned to a client. 414 The first k-bits on the left of this 2-octets field is the PSID 415 value. The remaining (16-k) bits on the right are padding zeros. 417 [I-D.ietf-softwire-map] Section 5.1 provides a full description of 418 how the PSID is interpreted by the client. 420 In order to exclude the system ports ([RFC6335]) or ports reserved by 421 ISPs, the former port-sets that contain well-known ports MUST NOT be 422 assigned unless the operator has explicitly configured otherwise 423 (e.g., by allocating a full IPv4 address). 425 10. Security Considerations 427 The security considerations described in [RFC2131] and [RFC7341] are 428 also potentially applicable to this solution. Unauthorised DHCP 4o6 429 servers in the network could be used to stage an amplification attack 430 or to supply invalid configuration leading to service disruption. 431 The risks of these types of attacks can be reduced through the use of 432 unicast DHCP 4o6 message flows (enabled by supplying DHCP 4o6 server 433 unicast addresses within the OPTION_DHCP4_O_DHCP6_SERVER option). 435 A malicious user could attempt a DoS attack by requesting a large 436 number ofIPv4 address (or fractional address) and port sets 437 allocations, exhausting the available addresses and port sets for 438 other clients. This can be mitigated through DHCP 4o6 address 439 allocation policy, limiting the number of simultaneously active IPv4 440 leases for clients whose request originate from each customer site. 442 The purpose of the client identifier option is to ensure that the 443 same client retains the same parameters over time. This interferes 444 with the client's privacy, as it allows the server to track the 445 client. Clients can manage their privacy exposure by controlling the 446 value of the client identifier, trading off stability of parameter 447 allocation for privacy. We expect that guidance on this trade-off 448 will be discussed in a future version of 449 [I-D.ietf-dhc-anonymity-profile]. 451 Additional security considerations are discussed in Section 11 of 452 [I-D.ietf-softwire-map] and Section 9 of 453 [I-D.ietf-softwire-lw4over6]. 455 10.1. Port Randomization 457 Preserving port randomization [RFC6056] may be more difficult because 458 the host can only randomize the ports inside a fixed port range (see 459 Section 13.4 of [RFC6269]). 461 More discussion to improve the robustness of TCP against Blind In- 462 Window Attacks can be found at [RFC5961]. Other means than the 463 (IPv4) source port randomization to provide protection against 464 attacks should be used (e.g., use [RFC5961] to improve the robustness 465 of TCP against Blind In-Window Attacks, use IPv6). 467 11. IANA Considerations 469 IANA is requested to assign the following new DHCPv4 Option Code in 470 the registry maintained in: http://www.iana.org/assignments/bootp- 471 dhcp-parameters/: 473 Option Name Value Data Meaning 474 length 475 -------------------- ----- ------ ----------------------------------- 476 OPTION_V4_PORTPARAMS TBA 4 This option is used to configure a 477 set of ports bound to a shared IPv4 478 address. 480 12. Acknowledgements 482 This document is merged from [I-D.sun-dhc-port-set-option] and 483 [I-D.farrer-dhc-shared-address-lease]. 485 The authors would like to thank Peng Wu, Gabor Bajko, Teemu 486 Savolainen, Ted Lemon, Tina Tsou, Pierre Levis, Cong Liu, Marcin 487 Siodelski, and Christian Huitema for their contributions. 489 Many thanks to Brian Haberman for the review. 491 13. References 493 13.1. Normative References 495 [I-D.ietf-softwire-lw4over6] 496 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 497 I. Farrer, "Lightweight 4over6: An Extension to the DS- 498 Lite Architecture", draft-ietf-softwire-lw4over6-13 (work 499 in progress), November 2014. 501 [I-D.ietf-softwire-map] 502 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 503 Murakami, T., and T. Taylor, "Mapping of Address and Port 504 with Encapsulation (MAP)", draft-ietf-softwire-map-13 505 (work in progress), March 2015. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 511 2131, March 1997. 513 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 514 Extensions", RFC 2132, March 1997. 516 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 517 Identifiers for Dynamic Host Configuration Protocol 518 Version Four (DHCPv4)", RFC 4361, February 2006. 520 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 521 Robustness to Blind In-Window Attacks", RFC 5961, August 522 2010. 524 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 525 Protocol Port Randomization", BCP 156, RFC 6056, January 526 2011. 528 [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 529 Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 530 7341, August 2014. 532 13.2. Informative References 534 [I-D.farrer-dhc-shared-address-lease] 535 Farrer, I., "Dynamic Allocation of Shared IPv4 Addresses 536 using DHCPv4 over DHCPv6", draft-farrer-dhc-shared- 537 address-lease-00 (work in progress), June 2013. 539 [I-D.ietf-dhc-anonymity-profile] 540 Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 541 profile for DHCP clients", draft-ietf-dhc-anonymity- 542 profile-00 (work in progress), May 2015. 544 [I-D.ietf-softwire-map-dhcp] 545 Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 546 W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for 547 configuration of Softwire Address and Port Mapped 548 Clients", draft-ietf-softwire-map-dhcp-12 (work in 549 progress), March 2015. 551 [I-D.sun-dhc-port-set-option] 552 Qiong, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair, 553 "Dynamic Host Configuration Protocol (DHCP) Option for 554 Port Set Assignment", draft-sun-dhc-port-set-option-02 555 (work in progress), October 2013. 557 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 558 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 559 2005. 561 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 562 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 563 April 2009. 565 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 566 Roberts, "Issues with IP Address Sharing", RFC 6269, June 567 2011. 569 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 570 Cheshire, "Internet Assigned Numbers Authority (IANA) 571 Procedures for the Management of the Service Name and 572 Transport Protocol Port Number Registry", BCP 165, RFC 573 6335, August 2011. 575 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 576 IPv4 Address Shortage", RFC 6346, August 2011. 578 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 579 and H. Ashida, "Common Requirements for Carrier-Grade NATs 580 (CGNs)", BCP 127, RFC 6888, April 2013. 582 Authors' Addresses 584 Yong Cui 585 Tsinghua University 586 Beijing 100084 587 P.R. China 589 Phone: +86-10-6260-3059 590 Email: yong@csnet1.cs.tsinghua.edu.cn 592 Qi Sun 593 Tsinghua University 594 Beijing 100084 595 P.R. China 597 Phone: +86-10-6278-5822 598 Email: sunqi@csnet1.cs.tsinghua.edu.cn 600 Ian Farrer 601 Deutsche Telekom AG 602 CTO-ATI, Landgrabenweg 151 603 Bonn, NRW 53227 604 Germany 606 Email: ian.farrer@telekom.de 608 Yiu L. Lee 609 Comcast 610 One Comcast Center 611 Philadelphia PA 19103 612 USA 614 Email: yiu_lee@cable.comcast.com 615 Qiong Sun 616 China Telecom 617 Room 708, No.118, Xizhimennei Street 618 Beijing 100035 619 P.R. China 621 Phone: +86-10-58552936 622 Email: sunqiong@ctbri.com.cn 624 Mohamed Boucadair 625 France Telecom 626 Rennes 35000 627 France 629 Email: mohamed.boucadair@orange.com