idnits 2.17.1 draft-wing-dhc-dns-reconfigure-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2013) is 3868 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: 'RFC3315' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC3646' is defined on line 369, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-18 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group P. Patil 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Boucadair 5 Expires: March 17, 2014 France Telecom 6 D. Wing 7 T. Reddy 8 Cisco 9 September 13, 2013 11 DHCPv6 Dynamic Reconfiguration 12 draft-wing-dhc-dns-reconfigure-02 14 Abstract 16 This specification extends DHCPv6 so that a DHCPv6 Relay Agent can 17 dynamically indicate end host connectivity to a DHCPv6 Server. This 18 information is also triggered by any change in connectivity type 19 provided to the host. The DHCPv6 server uses this information as an 20 input to its decision-making about configuration parameters to be 21 conveyed to that host. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 17, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Problem Statement: Focus on DNS Reconfiguration . . . . . . . 3 60 4. Host Connectivity Status Option . . . . . . . . . . . . . . . 4 61 5. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . 5 62 5.1. Relay Forward . . . . . . . . . . . . . . . . . . . . . . 5 63 5.2. Reconfigure Request . . . . . . . . . . . . . . . . . . . 6 64 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 6 65 6.1. Relay Forward . . . . . . . . . . . . . . . . . . . . . . 6 66 6.2. Reconfigure Request . . . . . . . . . . . . . . . . . . . 6 67 7. Host Tracking . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Some networks are expected to support IPv4-only, dual-stack, and 78 IPv6-only hosts at the same time. Due to devices capabilities and 79 available connectivity types, providing generic configuration from a 80 DHCP server to connected hosts is sub-optimal in most cases, and may 81 even break functionality in some cases. Network infrastructure is 82 usually well equipped to be aware of single/dual-stack nature of 83 hosts. The network can also track and detect transitions from single 84 to dual-stack or vice-versa. 86 This specification describes a DHCPv6 extension for relay agents to 87 indicate host characteristics pertaining to host connectivity to 88 DHCPv6 servers. The information passed by a relay is generic and a 89 DHCPv6 server can interpret and process this information to make a 90 more informed decision on the configuration parameters that a client 91 is to receive. 93 The DHCPv6 server can either be configured or have built-in logic to 94 use this information as desired, which is outside the scope of this 95 document. 97 Section 3 describes a typical problem that can be addressed using the 98 mechanism described in this specification. A DHCPv6 server makes a 99 decision on priority of DNS servers to be sent back to the client 100 based on host connectivity characteristics provided by the relay 101 agent. 103 While the host stack can be upgraded to send this information to the 104 DHCPv6 server on its own, a generalized upgrade of all DHCPv6 client 105 implementations on all operating systems is extremely difficult. 107 [DISCUSSION NOTE: A companion solution could be to define a 108 container that can be used to return per-AF specific configuration 109 parameters to the client. In such a scheme, the server blindly 110 returns all pieces of configuration and it is up to the client to 111 make use of appropriate set of parameters according to its 112 available connectivity. This alternative assumes an update of 113 dhcp client. This approach can be seen as complimentary to the 114 one defined in this specification. The document will be updated 115 to reflect consensus of the WG on whether the additional option is 116 to be specified.] 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 Dual-Stack host: Denotes a host that is configured with both an IPv4 125 address and IPv6 prefix and is reachable using both IPv4 and IPv6 126 connectivity. 128 3. Problem Statement: Focus on DNS Reconfiguration 130 Default address selection rules specified in [RFC6724] prefers IPv6 131 over IPv4. If a dual-stack host is configured to use a DNS64 server 132 [RFC6147], it will send its DNS queries to that DNS64 server which 133 will synthesize a AAAA response if no A record is found. Thus, the 134 dual-stack host will always use IPv6 if a DNS lookup was involved, 135 even if IPv4 could have been used more optimally. 137 In some deployments, if NAT44 [RFC3022] and NAT64 [RFC6146] are 138 deployed on the same network, it is preferable to use NAT44 over 139 NAT64 because of scale, performance and application incompatibility 140 issues (e.g., FTP) [RFC6384]. At the same time, native IPv6 can 141 still be preferred over IPv4. 143 A DHCPv6 Relay Agent can observe host characteristics on a network to 144 determine if a host is IPv4-only, dual-stack or IPv6-only and also 145 detect transitions from single to dual-stack or vice-versa. This 146 information can be used by the DHCPv6 Relay Agent to influence the 147 DHCPv6 Server to send appropriately prioritized DNS Servers to the 148 client. The DHCPv6 server can implement the following based on 149 connectivity information received from the relay agent. 151 o IPv6-only transition to Dual-Stack: In case a host is IPv6-only, 152 it is provided with a DNS64 server. When transitioning to dual- 153 stack, an IPv4 DNS server is assigned as a consequence of 154 obtaining an IPv4 Address. The DHCPv6 Relay Agent can detect this 155 and send a RECONFIGURE_REQUEST message [RFC6977] to the DHCPv6 156 Server indicating that the host needs to be provided with a 157 regular DNS server. In lieu of this mechanism, the host would 158 continue to use the DNS64 server until the host stack 159 reinitializes. 161 o Dual-Stack to IPv6-only: In case a host is dual-stack, it is 162 provided with a regular DNS server followed by DNS64 server. When 163 transitioning to IPv6-only, the DHCPv6 Relay Agent can detect this 164 change and send a RECONFIGURE_REQUEST message to the DHCPv6 server 165 indicating that the host needs to be assigned a DNS64 server only. 166 In lieu of this mechanism, the host would continue to use the 167 regular DNS Server which is inaccessible and eventually time out 168 to fail over to the DNS64 Server. The host will take additional 169 time to fully initialize causing delays in connection. 171 4. Host Connectivity Status Option 173 The option (Figure 1) includes an 8-bit status code that indicates 174 specific host connectivity characteristics. The option can be 175 included by a DHCPv6 Relay Agent in RELAY-FORW and RECONFIGURE- 176 REQUEST. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | OPTION_HOST_CONNECTIVITY | option-len | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | status | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 option-code OPTION_HOST_CONNECTIVITY (TBA). 187 option-len 1. 188 status 8-bit integer value carrying the connectivity status 189 of a host. The following codes are defined: 190 +-----+--------------------+ 191 |Value| Name | 192 +-----+--------------------+ 193 | 1 | IPv4_TO_DUAL_STACK | 194 | 2 | IPv6_TO_DUAL_STACK | 195 | 3 | DUAL_STACK_TO_IPv4 | 196 | 4 | DUAL_STACK_TO_IPv6 | 197 +-----+--------------------+ 199 Figure 1: Relay Agent Host Connectivity Option message format 201 o IPv4_TO_DUAL_STACK: Host is transitioning from IPv4-Only to Dual- 202 Stack mode. 204 o IPv6_TO_DUAL_STACK: Host is transitioning from IPv6-Only to Dual- 205 Stack mode. 207 o DUAL_STACK_TO_IPv4: Host is transitioning from Dual-Stack to 208 IPv4-Only mode. 210 o DUAL_STACK_TO_IPv6: Host is transitioning from Dual-Stack to 211 IPv6-Only mode. 213 5. DHCPv6 Relay Agent Behavior 215 DHCPv6 relay agents that implement this specification MUST be 216 configurable for tracking host connectivity and inserting the 217 OPTION_HOST_CONNECTIVITY option in RELAY-FORW and RECONFIGURE-REQUEST 218 messages. 220 To be able to notify details of hosts' connectivity, a relay agent 221 must be able to track host connectivity. A Relay Agent can detect 222 host connectivity type using mechanisms discussed in Section 7. The 223 Relay Agent then includes this information in the appropriate DHCPv6 224 message. 226 Relay agents need to maintain connectivity state of each host it can 227 track. This ensures that notifications to the DHCPv6 server, 228 especially DHCPv6 RECONFIGURE_REQUEST, are accurately sent when there 229 is a change in status. If a relay agent loses state due to some 230 reason (e.g., during restart events), it will build state again using 231 the mechanisms described in Section 7 and then send appropriate 232 notifications to the server. Such notifications are redundant and a 233 DHCPv6 Server can choose to ignore such redundant notifications from 234 the relay agent. Redundant notifications are also possible when 235 relay agents are deployed in fault tolerant mode. 237 5.1. Relay Forward 238 DHCPv6 relay agents that implement this specification MAY include the 239 option OPTION_HOST_CONNECTIVITY in the RELAY_FORW to indicate status 240 of host connectivity. 242 5.2. Reconfigure Request 244 DHCPv6 relay agents that implement this specification MUST be 245 configurable for sending the RECONFIGURE_REQUEST message. The relay 246 agent generates a Reconfigure-Request [RFC6977] anytime status of 247 host connectivity changes by including OPTION_HOST_CONNECTIVITY in 248 the request. 250 6. DHCPv6 Server Behavior 252 A DHCPv6 Server that supports OPTION_HOST_CONNECTIVITY may either 253 have specific configuration or built-in logic to process information 254 available in the option and send configuration parameters in DHCPv6 255 responses. How the server consumes and acts on the information 256 obtained in the option are outside the scope of this document. 258 The DHCPv6 server may use this connectivity information, if 259 available, in addition to other relay agent option data, other 260 options included in the DHCPv6 client messages, server configuration, 261 and physical network topology information in order to assign 262 appropriate configuration to the client. 264 The server MUST ignore the option if it doesn't recognize the status 265 in the OPTION_HOST_CONNECTIVITY option. The server SHOULD maintain 266 the latest status received from the relay agent. The server can use 267 this state to match against subsequent notifications and only further 268 process if there is change in status. A relay agent could, for 269 reasons such as restart, fault-tolerant mode etc, send redundant 270 notifications and matching of status at the server will avoid 271 unnecessary processing and message exchanges. 273 6.1. Relay Forward 275 Upon receiving a RELAY-FORW message containing 276 OPTION_HOST_CONNECTIVITY, the server can send appropriate 277 configuration in the RELAY-REPLY response. The server MUST NOT 278 return this option in a RELAY-REPLY message. 280 6.2. Reconfigure Request 282 Upon receiving a RECONIFURE-REQUEST message containing an 283 OPTION_HOST_CONNECTIVITY option, the server MUST follow the mechanism 284 described in [RFC6977] to create and send Reconfigure message. The 285 server MUST NOT return this option in a RECONFIGURE-REPLY message. 287 7. Host Tracking 289 Relay Agents can actively keep track of all IPv4/IPv6 addresses and 290 associated lease times assigned to hosts via the respective DHCP 291 servers. Relay Agents can therefore detect transitions from single 292 to dual-stack and vice-versa efficiently. In addition to this 293 technique, relay agents closest to the client can detect transitions 294 using snooping mechanisms. Network devices today use mechanisms such 295 as ARP and NDP snooping (bindings learnt by snooping all NDP traffic, 296 NS, NA, RS, RA) to determine host characteristics such as IPv4/IPv6 - 297 MAC - DUID bindings. IPv4/IPv6 and MAC counters are also used to 298 determine host liveliness. 300 First hop devices that implement first hop security also track IP 301 address bindings and determine binding updates such as temporary 302 addresses, deprecated addresses, etc. Existing work such as 303 [I-D.ietf-savi-dhcp] and [I-D.levy-abegnoli-savi-plbt] also aim to 304 active current host bindings, all of which can be leveraged to track 305 host addresses. 307 These mechanisms help determine if a particular IP address family is 308 inactive, has reverted to using a single stack even though it 309 initially had dual-stack capabilities and detect active dual-stack 310 usage after long periods of single-stack activity. 312 Other techniques to track host connectivity can be envisaged. It is 313 out of scope of this document to provide an exhaustive list of host 314 tracking techniques. 316 8. Security Considerations 318 This document describes an application of the mechanism specified in 319 [RFC6977]. Host tracking mechanisms MUST be reliable. If a relay is 320 compromised, it may be used to force an uncompromised server abuse 321 clients by triggering repetitive reconfigurations. Security 322 considerations described in [RFC6977] are applicable to this 323 mechanism. 325 9. IANA Considerations 327 IANA is requested to assign the following new DHCPv6 Option Code in 328 the registry maintained in http://www.iana.org/assignments/ 329 dhcpv6-parameters: 331 o OPTION_HOST_CONNECTIVITY 333 10. References 334 10.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, March 1997. 339 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 340 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 342 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 343 "Default Address Selection for Internet Protocol Version 6 344 (IPv6)", RFC 6724, September 2012. 346 [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 347 Reconfiguration from Relay Agents", RFC 6977, July 2013. 349 10.2. Informative References 351 [I-D.ietf-savi-dhcp] 352 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 353 DHCP", draft-ietf-savi-dhcp-18 (work in progress), June 354 2013. 356 [I-D.levy-abegnoli-savi-plbt] 357 Levy-Abegnoli, E., "Preference Level based Binding Table", 358 draft-levy-abegnoli-savi-plbt-02 (work in progress), March 359 2010. 361 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 362 Address Translator (Traditional NAT)", RFC 3022, January 363 2001. 365 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 366 and M. Carney, "Dynamic Host Configuration Protocol for 367 IPv6 (DHCPv6)", RFC 3315, July 2003. 369 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 370 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 371 December 2003. 373 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 374 NAT64: Network Address and Protocol Translation from IPv6 375 Clients to IPv4 Servers", RFC 6146, April 2011. 377 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 378 Beijnum, "DNS64: DNS Extensions for Network Address 379 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 380 April 2011. 382 Authors' Addresses 384 Prashanth Patil 385 Cisco Systems, Inc. 386 Bangalore 387 India 389 Email: praspati@cisco.com 391 Mohamed Boucadair 392 France Telecom 393 Rennes 35000 394 France 396 Email: mohamed.boucadair@orange.com 398 Dan Wing 399 Cisco Systems, Inc. 400 170 West Tasman Drive 401 San Jose, California 95134 402 USA 404 Email: dwing@cisco.com 406 Tirumaleswar Reddy 407 Cisco Systems, Inc. 408 Cessna Business Park, Varthur Hobli 409 Sarjapur Marathalli Outer Ring Road 410 Bangalore, Karnataka 560103 411 India 413 Email: tireddy@cisco.com