idnits 2.17.1 draft-farrer-dhc-shared-address-lease-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-dhc-dhcpv4-over-dhcpv6], [RFC2131]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 directly say this. It does mention RFC2131 though, so this could be OK. 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 (June 25, 2013) is 3958 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 471, but no explicit reference was found in the text == Unused Reference: 'RFC6148' is defined on line 479, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-dhcpv6-00 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-00 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-03 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-07 -- 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 I. Farrer 3 Internet-Draft Deutsche Telekom AG 4 Updates: 2131 (if approved) June 25, 2013 5 Intended status: Standards Track 6 Expires: December 27, 2013 8 Dynamic Allocation of Shared IPv4 Addresses using DHCPv4 over DHCPv6 9 draft-farrer-dhc-shared-address-lease-00 11 Abstract 13 This memo describes an update to [RFC2131], which enables the dynamic 14 leasing of shared IPv4 addresses and layer 4 source ports to DHCPv4 15 over DHCPv6 clients [I-D.ietf-dhc-dhcpv4-over-dhcpv6]. Shared 16 addressing allows a single IPv4 address to be allocated to multiple, 17 active clients simulataneously. Clients sharing the same address are 18 then differentiated by unique L4 source ports. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 27, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Functional Overview . . . . . . . . . . . . . . . . . . . . . 3 62 3. Client-server Interaction . . . . . . . . . . . . . . . . . . 4 63 3.1. Allocating a Shared, Dynamic IPv4 Address . . . . . . . . 4 64 3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 65 address . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Client Usage of a Shared Address . . . . . . . . . . . . . . 5 67 5. Additional Changes to [RFC2131] Behaviour . . . . . . . . . . 6 68 6. DHCPv4 Port Parameters Option . . . . . . . . . . . . . . . . 6 69 7. Specfic Behaviour for Softwire Clients . . . . . . . . . . . 7 70 8. DHCPv4 over DHCPv6 Source Address Option . . . . . . . . . . 9 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 12.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] introduces a "Unified Server" - a 82 DHCP server capable of servicing both DHCPv6 [RFC3315] and DHCPv4 83 over DHCPv6 requests. This enables the provisioning of DHCPv4 based 84 configuration to IPv6 connected clients over IPv6 only transport 85 networks. 87 One of the benefits of the DHCPv4 over DHCPv6 based approach is that 88 it allows the dynamic leasing of IPv4 addresses to clients, based on 89 existing mechanisms for address lease management available in DHCPv4 90 servers. This can make much more efficient use of remaining public 91 IPv4 addresses than static pre-allocation based approaches as only 92 IPv4 clients which are currently active need to be allocated 93 addresses. 95 Shortages of available public IPv4 addresses mean that it is not 96 always possible for operators to allocate a full IPv4 address to 97 every active customer simultaneously. This problem may be 98 particularly acute whilst the operator is in the migration phase from 99 a native IPv4 network to a native IPv6 network with IPv4 provided as 100 an overlay service. Such migrations are likely to increase the 101 requirement on public IPv4 addresses so that both existing and 102 transition networks can be provided for. 104 IPv4 address sharing provides a way of easing this problem. A shared 105 IP address is a single IPv4 address which is allocated to a number of 106 clients simultaneously. The clients differentiate themselves through 107 the use of layer 4 source ports, which are unique for each client 108 sharing a single IPv4 address, known as a Port Set ID (PSID). 110 The client will generally utilize these restricted source ports by 111 implementing a NAPT44 function, translating traffic from the original 112 source address and unrestricted port range to the allocated shared 113 IPv4 address and unique restricted port range. 115 This technique is also referred to as "extended" or "A+P" addressing 116 [RFC6346]. 118 Due to the nature of address sharing in this manner, it is only 119 suitable for some very specific architectures, such as those 120 described in [I-D.ietf-softwire-map] and 121 [I-D.ietf-softwire-lw4over6]. Use of shared addressing in other, 122 more traditional deployment architectures must be avoided due to the 123 fundamental incompatibilities of assigning a the same /32 IPv4 124 address to multiple clients such as when they are attached to the 125 same layer 2 segment. Some rules for the use of the allocated shared 126 dynamic address are provided in Section 4 below. 128 [RFC2131] describes DHCPv4, providing a method for dynamically 129 allocating IPv4 addresses to clients based on three different 130 mechanisms: 132 o Automatic Address Allocation 133 o Dynamic Address Allocation 134 o Manual Address Allocation 136 This memo describes how the dynamic allocation mechanism can be 137 adapted for allocating shared IPv4 addresses for use by DHCPv4 over 138 DHCPv6 clients and Unified Servers. The approach is referred to as 139 "shared, dynamic" addressing throughout this memo. 141 2. Functional Overview 142 From a functional perspective, shared, dynamic allocation by the 143 unified server is quite similar to the normal DHCPv4 server dynamic 144 allocation process. The underlying difference is that the unified 145 server MAY allocate the same IPv4 address to more than one DHCPv4 146 over DHCPv6 client simultaneously, providing that each address 147 allocation also includes a range of layer 4 source ports unique to 148 that address (i.e. each PSID may only be allocated once per /32 149 address). 151 To enable this, the DHCPv4 over DHCPv6 client needs to be extended to 152 implement OPTION_PORTPARAMSV4 (described below). This is used to 153 indicate to the Unified server that it is capable of supporting 154 shared, dynamic addressing and also for conveying the allocated PSID. 156 The server must be extended to implement OPTION_PORTPARAMSV4 so that 157 clients able to support shared, dynamic address leasing can be 158 identified and so that shared, dynamic addresses can be allocated and 159 their leases maintained. The server must also manage unique client 160 leases based on the address and PSID tuple, instead of just IPv4 161 address. 163 3. Client-server Interaction 165 The following sections describe the changes to the client and server 166 necessary to implement dynamic, shared address allocation. 168 3.1. Allocating a Shared, Dynamic IPv4 Address 170 Section 3.1 of [RFC2131] describes the client-server interaction for 171 allocating an IPv4 address. The process described below detail the 172 required changes for the dynamic, shared addressing mechanism. 174 The following message flow is transported within the DHCPv6 175 OPTION_BOOTP_MSG message. 177 1. The client constructs its DHCPv4 DHCPDISCOVER message 178 (transported within the DHCPv6 BOOTPRELAYV6 message). The 179 DHCPDISCOVER message MUST include the following options: 181 * A client Identifier (constructed as per [RFC4361] 182 * OPTION_PORTPARAMSV4 (described below) 184 The client MAY insert a non-zero value in the PSID-Len field 185 within OPTION_PORTPARAMSV4 to indicate the preferred size of the 186 restricted port range allocation to the unified server. 187 2. Each Unified server which receives the DHCPDISCOVER message 188 containing OPTION_PORTPARAMSV4 within the BOOTPRELAYV6 message 189 may respond with a DHCPOFFER message which contains an available 190 IPv4 address in the 'yiaddr' field. The response MUST also 191 include OPTION_PORTPARAMSV4 containing a restricted port-range. 192 If the received OPTION_PORTPARAMSV4 field contains a non-zero 193 PSID-Len field, the Unified server MAY allocate a port set of the 194 requested size to the client (depending on policy). 195 3. The client evaluates all received DHCPOFFER messages and selects 196 one based on the configuration parameters received (e.g. the 197 size of the offered port set). The client then sends a 198 DHCPREQUEST containing a server identifier and the corresponding 199 OPTION_PORTPARAMSV4 received in the DHCPOFFER message. 200 4. The server identified in the DHCPREQUEST message (via the siaddr 201 field) creates a binding for the client. The binding includes 202 the client identifier, the IPv4 address and the PSID. These 203 parameters are used by both the server and the client to identify 204 the lease referred to in any future DHCP messages. The server 205 responds with a DHCPACK message containing the configuration 206 parameters for the requesting client. 207 5. The client receives the DHCPACK message with the configuration 208 parameters. The client MUST NOT perform a final check on the 209 address, such as ARPing for a duplicate allocated address. 210 6. If the client chooses to relinquish its lease by sending a 211 DHCPRELEASE message, the client MUST include the original client 212 identifier, the leased network address and the allocated 213 restricted source ports included in OPTION_PORTPARAMSV4. 215 3.2. Reusing a Previously Allocated Shared, Dynamic IPv4 address 217 If the client remembers the previously allocated address and 218 restricted port range, then the process described in section 3.2 of 219 [RFC2131] must be followed. OPTION_PORTPARAMSV4 MUST be included in 220 the message flow, with the client's requested port set being included 221 in the DHCPDISCOVER message. 223 4. Client Usage of a Shared Address 225 As a single IPv4 address is being shared between a number of 226 different clients, the allocated shared address is only suitable for 227 certain functions. The client MUST implement a function to ensure 228 that only the allocated layer 4 ports of the shared IPv4 address are 229 used for sourcing new connections. 231 The client MUST apply the following rules for any traffic to or from 232 the shared /32 IPv4 address: 234 o Only port-aware protocols MUST be used. 235 o All connections originating from the shared IPv4 address MUST use 236 a source port taken from the allocated restricted port range. 238 o The client MUST NOT accept inbound connections with destination 239 ports outside of the allocated restricted port range. 241 In order to prevent addressing conflicts which could arise from the 242 allocation of the same IPv4 addreses, the client MUST NOT configure 243 the received restricted IPv4 address on-link. 245 In the event that the DHCPv4 over DHCPv6 configuration mechanism 246 fails for any reason, the client MUST NOT configure an IPv4 link- 247 local address [RFC3927](taken from the 169.254.0.0/16 range). 249 The mechanism by which a client implements these rules is outside of 250 the scope of this document. 252 5. Additional Changes to [RFC2131] Behaviour 254 The following change to the behaviour described in [RFC2131] is also 255 necessary in order to implement dynamic shared address allocation. 257 Section 2.2 The client MUST NOT probe a newly received IPv4 address 258 (e.g. with ARP) to see if it is in use by another host. 260 6. DHCPv4 Port Parameters Option 262 The Port Paramaters Option for DHCPv4 specifies the restricted set of 263 layer 4 source ports that are necessary to dynamically allocate a 264 shared address. The option uses the same fields as the MAP Port 265 Parameters Option described in Section 4.4 of 266 [I-D.ietf-softwire-map-dhcp], implemented as a DHCPv4 option. This 267 is to maintain compatibility with existing implementations. 269 The construction and usage of OPTION_PORTPARAMSV4 is 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | option-code | Length | offset | PSID-Len | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | PSID | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 1: DHCPv4 Port Parameters Option 281 o option-code: OPTION_PORTPARAMSV4 (TBA) 282 o option-length: 3 283 o offset: (PSID offset) 8 bits long field that specifies the numeric 284 value for the MAP algorithm's excluded port range/offset bits 285 (A-bits), as per section 5.1.1 in [I-D.ietf-softwire-map]. 287 Allowed values are between 0 and 16, with the default value being 288 6 for a MAP client. This parameter is unused by a Lightweight 289 4over6 client and should be set to 0. 290 o PSID-len: Bit length value of the number of significant bits in 291 the PSID field. (also known as 'k'). When set to 0, the PSID 292 field is to be ignored. After the first 'a' bits, there are k 293 bits in the port number representing valid of PSID. Subsequently, 294 the address sharing ratio would be 2^k. 295 o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value 296 algorithmically identifies a set of ports assigned to a CE. The 297 first k-bits on the left of this 2-octets field is the PSID value. 298 The remaining (16-k) bits on the right are padding zeros. 300 [I-D.ietf-softwire-map] (Section 5.1) provides a full description of 301 how the PSID is interpreted by the client. 303 When receiveing the Port Parameters option with an explicit PSID, the 304 client MUST use apply this PSID to the interface being configured by 305 DHCPv4 over DHCPv6. 307 7. Specfic Behaviour for Softwire Clients 309 [DISCUSSION NOTE: Should the following section be moved into a 310 separte draft as it is more softwire specific?] 312 Current mechanisms suitable for extending to incorporate dynamic, 313 shared IPv4 addressing include [I-D.ietf-softwire-map] and 314 [I-D.ietf-softwire-lw4over6]. For these mechanisms to function, the 315 operator needs information about the clients allocated IPv4 address, 316 PSID and also the /128 IPv6 prefix which the client will use as the 317 IPv4 in IPv6 tunnel endpoint. This binding information is used by 318 other functional elements in the operator's network (e.g. a softwire 319 tunnel concentrator) for correctly routing traffic to and from 320 clients. 322 For the shared, dynamic address allocation model, a two-way 323 communication model is necessary so that the Unified Server can 324 indicate to the client the preferred prefix to use for binding the 325 received IPv4 configuration and sourcing tunnel traffic. 327 As the Unified server is managing the leasing of DHCPv4 to clients, 328 it holds the most accurate IPv4 lease information available in the 329 network. It follows that the unified server should also hold 330 information about the /128 IPv6 prefixes in use by active clients as 331 tunnel endpoints, so that the unified server contains a single 332 comprehensive dynamic IPv4/IPv6 binding table. 334 To achieve this, the client also needs to inform the Unified server 335 of the /128 prefix that it has bound the IPv4 configuration to. 337 To provide this function, the DHCPV4oDHCPv6 client MAY implement 338 OPTION_DHCPV4_O_DHCPV6_SADDR (defined below). This option is 339 included by the client within OPTION_BOOTP_MSG messages and is used 340 alongside the DHCPv4 request process. 342 The option comprises of two IPv6 prefixes (with associated prefix 343 length fields): 345 cipv6-prefix-hint Sent by the server to indicate to the client the 346 preferred prefix to bind IPv4 configuration to. 347 If this field contains a prefix, the client MUST 348 perform a longest prefix match betweeen cipv6 349 -prefix-hint and all prefixes configured on the 350 device. The selected prefix MUST then be used to 351 bind the received IPv4 configuration to. If this 352 field is left blank, then the client MAY select 353 any valid IPv6 prefix. 354 cipv6-bound-prefix Used by the client to inform the Unified Server of 355 the IPv6 prefix that it has bound the IPv4 356 configuration to. This SHOULD be a /128 prefix 357 configured on the client. 359 If used, this option MUST be present within all future 360 OPTION_BOOT_MSG transactions between the client and the server. 362 The message flow for this process (aligned to the DHCPv4 address 363 allocation process) is as follows: 365 +-----------+---------------+-----------+--------------+------------+ 366 | DHCPv4 | cipv6-prefix- | cipv6-hin | cipv6-bound- | cipv6-boun | 367 | Message | hint | tlen | prefix | dlen | 368 +-----------+---------------+-----------+--------------+------------+ 369 | DHCPDISCO | blank | blank | blank | blank | 370 | VER | | | | | 371 | --------- | ------------- | --------- | --------- | ---------- | 372 | DHCPOFFER | Preferred | Preferred | blank | blank | 373 | | prefix | prefix | | | 374 | | | Length | | | 375 | --------- | ------------- | --------- | --------- | ---------- | 376 | DHCPREQUE | Preferred | Preferred | Bound prefix | Bound | 377 | ST | prefix | prefix | | prefix | 378 | | | length | | Length | 379 | --------- | ------------- | --------- | --------- | ---------- | 380 | DHCPACK | Preferred | Preferred | Bound prefix | Bound | 381 | | prefix | prefix | | prefix | 382 | | | length | | Length | 383 +-----------+---------------+-----------+--------------+------------+ 385 Table 1: IPv6/IPv4 Binding Message Flow 387 8. DHCPv4 over DHCPv6 Source Address Option 389 The DHCPv4 over DHCPv6 Source address option is used by the Unified 390 server to indicate an IPv6 prefix to use for DHCPv4 over DHCPv6 391 functions. It is also used by the client to inform the unified 392 server of the prefix it has selected for binding DHCPv4 over DHCPv6 393 functions to. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | OPTION_DHCPV4_O_DHCPV6_SADDR | Length | 399 +-------------------------------+-------------------------------+ 400 . cipv6-prefix-hint (variable length) . 401 +---------------------------------------------------------------+ 402 | cipv6-hintlen | cipv6-bound-prefix . 403 +---------------+ (variable length) +---------------+ 404 . |cipv6-boundlen | 405 +---------------------------------------------------------------+ 407 o option-code: OPTION_DHCPV4_O_DHCPV6_SADDR (TBA2) 408 o option-length: 2 + length of cipv6-prefix-hint + length of cipv6 409 -bound-prefix, specified in bytes 410 o cipv6-prefix-hint: 411 o cipv6-hintlen: 8 bit field expressing the bit mask length of the 412 IPv6 prefix specified in cipv6-prefix-hint 413 o cipv6-bound-prefix: The IPv6 prefix that the client is using to 414 bind the allocated DHCPv4 configuration to 415 o cipv6-boundlen: 8 bit field expressing the bit mask length of the 416 IPv6 prefix specified in cipv6-bound-prefix. Default: 128 418 9. Security Considerations 420 TBD 422 10. IANA Considerations 424 IANA is kindly requested to allocate the following DHCPv4 option 425 code: TBD for OPTION_PORTPARAMSV4 and the DHCPv6 option code: 426 OPTION_DHCPV4_O_DHCPV6_SADDR. 428 11. Acknowledgements 430 Thanks to Qi Sun and Olaf Bonness for thier reviews. 432 12. References 434 12.1. Normative References 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, March 1997. 439 12.2. Informative References 441 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] 442 Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. 443 Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc- 444 dhcpv4-over-dhcpv6-00 (work in progress), April 2013. 446 [I-D.ietf-softwire-lw4over6] 447 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 448 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 449 Architecture", draft-ietf-softwire-lw4over6-00 (work in 450 progress), April 2013. 452 [I-D.ietf-softwire-map-dhcp] 453 Mrugalski, T., Troan, O., Dec, W., Bao, C., 454 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 455 for Mapping of Address and Port", draft-ietf-softwire-map- 456 dhcp-03 (work in progress), February 2013. 458 [I-D.ietf-softwire-map] 459 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 460 Murakami, T., and T. Taylor, "Mapping of Address and Port 461 with Encapsulation (MAP)", draft-ietf-softwire-map-07 462 (work in progress), May 2013. 464 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 465 2131, March 1997. 467 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 468 and M. Carney, "Dynamic Host Configuration Protocol for 469 IPv6 (DHCPv6)", RFC 3315, July 2003. 471 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 472 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 473 2005. 475 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 476 Identifiers for Dynamic Host Configuration Protocol 477 Version Four (DHCPv4)", RFC 4361, February 2006. 479 [RFC6148] Kurapati, P., Desetti, R., and B. Joshi, "DHCPv4 Lease 480 Query by Relay Agent Remote ID", RFC 6148, February 2011. 482 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 483 IPv4 Address Shortage", RFC 6346, August 2011. 485 Author's Address 487 Ian Farrer 488 Deutsche Telekom AG 489 Bonn 490 Germany 492 Email: ian.farrer@telekom.de