v6ops Working Group                                      G. Van de Velde
Internet-Draft                                                  O. Troan
Intended status: Informational                             Cisco Systems
Expires: January 3, 2010                                        T. Chown
                                               University of Southampton
                                                            July 2, 2009

           Non-Deterministic IPv6 Tunnels considered Harmful

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 3, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Van de Velde, et al.     Expires January 3, 2010                [Page 1]

Internet-Draft    Non-Deterministic Tunnels are Harmful        July 2009

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   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.

   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-deterministic (i.e. 6to4 [RFC3056] and Teredo [RFC4380] ) because
   neither the egress path nor the ingress path is always fully
   controlled.  While native IPv6 deployments will keep growing it is
   uncertain or even expected that these non-deterministic traffic flows
   will be providing the same user experience and operational quality as
   deterministic tunnels or native IPv6 connectivity.

   This paper will detail some considerations around non-deterministic
   tunnels and will document the harmful element of these for the future
   growth of networks and the Internet.

Van de Velde, et al.     Expires January 3, 2010                [Page 2]

Internet-Draft    Non-Deterministic Tunnels are Harmful        July 2009

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Deterministic Tunnelling Properties . . . . . . . . . . . . . . 4
   3.  Non-deterministic Tunnelling Properties . . . . . . . . . . . . 4
     3.1.  Performance . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.2.  Topological Considerations  . . . . . . . . . . . . . . . . 5
     3.3.  Operational Provisioning  . . . . . . . . . . . . . . . . . 6
     3.4.  Operational Troubleshooting . . . . . . . . . . . . . . . . 6
     3.5.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.6.  Content Services  . . . . . . . . . . . . . . . . . . . . . 7
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Van de Velde, et al.     Expires January 3, 2010                [Page 3]

Internet-Draft    Non-Deterministic Tunnels are Harmful        July 2009

1.  Introduction

   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 IPv4 available addresses 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.

   Historically IETF has been facilitating a variety of technologies and
   procedures to deploy IPv6 within Networks which have been running
   IPv4 successfully.  In general and for the sake of this draft they
   can be divided into three major groups: (1) native (dual-stack) IPv6,
   (2) Tunnelled IPv6 and (3) Translation.  While native IPv6
   deployments have 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.  While
   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-deterministic 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-deterministic
   tunnelling techniques are considered harmful especially for those
   that want to access applications over the network in a reliable and
   secure way and have no particular interest on how connectivity to the
   applications is established (IPv4, translation, IPv6, etc...)

2.  Deterministic Tunnelling Properties

   A deterministic tunnel is a tunnel which has explicit tunnel
   aggregation and de-aggregation points (i.e.  ISATAP [RFC5214], manual
   tunnels, 6rd [I-D.despres-6rd], IPv6 over MPLS [RFC4798], etc...).
   An important aspect is also that the aggregation and de-aggregation
   points are provided by a trusted party and hence have controlable
   good quality and performance.

3.  Non-deterministic Tunnelling Properties

   The properties of Non-deterministic 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-
   deterministic tunnel.  A common property of non-deterministic tunnels

Van de Velde, et al.     Expires January 3, 2010                [Page 4]

Internet-Draft    Non-Deterministic Tunnels are Harmful        July 2009

   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.

   Non-deterministic 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.

3.1.  Performance

   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.

   During initial IPv6 deployment there have been mainly technical savvy
   people that have been using non-deterministic tunnel technologies and
   it has for many been working well.  However, if non-deterministic
   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... ).

3.2.  Topological Considerations

   Due to non-deterministic 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-

Van de Velde, et al.     Expires January 3, 2010                [Page 5]

Internet-Draft    Non-Deterministic Tunnels are Harmful        July 2009

   deterministic 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.

3.3.  Operational Provisioning

   Some elements regarding provisioning of both deterministic and non-
   deterministic 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 deterministic 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-deterministic 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-deterministic 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-
   deterministic 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.

3.4.  Operational Troubleshooting

   When one is using non-deterministic 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.

   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.

3.5.  Security

   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

Van de Velde, et al.     Expires January 3, 2010                [Page 6]

Internet-Draft    Non-Deterministic Tunnels are Harmful        July 2009

   6to4 tunnels can be found in [RFC3964].

   For the user of the non-deterministic 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-
   deterministic tunnels increases the risk of rogue aggregation/
   de-aggregation devices and may be open to malicious packet analyses
   or manipulation.

   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

   There is also an impact caused by ipv4 firewalling upon non-
   deterministic tunnels.  Common firewall policies recommend to block
   tunnels, especially non-deterministic tunnels, because there is no
   trust that the traffic within the tunnel is not of mallicious intend.
   This restricts the applicability of some non-deterministic 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..).

3.6.  Content Services

   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-deterministic
   tunnels makes this a much harder equation and can result in all three
   elements to suffer a negatively, without the ability to uniquely
   identify and resolve the root cause.  The statistical impact of non-
   deterministic tunnels has been measured by some Internet Content
   providers and is often an additional delay of O(100msec) (need to add
   reference here)

   This reduces the interest of content providers to provide content
   services over IPv6 when non-deterministic tunnels are used.

4.  Conclusion

   Non-deterministic 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

Van de Velde, et al.     Expires January 3, 2010                [Page 7]

Internet-Draft    Non-Deterministic Tunnels are Harmful        July 2009

   pragmatic concern, while universal supportability for the tunnel
   relay services appear to be non-trivial.  Due to these elements the
   usage of non-deterministic tunnelling can be considered harmful for
   the growth of networks and the Internet.

5.  IANA Considerations

   There are no extra IANA consideration for this document.

6.  Security Considerations

   There are no extra Security consideration for this document.

7.  Acknowledgements

8.  References

8.1.  Normative References

8.2.  Informative References

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3964]  Savola, P. and C. Patel, "Security Considerations for
              6to4", RFC 3964, December 2004.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC4798]  De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
              "Connecting IPv6 Islands over IPv4 MPLS Using IPv6
              Provider Edge Routers (6PE)", RFC 4798, February 2007.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

              Despres, R., "IPv6 Rapid Deployment on IPv4
              infrastructures (6rd) (draft-despres-6rd-03)", April 2009.

Van de Velde, et al.     Expires January 3, 2010                [Page 8]

Internet-Draft    Non-Deterministic Tunnels are Harmful        July 2009

Authors' Addresses

   Gunter Van de Velde
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831

   Phone: +32 2704 5473
   Email: gvandeve@cisco.com

   Ole Troan
   Cisco Systems
   Folldalslia 17B
   Bergen  N-5239

   Phone: +47 917 38519
   Email: ot@cisco.com

   Tim Chown
   University of Southampton
   Southampton,   SO17 1BJ
   United Kingdom

   Phone: +44 23 8059 3257
   Email: tjc@ecs.soton.ac.uk

Van de Velde, et al.     Expires January 3, 2010                [Page 9]