Note: This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects the author’s personal perspective on some current highlights.
In the past, the Internet Architecture Board (IAB) has published a number of documents related to Internet transparency and the end-to-end principle, and other IETF documents have touched on those issues as well. These documents articulate the general principles on which the Internet architecture is based, as well as the following core values the Internet community seeks to protect going forward.
- Oblivious transport. A network that does not filter or transform the data that it carries may be said to be transparent, or oblivious to the content of the packet – New Arch: Future Generation Internet Architecture (PDF: 507KB)
- Tussle. [The process by which] different parties adapt the [Internet’s] mix of mechanisms to try to achieve their conflicting goals, and others respond by adapting the mechanisms to push back. Tussle in Cyberspace (PDF: 507KB)
- In very general terms, the community believes the goal is connectivity, the tool is the Interent Protocol, and the intelligence is in the end to end rather than hidden in the network. (From RFC 1958 “Architectural Principles of the Internet”)
- One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes. (From RFC 3724 “A Rise of the Middle and the Future of End-to-End”)
Although the pure IPv6 scenario is the cleanest and simplest, it is not straightforward to reach it. The various scenarios without use of IPv6 are all messy and ultimately seem to lead to dead ends. . . . deployment of IPv6 . . . is also messy but avoids the dead ends. (From RFC 2775 “Internet Transparency”)
There are a number of questions we should ask: How has the thinking on Internet transparency evolved over the years? What core tenets still guide us, and what new insights have been developed? Are there transparency issues that have not received enough attention? And are new potential transparency barriers being encountered?
Even while the Internet has greatly expanded both in size and in application diversity, the degree of transparency has diminished. RFC 2775 “Internet Transparency” notes some of the causes for the loss of Internet transparency and analyses their
impact:
- Application-layer gateways
RFC 2775 says: “If the full range of Internet applications is to be used, NATs have to be coupled with Application Layer Gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be updated whenever a new address-dependent application comes along.” This means that ALGs represent an additional barrier to transparency above and beyond NAT and that ALGs create barriers to the updating of existing applications as well as to the deployment of new applications. It further means that Domain Name System (DNS) ALGs represent a barrier to the deployment of DNS Security Extensions (DNSSEC). - The Domain Name System
The use of a unique root for the DNS namespace is essential and a fundamental principle. Recursive name servers and/or DNS forwarders may replace responses that indicate that a name does not exist with a name and an address record that hosts a Web service. In addition to that, recursive forwarders modifying responses are incompatible with DNSSEC. - Load balancing and redirection
If load balancing and redirection services are not implemented well, it can lead to other services’ being disrupted; for instance, DNS redirection may not properly determine locality. Misconfigured packet filters may result in improper shunting of traffic to overlay networks. And anycast service may not provide oblivious transport in the face of routing changes. - IPv6 address restrictions
Even though RFC 2775 states that “it is a basic assumption of IPv6 that no artificial constraints will be placed on the supply of addresses, given that there are so many of them,” providers may not support prefix delegation and gateways may not support bridging and/or neighbour discovery proxy. Also, IKEv2 may assign only a single IPv6 address (as defined in RFC 4306). - Application filtering
Applications may be blocked without consent of the edge of the network, or providers may not disclose service terms and policies to the users. - Quality of Service (QoS)
QoS may be used to restrict deployment of new applications and therefore has potential implications for transparency, since having better or worse QoS for a flow can result in making the Internet more or less oblivious to that flow.
It looks like the IAB statements on transparency – some of them quoted earlier – remain relevant today, and the tussle that led to a reduction in Internet transparency continues.
While full restoration of Internet transparency through the deployment of IPv6 remains a goal, the Internet’s growing role in society, the increasing diversity of applications, and the continued growth in security threats have altered the balance between transparency and security. While transparency provides great flexibility, it also makes it easier to deliver unwanted as well as wanted traffic.
Since many of the fundamental forces that have led to a reduction in the transparency of the IPv4 Internet also may play a role in the IPv6 Internet, the transparency of the IPv6 Internet is not preordained; rather, represents an ideal whose maintenance will require significant ongoing effort.