idnits 2.17.1 draft-ietf-dhc-conn-status-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 4, 2014) is 3732 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 339, but no explicit reference was found in the text == Unused Reference: 'RFC3646' is defined on line 362, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-18 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: August 8, 2014 France Telecom 6 D. Wing 7 T. Reddy 8 Cisco 9 February 4, 2014 11 IP Connectivity Status Notifications for DHCPv6 12 draft-ietf-dhc-conn-status-00 14 Abstract 16 This specification extends DHCPv6 so that a DHCPv6 Relay Agent can 17 dynamically inform the DHCPv6 server about the IP connectivity status 18 of a host. The IP connectivity status information is also triggered 19 by any change in the connectivity as provided to the host. The 20 DHCPv6 server uses this information as an input to its decision- 21 making about configuration parameters to be 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 August 8, 2014. 40 Copyright Notice 42 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Reconfigure Request . . . . . . . . . . . . . . . . . . . 6 64 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 6 65 6.1. Relay Forward . . . . . . . . . . . . . . . . . . . . . . 7 66 6.2. Reconfigure Request . . . . . . . . . . . . . . . . . . . 7 67 7. Host Tracking . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 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. The network infrastructure 82 is usually well equipped to be aware of the connectivty delivered to 83 connected hosts. The network can also track and detect transitions 84 from single to dual-stack or vice-versa. 86 This document specifies a DHCPv6 extension for relay agents to 87 indicate status of hosts connectivity to remote DHCPv6 servers. The 88 information passed by a relay is generic and a DHCPv6 server can 89 interpret and process this information to make a more informed 90 decision on the configuration parameters that a client is to receive. 92 The DHCPv6 server can either be configured or have built-in logic to 93 use this information as desired, which is outside the scope of this 94 document. 96 Section 3 describes a typical problem that can be solved owing to the 97 mechanism described in this specification. A DHCPv6 server 98 prioritizes the DNS servers to be sent back to a requesting client 99 based on host connectivity characteristics provided by the DHCPv6 100 relay agent. 102 While the host stack can be upgraded to send this information to the 103 DHCPv6 server on its own, a generalized upgrade of all DHCPv6 client 104 implementations on all operating systems is extremely difficult. 106 [DISCUSSION NOTE: A companion solution could be to define a 107 container that can be used to return per-AF specific configuration 108 parameters to the client. In such a scheme, the server blindly 109 returns all pieces of configuration and it is up to the client to 110 make use of the appropriate set of parameters according to its 111 available connectivity. This alternative assumes an update at the 112 dhcp client's side. This approach can be seen as complimentary to 113 the one defined in this specification. The document will be 114 updated to reflect consensus of the WG on whether the additional 115 option is to be specified.] 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 Dual-Stack host: Denotes a host that is configured with both an IPv4 124 address and IPv6 prefix and is reachable using both IPv4 and IPv6 125 connectivity. 127 3. Problem Statement: Focus on DNS Reconfiguration 129 Default address selection rules specified in [RFC6724] prefers IPv6 130 over IPv4. If a dual-stack host is configured to use a DNS64 server 131 [RFC6147], it will send its DNS queries to that DNS64 server which 132 will synthesize a AAAA response if no A records are found. Thus, a 133 dual-stack host will always use IPv6 if a DNS lookup was involved, 134 even if IPv4 could have been used more optimally. 136 In some deployments, if NAT44 [RFC3022] and NAT64 [RFC6146] are 137 deployed within the same network, it is preferable to use NAT44 over 138 NAT64 because of scale, performance and application incompatibility 139 issues (e.g., FTP) [RFC6384]. At the same time, native IPv6 can 140 still be preferred over IPv4. 142 A DHCPv6 relay agent can observe host characteristics on a network to 143 determine if a host is IPv4-only, dual-stack, or IPv6-only and also 144 detect transitions from single to dual-stack or vice-versa. This 145 information can be used by the DHCPv6 relay agent to influence the 146 DHCPv6 server to send appropriately prioritized DNS Servers to the 147 client. The DHCPv6 server can implement the following based on 148 connectivity information received from the DHCPv6 relay agent. 150 o IPv6-only transition to Dual-Stack: In case a host is IPv6-only, 151 it is provided with a DNS64 server. When transitioning to dual- 152 stack, an IPv4 DNS server is assigned as a consequence of 153 obtaining an IPv4 Address. The DHCPv6 relay agent can detect this 154 and send a RECONFIGURE_REQUEST message [RFC6977] to the DHCPv6 155 server indicating that the host needs to be provided with a 156 regular DNS server. In lieu of this mechanism, the host would 157 continue to use the DNS64 server until the host stack 158 reinitializes. 160 o Dual-Stack to IPv6-only: In case a host is dual-stack, it is 161 provided with a regular DNS server followed by DNS64 server. When 162 transitioning to IPv6-only, the DHCPv6 relay agent can detect this 163 change and send a RECONFIGURE_REQUEST message to the DHCPv6 server 164 indicating that the host needs to be assigned a DNS64 server only. 165 In lieu of this mechanism, the host would continue to use the 166 regular DNS Server which is inaccessible and eventually time out 167 to fail over to the DNS64 Server. The host will take additional 168 time to fully initialize causing delays in connection. 170 4. Host Connectivity Status Option 172 The option (Figure 1) includes an 8-bit status code that indicates 173 specific host connectivity characteristics. The option can be 174 included by a DHCPv6 relay agent in RELAY-FORW and RECONFIGURE- 175 REQUEST. 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | OPTION_HOST_CONNECTIVITY | option-len | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | status | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 option-code OPTION_HOST_CONNECTIVITY (TBA). 186 option-len 1. 187 status 8-bit field indicating IP family connectivity status 188 of a host. The following codes are defined: 189 +------+----------+ 190 | Bit | Status | 191 +----- +----------+ 192 | 1 | IPv4 | 193 | 2 | IPv6 | 194 | 3..8 | Reserved | 195 +------+----------+ 197 Figure 1: Relay Agent Host Connectivity Option message format 199 o IPv4 : The host that is configured with an IPv4 address and is 200 reachable using IPv4. 202 o IPv6 : The host that is configured with an IPv6 prefix and is 203 reachable using IPv6. 205 o If both bits are enabled, the host is dual-stack i.e the host that 206 is configured with both an IPv4 address and IPv6 prefix and is 207 reachable using both IPv4 and IPv6 connectivity. 209 5. DHCPv6 Relay Agent Behavior 211 DHCPv6 relay agents that implement this specification MUST be 212 configurable for tracking host connectivity and inserting the 213 OPTION_HOST_CONNECTIVITY option in RELAY-FORW and RECONFIGURE-REQUEST 214 messages. 216 To be able to notify details of hosts' connectivity, a DHCPv6 relay 217 agent must be able to track host connectivity. A DHCPv6 relay agent 218 can detect host connectivity type using mechanisms discussed in 219 Section 7. The DHCPv6 relay agent then includes this information in 220 the appropriate DHCPv6 message. 222 DHCPv6 relay agents need to maintain connectivity state of each host 223 it can track. This ensures that notifications to the DHCPv6 server, 224 especially DHCPv6 RECONFIGURE_REQUEST, are accurately sent when there 225 is a change in status. If a DHCPv6 relay agent loses state due to 226 some reason (e.g., during restart events), it will build state again 227 using the mechanisms described in Section 7 and then send appropriate 228 notifications to the server. Such notifications are redundant and a 229 DHCPv6 server can choose to ignore such redundant notifications from 230 the DHCPv6 relay agent. Redundant notifications are also possible 231 when DHCPv6 relay agents are deployed in fault tolerant mode. 233 5.1. Relay Forward 235 DHCPv6 relay agents that implement this specification MAY include the 236 option OPTION_HOST_CONNECTIVITY in the RELAY_FORW to indicate status 237 of host connectivity. 239 5.2. Reconfigure Request 241 DHCPv6 relay agents that implement this specification MUST be 242 configurable for sending the RECONFIGURE_REQUEST message. The DHCPv6 243 relay agent generates a Reconfigure-Request [RFC6977] anytime status 244 of host connectivity changes by including OPTION_HOST_CONNECTIVITY in 245 the request. 247 6. DHCPv6 Server Behavior 249 A DHCPv6 server that supports OPTION_HOST_CONNECTIVITY may either 250 have specific configuration or built-in logic to process information 251 available in the option and send configuration parameters in DHCPv6 252 responses. How the server consumes and acts on the information 253 obtained in the option is outside the scope of this document. 255 The DHCPv6 server may use this connectivity information, if 256 available, in addition to other DHCPv6 relay agent option data, other 257 options included in the DHCPv6 client messages, server configuration, 258 and physical network topology information in order to assign 259 appropriate configuration to the client. 261 The server MUST ignore the option if it doesn't recognize the status 262 in the OPTION_HOST_CONNECTIVITY option. The server SHOULD maintain 263 the latest status received from the DHCPv6 relay agent. The server 264 can use this state to match against subsequent notifications and only 265 further process if there is change in status. A DHCPv6 relay agent 266 could, for reasons such as restart, fault-tolerant mode etc, send 267 redundant notifications and matching of status at the server will 268 avoid unnecessary processing and message exchanges. 270 6.1. Relay Forward 272 Upon receiving a RELAY-FORW message containing 273 OPTION_HOST_CONNECTIVITY, the server can send appropriate 274 configuration in the RELAY-REPLY response. The server MUST NOT 275 return this option in a RELAY-REPLY message. 277 6.2. Reconfigure Request 279 Upon receiving a RECONIFURE-REQUEST message containing an 280 OPTION_HOST_CONNECTIVITY option, the server MUST follow the mechanism 281 described in [RFC6977] to create and send Reconfigure message. The 282 server MUST NOT return this option in a RECONFIGURE-REPLY message. 284 7. Host Tracking 286 DHCPv6 relay agents can actively keep track of all IPv4/IPv6 287 addresses and associated lease times assigned to hosts via the 288 respective DHCP servers. DHCPv6 relay agents can therefore detect 289 transitions from single to dual-stack and vice-versa efficiently. In 290 addition to this technique, DHCPv6 relay agents closest to the client 291 can detect transitions using snooping mechanisms. Network devices 292 today use mechanisms such as ARP and NDP snooping (bindings learnt by 293 snooping all NDP traffic, NS, NA, RS, RA) to determine host 294 characteristics such as IPv4/IPv6 - MAC - DUID bindings. IPv4/IPv6 295 and MAC counters are also used to determine host liveliness. 297 First hop devices that implement first hop security features can also 298 track IP address bindings and determine binding updates such as 299 temporary addresses, deprecated addresses, etc. Existing work such 300 as [I-D.ietf-savi-dhcp] and [I-D.levy-abegnoli-savi-plbt] also aim to 301 active current host bindings, all of which can be leveraged to track 302 host addresses. 304 These mechanisms help determine if a particular IP address family is 305 inactive, has reverted to using a single stack even though it 306 initially had dual-stack capabilities and detect active dual-stack 307 usage after long periods of single-stack activity. 309 Other techniques to track host connectivity can be envisaged. It is 310 out of scope of this document to provide an exhaustive list of host 311 tracking techniques. 313 8. Security Considerations 315 This document describes an application of the mechanism specified in 316 [RFC6977]. 318 Host tracking mechanisms MUST be reliable. If a DHCPv6 relay agent 319 is compromised, it may be used to force an uncompromised DHCPv6 320 server abuse DHCPv6 clients by triggering repetitive 321 reconfigurations. Security considerations described in [RFC6977] are 322 applicable to this specification. 324 9. IANA Considerations 326 IANA is requested to assign the following new DHCPv6 Option Code in 327 the registry maintained in http://www.iana.org/assignments/ 328 dhcpv6-parameters: 330 o OPTION_HOST_CONNECTIVITY 332 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 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 340 and M. Carney, "Dynamic Host Configuration Protocol for 341 IPv6 (DHCPv6)", RFC 3315, July 2003. 343 [RFC6977] Boucadair, M. and X. Pougnard, "Triggering DHCPv6 344 Reconfiguration from Relay Agents", RFC 6977, July 2013. 346 10.2. Informative References 348 [I-D.ietf-savi-dhcp] 349 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 350 DHCP", draft-ietf-savi-dhcp-18 (work in progress), June 351 2013. 353 [I-D.levy-abegnoli-savi-plbt] 354 Levy-Abegnoli, E., "Preference Level based Binding Table", 355 draft-levy-abegnoli-savi-plbt-02 (work in progress), March 356 2010. 358 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 359 Address Translator (Traditional NAT)", RFC 3022, January 360 2001. 362 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 363 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 364 December 2003. 366 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 367 NAT64: Network Address and Protocol Translation from IPv6 368 Clients to IPv4 Servers", RFC 6146, April 2011. 370 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 371 Beijnum, "DNS64: DNS Extensions for Network Address 372 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 373 April 2011. 375 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 376 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 378 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 379 "Default Address Selection for Internet Protocol Version 6 380 (IPv6)", RFC 6724, September 2012. 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 405 Tirumaleswar Reddy 406 Cisco Systems, Inc. 407 Cessna Business Park, Varthur Hobli 408 Sarjapur Marathalli Outer Ring Road 409 Bangalore, Karnataka 560103 410 India 412 Email: tireddy@cisco.com