A number of RFCs have been published that describe methods to encapsulate protocols within UDP. These protocols are normally intended to be encapsulated directly within an IPv4 (or IPv6) packet:
- RFC3948, “UDP Encapsulation of IPsec ESP Packets”
- RFC4380, “Teredo: Tunnelling IPv6 over UDP through Network Address Translations (NATs)”
- RFC6773, “DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal”
- RFC6951, “UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication”
- RFC8086, “GRE-in-UDP Encapsulation”
A simple Internet search for the term “internet draft over udp” also discovers a number of current and expired Internet Drafts describing UDP encapsulation of other protocols, including, surprisingly, a number proposing the encapsulation of TCP in UDP.
- draft-herbert-transports-over-udp, “Transport layer protocols over UDP”
- draft-cheshire-tcp-over-udp, “Encapsulation of TCP and other Transport Protocols over UDP”
- draft-welzl-irtf-iccrg-tcp-in-udp, “TCP in UDP”
- draft-denis-udp-transport, “UDP-Encapsulated Transport Protocols”
- draft-baset-tsvwg-tcp-over-udp, “TCP-over-UDP”
A final example is draft-ietf-quic-transport, “QUIC: A UDP-Based Multiplexed and Secure Transport”. QUIC is a protocol that Google has both developed and deployed in their Chrome browser for use as an alternative to TCP, and is primarily intended to be used to carry HTTP/2 protocol traffic.
Read also Your questions answered about QUIC
What problem(s) are they trying to solve?
Going by just the number of RFCs and drafts describing UDP encapsulation, a number of people have spent time and effort thinking and writing about UDP encapsulation.
So what problem or problems are they attempting to solve?
There are two main reasons other protocols are encapsulated in UDP, even though they may originally have been and commonly are encapsulated in native IPv4.
- To add entropy to the packet, to help distribute packets over multiple paths through the network.
- To allow the UDP encapsulated protocol to traverse middle boxes, primarily Network Address Translators (NATs).
An example of the first problem being solved is RFC8086, “GRE-in-UDP Encapsulation”. GRE, or Generic Routing Encapsulation, is a protocol used to tunnel other protocols across an IP network that doesn’t natively support them. The IP addresses in packets carrying GRE traffic between two points don’t vary, making load distribution based on varying IP addresses ineffective.
Adding a UDP header before the GRE header and varying the source port in the UDP header adds varying information that devices can use to better distribute the packets over different paths (IPv6 has a 20-bit “Flow Label” field in its fixed header to be used to add load distribution entropy rather than needing to add a UDP header – see RFC6437).
Encapsulating in UDP to facilitate NAT box traversal is necessary because many NAT device boxes will only pass UDP and TCP traffic, dropping all other packets. This second problem is the focus of the remainder of this article.
More transparency
Encapsulating in UDP hides the encapsulated protocol from NAT devices, allowing it to successfully pass through the NAT device when it otherwise wouldn’t. This ability comes at the relatively cheap cost of the addition of an 8-octet UDP header.
By encapsulating in UDP for NAT traversal, what is being gained is more end-to-end protocol transparency across the network.
Network or Internet transparency is an attribute of the Internet architecture. The Internet is intended to be transparent to any upper layer protocols that are being carried within the Internet packets, rather than just being restricted to TCP and UDP. RFC2775, “Internet Transparency”, as expected, discusses Internet transparency in detail.
Encapsulating in UDP isn’t restoring full transparency, however. Full transparency also means that each host attached to the network:
- Has a unique network layer address
- Has the ability to send a packet directly to any other host (a security policy or congestion may cause it not to arrive)
- Can use its own address to identify itself to other hosts attached to the same network.
This makes all hosts attached to the same network equals or “peers” of each other. The communications between hosts across this transparent network could be described as peer-to-peer.
There are other benefits of this peer-to-peer nature of the Internet’s network layer, which I’ve described in my previous blog series “The Trouble with NAT”.
One of the fundamental goals of IPv6 is to restore full Internet transparency that has been lost in the IPv4 Internet due to NATs.
A stepping stone network?
The rise of host virtualization has led to the rise of network virtualization, using technologies such as VXLAN. In the IETF, work on these technologies has primarily been occurring in the Network Virtualization Overlays (NVO3) working group.
The technology involves creating a virtual overlay network over the top of a physical underlay network. The virtual overlay network can carry layer 2 or layer 3 packets; the physical underlay network is either using IPv4 or IPv6.
Encapsulating in UDP for the purposes of NAT traversal could be seen to be creating a virtual overlay network for the UDP encapsulated protocol, constructed over the IPv4 underlay network that is suffering from transparency constraints imposed by NAT devices.
This “Foo-over-UDP” network may be established by static configuration. Alternatively, when it is created by an application, such as what the Chrome browser does with QUIC, it could be described as being dynamically created when needed by the application. It is an ad hoc virtual overlay network.
This Foo-over-UDP virtual network could also be seen as a stepping stone network on the path towards an IPv6 Internet. We have an IPv4 Internet where NAT is prevalent, limiting the use of upper layer protocols to TCP and UDP. Encapsulating in UDP creates a new (virtual overlay) network that is more transparent to upper layer protocols, operating over the ubiquitous IPv4 Internet. The final step is an IPv6 Internet that restores full transparency.
Invention cycles
It could be argued that the Foo-over-UDP (over IPv4) network could be the final step, rather than a stepping stone to IPv6. Although IPv6 deployment is occurring and accelerating, IPv4 and host support for UDP is already deployed.
However, deploying IPv6 will also overcome the other limitations of NAT, such as hard-state in the network, that would still exist if we settled for UDP over IPv4.
Invention seems to go in cycles. Once there is a problem to be solved, there is demand for a solution, and if the resources necessary to solve it are available and cheap enough, a solution to the problem is developed.
After the solution is developed, the focus will usually turn to making the solution cost less. This could be to increase the market for the solution by making it more affordable, to compete with somebody else producing the same or a similar solution, or to address the natural human desire for more value for money.
The drive for a cheaper solution may also make the consumers of the solution compromise some of their requirements. They will accept a good enough solution to their problem rather than a perfect one.
We’ve seen this cycle play out in networking in the past.
First, in the late 1990s, networks were multi-protocol, meaning they may have been running two or more layer 3 protocols, usually Novell’s IPX, Apple’s Appletalk and IPv4. Each of these protocols worked differently, however, they were all similar enough that one protocol could be used to solve the different problems that that IPX, Appletalk and IPv4 respectively solved. As IPv4 became ubiquitous, because it provided access to the Internet, Novell and Apple made their services protocols that originally rode over IPX or Appletalk available over IPv4. That resulted in networks converging on using IPv4 for all services.
The same pattern has played out at the link-layer. In the 1990s and 2000s, there were many different link-layers being used in networks, such as ATM, Frame Relay, Token Ring, Ethernet and ISDN. While there were differences, they were all similar enough that one protocol could be used to replace them all. Ethernet, being the cheapest, as it was being used on nearly all local area networks, became the single link-layer protocol being used.
The intention is that IPv6 will eventually become the single layer 3 protocol used in networks, replacing IPv4, once IPv6 has been deployed widely enough. Networks would go from having both IPv4 and IPv6 deployed to converging on IPv6.
The slight difference will be that in addition to converging on a single protocol for cost reasons, IPv6 is also overcoming limitations that now exist in IPv4. The past transitions from multiple network protocols to a single one weren’t also driven by limitations, they were driven purely by reducing operational costs.
Conclusion
Going by the number of RFCs and Internet Drafts relating to UDP encapsulation, for the purpose of IPv4 NAT traversal, there looks to be a strong desire for a more transparent Internet. Not only have these documents been written and published, in one case, QUIC, the protocol has been widely deployed and is being used over the Internet today.
Encapsulating in UDP increases the transparency of the IPv4 + NAT Internet, however, it doesn’t fully restore it, and still leaves a number of other constraints that NAT imposes – the topic of my past blog series.
The intent of IPv6 is to restore full transparency and to also overcome NAT constraints. The desire for efficiency through reduced costs should mean that once IPv6 is widely deployed, it will become the single layer 3 protocol that we use to carry all other protocols.
Mark Smith is a network engineer. He has worked at a number of networked organisations since the early 1990s, including a number of residential and corporate ISPs. Most recently he has been working in the AMI/Smartgrid sector.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Really? IPv6 is now pretty much established outside of enterprise networks (30% of US end user traffic, according to Google:http://bit.ly/2bJxOzL). I have seen – and annoyingly now cannot find – papers outlining significant increased engineering and operational costs from using UDP as a transport. iirc these arise as you’ve got to build your own TCP stack in userland.
“IPv6 is now pretty much established outside of enterprise networks (30% of US end user traffic, according to Google:http://bit.ly/2bJxOzL). ”
Look beyond the US and you’ll find the percentages for the majority of the rest of the world are much lower.
“I have seen – and annoyingly now cannot find – papers outlining significant increased engineering and operational costs from using UDP as a transport. iirc these arise as you’ve got to build your own TCP stack in userland.”
I’m observing what has happened and the costs that have been proposed or been paid in the interests of regaining a level of transparency. I’m not promoting the use of UDP encapsulation; IPv6 should have been deployed far more widely far more earlier than now, such that UDP encapsulation shouldn’t have been necessary to gain the desired increase in transparency.
One of my goals here is to show people who may think an Internet with NATs in it is perfectly fine, that hosts and their applications are already resorting to protocol obfuscation measures to overcome the limitations that NATs impose.
Hi,
I am writing a sample code which receives messages from INADDR_LOOPBACK(IPv4) using below command from a terminal.
while true; do echo $RANDOM > /dev/udp/127.0.0.1/1234; sleep 0.30; done
This code works fine for IPv4 as mentioned.
Now, I have changed the code for IPv6 using corresponding IPv6 structures and trying to receive messages from in6addr_loopback. However I am not sure what command I should use to echo random numbers. I tried below commands however my code is just waiting to receive messages.
while true; do echo $RANDOM > /dev/udp/0:0:0:0:0:0:0:1/1234; sleep 0.30; done
while true; do echo $RANDOM > /dev/udp/::1/1234; sleep 0.30; done
Would you please help me with correct command to echo random numbers on local host.