 What is UDP

 Comparison of UDP and TCP

 TCP
 Reliable
 Ordered
 Heavyweight
 Streaming
 UDP
 Unreliable
 ordered
 Not
 Lightweight
 Datagrams
 Benefits of UDP
 No connection establishment.
 Unregulated send rate.
 support many more active clients
 Major Problems of using UDP
 Reliability Considerations
 Lost Datagrams
 Message Corruption
 Congestion Control
 Sequenced Delivery
 Security Considerations
 Sender Authentication and Message Forgery
 Message Observation
 Replaying
 Unreliable Delivery
 Message Prioritization and Differentiation
 Denial of Service
 UDP Segment Structure
 Data :-
 Length :-
 UDP Checksum :-
 IPv4
 IPv6
 Destination port
 Source port
 UDP Broadcast Flooding
 Implementing IP Helper Addressing
 Implementing UDP Flooding

 Encapsulation and Decapsulation Procedures

 Auxiliary Procedures
 Tunnel Mode Decapsulation NAT Procedure
 Transport Mode Decapsulation NAT Procedure
 Transport Mode ESP Encapsulation
 Transport Mode ESP Decapsulation
 Tunnel Mode ESP Encapsulation
 Tunnel Mode ESP Decapsulation
 Reliability and congestion control solutions
 UDP hole punching
 Description
 Algorithm
 Why is a lighter UDP protocol needed?
 UDP-Lite
 RUDP
 Applications
 UDP is an acronym for User Datagram Protocol, and it is an integral
part of Internet Protocol suite. It was designed by David P. Reed in
1980.UDP is sometimes called the Universal Datagram Protocol.

Fig. : Protocol Stack

 UDP is a connectionless transport layer (layer 4) protocol in OSI model,
The Internet makes two transport protocols available to its applications, UDP
and TCP. UDP provides a simple and unreliable message service for
transaction-oriented services. UDP is basically an interface between IP and
upper-layer processes. UDP protocol ports distinguish multiple applications
running on a single device from one another.

Note:-

Connectionless Protocols: - These protocols do not establish

a connection between devices. As soon as a device has data
to send to another, it just sends it. Service provider usually
cannot guarantee that there will be no loss, error insertion,
misdelivery, duplication, or out-of-sequence delivery of the
packet. No optimizations are possible when sending several
frames between the same two peers

The datagrams sent from one computer to another using UDP may become
lost without getting into notice. Moreover, they may arrive in a different order
as compared to their order when they were sent.

Time-sensitive applications often use UDP because dropping packets is

preferable to waiting for delayed packets, which may not be an option in a
real-time system.

The user datagram protocol or UDP, unlike TCP, doesn’t guarantee the
correct sequence of transferred data. Moreover, it also doesn’t guarantee
any reliability of the data.
TCP Transmission Control Protocol is a connection-oriented protocol,
which means that it requires handshaking to set up end-to-end
communications. Once a connection is set up user data may be sent bi-
directionally over the connection.
 Reliable – TCP manages message acknowledgment, retransmission and
timeout. Many attempts to reliably deliver the message are made. If it gets
lost along the way, the server will re-request the lost part. In TCP, there's
either no missing data, or, in case of multiple timeouts, the connection is
dropped.
 Ordered – if two messages are sent over a connection in sequence, the first
message will reach the receiving application first. When data segments
arrive in the wrong order, TCP buffers the out-of-order data until all data
can be properly re-ordered and delivered to the application.
 Heavyweight – TCP requires three packets to set up a socket connection,
before any user data can be sent. TCP handles reliability and congestion
control.
 Streaming – Data is read as a byte stream, no distinguishing indications are
transmitted to signal message (segment) boundaries.

UDP is a simpler message-based connectionless protocol. Connectionless

protocols do not set up a dedicated end-to-end connection. Communication
is achieved by transmitting information in one direction from source to
destination without verifying the readiness or state of the receiver.
 Unreliable – When a message is sent, it cannot be known if it will reach its
destination; it could get lost along the way. There is no concept of
acknowledgment, retransmission and timeout.
 Not ordered – If two messages are sent to the same recipient, the order in
which they arrive cannot be predicted.
 Lightweight – There is no ordering of messages, no tracking connections,
etc. It is a small transport layer designed on top of IP.
 Datagrams – Packets are sent individually and are checked for integrity
only if they arrive. Packets have definite boundaries which are honored
upon receipt, meaning a read operation at the receiver socket will yield an
entire message as it was originally sent.
All the above factors might give an impression that UDP is not a handy
protocol to use.

However, regardless of its limitations and reliability issues, it still

provides considerable benefits that may come handy in different scenarios.

1. No connection establishment.
There are no delays as UDP does not need to establish a connection.
Thus, an application such as DNS (Domain Name System) would be
much slower over TCP than over UDP.

2. Unregulated send rate.

Unlike its TCP counterpart, which has a congestion control mechanism
that throttles the sender when one or more links between the sender
and the receiver become congested, UDP has no such restrictions.
These restrictions can seriously affect real-time applications, which
may tolerate packet loss but have a minimum send rate.
The capability of UDP to send data is only constrained by the capacity
of the applications to generate data.

3. TCP has connection state in the end systems, which includes receiving
and sending buffers, congestion control parameters, and sequence and
acknowledgment number parameters.
This state information is needed to implement TCP's reliable data
transfer service and to provide congestion control.
UDP, on its part, does not maintain connection state and does not track
any of these parameters.
For this reason, a server devoted to a particular application can
typically support many more active clients when the application runs
over UDP rather than over TCP.
 Despite of its benefits, UDP still have some major problems associated
with it. One of major concern of using User Datagram Protocol is that it
doesn’t offer network congestion control or avoidance mechanism.

 Reliability Considerations
The UDP is an unreliable, low-overhead protocol. This section discusses
reliability issues inherent in UDP that implementers and users should be aware
of.

 Lost Datagrams

This transport mapping does not provide any mechanism to detect and
correct loss of datagrams. Datagrams can be lost in transit due to
congestion, corruption, or any other intermittent network problem. IP
fragmentation exacerbates this problem because loss of a single fragment
will result in the entire message being discarded.

 Message Corruption

The UDP/IP datagrams can get corrupted in transit due to software,

hardware, or network errors. This transport mapping specifies use of UDP
checksums to enable corruption detection in addition to checksums used in
IP and Layer 2 protocols. However, checksums do not guarantee corruption
detection, and this transport mapping does not provide for message
acknowledgement or retransmission mechanism.

 Congestion Control

Because syslog can generate unlimited amounts of data, transferring this

data over UDP is generally problematic, because UDP lacks congestion
control mechanisms.
 Congestion control mechanisms that respond to congestion by reducing
traffic rates and establish a degree of fairness between flows that share the
same path are vital to the stable operation of the Internet. This is why the
syslog TLS (Transport Layer Security) is REQUIRED to implement and
RECOMMENDED for general use.
The only environments where the syslog UDP transport MAY be used as
an alternative to the TLS transport are managed networks, where the
network path has been explicitly provisioned for UDP syslog traffic through
traffic engineering mechanisms, such as rate limiting or capacity
reservations. In all other environments, the TLS transport SHOULD be
used.

 Sequenced Delivery

The IP transport used by the UDP does not guarantee that the sequence of
datagram delivery will match the order in which the datagrams were sent.
The time stamp contained within each syslog message can serve as a rough
guide in establishing sequence order.
However, it will not help in cases where multiple messages were
generated during the same time slot, the sender could not generate a time
stamp, or messages originated from different hosts whose clocks were not
synchronized.
The order of syslog message arrival via this transport SHOULD NOT be
used as an authoritative guide in establishing an absolute or relative
sequence of events on the syslog sender hosts.

Note:-

syslog is a standard for forwarding log messages in an IP

network. The term "syslog" is often used for both the actual syslog
protocol, as well as the application or library sending syslog
messages.
Syslog is a client/server protocol the syslog sender sends a small
(less than 1KB) textual message to the syslog receiver. The receiver
is commonly called "syslogd", "syslog daemon" or "syslog server".
Syslog messages can be sent via UDP and/or TCP. The data is
sent in cleartext; although not part of the syslog protocol itself, an
SSL wrapper can be used to provide for a layer of encryption
through SSL/TLS.
Syslog is typically used for computer system management and
security auditing. While it has a number of shortcomings, syslog is
supported by a wide variety of devices and receivers across multiple
platforms. Because of this, syslog can be used to integrate log data
from many different types of systems into a central repository.
 Security Considerations

Using this specification on an unsecured network is NOT RECOMMENDED.

This section focuses on security considerations specific to the syslog transport
over UDP. Some of the security issues raised in this section can be mitigated
through the use of IPSec as defined in.

 Sender Authentication and Message Forgery

This transport mapping does not provide for strong sender
authentication. The receiver of the syslog message will not be able to
ascertain that the message was indeed sent from the reported sender, or
whether the packet was sent from another device. This can also lead to a
case of mistaken identity if an inappropriately configured machine sends
syslog messages to a receiver representing itself as another machine.

This transport mapping does not provide protection against syslog

message forgery. An attacker can transmit syslog messages (either from the
machine from which the messages are purportedly sent or from any other
machine) to a receiver.

In one case, an attacker can hide the true nature of an attack amidst
many other messages. As an example, an attacker can start generating
forged messages indicating a problem on some machine. This can get the
attention of the system administrators, who will spend their time
investigating the alleged problem. During this time, the attacker could be
able to compromise a different machine or a different process on the same
machine.

Additionally, an attacker can generate false syslog messages to give

untrue indications of the status of systems. As an example, an attacker can
stop a critical process on a machine, which could generate a notification of
exit. The attacker can subsequently generate a forged notification that the
process had been restarted. The system administrators could accept that
misinformation and not verify that the process had indeed not been restarted.
 Message Observation

This transport mapping does not provide confidentiality of the messages

in transit. If syslog messages are in clear text, this is how they will be
transferred. In most cases, passing clear-text, a human-readable message is a
benefit to the administrators.

Unfortunately, an attacker could also be able to observe the human-

readable contents of syslog messages. The attacker could then use the
knowledge gained from these messages to compromise a machine.

It is RECOMMENDED that no sensitive information be transmitted via

this transport mapping or that transmission of such information be restricted
to properly secured networks.

 Replaying
Message forgery and observation can be combined into a replay attack.
An attacker could record a set of messages that indicate normal activity of a
machine.

At a later time, an attacker could remove that machine from the network
and replay the syslog messages with new time stamps. The administrators
could find nothing unusual in the received messages, and their receipt would
falsely indicate normal activity of the machine.

 Unreliable Delivery
As was previously discussed in Section 4, Reliability Considerations,
the UDP transport is not reliable, and packets containing syslog message
datagrams can be lost in transit without any notice.

There can be security consequences to the loss of one or more syslog

messages. Administrators could be unaware of a developing and potentially
serious problem. Messages could also be intercepted and discarded by an
attacker as a way to hide unauthorized activities.
 Message Prioritization and Differentiation
This transport mapping does not mandate prioritization of syslog
messages either on the wire or when processed on the receiving host based
on their severity.

Unless some prioritization is implemented by sender, receiver, and/or

network, the security implication of such behavior is that the syslog receiver
or network devices could get overwhelmed with low-severity messages and
be forced to discard potentially high-severity messages.

 Denial of Service

An attacker could overwhelm a receiver by sending more messages to it

than could be handled by the infrastructure or the device itself.
Implementers SHOULD attempt to provide features that minimize this
threat, such as optionally restricting reception of messages to a set of
known source IP addresses.

 In a UDP network, other forms of congestion control mechanism are

required to be implemented so that UDP can offer smooth network
traffic. One of the potential solutions to this problem is DCCP or the
Datagram Congestion Control Protocol which is specifically designed in
order to the monitor the traffic running in a UDP network.
 The UDP header consists of only 4 fields. Source Port and CheckSum,
The use of two of those is optional in IPv4 . In IPv6 only the source port
is optional.

32 Bits
Destination
Source Port
Port
UDP
Length
Checksum
Data
.
.
UDP segment structure

 Data :-
The application data occupies the data field of the UDP datagram :-

For example,
- For DNS (Domain Name System) , the data field contains either a query
message or a response message.
- For a streaming audio application, audio samples fill the data field.

 Length :-
 It is the length in octets of this user datagram, including this header and
the data.
 In other words, it is the number of bytes comprising the combined UDP
header information and payload data.
 The minimum value of the length is eight.
 UDP Checksum :-
The UDP checksum provides for error detection. Therefore, this protects an
application against receiving corrupted payload data in place of, or in
addition to, the data that was sent. In the cases where this check is not
required, the value of 0x0000 is placed in this field, in which case the data is
not checked by the receiver.

- UDP at the sender side performs the one's complement of the sum of all the
16-bit words in the segment. This result is put in the checksum field of the
UDP segment.
- When the segment arrives (if it arrives!) at the receiving host, all 16-bit
words are added together, including the checksum.
- If this sum equals 1111111111111111, then the segment has no detected
errors.
- If one of the bits is a zero, then we know that errors have been introduced
into the segment.

As an example, suppose that we have the following three 16-bit words:

0110011001100110
0101010101010101
0000111100001111

The sum of first of these 16-bit words is:

0110011001100110
0101010101010101
---------------------------
1011101110111011

Adding the third word to the above sum gives

1011101110111011
0000111100001111
----------------------------
1100101011001010
 - The 1's complement is obtained by converting all the 0s to 1s and
converting all the 1s to 0s.
- Thus the 1's complement of the sum 1100101011001010 is
0011010100110101, which becomes the checksum.
- At the receiver, all four 16-bit words are added, including the checksum.
- Internet checksum is not foolproof -- even if the sum equals
111111111111111, it is still possible that there are undetected errors in the
segment.
- For this reason, a number of protocols use more sophisticated error
detection techniques than simple check summing.
- Although UDP provides error checking, it does not do anything to recover
from an error.

 IPv4
This is usually an IP header, followed by a UDP header and UDP payload
that may be an RTP header and its payload. However, the FULL_HEADER
packet may also carry IP
Encapsulated packets, in which case there would be two IP headers followed
by UDP and possibly RTP

- When UDP runs over IPv4, the checksum is computed using a pseudo-
header that contains information from the IPv4 header:

bits 0 - 7 8 - 15 16 - 23 24 - 31
0 Source address
32 Destination address
64 Zeros Protocol UDP length
96 Source Port Destination Port
128 Length Checksum

160 Data

- The source and destination addresses are those in the IPv4 header. The UDP
length field is the length of the UDP header and data.
- UDP checksum computation is optional for IPv4. If a checksum is not used
it should be set to the value zero.
 IPv6
The packet may be built of some combination of IPv6 and IPv4 headers.
Each successive header is indicated by the type field of the previous
header, as usual.

- When UDP runs over IPv6, the checksum is mandatory.

- Any transport or other upper-layer protocol that includes the addresses
from the IP header in its checksum computation must be modified for use
over IPv6 to include the 128-bit IPv6 addresses.
- When computing the checksum, a pseudo-header is used that mimics the
IPv6 header:

bits 0 - 7 8 - 15 16 - 23 24 - 31
0
32
Source address
64
96
128
160
Destination address
192
224
256 UDP length
288 Zeros Next Header
320 Source Port Destination Port
352 Length Checksum

384 Data

- The source address is the one in the IPv6 header. The destination address
is the final destination; if the IPv6 packet doesn't contain a Routing header,
that will be the destination address in the IPv6 header; otherwise, at the
originating node, it will be the address in the last element of the Routing
header, and, at the receiving node, it will be the destination address in the
IPv6 header. The UDP length field is the length of the UDP header and data.
 Source port
o Source port is an optional field.
o When used, it indicates the port of the sending process and may be
assumed to be the port to which a reply should be addressed in the
absence of any other information.
o If not used, a value of zero is inserted.

 Destination port
o UDP packets from a client use this as a service access point (SAP) to
indicate the service required from the remote server.
o UDP packets from a server carry the client SAP in this field.
 A broadcast is a data packet that is destined for multiple hosts. Broadcasts
can occur at the data link layer and the network layer. Data-link broadcasts
are sent to all hosts attached to a particular physical network. Network layer
broadcasts are sent to all hosts attached to a particular logical network

Because broadcasts are recognized by all hosts, a significant goal of router

configuration is to control unnecessary proliferation of broadcast packets.
Cisco routers support two kinds of broadcasts: directed and flooded.

A directed broadcast is a packet sent to a specific network or series of

networks, whereas a flooded broadcast is a packet sent to every network. In
IP internetworks, most broadcasts take the form of User Datagram Protocol
(UDP) broadcasts.

Although current IP implementations use a broadcast address of all ones,

the first IP implementations used a broadcast address of all zeros. Many of
the early implementations do not recognize broadcast addresses of all ones
and fail to respond to the broadcast correctly. Other early implementations
forward broadcasts of all ones,

This causes a serious network overload known as a broadcast storm.

Implementations that exhibit these problems include systems based on
versions of BSD UNIX prior to Version 4.3.Two different approaches can be
used to configure Cisco routers for forwarding UDP broadcast traffic: IP
helper addressing and UDP flooding.

 Implementing IP Helper Addressing

IP helper addressing is a form of static addressing that uses directed

broadcasts to forward local and all-nets broadcasts to desired destinations
within the internet work. IP helper addressing is well-suited to
nonredundant, nonparallel topologies that do not require a mechanism for
controlling broadcast loops.
Although IP helper addressing is useful in networks that do not require
redundancy, when configured in networks that feature redundancy,
 IP helper addressing results in packet duplication that severely reduces
router and network performance.

 Implementing UDP Flooding

UDP flooding uses the spanning tree algorithm to forward packets in a

controlled manner. Bridging is enabled on each router interface for the sole
purpose of building the spanning tree. The spanning tree prevents loops by
stopping a broadcast from being forwarded out an interface on which the
broadcast was received. The spanning tree also prevents packet duplication
by placing certain interfaces in the blocked state (so that no packets are
forwarded) and other interfaces in the forwarding state (so that packets that
need to be forwarded are forwarded).

To enable UDP flooding, the router must be running software that supports
transparent bridging and bridging must be configured on each interface that
is to participate in the flooding. If bridging is not configured for an interface,
the interface will receive broadcasts, but the router will not forward those
broadcasts and will not use that interface as a destination for sending
broadcasts received on a different interface. Note Releases prior to Cisco
Internetwork Operating System (Cisco IOS) Software Release 10.2 do not
support flooding subnet broadcasts.

When configured for UPD flooding, the router uses the destination address
specified by the ip broadcast-address command on the output interface to
assign a destination address to a flooded UDP datagram. Thus, the
destination address might change as the datagram propagates through the
network. The source address, however, does not change. With UDP
flooding, both routers shown in Figure 19-1 use a spanning tree to control
the network topology for the purpose of forwarding broadcasts

By configuring UDP flooding, one router forwards UDP traffic without

burdening the second router with duplicate packets. By dedicating one router
to the task of forwarding UDP traffic, the second router becomes available
for forwarding unicast traffic. At the same time, because each router is
configured as the backup for the other router, redundancy is maintained; if
either router fails, the other router can assume the work of the failed router
without intervention from an operator. When compared with IP helper
addressing, UDP flooding makes the most efficient use of router resources.
 Auxiliary Procedures
NAT (Network Address Translation)
1. Tunnel Mode Decapsulation NAT Procedure
When a tunnel mode has been used to transmit packets the inner IP header
can contain addresses that are not suitable for the current network. This
procedure defines how these addresses are to be converted to suitable
addresses for the current network. Depending on local policy, one of the
following MUST be done:

1. If a valid source IP address space has been defined in the policy for the
encapsulated packets from the peer, check that the source IP address of
the inner packet is valid according to the policy.
2. If an address has been assigned for the remote peer, check that the source
IP address used in the inner packet is the assigned IP address.
3. NAT is performed for the packet, making it suitable for transport in the
local network.

2. Transport Mode Decapsulation NAT Procedure

When a transport mode has been used to transmit packets, contained TCP or
UDP headers will have incorrect checksums due to the change of parts of the
IP header during transit. This procedure defines how to fix these checksums
.Depending on local policy; one of the following MUST be done:

1. If the protocol header after the ESP header is a TCP/UDP header and the
peer’s real source and destination IP address have been received according
to incrementally recompute the TCP/UDP checksum:
* Subtract the IP source address in the received packet from the checksum.
* Add the real IP source address received via IKE to the checksum
* Subtract the IP destination address in the received packet from the
checksum.
Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security
association (SA) in the IPSec protocol suite.
* Add the real IP destination address received via IKE to the checksum
Note: If the received and real address are the same for a given address
(e.g., say the source address), the operations cancel and don’t need to
be performed.
2. If the protocol header after the ESP header is a TCP/UDP header,
recompute the checksum field in the TCP/UDP header.
3. If the protocol header after the ESP header is a UDP header, set the
checksum field to zero in the UDP header. If the protocol after the ESP
header is a TCP header, and if there is an option to flag to the stack that
the TCP checksum does not need to be computed, then that flag MAY be
used. This SHOULD only be done for transport mode, and if the packet
is integrity protected. Tunnel mode TCP checksums MUST be verified.

 Transport Mode ESP Encapsulation

BEFORE APPLYING ESP/UDP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------

AFTER APPLYING ESP/UDP

-------------------------------------------------------------
IPv4 |orig IP hdr | UDP | Non-| ESP | | | ESP | ESP|
|(any options)| Hdr | IKE | Hdr | TCP | Data | Trailer |Auth|
-------------------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|

1) Ordinary ESP encapsulation procedure is used.

2) A properly formatted UDP header and a Non-IKE Marker are inserted where
shown.
3) The Total Length, Protocol and Header Checksum fields in the IP header are
edited to match the resulting IP packet.

 Transport Mode ESP Decapsulation

1) The UDP header and the Non-IKE Marker are removed from the packet.
2) The Total Length, Protocol and Header Checksum fields in the new IP
header are edited to match the resulting IP packet.
3) Ordinary ESP decapsulation procedure is used.
4) Transport mode decapsulation NAT procedure is used.
 Tunnel Mode ESP Encapsulation

BEFORE APPLYING ESP/UDP

----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------

AFTER APPLYING ESP/UDP

--------------------------------------------------------------------
IPv4 |new h.| UDP | Non-| ESP |orig IP hdr | | | ESP | ESP|
|(opts)| Hdr | IKE | Hdr |(any options)| TCP | Data | Trailer |Auth|
--------------------------------------------------------------------
|<------------ encrypted ----------->|
|<------------- authenticated ------------>|

1) Ordinary ESP encapsulation procedure is used.

2) A properly formatted UDP header and a Non-IKE Marker are inserted where
shown.
3) The Total Length, Protocol and Header Checksum fields in the new IP
header are edited to match the resulting IP packet.

 Tunnel Mode ESP Decapsulation

1) The UDP header and the Non-IKE Marker are removed from the packet.
2) The Total Length, Protocol and Header Checksum fields in the new IP
header are edited to match the resulting IP packet.
3) Ordinary ESP decapsulation procedure is used.
4) Tunnel mode decapsulation NAT procedure is used.
 Lacking reliability, UDP applications must generally be willing to accept
some loss, errors or duplication. Some applications such as TFTP may add
rudimentary reliability mechanisms into the application layer as needed.

Most often, UDP applications do not require reliability mechanisms and

may even be hindered by them. Streaming, real-time multiplayer games and
voice over IP (VoIP) are examples of applications that often use UDP.

If an application requires a high degree of reliability, a protocol such as the

Transmission Control Protocol or erasure codes may be used instead.

Lacking any congestion avoidance and control mechanisms, network-based

mechanisms are required to minimize potential congestion collapse effects
of uncontrolled, high rate UDP traffic loads.

In other words, since UDP senders cannot detect congestion, network-

based elements such as routers using packet queuing and dropping
techniques will often be the only tool available to slow down excessive UDP
traffic. The Datagram Congestion Control Protocol (DCCP) is being
designed as a partial solution to this potential problem by adding end host
TCP-friendly congestion control behavior to high-rate UDP streams such as
streaming media.
 UDP hole punching is a commonly used NAT (Network Address
Translation) traversal technique. NAT traversal is a general term for
techniques that establish and maintain TCP/IP network and/or UDP
connections traversing network address translation (NAT) gateways.

NAT traversal techniques are typically required for client-to-client

networking applications, especially peer-to-peer and Voice-over-IP (VoIP)
deployments.

 Description
(UDP) hole punching is a method for establishing bidirectional UDP
connections between Internet hosts in private networks using NAT. It does
not work with all types of NATs as their behavior is not standardized.

Each host behind a NAT contacts a third, well-known server (usually a

STUN server) in the public address space and then, once the NAT devices
have established UDP state information, switches to direct communication
hoping that the NAT devices will keep the states despite the packets
coming from a different host.

A STUN (Simple Traversal of User Datagram Protocol [UDP] Through Network

Address Translators [NATs]) server allows NAT clients (i.e. computers behind a
firewall) to setup phone calls to a VOIP provider hosted outside of the local network.

UDP hole punching will not work with a Symmetric NAT (also known as
bi-directional NAT) which tends to be found inside large corporate
networks. With Symmetric NAT, the NAT's mapping associated with the
connection to the well known server is restricted to receiving data from the
well known server, and therefore the NAT mapping the well known server
sees is not useful information to the endpoint. For details on the different
types of NAT.
In a somewhat more elaborate approach both hosts will start sending to
each other, using multiple attempts. On a Restricted Cone NAT, the first
packet from the other host will be blocked. After that the NAT device has a
record of having sent a packet to the other machine, and will let any
packets coming from these IP address and port number through.

The technique is widely used in peer-to-peer software and Voice over

Internet Protocol telephony. It is one of the methods used in Skype to
communicate without bypassing firewalls or NAT. It can also be used to
assist the establishment of virtual private networks operating over UDP.
The same technique is sometimes extended to Transmission Control
Protocol (TCP) connections, albeit with much less success.

 Algorithm
Let A and B be the two hosts, each in its own private network; N1 and N2
are the two NAT devices; S is a public server with a well-known globally
reachable IP address.

1. A and B each begin a UDP conversation with S; the NAT devices N1

and N2 create UDP translation states and assign temporary external port
numbers .
2. S relays these port numbers back to A and B .
3. A and B contact each others' NAT devices directly on the translated
ports; the NAT devices use the previously created translation states and
send the packets to A and B.
The problem is that today's Internet protocols have been designed for
connections characterized by:
 high-bandwidth;
 low-delay;
 low frequency of errors;

To accommodate wireless mobile devices (portable computers, PDAs,

cellular phones) for which the connections are characterized by:
 low-bandwidth;
 high-delay;
 high frequency of errors;

Audio/video applications often prefer damaged data over no data since the
use of clever codecs can cope for the error. Disabling UDP checksum is not
an option since headers would go unverified and packets might be
misdelivered. Also in IPv6 the UDP checksum is mandatory.
 A special class of applications can derive benefit from having partially
damaged payloads delivered, rather than discarded, when using paths that
include error-prone links. Such applications can tolerate payload corruption
and may choose to use the Lightweight User Datagram Protocol (UDP-Lite)
variant of UDP instead of basic UDP.

The header format closely follows that of UDP. UDP-Lite changes the
semantics of the UDP "payload length" field to that of a:

"Checksum coverage length" field. Otherwise, UDP-Lite is identical to UDP.

The interface of UDP-Lite differs from that of UDP by the addition of a single
(socket) option that communicates a checksum coverage length value: at the
sender, this specifies the intended checksum coverage, with the remaining
unprotected part of the payload called the "error insensitive part".

By default, the UDP-Lite checksum coverage extends across the entire

datagram. If required, an application may dynamically modify this length
value, e.g., to offer greater protection to some messages.

UDP-Lite always verifies that a packet was delivered to the intended

destination, i.e., always verifies the header fields. Errors in the insensitive
part will not cause a UDP datagram to be discarded by the destination.

Applications using UDP-Lite therefore must not make assumptions

regarding the correctness of the data received in the insensitive part of the
UDP-Lite payload (this may have been changed). The sending application
therefore needs to specify a minimum checksum coverage that include all
sensitive protocol headers.
 Reliable UDP (RUDP) is a simple packet based transport protocol, which is
intended as a reliable protocol to transport telephony signaling across IP
networks. RUDP is designed to allow characteristics of each connection to be
individually configured so that a number of protocols with different transport
requirement can be implemented simultaneously not on the same platform.

It is layered on the UDP/IP protocols and provides reliable in-order delivery

(up to a maximum number of retransmissions) for virtual connections. RUDP
has a very flexible design that would make it suitable for a variety of transport
uses. One such use would be to transport telecommunication-signaling
protocols.

Reliable UDP (RUDP) is a set of quality of service enhancements, such as

congestion control tuning improvements, retransmit, and thinning server
algorithms, that improve the ability to present a good quality RTP stream to
RTP clients even in the presence of packet loss and network congestion.
Reliable UDP's congestion control mechanisms allow streams to behave in a
TCP-friendly fashion without disturbing the real-time nature of the protocol.

To work well with TCP traffic on the Internet, RUDP (Reliable UDP) uses
retransmission and congestion control algorithms similar to the algorithms
used by TCP. Additionally, these algorithms are time-tested to utilize
available bandwidth optimally.

Reliable UDP (RUDP) features include:

 Client acknowledgment of packets sent by the server to the client

 Windowing and congestion control so the server does not exceed the
currently available bandwidth
 Server retransmission to the client in the event of packet loss
 Faster than real-time streaming known as over buffering
Voice and video traffic is generally transmitted using UDP.Real-time video
and audio streaming protocols are designed to handle occasional lost
packets, so only slight degradation in quality occurs rather than large delays
if lost packets are retransmitted.

Because both TCP and UDP run over the same network, many businesses
are finding that a recent increase in UDP traffic from these real-time
applications is hindering the performance of applications using TCP, such
as point of sale, accounting, and database systems.

When TCP detects packet loss, it will throttle back its data rate usage.
Since both real-time and business applications are important to businesses,
developing quality of service solutions is crucial.