idnits 2.17.1 draft-csf-dhc-dynamic-shared-v4allocation-00.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. -- The draft header indicates that this document updates RFC2131, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2131, updated by this document, for RFC5378 checks: 1994-11-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2014) is 3722 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: 'RFC3927' is defined on line 526, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-04 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 ** Downref: Normative reference to an Informational RFC: RFC 6269 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-08 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-06 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-06 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). 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 Updates: 2131 (if approved) Tsinghua University 5 Intended status: Standards Track I. Farrer 6 Expires: August 17, 2014 Deutsche Telekom AG 7 Y. Lee 8 Comcast 9 Q. Sun 10 China Telecom 11 M. Boucadair 12 France Telecom 13 February 13, 2014 15 Dynamic Allocation of Shared IPv4 Addresses 16 draft-csf-dhc-dynamic-shared-v4allocation-00 18 Abstract 20 This memo describes the dynamic allocation of shared IPv4 addresses 21 to clients using the DHCPv4 protocol. Address sharing allows a 22 single IPv4 address to be allocated to multiple, active clients 23 simultaneously, each client being differentiated by a unique set of 24 L4 source ports. The changes necessary to existing DHCPv4 client and 25 server behaviour are described and a new DHCPv4 option for 26 provisioning clients with shared IPv4 addresses is included. 28 Due to the nature of sharing IP addresses, there are necessarily some 29 limitations to the applicability. This memo describes those 30 limitations and recommends suitable architectures and technologies 31 where address sharing may be utilized. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on August 17, 2014. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Functional Overview . . . . . . . . . . . . . . . . . . . . . 4 75 3. Client-Server Interaction . . . . . . . . . . . . . . . . . . 4 76 3.1. Allocating a Shared, Dynamic IPv4 Address . . . . . . . . 5 77 3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 78 address . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.1. Leasing Shared and Non-Shared IPv4 Addresses from a 81 Single DHCP 4o6 Server . . . . . . . . . . . . . . . . . 7 82 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 83 5.1. Client Usage of a Shared Address . . . . . . . . . . . . 7 84 6. Additional Changes to RFC 2131 . . . . . . . . . . . . . . . 8 85 7. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 8 86 8. Security Consideration . . . . . . . . . . . . . . . . . . . 9 87 8.1. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 9 88 8.2. Port Randomization . . . . . . . . . . . . . . . . . . . 9 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 93 11.2. Informative References . . . . . . . . . . . . . . . . . 11 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 96 1. Introduction 98 Shortages of available public IPv4 addresses mean that it is not 99 always possible for operators to allocate a full IPv4 address to 100 every customer. This problem may be particularly acute whilst the 101 operator is in the migration phase from a native IPv4 network to a 102 native IPv6 network with IPv4 provided as an overlay service. This 103 is likely to increase the requirement on public IPv4 addresses to 104 provide for both existing and transition networks. 106 Two main types of solution have emerged to ease the problem: 108 1. Centralised Network Address Translation (NAT44) in the core 109 network 110 2. Distributing the same public IPv4 address to multiple clients 111 using non-overlapping layer 4 port sets. 113 The solution described in this memo is only suitable on the second 114 solution. 116 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] introduces a "DHCP 4o6 Server", 117 which is capable of servicing both DHCPv6 [RFC3315] and DHCPv4-over- 118 DHCPv6 requests. This enables the provisioning of DHCPv4 based 119 configuration to IPv6 connected clients over IPv6 only transport 120 networks. 122 One of the benefits of the DHCPv4-over-DHCPv6 based approach is that 123 it allows the dynamic leasing of IPv4 addresses to clients, based on 124 existing mechanisms for address lease management available in DHCPv4 125 servers. This can make much more efficient use of remaining public 126 IPv4 addresses than static pre-allocation based approaches as only 127 IPv4 clients that are currently active need to be allocated 128 addresses. This memo uses the defined OPTION_PORTPARAMSV4 with 129 DHCPv4 over DHCPv6, achieving the dynamic leasing of the shared IPv4 130 addresses. 132 Due to the nature of address sharing in this manner, it is only 133 suitable for specific architectures based on the Address plus Port 134 Model (A+P) [RFC6346]. This model extends the unique identifier for 135 a client from the 32-bit IPv4 address to 48-bits by including the 136 16-bits of the layer 4 header. Each client is allocated a unique 137 block of layer 4 ports, and the client will generally utilize these 138 restricted source ports by implementing a NAPT44 funtion, translating 139 traffic from the original private IPv4 source address and 140 unrestricted port to the allocated shared IPv4 address and unique 141 restricted port range. [I-D.ietf-softwire-map] and 142 [I-D.ietf-softwire-lw4over6] describe two implemented examples of the 143 A+P approach which may be suitable for shared, dynamic IPv4 144 addressing. 146 The use of shared addressing in other, more traditional deployment 147 architectures must be avoided due to the fundamental 148 incompatibilities of assigning a the same /32 IPv4 address to 149 multiple clients attached to the same layer 2 segment. 151 This memo also defines OPTION_PORTPARAMSV4, a DHCPv4 option for 152 assigning non-overlapping layer 4 port sets during the IPv4 address 153 allocation process. 155 Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4 156 transport mechanism throughout this document, OPTION_PORTPARAMSV4 may 157 also be used in DHCPv4 over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6] and 158 other DHCPv4 IPv4 address allocation mechanisms. The usage of 159 OPTION_PORTPARAMSV4 in those cases is out of scope of this document. 161 2. Functional Overview 163 Functionally, the dynamic allocation of shared IPv4 addresses by the 164 DHCP 4o6 Server is quite similar to the normal DHCPv4 server dynamic 165 allocation process described in [RFC2131]. The essential difference 166 is that the DHCP 4o6 Server MAY allocate the same IPv4 address to 167 more than one DHCP 4o6 client simultaneously, providing that each 168 address allocation also includes a range of layer 4 source ports 169 unique to that address (i.e. each PSID may only be allocated once per 170 /32 address). 172 To enable this, the DHCP 4o6 client needs to be extended to implement 173 OPTION_PORTPARAMSV4 (described below). This option is used to 174 indicate to the DHCP 4o6 server the client's support the dynamic 175 allocation of a shared IPv4 address and also for conveying the 176 allocated PSID back to the client. 178 The server must be extended to implement OPTION_PORTPARAMSV4 so that 179 it can identify clients supporting shared, dynamic address leasing. 180 With this option, the server can dynamically maintain shared IPv4 181 address leases. The server must also manage unique client leases 182 based on the IPv4 address and PSID tuple, instead of just IPv4 183 address. 185 3. Client-Server Interaction 187 Section 3 of [RFC2131] describes client-server interactions necessary 188 for leasing addresses. The following sections describe the changes 189 necessary for the client and server to implement the dynamic 190 allocation of a shared IPv4 address. 192 3.1. Allocating a Shared, Dynamic IPv4 Address 194 Section 3.1 of [RFC2131] describes the client-server interaction for 195 allocating an IPv4 address. The process described below detail the 196 changes necessary for the allocation of a shared IPv4 address. 198 Using DHCP 4o6, the following DHCPv4 message flow is transported 199 within the DHCPV4-QUERY and DHCPV4-RESPONSE options, which are DHCPv6 200 options used for carrying DHCPv4 messages. 202 1. When the client constructs its DHCPv4 DHCPDISCOVER message to be 203 transported within the DHCPv4-query message, the DHCPDISCOVER 204 message MUST include the following options: A client Identifier 205 (constructed as per [RFC4361] and OPTION_PORTPARAMSV4 (described 206 below). The client MAY insert a non-zero value in the PSID-Len 207 field within OPTION_PORTPARAMSV4 to indicate the preferred size 208 of the restricted port range allocation to the DHCP 4o6 Server. 209 2. Each DHCP 4o6 Server that receives the DHCPDISCOVER message 210 within the DHCPv4-query message responds with a DHCPOFFER message 211 that contains an available IPv4 address in the 'yiaddr' field. 212 The response MUST also include OPTION_PORTPARAMSV4 containing a 213 restricted port-range. If the received OPTION_PORTPARAMSV4 field 214 contains a non-zero PSID-Len field, the DHCP 4o6 Server MAY 215 allocate a port set of the requested size to the client 216 (depending on policy). The DHCPOFFER message is included into 217 the DHCPv4-response message and sent to the client. 218 3. The client evaluates all received DHCPOFFER messages and selects 219 one based on the configuration parameters received, such as the 220 size of the offered port set. The client then sends a 221 DHCPREQUEST containing a server identifier and the corresponding 222 OPTION_PORTPARAMSV4 received in the DHCPOFFER message. 223 4. The server identified in the DHCPREQUEST message (via the siaddr 224 field) creates a binding for the client. The binding includes 225 the client identifier, the IPv4 address and the PSID. These 226 parameters are used by both the server and the client to identify 227 a lease referred to in any DHCP messages. The server responds 228 with a DHCPACK message containing the configuration parameters 229 for the requesting client. Optionally, the the server may also 230 store the IPv6 address that the client has bound the received 231 IPv4 paramters to. 232 5. The client receives the DHCPACK message with the configuration 233 parameters. The client MUST NOT perform a final check on the 234 address, such as ARPing for a duplicate allocated address. 235 6. If the client chooses to relinquish its lease by sending a 236 DHCPRELEASE message, the client MUST include the original client 237 identifier, the leased network address and the allocated 238 restricted source ports inlcuded in OPTION_PORTPARAMSV4. 240 3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 address 242 If the client remembers the previously allocated address and 243 restricted port range, then the process described in section 3.2 of 244 [RFC2131] must be followed. OPTION_PORTPARAMSV4 MUST be included in 245 the message flow, with the client's requested port set being included 246 in the DHCPDISCOVER message. 248 4. Server Behavior 250 The DHCP 4o6 Server MUST NOT reply with the OPTION_PORTPARAMSV4 until 251 the client has explicitly listed the option code in the Parameter 252 Request List (Option 55) [RFC2132]. 254 The DHCP 4o6 Server SHOULD reply with OPTION_PORTPARAMSV4 if the 255 client includes the option in its Parameter Request List. In order 256 to achieve the dynamic management of IPv4 address and port set in the 257 address sharing environment, the server MUST run an address and port- 258 set pool that plays the same role as address pool in a regular DHCP 259 server. The server MUST use the combination of address and PSID as 260 the key to maintain the state of a lease, and look for an available 261 lease for assignment. The leasing database MUST include the 262 information of the address and PSID. 264 When a server receives a DHCPDISCOVER message with 265 OPTION_PORTPARAMSV4 in the Parameter Request List from a client, the 266 server chooses an IPv4 address and a port-set for the requesting 267 client. The logic of choosing is similar to that in Section 4.3.1 of 268 [RFC2131]. The difference is the server looks for the client's 269 binding or an available lease in the server's pool of addresses and 270 PSIDs. After selecting an available IPv4 address with a PSID, the 271 server sends a DHCPOFFER message to the requesting client. 273 When the server receives a DHCPREQUEST message with 274 OPTION_PORTPARAMSV4, the server MUST determine the client's state 275 according to related parameters (Section 4.3.2 of [RFC2131]) and the 276 value of OPTION_PORTPARAMSV4. 278 Upon reception of a DHCPRELEASE message with OPTION_PORTPARAMSV4, the 279 server looks for the lease using the address in the message and the 280 PSID value in the OPTION_PORTPARAMSV4, and marks it as unallocated. 282 The port-set assignment MUST be coupled with the address assignment 283 process. Therefore server MUST assign the address and port set in 284 the same DHCP messages. The lease information for the address is 285 applicable to the port-set as well. 287 4.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single DHCP 288 4o6 Server 290 A single DHCP 4o6 server may have clients that do not support 291 OPTION_PORTPARAMS as well as those that do. As the rules for the 292 allocation of shared addresses differ from the rules for full IPv4 293 address assigment, the DHCP 4o6 server MUST implement a mechanism to 294 ensure that clients which do not support OPTION_PORTPARAMS do not 295 receive shared addresses. For example two separate IPv4 addressing 296 pools could be used, one of which allocates IPv4 addresses and PSIDs 297 only to clients which have requested them. 299 5. Client Behavior 301 The DHCP client applying for a port-set MUST include the 302 OPTION_PORTPARAMSV4 code in the Parameter Request List (Option 55). 303 The client retrieves a port set using the value contained in 304 OPTION_PORTPARAMSV4. 306 When the client renews or releases the DHCP lease, it MUST put the 307 values of offset, PSID length and PSID into the OPTION_PORTPARAMSV4, 308 and send to the server within corresponding DHCPv4 messages. 310 In the DHCPDISCOVER message, the client MAY use a non-zero value for 311 the PSID-len field within OPTION_PORTPARMAS. This is used by the 312 client to request a specific size of port-set (i.e. the number of 313 source ports that it will be allocated). 315 5.1. Client Usage of a Shared Address 317 As a single IPv4 address is being shared between a number of 318 different clients, the allocated shared address is only suitable for 319 certain uses. The client MUST implement a function to ensure that 320 only the allocated layer 4 ports of the shared IPv4 address are used 321 for sourcing new connections. 323 The client MUST apply the following rules for any traffic to or from 324 the shared /32 IPv4 address: 326 o Only port-aware protocols or ICMP implementing [RFC5508] MUST be 327 used 328 o All connections originating from the shared IPv4 address MUST use 329 a source port taken from the allocated restricted port range. 330 o The client MUST NOT accept inbound connections on ports outside of 331 the allocated restricted port range. 333 In order to prevent addressing conflicts which could arise from the 334 allocation of the same IPv4 addreses, the client MUST NOT configure 335 the received restricted IPv4 address on-link. 337 The mechanism by which a client implements these rules is outside of 338 the scope of this document. 340 In the event that the DHCPv4 over DHCPv6 configuration mechanism 341 fails for any reason, the client MUST NOT configure an IPv4 link- 342 local address [RFC3927](taken from the 169.254.0.0/16 range). 344 6. Additional Changes to RFC 2131 346 In addtion to the changes mentioned elsewhere in this document, the 347 following changes to the behaviour described in [RFC2131] are 348 necessary in order to implement dynamic allocation of a shared IPv4 349 address. 351 Section 2.2 The client MUST NOT probe a newly received IPv4 address 352 (e.g. with ARP) to see if it is in use by another host. 353 Section 3.1 Item 5. The client MUST NOT perform a final check on the 354 assigned IPv4 address. 356 7. DHCPv4 Port Parameters Option 358 The Port Paramaters Option for DHCPv4 specifies the restricted set of 359 layer 4 source ports that are necessary to dynamically allocate a 360 shared address. The option uses the same fields as the MAP Port 361 Parameters Option described in Section 4.4 of 362 [I-D.ietf-softwire-map-dhcp], implemented as a DHCPv4 option. This 363 is to maintain compatibility with existing implementations. 365 The construction and usage of OPTION_PORTPARAMSV4 is 367 0 1 368 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | option-code | Length | offset | PSID-Len | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | PSID | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 1: DHCPv4 Port Parameters Option 378 o option-code: OPTION_PORTPARAMSV4 (TBA) 379 o option-length: 3 380 o offset: (PSID offset) 8 bits long field that specifies the numeric 381 value for the MAP algorithm's excluded port range/offset bits 382 (A-bits), as per section 5.1.1 in [I-D.ietf-softwire-map]. 383 Allowed values are between 0 and 16, with the default value being 384 4 for a MAP client. This parameter is unused by a Lightweight 385 4over6 client and should be set to 0. 386 o PSID-len: Bit length value of the number of significant bits in 387 the PSID field (also known as 'k'). When set to 0, the PSID field 388 is to be ignored. After the first 'a' bits, there are k bits in 389 the port number representing valid of PSID. Subsequently, the 390 address sharing ratio would be 2^k. 391 o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value 392 algorithmically identifies a set of ports assigned to a CE. The 393 first k-bits on the left of this 2-octets field is the PSID value. 394 The remaining (16-k) bits on the right are padding zeros. 396 [I-D.ietf-softwire-map] (Section 5.1) provides a full description of 397 how the PSID is interpreted by the client. 399 When receiveing the Port Parameters option with an explicit PSID, the 400 client MUST use this explicit PSID in configuring its DHCPv4 over 401 DHCPv6 interface. 403 8. Security Consideration 405 8.1. Denial-of-Service 407 The solution is generally vulnerable to DoS when used on a shared 408 medium or when access network authentication is not a prerequisite to 409 IP address assignment. The solution SHOULD only be used on point-to- 410 point links, tunnels, and/or in environments where authentication at 411 link layer is performed before IP address assignment, and not shared 412 medium. 414 8.2. Port Randomization 416 Preserving port randomization [RFC6056] may be more or less difficult 417 depending on the address sharing ratio (i.e., the size of the port 418 space assigned to a CPE). The host can only randomize the ports 419 inside a fixed port range [RFC6269]. 421 More discussion to improve the robustness of TCP against Blind In- 422 Window Attacks can be found at [RFC5961]. Other means than the 423 (IPv4) source port randomization to provide protection against 424 attacks should be used (e.g., use [I-D.vixie-dnsext-dns0x20] to 425 protect against DNS attacks, [RFC5961] to improve the robustness of 426 TCP against Blind In-Window Attacks, use IPv6). 428 A proposal to preserve the entropy when selecting port is discussed 429 in [I-D.bajko-pripaddrassign]. 431 9. IANA Considerations 433 IANA is kindly requested to allocate the following DHCPv4 option 434 code: TBD for OPTION_PORTPARAMSV4. 436 10. Acknowledgements 438 This document is merged from [I-D.sun-dhc-port-set-option] and 439 [I-D.farrer-dhc-shared-address-lease]. 441 11. References 443 11.1. Normative References 445 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 446 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 447 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 448 dhcpv4-over-dhcpv6-04 (work in progress), January 2014. 450 [I-D.ietf-softwire-map] 451 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 452 Murakami, T., and T. Taylor, "Mapping of Address and Port 453 with Encapsulation (MAP)", draft-ietf-softwire-map-10 454 (work in progress), January 2014. 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 460 2131, March 1997. 462 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 463 Extensions", RFC 2132, March 1997. 465 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 466 Identifiers for Dynamic Host Configuration Protocol 467 Version Four (DHCPv4)", RFC 4361, February 2006. 469 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 470 Robustness to Blind In-Window Attacks", RFC 5961, August 471 2010. 473 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 474 Protocol Port Randomization", BCP 156, RFC 6056, January 475 2011. 477 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 478 Roberts, "Issues with IP Address Sharing", RFC 6269, June 479 2011. 481 11.2. Informative References 483 [I-D.bajko-pripaddrassign] 484 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 485 "Port Restricted IP Address Assignment", draft-bajko- 486 pripaddrassign-04 (work in progress), April 2012. 488 [I-D.farrer-dhc-shared-address-lease] 489 Farrer, I., "Dynamic Allocation of Shared IPv4 Addresses 490 using DHCPv4 over DHCPv6", draft-farrer-dhc-shared- 491 address-lease-00 (work in progress), June 2013. 493 [I-D.ietf-dhc-dhcpv4-over-ipv6] 494 Cui, Y., Wu, P., Wu, J., Lemon, T., and Q. Sun, "DHCPv4 495 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-08 496 (work in progress), October 2013. 498 [I-D.ietf-softwire-lw4over6] 499 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 500 I. Farrer, "Lightweight 4over6: An Extension to the DS- 501 Lite Architecture", draft-ietf-softwire-lw4over6-06 (work 502 in progress), February 2014. 504 [I-D.ietf-softwire-map-dhcp] 505 Mrugalski, T., Troan, O., Dec, W., Bao, C., 506 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 507 for configuration of Softwire Address and Port Mapped 508 Clients", draft-ietf-softwire-map-dhcp-06 (work in 509 progress), November 2013. 511 [I-D.sun-dhc-port-set-option] 512 Qiong, Q., Lee, Y., Sun, Q., Bajko, G., and M. Boucadair, 513 "Dynamic Host Configuration Protocol (DHCP) Option for 514 Port Set Assignment", draft-sun-dhc-port-set-option-02 515 (work in progress), October 2013. 517 [I-D.vixie-dnsext-dns0x20] 518 Vixie, P. and D. Dagon, "Use of Bit 0x20 in DNS Labels to 519 Improve Transaction Identity", draft-vixie-dnsext- 520 dns0x20-00 (work in progress), March 2008. 522 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 523 and M. Carney, "Dynamic Host Configuration Protocol for 524 IPv6 (DHCPv6)", RFC 3315, July 2003. 526 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 527 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 528 2005. 530 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 531 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 532 April 2009. 534 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 535 IPv4 Address Shortage", RFC 6346, August 2011. 537 Authors' Addresses 539 Yong Cui 540 Tsinghua University 541 Beijing 100084 542 P.R.China 544 Phone: +86-10-6260-3059 545 Email: yong@csnet1.cs.tsinghua.edu.cn 547 Qi Sun 548 Tsinghua University 549 Beijing 100084 550 P.R.China 552 Phone: +86-10-6278-5822 553 Email: sunqi@csnet1.cs.tsinghua.edu.cn 555 Ian Farrer 556 Deutsche Telekom AG 557 CTO-ATI, Landgrabenweg 151 558 Bonn, NRW 53227 559 Germany 561 Email: ian.farrer@telekom.de 563 Yiu L. Lee 564 Comcast 565 One Comcast Center 566 Philadelphia PA 19103 567 USA 569 Email: yiu_lee@cable.comcast.com 570 Qiong Sun 571 China Telecom 572 Room 708, No.118, Xizhimennei Street 573 Beijing 100035 574 P.R.China 576 Phone: +86-10-58552936 577 Email: sunqiong@ctbri.com.cn 579 Mohamed Boucadair 580 France Telecom 581 2330 Central Expressway 582 Rennes 35000 583 France 585 Email: mohamed.boucadair@orange.com