idnits 2.17.1 draft-rosenberg-internet-waist-hourglass-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 328. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 11, 2008) is 5912 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-tuexen-sctp-udp-encaps-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Rosenberg 3 Internet-Draft Cisco 4 Intended status: Best Current February 11, 2008 5 Practice 6 Expires: August 14, 2008 8 UDP and TCP as the New Waist of the Internet Hourglass 9 draft-rosenberg-internet-waist-hourglass-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 14, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 One of the fundamental design principles of the Internet is that IP 43 represents a common intermediate protocol layer, linking together a 44 variety of link layer technologies underneath with a large number of 45 applications on top. When drawn graphically, this can be show as an 46 hourglass with IP in the middle. The preponderence of NATs and 47 firewalls in the Internet has changed this reality, such that UDP and 48 TCP are now the waist of the hourglass. This document discusses this 49 change and describes its implications for protocol and application 50 design. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. What Caused the New Model? . . . . . . . . . . . . . . . . . . 4 57 4. New Transport Protocols . . . . . . . . . . . . . . . . . . . . 5 58 5. What about IPv6? . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Intellectual Property and Copyright Statements . . . . . . . . . . 8 67 1. Terminology 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 73 2. Introduction 75 One of the fundamental design principles of the Internet is that IP 76 represents a common intermediate protocol layer. This intermediate 77 layer is designed to support a variety of link layers - ethernet, 78 fiber, ATM, and so on. Furthermore, new link layer technologies can 79 be added in the future, without affecting IP itself. 81 In addition, IP can support a broad set of applications on top of it, 82 ranging from email to instant messaging to voice over IP. All of 83 those applications do not require changes to IP itself. As with link 84 layers, new applications can be added at any time. 86 This design principle is often described as, "Everything over IP, and 87 IP over everything". Graphically, it is often shown as an hourglass, 88 with IP in the middle: 90 +------+------+------+------+------+ 91 |Email | Web | VoIP | P2P | RTSP | 92 +------+------+------+------+------+ 93 | TCP | UDP | ICMP | 94 +------+------+------+ 95 | IP | 96 +------+------+------+ 97 |Ether |Sonet | ATM | 98 +------+------+------+------+------+ 99 |Fiber | TP | CAT5 | WiFi | GSM | 100 +------+------+------+------+------+ 102 Figure 1: The Original IP Hourglass 104 This simple design is at the core of the success of the Internet, and 105 is arguably the foundational principle on which it exists. 107 Unfortunately, there is a new reality in the Internet. Like it or 108 not, this model is no longer true. 110 The preponderence of NATs and firewalls in the Internet has created a 111 new model. In this new model, the waist of the hourglass is now UDP 112 and TCP, with ICMP being squeezed out. The new model looks like 113 this: 115 +------+------+------+------+------+ 116 |Email | Web | VoIP | P2P | RTSP | 117 +------+------+------+------+------+ 118 |TCP/IP|UDP/IP| 119 +--+------+------+---+ 120 |Ether |Sonet | ATM | 121 +------+------+------+------+------+ 122 |Fiber | TP | CAT5 | WiFi | GSM | 123 +------+------+------+------+------+ 125 Figure 2: The Original IP Hourglass 127 This draft explains why this has happened and why it is now 128 impossible to define new protocols natively on top of IP, discusses 129 the implication for protocol design, and then considers the 130 implications for IPv6. 132 3. What Caused the New Model? 134 Originally, NAT was designed to operate strictly at the IP layer - 135 translating internal to external addresses 1-for-1. This was done 136 primarily to avoid network renumbering when there was a change in 137 provider. However, NAT-P - NAT with port translation - quickly 138 emerged. In NAT-P, a large number of hosts can utilize a single 139 external IP address by using the UDP and TCP port numbers as a 140 demultiplexing point. 142 In essence, the UDP or TCP port number became an extended version of 143 the IP address - adding another 16 bits to the total amount of space, 144 providing for 48 overall. 146 NAT-P in particular, often just called NAT, has seem extremely 147 widespread deployment. Almost every residence with broadband 148 Internet is running NAT (NAT-P to be specific). NAT is common in 149 enterprises, and there are more and more cases of multilayer NAT 150 within a single enterprise. Service providers have been known to NAT 151 entire networks; for example some wireless networks give mobile 152 devices net-10 addresses. 154 When put together, the implication is that basic packet transport 155 between point A and point B is, these days, frequently possible only 156 if the transport is UDP or TCP. This is because NAT-P requires one 157 of these two in order to utilize the 16 bit ports as as a 158 demultiplexing point. NATs, which are part of the network, have 159 become not just TCP and UDP-aware, they have become TCP and UDP 160 *dependent*. Almost every NAT in deployment today will simply 161 discard a packet above IP that is not TCP or UDP. The primary 162 exception is ICMP. Some NATs will pass ICMP packets, but it is 163 filtered by many. Consequently, it only sometimes works on the 164 Internet. This is also making it difficult to rely on. Indeed, it's 165 success rate is sufficiently poor that new mechanisms for path MTU 166 discovery have been designed which work without ICMP [RFC4821]. 168 This means that the operation of the public Internet is dependent on 169 the existence of UDP and TCP traffic. While it is true that, in some 170 cases you can get other transport protocols to run between two hosts, 171 if you want RELIABLE transport on the Internet - transport that works 172 between ANY two points - you have but two choices - UDP or TCP. 173 Nothing else works reliably, or even close to reliably. 175 Its not just NAT. Firewalls are also TCP and UDP aware, and are 176 often configured to discard non-UDP or non-TCP traffic. 178 4. New Transport Protocols 180 Does this mean that it is impossible to define new transport 181 protocols? Fortunately, the answer is no. 183 New transport protocols can be defined. However, if the intention is 184 that these protocols ever actually work on the public Internet, they 185 need to run on top of the only available packet transport on the 186 Internet - UDP/IP. UDP has replaced IP as the 'raw' point to point 187 packet transport on the Internet. If congestion control or signaling 188 or other features are desired, they must be layered on top of UDP, 189 rather than in a new protocol beside it. 191 It is tempting to design a protocol on top of IP in such a way that 192 it is "NAT friendly". In this context, "NAT friendly" means that the 193 protocol has been designed to make ALGs for that protocol easy to 194 implement. However, there is a vicious cycle that prevents such ALG 195 functionality from ever being built. New features get added to 196 products, such as NATs, when the market demands them. The market 197 demands them when there is enough usage to create such a demand. 198 However, if the protocol will fail utterly to work in the face of 199 existing NAT, there will never be enough usage to create such demand. 200 Even if there was, the amount of time it would take to upgrade all of 201 the NATs on the Internet to support this ALG functionality is 202 astoundingly large. Thus, the protocol will continue to be 203 unreliable on the Internet, since there is always a chance that it 204 hits a NAT which doesn't support the necessary ALG functionality. 206 Consequently, designing protocols to be "NAT friendly" in this way 207 does not work in practice. New applications and protocols MUST be 208 designed to run on top of either UDP or TCP. Full stop. Examples of 209 where this has been done after the fact is 210 [I-D.tuexen-sctp-udp-encaps] for SCTP and [RFC3948] for IPSec. 211 However, it is far better to define this at the beginning, and 212 furthermore, have it as the one and only mode of operation. This 213 avoid protocol choices, and therefore simplifies design and improves 214 interoperability. 216 5. What about IPv6? 218 Will the IPv6 Internet share the same fate as the IPv4 Internet, and 219 work only with UDP and TCP? It seems likely that the answer will be 220 yes. 222 The primary reason is that the IPv6 Internet is not something that 223 will appear overnight to replace the IPv4 Internet. It will run 224 alongside it for a very long time. Hosts that have connection to the 225 IPv6 Internet will find themselves frequently using IPv4 (in a dual- 226 stack deployment), because the target host is available only on IPv4, 227 or will find themselves communicating with via IPv6 to a v4-only host 228 through NAT. In both cases, any protocols except for UDP and TCP 229 based protocols will not work. And thus, the v6 host will need to 230 utilize protocols that do work in all cases - ones based on UDP and 231 TCP - rather than ones that work only in a few cases. And so, when 232 we eventually do cutover to IPv6 only, it will be with hosts which 233 have, all along, only been running protocols that run on top of UDP 234 or TCP. 236 Another reason is that the IPv6 Internet will certainly be filled 237 with firewalls, and if history is any guide for the future, only TCP 238 and UDP are likely to work through such firewalls. 240 Finally, the IPv6 Internet may be filled with NAT anyway, despite 241 attempts to provide ample address space. 243 Consequently, for an application designers perspective, why build an 244 application on top of a protocol which doesn't work on the IPv4 245 Internet, and won't work on anything but a pure IPv6 network, when an 246 application running on top of UDP or TCP will work everywhere? 248 6. Security Considerations 250 This document does not introduce any additional security 251 considerations for the Internet. 253 7. Acknowledgements 255 The author would like to thank Dan Wing, Cullen Jennings, Scott Brim, 256 Paul Kyzivat, and Dave Oran for their comments. 258 8. References 260 8.1. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 8.2. Informative References 267 [I-D.tuexen-sctp-udp-encaps] 268 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 269 Packets", draft-tuexen-sctp-udp-encaps-01 (work in 270 progress), November 2006. 272 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 273 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 274 RFC 3948, January 2005. 276 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 277 Discovery", RFC 4821, March 2007. 279 Author's Address 281 Jonathan Rosenberg 282 Cisco 283 Edison, NJ 284 US 286 Phone: +1 973 952-5000 287 Email: jdrosen@cisco.com 288 URI: http://www.jdrosen.net 290 Full Copyright Statement 292 Copyright (C) The IETF Trust (2008). 294 This document is subject to the rights, licenses and restrictions 295 contained in BCP 78, and except as set forth therein, the authors 296 retain all their rights. 298 This document and the information contained herein are provided on an 299 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 300 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 301 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 302 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 303 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 304 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 306 Intellectual Property 308 The IETF takes no position regarding the validity or scope of any 309 Intellectual Property Rights or other rights that might be claimed to 310 pertain to the implementation or use of the technology described in 311 this document or the extent to which any license under such rights 312 might or might not be available; nor does it represent that it has 313 made any independent effort to identify any such rights. Information 314 on the procedures with respect to rights in RFC documents can be 315 found in BCP 78 and BCP 79. 317 Copies of IPR disclosures made to the IETF Secretariat and any 318 assurances of licenses to be made available, or the result of an 319 attempt made to obtain a general license or permission for the use of 320 such proprietary rights by implementers or users of this 321 specification can be obtained from the IETF on-line IPR repository at 322 http://www.ietf.org/ipr. 324 The IETF invites any interested party to bring to its attention any 325 copyrights, patents or patent applications, or other proprietary 326 rights that may cover technology that may be required to implement 327 this standard. Please address the information to the IETF at 328 ietf-ipr@ietf.org. 330 Acknowledgment 332 Funding for the RFC Editor function is provided by the IETF 333 Administrative Support Activity (IASA).