Network Working Group B. Aboba, Ed.
Request for Comment: 4924 E. Davies
Category: Informational Internet Architecture Board
July 2007
Reflections on Internet Transparency
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document provides a review of previous IAB statements on
Internet transparency, as well a discussion of new transparency
issues. Far from having lessened in relevance, technical
implications of intentionally or inadvertently impeding network
transparency play a critical role in the Internet's ability to
support innovation and global communication. This document provides
some specific illustrations of those potential impacts.
Table of Contents
1. Introduction ....................................................2
2. Additional Transparency Issues ..................................4
2.1. Application Restriction ....................................4
2.2. Quality of Service (QoS) ...................................6
2.3. Application Layer Gateways (ALGs) ..........................7
2.4. IPv6 Address Restrictions ..................................8
2.4.1. Allocation of IPv6 Addresses by Providers ...........8
2.4.2. IKEv2 ...............................................8
2.5. DNS Issues .................................................9
2.5.1. Unique Root .........................................9
2.5.2. Namespace Mangling ..................................9
2.6. Load Balancing and Redirection ............................10
3. Security Considerations ........................................11
4. References .....................................................11
4.1. Informative References ....................................11
Acknowledgments ...................................................13
Appendix A - IAB Members at the Time of Approval ..................14
Aboba & Davies Informational [Page 1]RFC 4924 Reflections on Internet Transparency July 20071. Introduction
In the past, the IAB has published a number of documents relating to
Internet transparency and the end-to-end principle, and other IETF
documents have also touched on these issues as well. These documents
articulate the general principles on which the Internet architecture
is based, as well as the core values that the Internet community
seeks to protect going forward. This document reaffirms those
principles, describes the concept of "oblivious transport" as
developed in the DARPA NewArch project [NewArch], and addresses a
number of new transparency issues.
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
packets. Networks that provide oblivious transport enable the
deployment of new services without requiring changes to the core. It
is this flexibility that is perhaps both the Internet's most
essential characteristic as well as one of the most important
contributors to its success.
"Architectural Principles of the Internet" [RFC1958], Section 2
describes the core tenets of the Internet architecture:
However, in very general terms, the community believes that the
goal is connectivity, the tool is the Internet Protocol, and the
intelligence is end to end rather than hidden in the network.
The current exponential growth of the network seems to show that
connectivity is its own reward, and is more valuable than any
individual application such as mail or the World-Wide Web. This
connectivity requires technical cooperation between service
providers, and flourishes in the increasingly liberal and
competitive commercial telecommunications environment.
"The Rise of the Middle and the Future of End-to-End: Reflections on
the Evolution of the Internet Architecture" [RFC3724], Section 4.1.1
describes some of the desirable consequences of this approach:
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. The counterargument - that many end
nodes are now essentially closed boxes which are not updatable and