doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc3724.txt b/doc/rfc/rfc3724.txt
new file mode 100644
index 0000000..44ab9c9
--- /dev/null
+++ b/doc/rfc/rfc3724.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                      J. Kempf, Ed.
+Request for Comments: 3724                               R. Austein, Ed.
+Category: Informational                                              IAB
+                                                              March 2004
+
+
+          The Rise of the Middle and the Future of End-to-End:
+       Reflections on the Evolution of the Internet Architecture
+
+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 Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   The end-to-end principle is the core architectural guideline of the
+   Internet.  In this document, we briefly examine the development of
+   the end-to-end principle as it has been applied to the Internet
+   architecture over the years.  We discuss current trends in the
+   evolution of the Internet architecture in relation to the end-to-end
+   principle, and try to draw some conclusion about the evolution of the
+   end-to-end principle, and thus for the Internet architecture which it
+   supports, in light of these current trends.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  A Brief History of the End-to-End Principle. . . . . . . . . .  2
+   3.  Trends Opposed to the End-to-End Principle . . . . . . . . . .  5
+   4.  Whither the End-to-End Principle?. . . . . . . . . . . . . . .  8
+   5.  Internet Standards as an Arena for Conflict. . . . . . . . . . 10
+   6.  Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
+   9.  Informative References . . . . . . . . . . . . . . . . . . . . 12
+   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
+   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+
+
+Kempf & Austein              Informational                      [Page 1]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+1.  Introduction
+
+   One of the key architectural guidelines of the Internet is the end-
+   to-end principle in the papers by Saltzer, Reed, and Clark [1][2].
+   The end-to-end principle was originally articulated as a question of
+   where best not to put functions in a communication system.  Yet, in
+   the ensuing years, it has evolved to address concerns of maintaining
+   openness, increasing reliability and robustness, and preserving the
+   properties of user choice and ease of new service development as
+   discussed by Blumenthal and Clark in [3]; concerns that were not part
+   of the original articulation of the end-to-end principle.
+
+   In this document, we examine how the interpretation of the end-to-end
+   principle has evolved over the years, and where it stands currently.
+   We examine trends in the development of the Internet that have led to
+   pressure to define services in the network, a topic that has already
+   received some amount of attention from the IAB in RFC 3238 [5].  We
+   describe some considerations about how the end-to-end principle might
+   evolve in light of these trends.
+
+2.  A Brief History of the End-to-End Principle
+
+2.1.  In the Beginning...
+
+   The end-to-end principle was originally articulated as a question of
+   where best to put functions in a communication system:
+
+      The function in question can completely and correctly be
+      implemented only with the knowledge and help of the application
+      standing at the end points of the communication system.
+      Therefore, providing that questioned function as a feature of the
+      communication system itself is not possible.  (Sometimes an
+      incomplete version of the function provided by the communication
+      system may be useful as a performance enhancement.) [1].
+
+   A specific example of such a function is delivery guarantees [1].
+   The original ARPANET returned a message "Request for Next Message"
+   whenever it delivered a packet.  Although this message was found to
+   be useful within the network as a form of congestion control, since
+   the ARPANET refused to accept another message to the same destination
+   until the previous acknowledgment was returned, it was never
+   particularly useful as an indication of guaranteed delivery.  The
+   problem was that the host stack on the sending host typically doesn't
+   want to know just that the network delivered a packet, but rather the
+   stack layer on the sending host wants to know that the stack layer on
+   the receiving host properly processed the packet.  In terms of modern
+   IP stack structure, a reliable transport layer requires an indication
+   that transport processing has successfully completed, such as given
+
+
+
+Kempf & Austein              Informational                      [Page 2]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   by TCP's ACK message [4], and not simply an indication from the IP
+   layer that the packet arrived.  Similarly, an application layer
+   protocol may require an application-specific acknowledgement that
+   contains, among other things, a status code indicating the
+   disposition of the request.
+
+   The specific examples given in [1] and other references at the time
+   [2] primarily involve transmission of data packets: data integrity,
+   delivery guarantees, duplicate message suppression, per packet
+   encryption, and transaction management.  From the viewpoint of
+   today's Internet architecture, we would view most of these as
+   transport layer functions (data integrity, delivery guarantees,
+   duplicate message suppression, and perhaps transaction management),
+   others as network layer functions with support at other layers where
+   necessary (for example, packet encryption), and not application layer
+   functions.
+
+2.2.  ...In the Middle...
+
+   As the Internet developed, the end-to-end principle gradually widened
+   to concerns about where best to put the state associated with
+   applications in the Internet: in the network or at end nodes.  The
+   best example is the description in RFC 1958 [6]:
+
+      This principle has important consequences if we require
+      applications to survive partial network failures.  An end-to-end
+      protocol design should not rely on the maintenance of state (i.e.,
+      information about the state of the end-to-end communication)
+      inside the network.  Such state should be maintained only in the
+      endpoints, in such a way that the state can only be destroyed when
+      the endpoint itself breaks (known as fate-sharing).  An immediate
+      consequence of this is that datagrams are better than classical
+      virtual circuits.  The network's job is to transmit datagrams as
+      efficiently and flexibly as possible.  Everything else should be
+      done at the fringes.
+
+   The original articulation of the end-to-end principle - that
+   knowledge and assistance of the end point is essential and that
+   omitting such knowledge and implementing a function in the network
+   without such knowledge and assistance is not possible - took a while
+   to percolate through the engineering community, and had evolved by
+   this point to a broad architectural statement about what belongs in
+   the network and what doesn't.  RFC 1958 uses the term "application"
+   to mean the entire network stack on the end node, including network,
+   transport, and application layers, in contrast to the earlier
+   articulation of the end-to-end principle as being about the
+   communication system itself.  "Fate-sharing" describes this quite
+   clearly: the fate of a conversation between two applications is only
+
+
+
+Kempf & Austein              Informational                      [Page 3]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   shared between the two applications; the fate does not depend on
+   anything in the network, except for the network's ability to get
+   packets from one application to the other.
+
+   The end-to-end principle in this formulation is specifically about
+   what kind of state is maintained where:
+
+      To perform its services, the network maintains some state
+      information: routes, QoS guarantees that it makes, session
+      information where that is used in header compression, compression
+      histories for data compression, and the like.  This state must be
+      self-healing; adaptive procedures or protocols must exist to
+      derive and maintain that state, and change it when the topology or
+      activity of the network changes.  The volume of this state must be
+      minimized, and the loss of the state must not result in more than
+      a temporary denial of service given that connectivity exists.
+      Manually configured state must be kept to an absolute minimum.[6]
+
+   In this formulation of the end-to-end principle, state involved in
+   getting packets from one end of the network to the other is
+   maintained in the network.  The state is "soft state," in the sense
+   that it can be quickly dropped and reconstructed (or even required to
+   be periodically renewed) as the network topology changes due to
+   routers and switches going on and off line.  "Hard state", state upon
+   which the proper functioning of the application depends, is only
+   maintained in the end nodes.  This formulation of the principle is a
+   definite change from the original formulation of the principle, about
+   end node participation being required for proper implementation of
+   most functions.
+
+   In summary, the general awareness both of the principle itself and of
+   its implications for how unavoidable state should be handled grew
+   over time to become a (if not the) foundation principle of the
+   Internet architecture.
+
+2.3.  ...And Now.
+
+   An interesting example of how the end-to-end principle continues to
+   influence the technical debate in the Internet community is IP
+   mobility.  The existing Internet routing architecture severely
+   constrains how closely IP mobility can match the end-to-end principle
+   without making fundamental changes.  Mobile IPv6, described in the
+   Mobile IPv6 specification by Johnson, Perkins, and Arkko [7],
+   requires a routing proxy in the mobile node's home network (the Home
+   Agent) for maintaining the mapping between the mobile node's routing
+   locator, the care of address, and the mobile node's node identifier,
+   the home address.  But the local subnet routing proxy (the Foreign
+   Agent), which was a feature of the older Mobile IPv4 design [8] that
+
+
+
+Kempf & Austein              Informational                      [Page 4]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   compromised end-to-end routing, has been eliminated.  The end node
+   now handles its own care of address.  In addition, Mobile IPv6
+   includes secure mechanisms for optimizing routing to allow end-to-end
+   routing between the mobile end node and the correspondent node,
+   removing the need to route through the global routing proxy at the
+   home agent.  These features are all based on end to end
+   considerations.  However, the need for the global routing proxy in
+   the Home Agent in Mobile IPv6 is determined by the aliasing of the
+   global node identifier with the routing identifier in the Internet
+   routing architecture, a topic that was discussed in an IAB workshop
+   and reported in RFC 2956 [9], and that hasn't changed in IPv6.
+
+   Despite this constraint, the vision emerging out of the IETF working
+   groups developing standards for mobile networking is of a largely
+   autonomous mobile node with multiple wireless link options, among
+   which the mobile node picks and chooses.  The end node is therefore
+   responsible for maintaining the integrity of the communication, as
+   the end-to-end principle implies.  This kind of innovative
+   application of the end-to-end principle derives from the same basic
+   considerations of reliability and robustness (wireless link
+   integrity, changes in connectivity and service availability with
+   movement, etc.) that motivated the original development of the end-
+   to-end principle.  While the basic reliability of wired links,
+   routing, and switching equipment has improved considerably since the
+   end-to-end principle was formalized 15 years ago, the reliability or
+   unreliability of wireless links is governed more strongly by the
+   basic physics of the medium and the instantaneous radio propagation
+   conditions.
+
+3.  Trends Opposed to the End-to-End Principle
+
+   While the end-to-end principle continues to provide a solid
+   foundation for much IETF design work, the specific application of the
+   end-to-end principle described in RFC 1958 has increasingly come into
+   question from various directions.  The IAB has been concerned about
+   trends opposing the end-to-end principle for some time, for example
+   RFC 2956 [9] and RFC 2775 [12].  The primary focus of concern in
+   these documents is the reduction in transparency due to the
+   introduction of NATs and other address translation mechanisms in the
+   Internet, and the consequences to the end-to-end principle of various
+   scenarios involving full, partial, or no deployment of IPv6.  More
+   recently, the topic of concern has shifted to the consequences of
+   service deployment in the network.  The IAB opinion on Open Pluggable
+   Edge Services (OPES) in RFC 3238 [5] is intended to assess the
+   architectural desirability of defining services in the network and to
+   raise questions about how such services might result in compromises
+
+
+
+
+
+Kempf & Austein              Informational                      [Page 5]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   of privacy, security, and end-to-end data integrity.  Clark, et al.
+   in [10] and Carpenter in RFC 3234 [11] also take up the topic of
+   service definition in the network.
+
+   Perhaps the best review of the forces militating against the end-to-
+   end principle is by Blumenthal and Clark in [3].  The authors make
+   the point that the Internet originally developed among a community of
+   like-minded technical professionals who trusted each other, and was
+   administered by academic and government institutions who enforced a
+   policy of no commercial use.  The major stakeholders in the Internet
+   are quite different today.  As a consequence, new requirements have
+   evolved over the last decade.  Examples of these requirements are
+   discussed in the following subsections.  Other discussions about
+   pressures on the end-to-end principle in today's Internet can be
+   found in the discussion by Reed [13] and Moors' paper in the 2002
+   IEEE International Communications Conference [14].
+
+3.1.  Need for Authentication
+
+   Perhaps the single most important change from the Internet of 15
+   years ago is the lack of trust between users.  Because the end users
+   in the Internet of 15 years ago were few, and were largely dedicated
+   to using the Internet as a tool for academic research and
+   communicating research results (explicit commercial use of the
+   Internet was forbidden when it was run by the US government), trust
+   between end users (and thus authentication of end nodes that they
+   use) and between network operators and their users was simply not an
+   issue in general.  Today, the motivations of some individuals using
+   the Internet are not always entirely ethical, and, even if they are,
+   the assumption that end nodes will always co-operate to achieve some
+   mutually beneficial action, as implied by the end-to-end principle,
+   is not always accurate.  In addition, the growth in users who are
+   either not technologically sophisticated enough or simply
+   uninterested in maintaining their own security has required network
+   operators to become more proactive in deploying measures to prevent
+   naive or uninterested users from inadvertently or intentionally
+   generating security problems.
+
+   While the end-to-end principle does not require that users implicitly
+   trust each other, the lack of trust in the Internet today requires
+   that application and system designers make a choice about how to
+   handle authentication, whereas that choice was rarely apparent 15
+   years ago.  One of the most common examples of network elements
+   interposing between end hosts are those dedicated to security:
+   firewalls, VPN tunnel endpoints, certificate servers, etc.  These
+   intermediaries are designed to protect the network from unimpeded
+   attack or to allow two end nodes whose users may have no inherent
+   reason to trust each other to achieve some level of authentication.
+
+
+
+Kempf & Austein              Informational                      [Page 6]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   At the same time, these measures act as impediments for end-to-end
+   communications.  Third party trust intermediaries are not a
+   requirement for security, as end-to-end security mechanisms, such as
+   S/MIME [15], can be used instead, and where third party measures such
+   as PKI infrastructure or keys in DNS are utilized to exchange keying
+   material, they don't necessarily impinge on end-to-end traffic after
+   authentication has been achieved.  Even if third parties are
+   involved, ultimately it is up to the endpoints and their users in
+   particular, to determine which third parties they trust.
+
+3.2.  New Service Models
+
+   New service models inspired by new applications require achieving the
+   proper performance level as a fundamental part of the delivered
+   service.  These service models are a significant change from the
+   original best effort service model.  Email, file transfer, and even
+   Web access aren't perceived as failing if performance degrades,
+   though the user may become frustrated at the time required to
+   complete the transaction.  However, for streaming audio and video, to
+   say nothing of real time bidirectional voice and video, achieving the
+   proper performance level, whatever that might mean for an acceptable
+   user experience of the service, is part of delivering the service,
+   and a customer contracting for the service has a right to expect the
+   level of performance for which they have contracted.  For example,
+   content distributors sometimes release content via content
+   distribution servers that are spread around the Internet at various
+   locations to avoid delays in delivery if the server is topologically
+   far away from the client.  Retail broadband and multimedia services
+   are a new service model for many service providers.
+
+3.3.  Rise of the Third Party
+
+   Academic and government institutions ran the Internet of 15 years
+   ago.  These institutions did not expect to make a profit from their
+   investment in networking technology.  In contrast, the network
+   operator with which most Internet users deal today is the commercial
+   ISP.  Commercial ISPs run their networks as a business, and their
+   investors rightly expect the business to turn a profit.  This change
+   in business model has led to a certain amount of pressure on ISPs to
+   increase business prospects by deploying new services.
+
+   In particular, the standard retail dialup bit pipe account with email
+   and shell access has become a commodity service, resulting in low
+   profit margins.  While many ISPs are happy with this business model
+   and are able to survive on it, others would like to deploy different
+   service models that have a higher profit potential and provide the
+   customer with more or different services.  An example is retail
+   broadband bit pipe access via cable or DSL coupled with streaming
+
+
+
+Kempf & Austein              Informational                      [Page 7]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   multimedia.  Some ISPs that offer broadband access also deploy
+   content distribution networks to increase the performance of
+   streaming media.  These services are typically deployed so that they
+   are only accessible within the ISP's network, and as a result, they
+   do not contribute to open, end-to-end service.  From an ISP's
+   standpoint, however, offering such service is an incentive for
+   customers to buy the ISP's service.
+
+   ISPs are not the only third party intermediary that has appeared
+   within the last 10 years.  Unlike the previous involvement of
+   corporations and governments in running the Internet, corporate
+   network administrators and governmental officials have become
+   increasingly demanding of opportunities to interpose between two
+   parties in an end-to-end conversation.  A benign motivation for this
+   involvement is to mitigate the lack of trust, so the third party acts
+   as a trust anchor or enforcer of good behavior between the two ends.
+   A less benign motivation is for the third parties to insert policy
+   for their own reasons, perhaps taxation or even censorship.  The
+   requirements of third parties often have little or nothing to do with
+   technical concerns, but rather derive from particular social and
+   legal considerations.
+
+4.  Whither the End-to-End Principle?
+
+   Given the pressures on the end-to-end principle discussed in the
+   previous section, a question arises about the future of the end-to-
+   end principle.  Does the end-to-end principle have a future in the
+   Internet architecture or not?  If it does have a future, how should
+   it be applied?  Clearly, an unproductive approach to answering this
+   question is to insist upon the end-to-end principle as a
+   fundamentalist principle that allows no compromise.  The pressures
+   described above are real and powerful, and if the current Internet
+   technical community chooses to ignore these pressures, the likely
+   result is that a market opportunity will be created for a new
+   technical community that does not ignore these pressures but which
+   may not understand the implications of their design choices.  A more
+   productive approach is to return to first principles and re-examine
+   what the end-to-end principle is trying to accomplish, and then
+   update our definition and exposition of the end-to-end principle
+   given the complexities of the Internet today.
+
+4.1.  Consequences of the End-to-End Principle
+
+   In this section, we consider the two primary desirable consequences
+   of the end-to-end principle: protection of innovation and provision
+   of reliability and robustness.
+
+
+
+
+
+Kempf & Austein              Informational                      [Page 8]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+4.1.1.  Protection of Innovation
+
+   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 that most users
+   don't want to update them anyway - does not apply to all nodes and
+   all users.  Many end nodes are still user configurable and a sizable
+   percentage of users are "early adopters," who are willing to put up
+   with a certain amount of technological grief in order to try out a
+   new idea.  And, even for the closed boxes and uninvolved users,
+   downloadable code that abides by the end-to-end principle can provide
+   fast service innovation.  Requiring someone with a new idea for a
+   service to convince a bunch of ISPs or corporate network
+   administrators to modify their networks is much more difficult than
+   simply putting up a Web page with some downloadable software
+   implementing the service.
+
+4.1.2.  Reliability and Trust
+
+   Of increasing concern today, however, is the decrease in reliability
+   and robustness that results from deliberate, active attacks on the
+   network infrastructure and end nodes.  While the original developers
+   of the Internet were concerned by large-scale system failures,
+   attacks of the subtlety and variety that the Internet experiences
+   today were not a problem during the original development of the
+   Internet.  By and large, the end-to-end principle was not addressed
+   to the decrease in reliability resulting from attacks deliberately
+   engineered to take advantage of subtle flaws in software.  These
+   attacks are part of the larger issue of the trust breakdown discussed
+   in Section 3.1.  Thus, the issue of the trust breakdown can be
+   considered another forcing function on the Internet architecture.
+
+   The immediate reaction to this trust breakdown has been to try to
+   back fit security into existing protocols.  While this effort is
+   necessary, it is not sufficient.  The issue of trust must become as
+   firm an architectural principle in protocol design for the future as
+   the end-to-end principle is today.  Trust isn't simply a matter of
+   adding some cryptographic protection to a protocol after it is
+   designed.  Rather, prior to designing the protocol, the trust
+   relationships between the network elements involved in the protocol
+   must be defined, and boundaries must be drawn between those network
+   elements that share a trust relationship.  The trust boundaries
+   should be used to determine what type of communication occurs between
+   the network elements involved in the protocol and which network
+   elements signal each other.  When communication occurs across a trust
+   boundary, cryptographic or other security protection of some sort may
+
+
+
+Kempf & Austein              Informational                      [Page 9]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   be necessary.  Additional measures may be necessary to secure the
+   protocol when communicating network elements do not share a trust
+   relationship.  For example, a protocol might need to minimize state
+   in the recipient prior to establishing the validity of the
+   credentials from the sender in order to avoid a memory depletion DoS
+   attack.
+
+4.2.  The End-to-End Principle in Applications Design
+
+   The concern expressed by the end-to-end principle is applicable to
+   applications design too.  Two key points in designing application
+   protocols are to ensure they don't have any dependencies that would
+   break the end-to-end principle and to ensure that they can identify
+   end points in a consistent fashion.  An example of the former is
+   layer violations - creating dependencies that would make it
+   impossible for the transport layer, for example, to do its work
+   appropriately.  Another issue is the desire to insert more
+   applications infrastructure into the network.  Architectural
+   considerations around this issue are discussed in RFC 3238 [5].  This
+   desire need not result in a violation of the end-to-end principle if
+   the partitioning of functioning is done so that services provided in
+   the network operate with the explicit knowledge and involvement of
+   endpoints, when such knowledge and involvement is necessary for the
+   proper functioning of the service.  The result becomes a distributed
+   application, in which the end-to-end principle applies to each
+   connection involved in implementing the application.
+
+5.  Internet Standards as an Arena for Conflict
+
+   Internet standards have increasingly become an arena for conflict
+   [10].  ISPs have certain concerns, businesses and government have
+   others, and vendors of networking hardware and software still others.
+   Often, these concerns conflict, and sometimes they conflict with the
+   concerns of the end users.  For example, ISPs are reluctant to deploy
+   interdomain QoS services because, among other reasons, every known
+   instance creates a significant and easily exploited DoS/DDoS
+   vulnerability.  However, some end users would like to have end-to-
+   end, Diffserv or Intserv-style QoS available to improve support for
+   voice and video multimedia applications between end nodes in
+   different domains, as discussed by Huston in RFC 2990 [16].  In this
+   case, the security, robustness, and reliability concerns of the ISP
+   conflict with the desire of users for a different type of service.
+
+   These conflicts will inevitably be reflected in the Internet
+   architecture going forward.  Some of these conflicts are impossible
+   to resolve on a technical level, and would not even be desirable,
+   because they involve social and legal choices that the IETF is not
+   empowered to make (for a counter argument in the area of privacy, see
+
+
+
+Kempf & Austein              Informational                     [Page 10]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   Goldberg, et al. [17]).  But for those conflicts that do involve
+   technical choices, the important properties of user choice and
+   empowerment, reliability and integrity of end-to-end service,
+   supporting trust and "good network citizen behavior," and fostering
+   innovation in services should be the basis upon which resolution is
+   made.  The conflict will then play out on the field of the resulting
+   architecture.
+
+6.  Conclusions
+
+   The end-to-end principle continues to guide technical development of
+   Internet standards, and remains as important today for the Internet
+   architecture as in the past.  In many cases, unbundling of the end-
+   to-end principle into its consequences leads to a distributed
+   approach in which the end-to-end principle applies to interactions
+   between the individual pieces of the application, while the unbundled
+   consequences, protection of innovation, reliability, and robustness,
+   apply to the entire application.  While the end-to-end principle
+   originated as a focused argument about the need for the knowledge and
+   assistance of end nodes to properly implement functions in a
+   communication system, particular second order properties developed by
+   the Internet as a result of the end-to-end principle have come to be
+   recognized as being as important, if not more so, than the principle
+   itself.  End user choice and empowerment, integrity of service,
+   support for trust, and "good network citizen behavior" are all
+   properties that have developed as a consequence of the end-to-end
+   principle.  Recognizing these properties in a particular proposal for
+   modifications to the Internet has become more important than before
+   as the pressures to incorporate services into the network have
+   increased.  Any proposal to incorporate services in the network
+   should be weighed against these properties before proceeding.
+
+7.  Acknowledgements
+
+   Many of the ideas presented here originally appeared in the works of
+   Dave Clark, John Wroclawski, Bob Braden, Karen Sollins, Marjory
+   Blumenthal, and Dave Reed on forces currently influencing the
+   evolution of the Internet.  The authors would particularly like to
+   single out the work of Dave Clark, who was the original articulator
+   of the end-to-end principle and who continues to inspire and guide
+   the evolution of the Internet architecture, and John Wroclawski, with
+   whom conversations during the development of this paper helped to
+   clarify issues involving tussle and the Internet.
+
+
+
+
+
+
+
+
+Kempf & Austein              Informational                     [Page 11]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+8.  Security Considerations
+
+   This document does not propose any new protocols, and therefore does
+   not involve any security considerations in that sense.  However,
+   throughout this document, there are discussions of the privacy and
+   integrity issues and the architectural requirements created by those
+   issues.
+
+9.  Informative References
+
+   [1]  Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End
+        Arguments in System Design," ACM TOCS, Vol 2, Number 4, November
+        1984, pp 277-288.
+
+   [2]  Clark, D., "The Design Philosophy of the DARPA Internet
+        Protocols," Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August
+        1988, pp. 106-114.
+
+   [3]  Blumenthal, M., Clark, D.D., "Rethinking the design of the
+        Internet: The end-to-end arguments vs. the brave new world", ACM
+        Transactions on Internet Technology, Vol. 1, No. 1, August 2001,
+        pp 70-109.
+
+   [4]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+        September 1981.
+
+   [5]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
+        Considerations for Open Pluggable Edge Services", RFC 3238,
+        January 2002.
+
+   [6]  Carpenter, B., Ed., "Architectural Principles of the Internet",
+        RFC 1958, June 1996.
+
+   [7]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
+        IPv6", Work in Progress.
+
+   [8]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
+        August 2002.
+
+   [9]  Kaat, M., "Overview of 1999 IAB Network Layer Workshop," RFC
+        2956, October 2000.
+
+   [10] Clark, D.D., Wroclawski, J., Sollins, K., and Braden, B.,
+        "Tussle in Cyberspace: Defining Tomorrow's Internet",
+        Proceedings of Sigcomm 2002.
+
+   [11] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
+        RFC 3234, February, 2002.
+
+
+
+Kempf & Austein              Informational                     [Page 12]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+   [12] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
+
+   [13] Reed, D., "The End of the End-to-End Argument?",
+        http://www.reed.com/dprframeweb/
+        dprframe.asp?section=paper&fn=endofendtoend.html, April 2000.
+
+   [14] Moors, T., "A Critical Review of End-to-end Arguments in System
+        Design," Proc. 2000 IEEE International Conference on
+        Communications, pp. 1214-1219, April, 2002.
+
+   [15] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
+        2633, June 1999.
+
+   [16] Huston, G., "Next Steps for the IP QoS Architecture", RFC 2990,
+        November 2000.
+
+   [17] Goldberg, I., Wagner, D., and Brewer, E., "Privacy-enhancing
+        technologies for the Internet," Proceedings of IEEE COMPCON 97,
+        pp. 103-109, 1997.
+
+10. Author Information
+
+   Internet Architecture Board
+   EMail:  iab@iab.org
+
+   IAB Membership at time this document was completed:
+
+      Bernard Aboba
+      Harald Alvestrand
+      Rob Austein
+      Leslie Daigle
+      Patrik Faltstrom
+      Sally Floyd
+      Jun-ichiro Itojun Hagino
+      Mark Handley
+      Geoff Huston
+      Charlie Kaufman
+      James Kempf
+      Eric Rescorla
+      Mike St. Johns
+
+
+
+
+
+
+
+
+
+
+
+Kempf & Austein              Informational                     [Page 13]
+
+RFC 3724                  Future of End-to-End                March 2004
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Kempf & Austein              Informational                     [Page 14]
+