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

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 http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

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.

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.

Abstract

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] (Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds,” February 2001.) and Teredo [RFC4380] (Huitema, C., “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs),” February 2006.) ) 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.

Table of Contents

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

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] (Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP),” March 2008.), manual tunnels, 6rd [I‑D.despres‑6rd] (Despres, R., “IPv6 Rapid Deployment on IPv4 infrastructures (6rd) (draft-despres-6rd-03),” April 2009.), IPv6 over MPLS [RFC4798] (De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, “Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE),” February 2007.), 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 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-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 6to4 tunnels can be found in [RFC3964] (Savola, P. and C. Patel, “Security Considerations for 6to4,” December 2004.).

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

Authors' Addresses