One document matched: draft-vandevelde-v6ops-harmful-tunnels-01.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc compact="yes" ?>
<?rfc toc="yes" ?>

 <!ENTITY rfc3056  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3056.xml'>
 <!ENTITY rfc3964  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3964.xml'>
 <!ENTITY rfc4380  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml'>
 <!ENTITY rfc4798  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4798.xml'>
 <!ENTITY rfc5214  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5214.xml'>
 <!ENTITY rfc5969  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969.xml'>
 
<rfc category="info" ipr="pre5378Trust200902" docName="<draft-vandevelde-v6ops-harmful-tunnels-01.txt>">

<front>

<title abbrev="Non-Managed Tunnels are Harmful">
Non-Managed IPv6 Tunnels considered Harmful
</title>


     <author initials="G." surname="Van de Velde" fullname="Gunter Van de Velde">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>De Kleetlaan 6a</street>
          <city>Diegem</city>
          <country>Belgium</country>
          <code>1831</code>
        </postal>
        <phone>+32 2704 5473</phone>
        <email>gvandeve@cisco.com</email>
      </address>
    </author>

     <author initials="O" surname="Troan" fullname="Ole Troan">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>   Folldalslia 17B</street>
          <city>Bergen</city>
          <country>Norway</country>
          <code>N-5239</code>
        </postal>
        <phone>+47 917 38519</phone>
        <email>ot@cisco.com</email>
      </address>
    </author>

     <author initials="T" surname="Chown" fullname="Tim Chown">
      <organization>University of Southampton</organization>
      <address>
        <postal>
          <street>Highfield </street>
          <city>Southampton</city>
          <region></region>
          <country>United Kingdom</country>
          <code>SO17 1BJ </code>
        </postal>
        <phone>+44 23 8059 3257</phone>
        <email>tjc@ecs.soton.ac.uk</email>
      </address>
    </author>


<date day="31" month="August" year="2010"></date>
<workgroup>v6ops Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>IPv6</keyword>
<keyword>non-deterministic</keyword>


<abstract>

<t>IPv6 is ongoing and natively being deployed by a growing community 
and it is important that the quality perception and traffic flows 
are as optimal as possible. Ideally it would be as good as the 
IPv4 perceptive experience.
</t>

<t>This paper looks into a set of transitional technologies where the 
actual user has IPv6 connectivity through the means of IPv6-in-IPv4 
tunnels. A subset of the available tunnels has the property of 
being non-managed (i.e. 6to4 <xref target="RFC3056"/> and Teredo <xref target="RFC4380"/> ).
</t>

<t>While native IPv6 deployments will keep growing it is uncertain 
or even expected that non-managed IPv6 tunnels will 
be providing the same user experience and operational 
quality as managed tunnels or native IPv6 connectivity. 
</t>

<t>This paper will detail some considerations around non-managed 
tunnels and will document the harmful element of these for the 
future growth of networks and the Internet.
</t>

</abstract>

</front>

<middle>

<section title="Introduction">
  
  <t>While the Internet and networks continue to grow, it is 
  found that the deployment of IPv6 within these networks is 
  an ongoing activity due to global IPv4 address pool depletion. 
  An important aspect is that the quality, availability and 
  security of the IPv6 connectivity is as good as possible, and 
  when possible even more advanced as the IPv4 connectivity.
  </t>

  <t>Historically IETF has been facilitating a variety of technologies 
  and procedures to deploy IPv6 successfully in addition to existing 
  IPv4 connectivity. In general and for the sake of this draft these 
  procedures and technologies can be divided into three major 
  groups: (1) native (dual-stack) IPv6, (2) Tunnelled IPv6 
  and (3) Translation. While native IPv6 deployments 
  has been steadily growing, the value and the drawbacks of some 
  tunnelling mechanisms can be investigated. Translational techniques 
  provide a total different aspect of considerations and applicability 
  and is beyond the scope of this paper. Transition  
  techniques have been and still are in many cases important for the bootstrapping 
  of IPv6, this paper will look into a range of property aspects of non-managed 
  IPv6 tunnelling techniques. Areas of perverse traffic paths, security 
  considerations, lack of business incentives to run tunnel 
  relays/gateways, black holing and ownership of supportability will be 
  analysed. Finally the paper will conclude that for the growth of IP 
  connectivity, non-managed tunnelling techniques are considered 
  harmful especially for those that want to access 
  applications over the network through pervasive IPv6 connectivityand 
  have no particular interrest on how connectivity to the applications is 
  established (IPv4, translation, IPv6, etc...)
  </t>  

</section>

<section title="Managed Tunnelling Properties">

  <t>A managed tunnel is a tunnel has a few properties supporting 
  the ownership and quality of the tunnel.
  </t>
  
  <t>When using a managed service, there tends to be an administrative 
  entity which provides quality assurance and can take action if users 
  of the service are experiencing a degraded service. An example would 
  be 6rd tunnels <xref target="RFC5969"/>
  </t>
  
  <t>In addition there is a general trust awareness and agreement 
  between the user of the managed tunnel service and the provider of 
  the managed tunnel service.
  </t>
  

</section>


<section title="Tunnel User Experience Views">

  
  <t>The tunnel experience can be divided into three distinct
  segments: (1) the End-user view, (2) the Enterprise View and (3) the
  Service Provider View.
  </t>
 
  <t>The End-user view exists mainly out of two different user profiles.
  The technical power user and the general user mainly trying to reach their
  favourite application on the network. The technical power user may have a
  particular interrest to run IPv6 as a transport mechanism, and if his
  upstream service provider has no native IPv6 connectivity available, then
  non-managed tunneling mechanisms may provide a solution satisfying to the
  immediate needs of the technical power user. Alternatively, the general user
  trying to reach his favourite network application, may have no interest
  or awareness of his IPv6 usage, particulary when non-managed tunnels are utilized.
  </t>
  
  <t>The Enterprise View is a more traffic flows and network oriented
  possitioning. When the upstream service provider does not have an
  IPv6 offer, then the enterprise may start to rely upon a technology
  as 6to4 <xref target="RFC3056"/>. However this technology has the potential
  of creating quite perverse traffic paths when user want to reach applications
  on the Internet. When user would like to reach other 6to4 <xref target="RFC3056"/>
  users, then more optimized traffic paths, generally following the IPv4 traffic
  paths are realized
  </t>

  <t>The final view is how a Internet service provider looks into non-managed
  tunnel usage. A service provider may decide to deploy a 6to4 relay to increase
  the IPv6 quality of their customers. This a service which require 
  resources (money, maintenance, etc...). Often the 6to4 relay service is
  not just (always) restricted to only the service providers customers, which
  as result provides often results in a demotivation to provide quality tunnel
  relay devices. From a content service provider perspective the usage of non-managed
  tunnel often results in measurable differences in RTT and reliability in some
  cases, and hence are reluctant to bring all services to mainstream IPv6 for all users 'just yet'.
  </t>  



</section>

<section title="Why do non-managed tunnels exist?">


  <t>Non-managed tunnels exist due to a variety of reasons.
  </t>

  <t>Early adopters: people and organisations with a desire to use new 
  and potentially market disrupting technologies and applications may
  have a desire to use the latest IP even when the upstream provider
  doesn't have an available service offering.
  </t>


 
  <t>Lock-step process to implement IPv6: It is not trivial to move a
  system or an organisation in lock-step towards IPv6 and the aid
  of tunnels help in this process.
  </t>


 
  <t>The utilisation of tunnels aid in providing a de-coupling between
  infrastructure readiness and application readiness, and hence
  contribute to the development of both elements.
  </t>

</section>

<section title="Non-Managed Tunnelling Properties">
  
  <t>The properties of Non-managed tunnels span many different areas. 
  In this section the properties are analysed and segmented within 
  different areas of impact. In each case the comparison is made between 
  native IPv6 connectivity and connectivity through a non-managed tunnel. 
  A common property of non-managed tunnels is that they often use 
  well-known anycast addresses or other well known addresses and anticipate 
  upon the goodwill of middleware (typically a relay or gateway) device 
  to serve as a tunnel termination point. In some cases, for example a 6to4 
  relay can be provided by a connected responsible service provider, and hence good 
  quality operation can be guaranteed.
  </t>

  <t>Non-managed tunnels often have asymmetric behaviour. There is an outbound and an 
  inbound connectivity behaviour from the tunnel initiator. It is possible to influence 
  the good quality tunnel behaviour of the outbound connectivity (e.g. by explicit 
  setting of the 6to4 relay), however, influencing good inbound connectivity is often an issue.
  </t>
 

<section title="Performance">

  <t>Deploying a tunnelling mechanism mostly results in encapsulation 
  and de-capsulation efforts. Often this activity has a performance 
  impact on the device, especially when the device does not use 
  hardware acceleration for this functionality. If the performance impact 
  is scoped into the device its lifetime through performance capacity 
  management then the actual impact is predictive. Non-deterministic 
  tunnels tend to have a non-predictive behaviour for capacity, and 
  hence application and network performance is non-predictive. The 
  key reason for this is the decoupling of the capacity management 
  of the tunnel aggregation devices from the capacity desired by 
  users of the aggregation devices.
  </t>

  <t>During initial IPv6 deployment there have been mainly technical 
  savvy people that have been using non-managed tunnel 
  technologies and it has for many been working well. 
  However, if non-managed tunnelling would be deployed in mass and 
  especially when enabled by default by CPE vendors or host vendors then 
  those aggregation points could become overloaded and result in bad 
  performance. There are a few measures that can be taken, i.e. upgrade 
  the CPU power of the aggregation device or its bandwidth available, however 
  this may not happen without the right motivation for the operator 
  of the aggregation device (i.e. cash flows, reputation, competitive 
  reasons, etc... ). 
  </t>

</section>

<section title="Topological Considerations">

  <t>Due to non-managed IPv6 tunnels the traffic flows may  
  result in sub-optimal flows through the network topology between 
  two communicating devices. The impact for example 
  can cause increase of the RTT and packet loss, especially considering 
  the availability (or better non-availability) of tunnel 
  aggregation/de-aggregation points of certain topological 
  areas or realms. The increase of non-managed tunnel usage would 
  amplify the negative impact on good quality connectivity. For many 
  operators of tunnel aggregation/de-aggregation 
  devices there is little motivation to increase the quality and 
  number of available devices within a topological area or 
  logistical realm.
  </t>

</section>

<section title="Operational Provisioning">

  <t>Some elements regarding provisioning of both managed and 
  non-managed tunnels can be controlled, while others are beyond 
  control or influence of people and applications using tunnels. 
  To make applications highly reliable and performing, all elements 
  within the traffic path must provide an expected quality service 
  and performance. For managed tunnels, the user or provider of the tunnel 
  can exercise a degree of operational management and hence influence 
  good quality behaviour upon the tunnel especially upon the aggregation 
  and de-aggregation devices. In some cases even the traffic path 
  between both aggregation and de-aggregation can be controlled. 
  Non-managed tunnels however have less good quality behaviour 
  of both tunnel aggregation and de-aggregation devices because often 
  good quality behaviour is beyond the control or influence of the tunnel 
  user. For non-managed tunnels the tunnel aggregator and/or tunnel 
  de-aggregator are operated by a 3rd party which may have a conflicting 
  interest with the user of the non-managed tunnel. An exception is 
  where the use of the tunnel mechanism is all within one ISP, or ISPs who
  are 'well coupled', e.g. as happens between many NRENs.
  </t>

</section>

<section title="Operational Troubleshooting">

  <t>When one is using non-managed tunnels, then these tunnels 
  may get aggregated or de-aggregated by a 3rd party or a device outside 
  the control of a contracted service provider. Troubleshooting these 
  devices these devices will be pretty hard for the tunnel user or to 
  work around the issue.
  </t>

  <t>Also some tools like traceroute don't work too well on asymmetric paths.
  Another aspect is that tunnels show as one hop in a traceroute, not indicating 
  where problems may be.
  </t>


</section>

<section title="Security">

  <t>For an aggregating or de-aggregating tunnel device it is a 
  non-trivial issue to separate the valid traffic from non-valid 
  traffic because it is from the aggregation device perspective almost 
  impossible to know -from- and -towards-  about the tunnel traffic. This 
  imposes potential attacks on the available resources of the 
  aggregating/de-aggregating router. A detailed security analysis for 6to4 tunnels 
  can be found in <xref target="RFC3964"/>.
  </t>

  <t>For the user of the non-managed IPv6 tunnel there is 
  an underlying trust that the aggregating/de-aggregating device is 
  a trustworthy device. However, some of the devices used are 
  run by anonymous 3rd parties outside the trusted infrastructure 
  from the user perspective, which is not an ideal situation. The usage of 
  non-managed tunnels increases the risk of rogue 
  aggregation/de-aggregation devices and may be open to malicious packet 
  analyses or manipulation.
  </t>

  <t>From the operator perspective, managing the aggregating/de-aggregating 
  tunnel device, there is a trust assumption that no-one abuses the 
  service. Abuse may impact preset or assumed service quality levels, and 
  hence the quality provided can be impacted
  </t>

  <t>There is also an impact caused by ipv4 firewalling upon non-managed 
  tunnels. Common firewall policies recommend to block tunnels, especially 
  non-managed tunnels, because there is no trust that the traffic within 
  the tunnel is not of mallicious intend. This restricts the applicability of 
  some non-managed tunnel mechanisms (e.g. 6to4). Other tunnel 
  mechanisms have found manners to avoid traditional firewall filtering (e.g. Teredo) 
  and open the local network infrastructure for mallicious influence (e.g. virus, 
  worms, infrastructure attacs, etc..).
  </t>

</section>

<section title="Content Services">

  <t>When providing content services a very important related aspect 
  is that these services are accessible with high reliability, are 
  trustworthy and have a high performance. Using non-managed
  tunnels makes this a much harder equation and can result in all 
  three elements to suffer negatively, without the ability to 
  uniquely identify and resolve the root cause. The statistical 
  impact of non-mnaged tunnels has been measured by some 
  Internet Content providers and is often an additional delay 
  of O(100msec) (need to add reference here)
  </t>

  <t>This reduces the interest of content providers to provide 
  content services over IPv6 when non-managed tunnels 
  are used.
  </t>

</section>

</section>


<section title="Conclusion">
  
  <t>Non-managed tunnels have properties impacting the 
  growth of networks and the Internet in a negative way. Consequences 
  regarding black-holing, perverse traffic paths, lack of business 
  incentive and operational management influence and security issues 
  are a real pragmatic concern, while universal supportability for 
  the tunnel relay services appear to be non-trivial. Due to these 
  elements the usage of non-managed tunnelling can be considered 
  harmful for the growth of networks and the Internet.
  </t>

</section>


<section title="IANA Considerations">


   <t>There are no extra IANA consideration for this document.
   </t>

</section>

<section title="Security Considerations">

   
   <t>There are no extra Security consideration for this document.   
   </t> 

</section>

<section title="Acknowledgements">

  <t>
  </t>

</section>

</middle>

<!-- =============================================================== -->

<back>

<references title='Normative References'>

</references>

<references title='Informative References'>

   &rfc3056;
   &rfc3964;
   &rfc4380;
   &rfc4798;
   &rfc5214;
   &rfc5969;

</references>

</back>

</rfc>