idnits 2.17.1 draft-vandevelde-v6ops-harmful-tunnels-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (July 2, 2009) is 5411 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 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 O. Troan 4 Intended status: Informational Cisco Systems 5 Expires: January 3, 2010 T. Chown 6 University of Southampton 7 July 2, 2009 9 Non-Deterministic IPv6 Tunnels considered Harmful 10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 3, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 IPv6 is ongoing and natively being deployed by a growing community 59 and it is important that the quality perception and traffic flows are 60 as optimal as possible. Ideally it would be as good as the IPv4 61 perceptive experience. 63 This paper looks into a set of transitional technologies where the 64 actual user has IPv6 connectivity through the means of IPv6-in-IPv4 65 tunnels. A subset of the available tunnels has the property of being 66 non-deterministic (i.e. 6to4 [RFC3056] and Teredo [RFC4380] ) because 67 neither the egress path nor the ingress path is always fully 68 controlled. While native IPv6 deployments will keep growing it is 69 uncertain or even expected that these non-deterministic traffic flows 70 will be providing the same user experience and operational quality as 71 deterministic tunnels or native IPv6 connectivity. 73 This paper will detail some considerations around non-deterministic 74 tunnels and will document the harmful element of these for the future 75 growth of networks and the Internet. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2. Deterministic Tunnelling Properties . . . . . . . . . . . . . . 4 81 3. Non-deterministic Tunnelling Properties . . . . . . . . . . . . 4 82 3.1. Performance . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3.2. Topological Considerations . . . . . . . . . . . . . . . . 5 84 3.3. Operational Provisioning . . . . . . . . . . . . . . . . . 6 85 3.4. Operational Troubleshooting . . . . . . . . . . . . . . . . 6 86 3.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 3.6. Content Services . . . . . . . . . . . . . . . . . . . . . 7 88 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 91 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 92 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 94 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 97 1. Introduction 99 While the Internet and networks continue to grow, it is found that 100 the deployment of IPv6 within these networks is an ongoing activity 101 due to IPv4 available addresses depletion. An important aspect is 102 that the quality, availability and security of the IPv6 connectivity 103 is as good as possible, and when possible even more advanced as the 104 IPv4 connectivity. 106 Historically IETF has been facilitating a variety of technologies and 107 procedures to deploy IPv6 within Networks which have been running 108 IPv4 successfully. In general and for the sake of this draft they 109 can be divided into three major groups: (1) native (dual-stack) IPv6, 110 (2) Tunnelled IPv6 and (3) Translation. While native IPv6 111 deployments have been steadily growing, the value and the drawbacks 112 of some tunnelling mechanisms can be investigated. Translational 113 techniques provide a total different aspect of considerations and 114 applicability and is beyond the scope of this paper. While 115 transition techniques have been and still are in many cases important 116 for the bootstrapping of IPv6, this paper will look into a range of 117 property aspects of non-deterministic IPv6 tunnelling techniques. 118 Areas of perverse traffic paths, security considerations, lack of 119 business incentives to run tunnel relays/gateways, black holing and 120 ownership of supportability will be analysed. Finally the paper will 121 conclude that for the growth of IP connectivity, non-deterministic 122 tunnelling techniques are considered harmful especially for those 123 that want to access applications over the network in a reliable and 124 secure way and have no particular interest on how connectivity to the 125 applications is established (IPv4, translation, IPv6, etc...) 127 2. Deterministic Tunnelling Properties 129 A deterministic tunnel is a tunnel which has explicit tunnel 130 aggregation and de-aggregation points (i.e. ISATAP [RFC5214], manual 131 tunnels, 6rd [I-D.despres-6rd], IPv6 over MPLS [RFC4798], etc...). 132 An important aspect is also that the aggregation and de-aggregation 133 points are provided by a trusted party and hence have controlable 134 good quality and performance. 136 3. Non-deterministic Tunnelling Properties 138 The properties of Non-deterministic tunnels span many different 139 areas. In this section the properties are analysed and segmented 140 within different areas of impact. In each case the comparison is 141 made between native IPv6 connectivity and connectivity through a non- 142 deterministic tunnel. A common property of non-deterministic tunnels 143 is that they often use well-known anycast addresses or other well 144 known addresses and anticipate upon the goodwill of middleware 145 (typically a relay or gateway) device to serve as a tunnel 146 termination point. In some cases, for example a 6to4 relay can be 147 provided by a connected responsible service provider, and hence good 148 quality operation can be guaranteed. 150 Non-deterministic tunnels often have asymmetric behaviour. There is 151 an outbound and an inbound connectivity behaviour from the tunnel 152 initiator. It is possible to influence the good quality tunnel 153 behaviour of the outbound connectivity (e.g. by explicit setting of 154 the 6to4 relay), however, influencing good inbound connectivity is 155 often an issue. 157 3.1. Performance 159 Deploying a tunnelling mechanism mostly results in encapsulation and 160 de-capsulation efforts. Often this activity has a performance impact 161 on the device, especially when the device does not use hardware 162 acceleration for this functionality. If the performance impact is 163 scoped into the device its lifetime through performance capacity 164 management then the actual impact is predictive. Non-deterministic 165 tunnels tend to have a non-predictive behaviour for capacity, and 166 hence application and network performance is non-predictive. The key 167 reason for this is the decoupling of the capacity management of the 168 tunnel aggregation devices from the capacity desired by users of the 169 aggregation devices. 171 During initial IPv6 deployment there have been mainly technical savvy 172 people that have been using non-deterministic tunnel technologies and 173 it has for many been working well. However, if non-deterministic 174 tunnelling would be deployed in mass and especially when enabled by 175 default by CPE vendors or host vendors then those aggregation points 176 could become overloaded and result in bad performance. There are a 177 few measures that can be taken, i.e. upgrade the CPU power of the 178 aggregation device or its bandwidth available, however this may not 179 happen without the right motivation for the operator of the 180 aggregation device (i.e. cash flows, reputation, competitive reasons, 181 etc... ). 183 3.2. Topological Considerations 185 Due to non-deterministic IPv6 tunnels the traffic flows may result in 186 sub-optimal flows through the network topology between two 187 communicating devices. The impact for example can cause increase of 188 the RTT and packet loss, especially considering the availability (or 189 better non-availability) of tunnel aggregation/de-aggregation points 190 of certain topological areas or realms. The increase of non- 191 deterministic tunnel usage would amplify the negative impact on good 192 quality connectivity. For many operators of tunnel aggregation/ 193 de-aggregation devices there is little motivation to increase the 194 quality and number of available devices within a topological area or 195 logistical realm. 197 3.3. Operational Provisioning 199 Some elements regarding provisioning of both deterministic and non- 200 deterministic tunnels can be controlled, while others are beyond 201 control or influence of people and applications using tunnels. To 202 make applications highly reliable and performing, all elements within 203 the traffic path must provide an expected quality service and 204 performance. For deterministic tunnels, the user or provider of the 205 tunnel can exercise a degree of operational management and hence 206 influence good quality behaviour upon the tunnel especially upon the 207 aggregation and de-aggregation devices. In some cases even the 208 traffic path between both aggregation and de-aggregation can be 209 controlled. Non-deterministic tunnels however have less good quality 210 behaviour of both tunnel aggregation and de-aggregation devices 211 because often good quality behaviour is beyond the control or 212 influence of the tunnel user. For non-deterministic tunnels the 213 tunnel aggregator and/or tunnel de-aggregator are operated by a 3rd 214 party which may have a conflicting interest with the user of the non- 215 deterministic tunnel. An exception is where the use of the tunnel 216 mechanism is all within one ISP, or ISPs who are 'well coupled', e.g. 217 as happens between many NRENs. 219 3.4. Operational Troubleshooting 221 When one is using non-deterministic tunnels, then these tunnels may 222 get aggregated or de-aggregated by a 3rd party or a device outside 223 the control of a contracted service provider. Troubleshooting these 224 devices these devices will be pretty hard for the tunnel user or to 225 work around the issue. 227 Also some tools like traceroute don't work too well on asymmetric 228 paths. Another aspect is that tunnels show as one hop in a 229 traceroute, not indicating where problems may be. 231 3.5. Security 233 For an aggregating or de-aggregating tunnel device it is a non- 234 trivial issue to separate the valid traffic from non-valid traffic 235 because it is from the aggregation device perspective almost 236 impossible to know -from- and -towards- about the tunnel traffic. 237 This imposes potential attacks on the available resources of the 238 aggregating/de-aggregating router. A detailed security analysis for 239 6to4 tunnels can be found in [RFC3964]. 241 For the user of the non-deterministic IPv6 tunnel there is an 242 underlying trust that the aggregating/de-aggregating device is a 243 trustworthy device. However, some of the devices used are run by 244 anonymous 3rd parties outside the trusted infrastructure from the 245 user perspective, which is not an ideal situation. The usage of non- 246 deterministic tunnels increases the risk of rogue aggregation/ 247 de-aggregation devices and may be open to malicious packet analyses 248 or manipulation. 250 From the operator perspective, managing the aggregating/ 251 de-aggregating tunnel device, there is a trust assumption that no-one 252 abuses the service. Abuse may impact preset or assumed service 253 quality levels, and hence the quality provided can be impacted 255 There is also an impact caused by ipv4 firewalling upon non- 256 deterministic tunnels. Common firewall policies recommend to block 257 tunnels, especially non-deterministic tunnels, because there is no 258 trust that the traffic within the tunnel is not of mallicious intend. 259 This restricts the applicability of some non-deterministic tunnel 260 mechanisms (e.g. 6to4). Other tunnel mechanisms have found manners 261 to avoid traditional firewall filtering (e.g. Teredo) and open the 262 local network infrastructure for mallicious influence (e.g. virus, 263 worms, infrastructure attacs, etc..). 265 3.6. Content Services 267 When providing content services a very important related aspect is 268 that these services are accessible with high reliability, are 269 trustworthy and have a high performance. Using non-deterministic 270 tunnels makes this a much harder equation and can result in all three 271 elements to suffer a negatively, without the ability to uniquely 272 identify and resolve the root cause. The statistical impact of non- 273 deterministic tunnels has been measured by some Internet Content 274 providers and is often an additional delay of O(100msec) (need to add 275 reference here) 277 This reduces the interest of content providers to provide content 278 services over IPv6 when non-deterministic tunnels are used. 280 4. Conclusion 282 Non-deterministic tunnels have properties impacting the growth of 283 networks and the Internet in a negative way. Consequences regarding 284 black-holing, perverse traffic paths, lack of business incentive and 285 operational management influence and security issues are a real 286 pragmatic concern, while universal supportability for the tunnel 287 relay services appear to be non-trivial. Due to these elements the 288 usage of non-deterministic tunnelling can be considered harmful for 289 the growth of networks and the Internet. 291 5. IANA Considerations 293 There are no extra IANA consideration for this document. 295 6. Security Considerations 297 There are no extra Security consideration for this document. 299 7. Acknowledgements 301 8. References 303 8.1. Normative References 305 8.2. Informative References 307 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 308 via IPv4 Clouds", RFC 3056, February 2001. 310 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 311 6to4", RFC 3964, December 2004. 313 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 314 Network Address Translations (NATs)", RFC 4380, 315 February 2006. 317 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 318 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 319 Provider Edge Routers (6PE)", RFC 4798, February 2007. 321 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 322 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 323 March 2008. 325 [I-D.despres-6rd] 326 Despres, R., "IPv6 Rapid Deployment on IPv4 327 infrastructures (6rd) (draft-despres-6rd-03)", April 2009. 329 Authors' Addresses 331 Gunter Van de Velde 332 Cisco Systems 333 De Kleetlaan 6a 334 Diegem 1831 335 Belgium 337 Phone: +32 2704 5473 338 Email: gvandeve@cisco.com 340 Ole Troan 341 Cisco Systems 342 Folldalslia 17B 343 Bergen N-5239 344 Norway 346 Phone: +47 917 38519 347 Email: ot@cisco.com 349 Tim Chown 350 University of Southampton 351 Highfield 352 Southampton, SO17 1BJ 353 United Kingdom 355 Phone: +44 23 8059 3257 356 Email: tjc@ecs.soton.ac.uk