One document matched: draft-rosenberg-internet-waist-hourglass-00.xml

<?xml version="1.0" encoding="utf-8"?>
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc symrefs='yes'?>

<?rfc compact='yes'?>
<?rfc subcompact='no'?>

<rfc ipr="full3978" category="bcp">


    <front>
        <title abbrev="The New Waist">
UDP and TCP as the New Waist of the Internet Hourglass</title>
    
        <author initials="J.R." surname="Rosenberg"
                fullname="Jonathan Rosenberg">
            <organization>Cisco</organization>
    
            <address>
                <postal>
                    <city>Edison</city> <region>NJ</region>
                    <country>US</country>
                </postal>
    
                <phone>+1 973 952-5000</phone>
                <email>jdrosen@cisco.com</email>
                <uri>http://www.jdrosen.net</uri>
            </address>
        </author>
    
        <date month="February" year="2008" />
    
        <keyword>NAT</keyword>
        <keyword>Waist</keyword>
        <keyword>Internet architecture</keyword>
        <abstract>
            <t>One of the fundamental design principles of the
            Internet is that IP represents a common intermediate
            protocol layer, linking together a variety of link layer
            technologies underneath with a large number of
            applications on top. When drawn graphically, this can be
            show as an hourglass with IP in the middle. The
            preponderence of NATs and firewalls in the Internet has
            changed this reality, such that UDP and TCP are now the
            waist of the hourglass. This document discusses this
            change and describes its implications for protocol
            and application design.</t>
        </abstract>
    </front>

<middle>

<section title="Terminology">

<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.  </t>

</section>

<section title="Introduction">

<t>
One of the fundamental design principles of the Internet is that IP
represents a common intermediate protocol layer. This intermediate layer is
designed to support a variety of link layers - ethernet, fiber, ATM,
and so on. Furthermore, new link layer technologies can be added in
the future, without affecting IP itself. 
</t>

<t>
In addition, IP can support a broad set of applications on top of it,
ranging from email to instant messaging to voice over IP. All of those
applications do not require changes to IP itself. As with link layers,
new applications can be added at any time.
</t>

<t>
This design principle is often described as, "Everything over IP, and
IP over everything". Graphically, it is often shown as an hourglass,
with IP in the middle:
</t>



<figure title="The Original IP Hourglass" anchor="fig-orig-hourglass"><artwork>
<![CDATA[
                                                                          
            +------+------+------+------+------+                          
            |Email | Web  | VoIP | P2P  | RTSP |                          
            +------+------+------+------+------+                          
                   | TCP  |  UDP | ICMP |                                 
                   +------+------+------+                                 
                          |  IP  |                                        
                   +------+------+------+                                 
                   |Ether |Sonet | ATM  |                                 
            +------+------+------+------+------+                          
            |Fiber | TP   | CAT5 | WiFi | GSM  |                          
            +------+------+------+------+------+                          
]]></artwork></figure>

<t>
This simple design is at the core of the success of the Internet, and
is arguably the foundational principle on which it exists.
</t>

<t>
Unfortunately, there is a new reality in the Internet. Like it or not,
this model is no longer true. 
</t>

<t>
The preponderence of NATs and firewalls in the Internet has created a
new model. In this new model, the waist of the hourglass is now UDP
and TCP, with ICMP being squeezed out. The new model looks like this:
</t>

<figure title="The Original IP Hourglass" anchor="fig-new-hourglass"><artwork>
<![CDATA[
                                                                          
            +------+------+------+------+------+                          
            |Email | Web  | VoIP | P2P  | RTSP |                          
            +------+------+------+------+------+                          
                      |TCP/IP|UDP/IP|                                     
                   +--+------+------+---+                                 
                   |Ether |Sonet | ATM  |                                 
            +------+------+------+------+------+                          
            |Fiber | TP   | CAT5 | WiFi | GSM  |                          
            +------+------+------+------+------+                          
]]></artwork></figure>


<t>
This draft explains why this has happened and  why it is now impossible to
define new protocols natively on top of IP, discusses the implication
for protocol design, and then considers the implications for IPv6.
</t>

</section>

<section title="What Caused the New Model?">

<t>
Originally, NAT was designed to operate strictly at the IP layer -
translating internal to external addresses 1-for-1. This was done
primarily to avoid network renumbering when there was a change in
provider. However, NAT-P - NAT with port translation - quickly
emerged. In NAT-P, a large number of hosts can utilize a single
external IP address by using the UDP and TCP port numbers as a
demultiplexing point.
</t>

<t>
In essence, the UDP or TCP port number became an extended version of
the IP address - adding another 16 bits to the total amount of space,
providing for 48 overall.
</t>

<t>
NAT-P in particular, often just called NAT, has seem extremely
widespread deployment. Almost every residence with broadband Internet
is running NAT (NAT-P to be specific). NAT is common in enterprises,
and there are more and more cases of multilayer NAT within a single
enterprise. Service providers have been known to NAT entire networks;
for example some wireless networks give mobile devices net-10
addresses. 
</t>

<t>
When put together, the implication is that basic packet transport
between point A and point B is, these days, frequently possible only
if the transport is UDP or TCP. This is because NAT-P requires one of
these two in order to utilize the 16 bit ports as as a demultiplexing
point. NATs, which are part of the network, have become not just TCP
and UDP-aware, they have become TCP and UDP *dependent*. Almost every
NAT in deployment today will simply discard a packet above IP that is
not TCP or UDP. The primary exception is ICMP. Some NATs will pass
ICMP packets, but it is filtered by many. Consequently, it only
sometimes works on the Internet. This is also making it difficult to
rely on. Indeed, it's success rate is sufficiently poor
that new mechanisms for path MTU discovery have been designed which
work without ICMP <xref target="RFC4821"/>.
</t>

<t>
This means that the operation of the public Internet is dependent on
the existence of UDP and TCP traffic. While it is true that, in some
cases you can get other transport protocols to run between two hosts,
if you want RELIABLE transport on the Internet - transport that works
between ANY two points - you have but two choices - UDP or
TCP. Nothing else works reliably, or even close to reliably.
</t>

<t>
Its not just NAT. Firewalls are also TCP and UDP aware, and are often
configured to discard non-UDP or non-TCP traffic. 
</t>

</section>

<section title="New Transport Protocols">

<t>
Does this mean that it is impossible to define new transport
protocols? Fortunately, the answer is no.
</t>

<t>
New transport protocols can be defined. However, if the intention is
that these protocols ever actually work on the public Internet, they
need to run on top of the only available packet transport on the
Internet - UDP/IP. UDP has replaced IP as the 'raw' point to point
packet transport on the Internet. If congestion control or signaling
or other features are desired, they must be layered on top of UDP,
rather than in a new protocol beside it.
</t>

<t>
It is tempting to design a protocol on top of IP in such a way that it
is "NAT friendly". In this context, "NAT friendly" means that the
protocol has been designed to make ALGs for that protocol easy to
implement. However, there is a vicious cycle that prevents
such ALG functionality from ever being built. New features get added
to products, such as NATs, when the market demands them. The market
demands them when there is enough usage to create such a
demand. However, if the protocol will fail utterly to work in the face
of existing NAT, there will never be enough usage to create such
demand. Even if there was, the amount of time it would take to upgrade
all of the NATs on the Internet to support this ALG functionality is
astoundingly large. Thus, the protocol will continue to be unreliable
on the Internet, since there is always a chance that it hits a NAT
which doesn't support the necessary ALG functionality.
</t>

<t>
Consequently, designing protocols to be "NAT friendly" in this way
does not work in practice. New applications and protocols MUST be
designed to run on top of either UDP or TCP. Full stop. Examples of
where this has been done after the fact is
<xref target="I-D.tuexen-sctp-udp-encaps"/> for SCTP and
<xref target="RFC3948"/> for IPSec. However, it is far better to
define this at the beginning, and furthermore, have it as the one and
only mode of operation. This avoid protocol choices, and therefore
simplifies design and improves interoperability.
</t>


</section>

<section title="What about IPv6?">

<t>
Will the IPv6 Internet share the same fate as the IPv4 Internet, and
work only with UDP and TCP? It seems likely that the answer will be
yes.
</t>

<t>
The primary reason is that the IPv6 Internet is not something that
will appear overnight to replace the IPv4 Internet. It will run
alongside it for a very long time. Hosts that have connection to the
IPv6 Internet will find themselves frequently using IPv4 (in a
dual-stack deployment), because the target host is available only on
IPv4, or will find themselves communicating with via IPv6 to a v4-only
host through NAT. In both cases, any protocols except for UDP and TCP
based protocols will not work. And thus, the v6 host will need to
utilize protocols that do work in all cases - ones based on UDP and
TCP - rather than ones that work only in a few cases. And so, when we
eventually do cutover to IPv6 only, it will be with hosts which have,
all along, only been running protocols that run on top of UDP or TCP.
</t>

<t>
Another reason is that the IPv6 Internet will certainly be filled with
firewalls, and if history is any guide for the future, only TCP and
UDP are likely to work through such firewalls.
</t>

<t>
Finally, the IPv6 Internet may be filled with NAT anyway, despite
attempts to provide ample address space. 
</t>

<t>
Consequently, for an application designers perspective, why build an
application on top of a protocol which doesn't work on the IPv4
Internet, and won't work on anything but a pure IPv6 network, when an
application running on top of UDP or TCP will work everywhere?
</t>

</section>

<section title="Security Considerations">

<t>
This document does not introduce any additional security
considerations for the Internet. 
</t>

</section>

<section title="Acknowledgements">

<t>The author would like to thank Dan Wing, Cullen Jennings, Scott
  Brim, Paul Kyzivat, and Dave Oran for their comments.
</t>

</section>

</middle>

<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.tuexen-sctp-udp-encaps"?>
<?rfc include="reference.RFC.3948"?>
<?rfc include="reference.RFC.4821"?>
</references>

</back>
</rfc>