idnits 2.17.1 draft-wing-behave-dhcpv6-reconfigure-01.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 (October 31, 2011) is 4561 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: 'I-D.wing-behave-dns64-config' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC5007' is defined on line 397, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE Working Group D. Wing 3 Internet-Draft T. Reddy 4 Intended status: Standards Track P. Patil 5 Expires: May 3, 2012 Cisco 6 October 31, 2011 8 DHCPv6 Dynamic Re-Configuration 9 draft-wing-behave-dhcpv6-reconfigure-01 11 Abstract 13 Some networks are expected to support IPv4-only, dual-stack, and 14 IPV6-only hosts at the same time. This makes prioritizing the DNS 15 servers for hosts tricky due to a heterogeneous mix of protocol 16 stacks causing optimal behavior to occur only when the host stack re- 17 initializes. The networks infrastructure is usually well equipped to 18 be aware of single/dual-stack nature of hosts. This specification 19 extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically 20 influence the priority of DNS servers provided to the host, so that 21 the host can use the optimal DNS server for resolution. 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 May 3, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Message . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Relay Reconfigure option . . . . . . . . . . . . . . . . . 5 63 5. DHCPv6 Relay Agent Behaviour . . . . . . . . . . . . . . . . . 7 64 6. DHCPv6 Server Behaviour . . . . . . . . . . . . . . . . . . . 7 65 7. Host Tracking . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 The default address selection rules [RFC3484] prefers IPv6 over IPv4. 76 If a dual-stack host is configured to use a DNS64 server, that DNS64 77 server will synthesize a AAAA response if there is an A record. 78 Thus, the dual-stack host will always use IPv6 if a DNS lookup was 79 involved, even if IPv4 could have been used more optimally. If NAT44 80 and NAT64 are deployed on the same network, , it is preferable to use 81 NAT44 over NAT64 because of scale, performance and application 82 incompatibility issues (e.g., FTP) [RFC6384]. At the same time, 83 native IPv6 can still be preferred over IPv4. The DHCPv6 Relay Agent 84 can observe host characteristics on a network to determine if the 85 host is IPV4-only, dual-stack or IPV6-only and also determine 86 transitions from single to dual-stack or vice-versa. In this 87 document we propose a specification that allows the DHCPv6 Relay 88 Agent to influence the DHCPv6 Server to send appropriately 89 prioritized DNS Servers to the client as per host characteristics. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 'normal' DNS server : DNS server using an IPv4-mapped IPv6 address 98 (that is, an IPv6 address starting with ::ffff:/96 IPv4-mapped 99 prefix). Hosts can communicate with 'normal' DNS server only using 100 IPv4 packets [RFC6052], section 4.2. 102 DNS64 server : DNS server using a normal IPv6 address and synthesizes 103 AAAA records from A records [RFC6147] 105 3. Mechanism 107 This document describes a new DHCPv6 Message and Option that is to be 108 used by the DHCPv6 Relay Agent to indicate to the DHCPv6 Server of 109 the priority of DNS servers to be provided to the specified host. 110 The DHCPv6 Server then sends a Reconfigure message to the host 111 providing updated/re-ordered DNS server list as suggested by the 112 Relay Agent. The idea is for the DHCPv6 Relay Agent to dynamically 113 send the reconfigure message based on host characteristics. 115 1. *IPv6-only transition to Dual-Stack* In case a host is IPv6-only 116 to start off, it is provided a DNS64 Server. When transitioning 117 to dual-stack, a IPv4 DNS Server is assigned as a consequence of 118 obtaining an IPv4 Address. The DHCPv6 Relay Agent can detect 119 this and send RELAY-RECONFIG message Section 4.1 to the DHCPv6 120 Server indicating that the host needs to be needs to be provided 121 with "normal" DNS Server followed by DNS64 server. In lieu of 122 this mechanism, the host would continue to use the DNS64 server 123 until the host stack Re-initializes. 125 2. *Dual-Stack to IPv6-only* In case a host is dual-stack, it is 126 provided with "normal" DNS followed by DNS64 server. When 127 transitioning to IPv6-only, the DHCPv6 Relay Agent can detect 128 this and send a RELAY-RECONFIG message to the DHCPv6 Server 129 indicating that the host needs to be assigned a DNS64 server 130 only. Without this, the host will continue to use the "normal" 131 DNS Server which is inaccessible and eventually time out to fail 132 over to the DNS64 Server. This means that the host will take 133 additional time to fully initialize causing delays in connection. 135 3. *IPv4-only transition to Dual-Stack* In case a host is IPv4-only 136 to start off, it is provided IPv4 DNS Server. When transitioning 137 to dual-Stack, DNS64 server is also provided as a consequence of 138 obtaining IPv6 address(s). The DHCPv6 Relay Agent can detect 139 this and send RELAY-RECONFIG message to the DHCPv6 Server 140 indicating that the host needs to be provided with "normal" DNS 141 Server followed by DNS64 server. 143 4. *Dual-Stack to IPv4-only* In case a host is dual-stack, it is 144 provided with "normal" DNS followed by DNS64 server. When 145 transitioning to IPv4-only, no change is required because the 146 host continues to use "normal" server. 148 4. Protocol overview 150 To realize the mechanism described above, this document extends the 151 DHCPv6 protocol allowing the DHCPv6 relay-agent to inform DHCPv6 152 server to initiate a reconfigure message with the client, resulting 153 in the client to initiate Renew/Reply or information-request/Reply 154 transaction with the server to receive updated/new configuration 155 information. 157 DHCPv6 Client DHCPv6 Relay Agent DHCPv6 Server 158 | | | 159 | |----------------------------->| 160 | | DHCPv6 Relay-supplied | 161 | | Reconfigure message | 162 | | | 163 | | | 164 |<--------------------------------------------------| 165 | | DHCPv6 Reconfigure | 166 | | | 167 |--------------------|----------------------------->| 168 | DHCPv6 Information-request | 169 | | | 170 |<--------------------------------------------------| 171 | DHCPv6 Reply | 172 | | | 174 Figure 1: Message Flow 176 4.1. Message 178 The RELAY-RECONFIG message uses the Client/Server message formats 179 described in [RFC3315], section 6. 181 RELAY-RECONFIG - A Relay Agent sends a RELAY-RECONFIG message to 182 DHCPv6 server so that server can update configuration information 183 based on the details in the Relay Reconfigure option. DHCPv6 server 184 will subsequently initiate Reconfigure message with the client to 185 propagate the new configuration information. 187 4.2. Relay Reconfigure option 189 The Relay Reconfigure option is used only in a RELAY-RECONFIG message 190 and identifies the query being performed. The option includes the 191 reconf-type, client-key and option(s) to provide data needed for the 192 DHCPv6 server to initiate Reconfigure message with the client. 194 The Relay Reconfigure option is defined below: 196 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | OPTION_RELAY_RECONF | option-len | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | reconf-type | client-key | Reserved | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | | 205 . . 206 . client-key-options . 207 . . 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Info-flags | Reserved1 | 210 ----------------------------------------------------------------- 212 Figure 2: Relay Reconfigure option message format 214 option-len: Length of the option. 216 reconf-type: 5 for Renew message, 11 for Information-request 217 message. 219 client-key: 8-bit unsigned integer. The client-key indicates the 220 key to identify the client. 222 client-key-options: 8-bit unsigned integer. This option can contain 223 either OPTION_IAADDR or OPTION_CLIENTID. The server identifies 224 the client either using IPv6 address assigned to the client using 225 OPTION_IAADDR option or using DHCP Unique Identifier (DUID) of the 226 client in OPTION_CLIENTID option [RFC3315]. 228 client-key values are defined below - 230 +------+-------------------------------- 231 |Value | Name | 232 +------+-------------------------------- 233 | 0x01 | IDENTIFY_CLIENT_BY_ADDRESS | 234 | 0x02 | IDENTIFY_CLIENT_BY_CLIENTID | 235 +------+-------------------------------- 237 Figure 3: client-key values 239 Info-flag values are defined below - 240 +------+-------------------------------- 241 |Value | Name | 242 +------+-------------------------------- 243 | 0x01 | IPV6_DNS64_SERV_ONLY | 244 | 0x02 | IPV6_HIG_PROI_NORM_SERV | 245 +------+-------------------------------- 247 Figure 4: Info-flag values 249 1: *IPV6_DNS64_DNS_SERV_ONLY* Provide only DNS64 address list to the 250 client. 252 2: *IPV6_HIG_PROI_NORM_SERV* Provide DNS address list in this order 253 to the client - first "normal" DNS servers, second DNS64 servers. 255 5. DHCPv6 Relay Agent Behaviour 257 Relay Agent and clients MUST discard any received RELAY-RECONFIG 258 messages. DHCPv6 relay agents that implement this specification MUST 259 be configurable for sending the RELAY-RECONFIG message. Relay agents 260 SHOULD have separate configuration for client-key in 261 OPTION_RELAY_RECONF option . The Relay Agent sets the "msg-type" 262 field to RELAY-RECONFIG. The Relay Agent generates a transaction ID 263 and inserts this value in the "transaction-id" field. The Relay 264 Agent MUST include OPTION_RELAY_RECONF option and set the reconf- 265 type, client-key, client-key-options accordingly. The Relay Agent 266 detects host characteristics using mechanisms discussed in Section 7. 267 For host transition from IPv6-only to dual-Stack or IPv4-only to 268 dual-stack Relay Agent will set Info-flags with 269 IPV6_HIG_PROI_NORM_SERV and for host transition from dual-stack to 270 IPv6 only Relay-Agent will set Info-flags with IPV6_DNS64_SERV_ONLY. 271 The Relay Reconfigure option is a general and extendable frame work 272 such that in future based on changes to host/network characteristics, 273 Relay agent can dynamically inform the DHCPv6 server to update the 274 host with other configuration information. 276 6. DHCPv6 Server Behaviour 278 Servers MUST discard any received RELAY-RECONFIG messages that meet 279 any of the following conditions : 281 o the message does not include OPTION_RELAY_RECONF option. 283 o DUID or IPv6 address in client-key-options does not match server 284 binding to identify the client. 286 Client will have to indicate with a Reconfigure Accept option in the 287 Solicit message that it will accept the Reconfigure message. Server 288 can have administrative policy that it will only respond to a client 289 willing to accept a Reconfigure message. If the client does not 290 indicate that it will accept Reconfigure message in the Solicit 291 message then the server will discard the Solicit Message. 293 Upon receiving RELAY-RECONFIG message containing the Relay 294 Reconfigure Option, the DHCPv6 server processing is described below 295 depending on the Info-flag values: 297 o *IPV6_DNS64_SERV_ONLY* The DHCPv6 server will select only IPv6 298 addresses list of DNS64 recursive name servers to be sent to the 299 client. The DHCPv6 server would send Reconfigure message to 300 inform the client that the server has updated configuration 301 information and then the client would initiate Information- 302 request/replay transaction with the server. The updated 303 configuration will now be sent as part of Information-request 304 reply by the DHCPv6 server. 306 o *IPV6_HIG_PROI_NORM_SERV* The DHCPv6 server will select DNS 307 servers in this order, first is the normal DNS servers and the 308 second is the DNS64 servers. The DHCPv6 server would send 309 Reconfigure message to the client to inform the client that the 310 server has updated configuration information and then the client 311 would initiate Information-request/replay transaction with the 312 server. The updated configuration will now be sent as part of 313 Information-request reply by the DHCPv6 server. The order of DNS 314 servers provided by option OPTION_DNS_SERVERS determines the 315 preference for use by the DNS client resolver [RFC3646] thus 316 ensuring higher priority for normal DNS server list followed by 317 DNS64 servers. 319 DHCPv6 server will use mechanism described [RFC3315], section 19.1 to 320 create and send Reconfigure message. 322 7. Host Tracking 324 Relay Agents can actively keep track of all IPv4/IPv6 addresses and 325 associated lease times assigned to hosts via the respective DHCP 326 servers. This enables Relay Agents to detect transitions from single 327 to dual-stack and vice-versa efficiently. In addition to this 328 technique, which is to be primarily used, transitions can also be 329 detected using snooping mechanisms. Network devices today use 330 mechanisms such as ARP and NDP snooping to determine host 331 characteristics such as IPv4/IPv6 - MAC bindings. IPv4/IPv6 and MAC 332 counters are also used to determine host liveliness. These 333 mechanisms help determine if a particular IP is inactive. Relay 334 Agents can leverage these to potentially detect IP address inactivity 335 to determine if a particular host has reverted to using a single 336 stack even though it initially had dual-stack capabilities. 337 Similarly, it can also detect active dual-stack usage after long 338 periods of single-stack activity. 340 8. Security Considerations 342 The RELAY-RECONFIG is exchanged only between the DHCPv6 relay agent 343 and DHCPv6 server, section 21.1 of [RFC3315] provides details on 344 securing DHCPv6 messages sent between servers and relay agents. And 345 section 23 of [RFC3315] provides general DHCPv6 security 346 considerations. 348 9. IANA Considerations 350 IANA is requested to assign new DHCPv6 Message types to RELAY- 351 RECONFIG from the msg-type space as defined in section "DHCP Message 352 Types" of [RFC3315]. IANA is requested to assign new option codes to 353 OPTION_RELAY_RECONF from the option-code space as defined in section 354 "DHCPv6 Options" of [RFC3315]. 356 10. References 358 10.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 364 and M. Carney, "Dynamic Host Configuration Protocol for 365 IPv6 (DHCPv6)", RFC 3315, July 2003. 367 [RFC3484] Draves, R., "Default Address Selection for Internet 368 Protocol version 6 (IPv6)", RFC 3484, February 2003. 370 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 371 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 372 December 2003. 374 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 375 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 376 October 2010. 378 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 379 Beijnum, "DNS64: DNS Extensions for Network Address 380 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 381 April 2011. 383 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 384 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 386 10.2. Informative References 388 [I-D.wing-behave-dns64-config] 389 Wing, D., "IPv6-only and Dual Stack Hosts on the Same 390 Network with DNS64", draft-wing-behave-dns64-config-03 391 (work in progress), February 2011. 393 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 394 Host Configuration Protocol (DHCP) version 6", RFC 3633, 395 December 2003. 397 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 398 "DHCPv6 Leasequery", RFC 5007, September 2007. 400 Authors' Addresses 402 Dan Wing 403 Cisco Systems, Inc. 404 170 West Tasman Drive 405 San Jose, California 95134 406 USA 408 Email: dwing@cisco.com 410 Tirumaleswar Reddy 411 Cisco Systems, Inc. 412 Cessna Business Park, Varthur Hobli 413 Sarjapur Marathalli Outer Ring Road 414 Bangalore, Karnataka 560103 415 India 417 Email: tireddy@cisco.com 418 Prashanth Patil 419 Cisco Systems, Inc. 420 Cessna Business Park, Varthur Hobli 421 Sarjapur Marthalli Outer Ring Road 422 Bangalore, Karnataka 560103 423 India 425 Email: praspati@cisco.com