idnits 2.17.00 (12 Aug 2021) /tmp/idnits25325/draft-vandevelde-v6ops-harmful-tunnels-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4380], [RFC3056]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 31, 2010) is 4274 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4798' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC5214' is defined on line 381, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 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 O. Troan 4 Intended status: Informational Cisco Systems 5 Expires: March 4, 2011 T. Chown 6 University of Southampton 7 August 31, 2010 9 Non-Managed IPv6 Tunnels considered Harmful 10 12 Abstract 14 IPv6 is ongoing and natively being deployed by a growing community 15 and it is important that the quality perception and traffic flows are 16 as optimal as possible. Ideally it would be as good as the IPv4 17 perceptive experience. 19 This paper looks into a set of transitional technologies where the 20 actual user has IPv6 connectivity through the means of IPv6-in-IPv4 21 tunnels. A subset of the available tunnels has the property of being 22 non-managed (i.e. 6to4 [RFC3056] and Teredo [RFC4380] ). 24 While native IPv6 deployments will keep growing it is uncertain or 25 even expected that non-managed IPv6 tunnels will be providing the 26 same user experience and operational quality as managed tunnels or 27 native IPv6 connectivity. 29 This paper will detail some considerations around non-managed tunnels 30 and will document the harmful element of these for the future growth 31 of networks and the Internet. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 4, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Managed Tunnelling Properties . . . . . . . . . . . . . . . . 4 81 3. Tunnel User Experience Views . . . . . . . . . . . . . . . . . 5 82 4. Why do non-managed tunnels exist? . . . . . . . . . . . . . . 5 83 5. Non-Managed Tunnelling Properties . . . . . . . . . . . . . . 6 84 5.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 6 85 5.2. Topological Considerations . . . . . . . . . . . . . . . . 7 86 5.3. Operational Provisioning . . . . . . . . . . . . . . . . . 7 87 5.4. Operational Troubleshooting . . . . . . . . . . . . . . . 7 88 5.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 5.6. Content Services . . . . . . . . . . . . . . . . . . . . . 8 90 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 99 1. Introduction 101 While the Internet and networks continue to grow, it is found that 102 the deployment of IPv6 within these networks is an ongoing activity 103 due to global IPv4 address pool depletion. An important aspect is 104 that the quality, availability and security of the IPv6 connectivity 105 is as good as possible, and when possible even more advanced as the 106 IPv4 connectivity. 108 Historically IETF has been facilitating a variety of technologies and 109 procedures to deploy IPv6 successfully in addition to existing IPv4 110 connectivity. In general and for the sake of this draft these 111 procedures and technologies can be divided into three major groups: 112 (1) native (dual-stack) IPv6, (2) Tunnelled IPv6 and (3) Translation. 113 While native IPv6 deployments has been steadily growing, the value 114 and the drawbacks of some tunnelling mechanisms can be investigated. 115 Translational techniques provide a total different aspect of 116 considerations and applicability and is beyond the scope of this 117 paper. Transition techniques have been and still are in many cases 118 important for the bootstrapping of IPv6, this paper will look into a 119 range of property aspects of non-managed IPv6 tunnelling techniques. 120 Areas of perverse traffic paths, security considerations, lack of 121 business incentives to run tunnel relays/gateways, black holing and 122 ownership of supportability will be analysed. Finally the paper will 123 conclude that for the growth of IP connectivity, non-managed 124 tunnelling techniques are considered harmful especially for those 125 that want to access applications over the network through pervasive 126 IPv6 connectivityand have no particular interrest on how connectivity 127 to the applications is established (IPv4, translation, IPv6, etc...) 129 2. Managed Tunnelling Properties 131 A managed tunnel is a tunnel has a few properties supporting the 132 ownership and quality of the tunnel. 134 When using a managed service, there tends to be an administrative 135 entity which provides quality assurance and can take action if users 136 of the service are experiencing a degraded service. An example would 137 be 6rd tunnels [RFC5969] 139 In addition there is a general trust awareness and agreement between 140 the user of the managed tunnel service and the provider of the 141 managed tunnel service. 143 3. Tunnel User Experience Views 145 The tunnel experience can be divided into three distinct segments: 146 (1) the End-user view, (2) the Enterprise View and (3) the Service 147 Provider View. 149 The End-user view exists mainly out of two different user profiles. 150 The technical power user and the general user mainly trying to reach 151 their favourite application on the network. The technical power user 152 may have a particular interrest to run IPv6 as a transport mechanism, 153 and if his upstream service provider has no native IPv6 connectivity 154 available, then non-managed tunneling mechanisms may provide a 155 solution satisfying to the immediate needs of the technical power 156 user. Alternatively, the general user trying to reach his favourite 157 network application, may have no interest or awareness of his IPv6 158 usage, particulary when non-managed tunnels are utilized. 160 The Enterprise View is a more traffic flows and network oriented 161 possitioning. When the upstream service provider does not have an 162 IPv6 offer, then the enterprise may start to rely upon a technology 163 as 6to4 [RFC3056]. However this technology has the potential of 164 creating quite perverse traffic paths when user want to reach 165 applications on the Internet. When user would like to reach other 166 6to4 [RFC3056] users, then more optimized traffic paths, generally 167 following the IPv4 traffic paths are realized 169 The final view is how a Internet service provider looks into non- 170 managed tunnel usage. A service provider may decide to deploy a 6to4 171 relay to increase the IPv6 quality of their customers. This a 172 service which require resources (money, maintenance, etc...). Often 173 the 6to4 relay service is not just (always) restricted to only the 174 service providers customers, which as result provides often results 175 in a demotivation to provide quality tunnel relay devices. From a 176 content service provider perspective the usage of non-managed tunnel 177 often results in measurable differences in RTT and reliability in 178 some cases, and hence are reluctant to bring all services to 179 mainstream IPv6 for all users 'just yet'. 181 4. Why do non-managed tunnels exist? 183 Non-managed tunnels exist due to a variety of reasons. 185 Early adopters: people and organisations with a desire to use new and 186 potentially market disrupting technologies and applications may have 187 a desire to use the latest IP even when the upstream provider doesn't 188 have an available service offering. 190 Lock-step process to implement IPv6: It is not trivial to move a 191 system or an organisation in lock-step towards IPv6 and the aid of 192 tunnels help in this process. 194 The utilisation of tunnels aid in providing a de-coupling between 195 infrastructure readiness and application readiness, and hence 196 contribute to the development of both elements. 198 5. Non-Managed Tunnelling Properties 200 The properties of Non-managed tunnels span many different areas. In 201 this section the properties are analysed and segmented within 202 different areas of impact. In each case the comparison is made 203 between native IPv6 connectivity and connectivity through a non- 204 managed tunnel. A common property of non-managed tunnels is that 205 they often use well-known anycast addresses or other well known 206 addresses and anticipate upon the goodwill of middleware (typically a 207 relay or gateway) device to serve as a tunnel termination point. In 208 some cases, for example a 6to4 relay can be provided by a connected 209 responsible service provider, and hence good quality operation can be 210 guaranteed. 212 Non-managed tunnels often have asymmetric behaviour. There is an 213 outbound and an inbound connectivity behaviour from the tunnel 214 initiator. It is possible to influence the good quality tunnel 215 behaviour of the outbound connectivity (e.g. by explicit setting of 216 the 6to4 relay), however, influencing good inbound connectivity is 217 often an issue. 219 5.1. Performance 221 Deploying a tunnelling mechanism mostly results in encapsulation and 222 de-capsulation efforts. Often this activity has a performance impact 223 on the device, especially when the device does not use hardware 224 acceleration for this functionality. If the performance impact is 225 scoped into the device its lifetime through performance capacity 226 management then the actual impact is predictive. Non-deterministic 227 tunnels tend to have a non-predictive behaviour for capacity, and 228 hence application and network performance is non-predictive. The key 229 reason for this is the decoupling of the capacity management of the 230 tunnel aggregation devices from the capacity desired by users of the 231 aggregation devices. 233 During initial IPv6 deployment there have been mainly technical savvy 234 people that have been using non-managed tunnel technologies and it 235 has for many been working well. However, if non-managed tunnelling 236 would be deployed in mass and especially when enabled by default by 237 CPE vendors or host vendors then those aggregation points could 238 become overloaded and result in bad performance. There are a few 239 measures that can be taken, i.e. upgrade the CPU power of the 240 aggregation device or its bandwidth available, however this may not 241 happen without the right motivation for the operator of the 242 aggregation device (i.e. cash flows, reputation, competitive reasons, 243 etc... ). 245 5.2. Topological Considerations 247 Due to non-managed IPv6 tunnels the traffic flows may result in sub- 248 optimal flows through the network topology between two communicating 249 devices. The impact for example can cause increase of the RTT and 250 packet loss, especially considering the availability (or better non- 251 availability) of tunnel aggregation/de-aggregation points of certain 252 topological areas or realms. The increase of non-managed tunnel 253 usage would amplify the negative impact on good quality connectivity. 254 For many operators of tunnel aggregation/de-aggregation devices there 255 is little motivation to increase the quality and number of available 256 devices within a topological area or logistical realm. 258 5.3. Operational Provisioning 260 Some elements regarding provisioning of both managed and non-managed 261 tunnels can be controlled, while others are beyond control or 262 influence of people and applications using tunnels. To make 263 applications highly reliable and performing, all elements within the 264 traffic path must provide an expected quality service and 265 performance. For managed tunnels, the user or provider of the tunnel 266 can exercise a degree of operational management and hence influence 267 good quality behaviour upon the tunnel especially upon the 268 aggregation and de-aggregation devices. In some cases even the 269 traffic path between both aggregation and de-aggregation can be 270 controlled. Non-managed tunnels however have less good quality 271 behaviour of both tunnel aggregation and de-aggregation devices 272 because often good quality behaviour is beyond the control or 273 influence of the tunnel user. For non-managed tunnels the tunnel 274 aggregator and/or tunnel de-aggregator are operated by a 3rd party 275 which may have a conflicting interest with the user of the non- 276 managed tunnel. An exception is where the use of the tunnel 277 mechanism is all within one ISP, or ISPs who are 'well coupled', e.g. 278 as happens between many NRENs. 280 5.4. Operational Troubleshooting 282 When one is using non-managed tunnels, then these tunnels may get 283 aggregated or de-aggregated by a 3rd party or a device outside the 284 control of a contracted service provider. Troubleshooting these 285 devices these devices will be pretty hard for the tunnel user or to 286 work around the issue. 288 Also some tools like traceroute don't work too well on asymmetric 289 paths. Another aspect is that tunnels show as one hop in a 290 traceroute, not indicating where problems may be. 292 5.5. Security 294 For an aggregating or de-aggregating tunnel device it is a non- 295 trivial issue to separate the valid traffic from non-valid traffic 296 because it is from the aggregation device perspective almost 297 impossible to know -from- and -towards- about the tunnel traffic. 298 This imposes potential attacks on the available resources of the 299 aggregating/de-aggregating router. A detailed security analysis for 300 6to4 tunnels can be found in [RFC3964]. 302 For the user of the non-managed IPv6 tunnel there is an underlying 303 trust that the aggregating/de-aggregating device is a trustworthy 304 device. However, some of the devices used are run by anonymous 3rd 305 parties outside the trusted infrastructure from the user perspective, 306 which is not an ideal situation. The usage of non-managed tunnels 307 increases the risk of rogue aggregation/de-aggregation devices and 308 may be open to malicious packet analyses or manipulation. 310 From the operator perspective, managing the aggregating/ 311 de-aggregating tunnel device, there is a trust assumption that no-one 312 abuses the service. Abuse may impact preset or assumed service 313 quality levels, and hence the quality provided can be impacted 315 There is also an impact caused by ipv4 firewalling upon non-managed 316 tunnels. Common firewall policies recommend to block tunnels, 317 especially non-managed tunnels, because there is no trust that the 318 traffic within the tunnel is not of mallicious intend. This 319 restricts the applicability of some non-managed tunnel mechanisms 320 (e.g. 6to4). Other tunnel mechanisms have found manners to avoid 321 traditional firewall filtering (e.g. Teredo) and open the local 322 network infrastructure for mallicious influence (e.g. virus, worms, 323 infrastructure attacs, etc..). 325 5.6. Content Services 327 When providing content services a very important related aspect is 328 that these services are accessible with high reliability, are 329 trustworthy and have a high performance. Using non-managed tunnels 330 makes this a much harder equation and can result in all three 331 elements to suffer negatively, without the ability to uniquely 332 identify and resolve the root cause. The statistical impact of non- 333 mnaged tunnels has been measured by some Internet Content providers 334 and is often an additional delay of O(100msec) (need to add reference 335 here) 337 This reduces the interest of content providers to provide content 338 services over IPv6 when non-managed tunnels are used. 340 6. Conclusion 342 Non-managed tunnels have properties impacting the growth of networks 343 and the Internet in a negative way. Consequences regarding black- 344 holing, perverse traffic paths, lack of business incentive and 345 operational management influence and security issues are a real 346 pragmatic concern, while universal supportability for the tunnel 347 relay services appear to be non-trivial. Due to these elements the 348 usage of non-managed tunnelling can be considered harmful for the 349 growth of networks and the Internet. 351 7. IANA Considerations 353 There are no extra IANA consideration for this document. 355 8. Security Considerations 357 There are no extra Security consideration for this document. 359 9. Acknowledgements 361 10. References 363 10.1. Normative References 365 10.2. Informative References 367 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 368 via IPv4 Clouds", RFC 3056, February 2001. 370 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 371 6to4", RFC 3964, December 2004. 373 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 374 Network Address Translations (NATs)", RFC 4380, 375 February 2006. 377 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 378 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 379 Provider Edge Routers (6PE)", RFC 4798, February 2007. 381 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 382 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 383 March 2008. 385 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 386 Infrastructures (6rd) -- Protocol Specification", 387 RFC 5969, August 2010. 389 Authors' Addresses 391 Gunter Van de Velde 392 Cisco Systems 393 De Kleetlaan 6a 394 Diegem 1831 395 Belgium 397 Phone: +32 2704 5473 398 Email: gvandeve@cisco.com 400 Ole Troan 401 Cisco Systems 402 Folldalslia 17B 403 Bergen N-5239 404 Norway 406 Phone: +47 917 38519 407 Email: ot@cisco.com 409 Tim Chown 410 University of Southampton 411 Highfield 412 Southampton, SO17 1BJ 413 United Kingdom 415 Phone: +44 23 8059 3257 416 Email: tjc@ecs.soton.ac.uk