idnits 2.17.1 draft-vandevelde-v6ops-pref-ps-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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 16, 2010) is 4994 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group G. Van de Velde 3 Internet-Draft C. Popoviciu 4 Intended status: Informational T. Hain 5 Expires: February 17, 2011 S. Venaas 6 Cisco Systems 7 k. Chittimaneni 8 Google Inc 9 August 16, 2010 11 Network signaling for IPv4/IPv6 protocol selection for end-systems 12 14 Abstract 16 Within an administrative realm, especially during an IPv6 17 implementation period, the network operator has interest to have 18 control on the IP protocol version (IPv4 or IPv6) used by the end 19 systems and network devices. This document provides a problem 20 statement about both protocol preference and protocol selection many 21 network operators face when implementing IPv6 in a controlled 22 process. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 17, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1. IPv6 deployment model . . . . . . . . . . . . . . . . . . . 4 73 2.2. Policy table . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Considerations for IPv4 and IPv6 selection on end-systems . . . 5 75 3.1. Dynamics of end-system configuration . . . . . . . . . . . 5 76 3.2. Hosts with multiple interfaces . . . . . . . . . . . . . . 5 77 3.3. Backward compatibility . . . . . . . . . . . . . . . . . . 5 78 3.4. Network based learning . . . . . . . . . . . . . . . . . . 5 79 3.5. Impact on RFC3484 . . . . . . . . . . . . . . . . . . . . . 6 80 3.6. Influence of IPv4/IPv6 protocol preference on 81 applications . . . . . . . . . . . . . . . . . . . . . . . 6 82 3.7. Dynamic tunneling . . . . . . . . . . . . . . . . . . . . . 6 83 4. Considerations for IPv4 and IPv6 selection on network 84 infrastructure elements . . . . . . . . . . . . . . . . . . . . 6 85 4.1. Signaling IPv4/IPv6 preference . . . . . . . . . . . . . . 6 86 4.2. Influence of IPv4/IPv6 preference on network 87 infrastructure elements . . . . . . . . . . . . . . . . . . 7 88 4.3. IPv4/IPv6 policy table location . . . . . . . . . . . . . . 7 89 4.4. Backward compatibility . . . . . . . . . . . . . . . . . . 7 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 92 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 98 1. Introduction 100 With IPv6 TCP/IP stacks preferring IPv6 over IPv4 for forwarding, 101 network administrators don't have control over which protocol end 102 hosts use. Such lack of control has the potential to negatively 103 impact the end host, especially in cases where the network is dual 104 stacked well before the backend systems and/or applications are. It 105 is thus preferable to have control over the device preference or 106 selection of IP4 or IPv6. This control will allow network 107 administrators to seamlessly implement IPv6 on the network with the 108 ability to carefully integrate IPv6 into production as and when all 109 other critical non-network components are found to be working as 110 expected. 112 This document describes a problem statement to control and 113 potentially communicate the IPv4/IPv6 protocol preference for 114 devices. The document outlays the various considerations for 115 protocol preference selection. This capability improves the ability 116 of hosts to pick an appropriate protocol (IPv4 or IPv6) for off-link 117 and on-link destinations. 119 Note that this procedure is applicable to end-systems and their 120 applications only; the forwarding algorithm used by routers is not 121 affected. 123 2. Components 125 2.1. IPv6 deployment model 127 When a network operator is in process of deploying a new technology 128 on the network, the network operator will likely include a set of 129 fallback mechanisms and will try to place as much control as possible 130 in each of the deployment steps. An element of control during the 131 integration of IPv6 is the management of IPv6 use by the end-systems 132 and the applications running on those systems. The protocol 133 preference management is done thorough a signaling mechanism. This 134 signaling allows the network operator to introduce IPv6 on the 135 routers and other network infrastructure elements without impacting 136 existing IPv4 behavior of the end-systems. Once the network operator 137 decides to activate IPv6 for end-systems, in order to allow each end- 138 system to include IPv6 as valid communication protocol following 139 RFC3484 address selection. 141 This operational sequence will help the enablement of IPv6 in a 142 controlled manner once the network infrastructure is found correctly 143 working according the expectations of the network operator. 145 2.2. Policy table 147 The policy table references to an information database defining the 148 expected behavior regarding IPv4/IPv6 protocol preference and 149 selection behavior for various parts of the administrative domain. 151 3. Considerations for IPv4 and IPv6 selection on end-systems 153 This section will detail considerations for an end-system with 154 respect to IPv4/IPv6 protocol preference. 156 3.1. Dynamics of end-system configuration 158 An end-system is usually configured in three possible ways: 160 (a) Preset configuration: these end-systems have a configuration 161 which has been defined during the manufacturing of the device; (b) 162 Manual configuration: In this case the end-systems are configured by 163 a set of parameters and settings which are individually configured on 164 the device through human interaction; (c) Dynamic configuration: Some 165 end-systems download through the network infrastructure a set of 166 parameters i.e. IP and DNS addresses through DHCP 168 3.2. Hosts with multiple interfaces 170 Lots of end-systems are connected to the network infrastructure with 171 only a single interface. For these systems, the IPv4 and IPv6 172 preference can be quite simply defined, either using or not-using 173 IPv6. However, there are many end-systems connected through two or 174 more interfaces to the network infrastructure. These systems require 175 a protocol preference to be defined for each interface independently. 176 These additional considerations also include aspects of conflicting 177 information received through the different interfaces regarding the 178 IPv6 protocol preference. 180 3.3. Backward compatibility 182 A solution for the IPv4/IPv6 preference shouldn't have an impact on 183 end-systems not capable to understand this functionality. 185 3.4. Network based learning 187 The IPv4/IPv6 protocol preference on an end-system should be signaled 188 by the 'network' (network devices or other infrastructure components 189 such as DHCP) to automate the end-systems behavior, however the IP4/ 190 IPv6 protocol preference solution should not exclude manual 191 configuration on end-systems. 193 3.5. Impact on RFC3484 195 A solution for IPv4/IPv6 protocol preference may influence the 196 availability or better the non-availability of IPv6 parameters within 197 the RFC3484 end-system address selection algorithm. This influence 198 must be understood very clearly for end-systems with single and with 199 multiple interfaces attached to the network infrastructure. 201 3.6. Influence of IPv4/IPv6 protocol preference on applications 203 The IPv4/IPv6 protocol preference should be propagated by the end- 204 system towards the applications running on the end-system. It should 205 not be excluded that a protocol preference solution may have more 206 specific information per application of importance to the end- 207 systems. As consequence the end system could use this information 208 for IPv4/IPv6 protocol preference per application or session for 209 example. 211 3.7. Dynamic tunneling 213 Some end systems make usage of dynamic tunnels for IPv6 even when the 214 network infrastructure does not support IPv6 as a native protocol. 215 The IPv4/IPv6 preference signal could influence the creation of these 216 tunnels based upon the signaled IPv4/IPv6 protocol preference. 218 4. Considerations for IPv4 and IPv6 selection on network infrastructure 219 elements 221 This section will detail considerations for network infrastructure 222 devices with respect to IPv4/IPv6 protocol preference. 224 4.1. Signaling IPv4/IPv6 preference 226 The IPv4/IPv6 preference signal can be sent by four methods. 228 (a) The end-system is configured during manufacturing of the system; 229 (b) A network operator configures the end-system by the console of 230 the end-system; (c) The network infrastructure could signal the end- 231 systems the IPv4/IPv6 preference through existing or new link-local 232 packets; (d) The network infrastructure signals the end-system that 233 there are elements that influence protocol selection, and that the 234 end-system may want to request the network infrastructure what these 235 elements exactly are. 237 4.2. Influence of IPv4/IPv6 preference on network infrastructure 238 elements 240 The IPv4/IPv6 preference selection should only have impact on the 241 end-systems and the network infrastructure devices should be ignoring 242 the preference signal. 244 4.3. IPv4/IPv6 policy table location 246 The IPv4/IPv6 protocol preference needs to be stored somewhere within 247 the network. This could be done either centrally or distributed. 248 Crucial is that the network infrastructure device is directly 249 connected to the end-system it wants to signal IPv4/IPv6 preference, 250 so that link-local communication between the end-system and the 251 network infrastructure device can be used. Between the network 252 infrastructure device and the policy table location non-link local 253 addresses may be utilized. 255 4.4. Backward compatibility 257 There should be no impact on either the network infrastructure when 258 end-systems do not understand the IPv4/IPv6 protocol preference 259 solution. 261 5. IANA Considerations 263 There are no extra IANA consideration for this document. 265 6. Security Considerations 267 7. Acknowledgements 269 8. References 271 8.1. Normative References 273 8.2. Informative References 274 Authors' Addresses 276 Gunter Van de Velde 277 Cisco Systems 278 De Kleetlaan 6a 279 Diegem 1831 280 Belgium 282 Phone: +32 476 476 022 283 Email: gvandeve@cisco.com 285 Ciprian Popoviciu 286 Cisco Systems 287 7025-6 Kit Creek Road 288 Research Triangle Park, North Carolina NC 27709-4987 289 United States 291 Phone: +1 919 392-3723 292 Email: cpopovic@cisco.com 294 Tony Hain 295 Cisco Systems 296 500 108th Ave. NE 297 Bellevue, Wa. 298 USA 300 Email: alh-ietf@tndh.net 302 Stig Venaas 303 Cisco Systems 304 Tasman Drive 305 San Jose, CA 95134 306 USA 308 Phone: 309 Email: stig@cisco.com 310 Kiran Kumar Chittimaneni 311 Google Inc 312 1600 Amphitheatre Parkway 313 Mountain View, CA 94043 314 USA 316 Phone: +1 650 253 6185 317 Email: kk@google.com