datagram
Click on the red underlined text to get to the source
... gateways are designed to be stateless, forwarding each IP
datagram independently of other datagrams. As a result,
redundant paths can be exploited to provide robust service ...
... gateways are designed to be stateless, forwarding each IP
datagram independently of other datagrams. As a result,
redundant paths can be exploited to provide robust service
...
... User Datagram Protocol (UDP) ...
... destination host.
IP is a connectionless or datagram internetwork service,
providing no end-to-end ...
... providing no end-to-end delivery guarantees. Thus, IP
datagrams may arrive at the destination host damaged,
duplicated, out of order ...
...
The datagram or connectionless nature of the IP protocol
is a fundamental and characteristic feature of the
...
... Internet has revealed problems of
management and scaling in a large datagram-based packet
communication system. These problems are being addressed, and
as a result there will be continuing evolution of the
...
... IP Datagram ...
... end-to-end transmission in
the IP protocol. An IP datagram consists of an IP header
followed by transport layer ...
... internet layer (Section 3), the
unqualified term "datagram" should be understood to refer
to an IP datagram.
...
... unqualified term "datagram" should be understood to refer
to an IP datagram.
...
... includes an IP header and data. A packet may be a
complete IP datagram or a fragment of an IP datagram. ...
... This is the effective destination address of a datagram,
even if it is broadcast or multicast ...
... At a given moment, all the IP datagrams from a particular
source host to a particular destination host ...
...
The terms frame, packet, datagram, message, and segment are
illustrated by the following schematic diagrams:
...
... |________|____hdr___|__________________|
<-------- Datagram ------------------>
<-------- Message ----------->
or, for TCP ...
... |________|__________|__________________|
<-------- Datagram ------------------>
<-------- Segment ----------->
...
... IP. Although ICMP
messages are encapsulated within IP datagrams, ICMP
processing is considered to be (and is typically implemented
as) part of the IP layer ...
... next
hop" gateway or host for outgoing IP datagrams and (2) reassemble
incoming IP datagrams. The IP layer ...
... host for outgoing IP datagrams and (2) reassemble
incoming IP datagrams. The IP layer may also (3) implement
intentional fragmentation ...
... IP layer may also (3) implement
intentional fragmentation of outgoing datagrams. Finally, the IP
layer must (4) provide diagnostic and error functionality. We
expect that IP layer ...
...
For normal datagrams, the processing is straightforward. For
incoming datagrams, the IP layer ...
... For normal datagrams, the processing is straightforward. For
incoming datagrams, the IP layer:
...
... verifies that the datagram is correctly formatted; ...
... reassembles the datagram if necessary; and ...
... fragments the datagram if necessary and if intentional
fragmentation is implemented (see Section 3.3.3); and ...
... switch MUST default to the
non-gateway mode. In this mode, a datagram arriving through one
interface will not be forwarded to another host ...
... In the following, the action specified in certain cases is to
"silently discard" a received datagram. This means that the
datagram will be discarded without further processing and that the
...
... silently discard" a received datagram. This means that the
datagram will be discarded without further processing and that the
host will not send any ICMP error message ...
... host SHOULD provide
the capability of logging the error (see Section 1.2.3), including
the contents of the silently-discarded datagram, and SHOULD record
the event in a statistics counter.
...
...
A datagram whose version number is not 4 MUST be silently
discarded.
...
... IP header checksum on every received
datagram and silently discard every datagram that has a bad
...
... A host MUST silently discard an incoming datagram that is
not destined for the host. An incoming datagram ...
... datagram that is
not destined for the host. An incoming datagram is destined
for the host if the datagram ...
... A host MUST silently discard an incoming datagram containing
an IP source address that is invalid by the rules of this
...
...
When sending an identical copy of an earlier datagram, a
host MAY optionally retain the same Identification field in
...
... when a host sends an identical copy of an earlier
datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams ...
... datagram, the new copy should contain the same
Identification value as the original. There are two
suggested advantages: (1) if the datagrams are
fragmented and some of the fragments are lost, the
...
... fragments are lost, the
receiver may be able to reconstruct a complete datagram
from fragments of the original and the copies; (2) a
...
... IP Identification field
(and Fragment Offset) to discard duplicate datagrams
from the queue.
...
...
However, the observed patterns of datagram loss in the
Internet do not favor the probability of retransmitted
...
... retransmission) tend to prevent retransmission of an
identical datagram [IP:9]. Therefore, we believe that
retransmitting the same Identification field is not
...
... UDP would require the cooperation of the application
programs to retain the same Identification value in
identical datagrams.
...
... transport layer to
set the TOS field of every datagram that is sent; the
default is all zero bits. The IP layer ...
... transport layer to
set the TTL field of every datagram that is sent. When a
fixed TTL value is used, it MUST be configurable. The
...
...
The intent is that TTL expiration will cause a datagram
to be discarded by a gateway but not by the destination
host ...
... There MUST be a means for the transport layer to specify IP
options to be included in transmitted IP datagrams (see
Section 3.4).
...
... All IP options (except NOP or END-OF-LIST) received in
datagrams MUST be passed to the transport layer (or to ICMP
processing when the datagram ...
... datagrams MUST be passed to the transport layer (or to ICMP
processing when the datagram is an ICMP message). The IP
...
... Some environments require the Security option in every
datagram; such a requirement is outside the scope of
this document and the IP ...
...
If host receives a datagram containing a completed
source route (i.e., the pointer points beyond the last
...
... source route (i.e., the pointer points beyond the last
field), the datagram has reached its final destination;
the option as received (the recorded route ...
... route will be reversed and
used to form a return source route for reply datagrams
(see discussion of IP Options ...
... DISCUSSION:
If a source-routed datagram is fragmented, each
fragment will contain a copy of the source route ...
... source route) must precede reassembly, the
original datagram will not be reassembled until
the final destination is reached.
...
... destination is reached.
Suppose a source routed datagram is to be routed
from host S to host ...
... There was an ambiguity in the specification over
whether the source route option in a datagram sent
out by S should be (A) or (B):
...
...
(where >> represents the pointer). If (A) is
sent, the datagram received at D will contain the
option: {G1, G2, ... Gn >>}, with S and D as the
IP ...
... IP source and destination addresses. If (B) were
sent, the datagram received at D would again
contain S and D as the same IP source and
...
... Internet header and at
least the first 8 data octets of the datagram that triggered
the error; more than 8 octets MAY be sent; this header ...
... flood
of ICMP Destination Unreachable datagrams from all
machines that do not have a client for that destination
port ...
... violate this rule. To be certain to detect broadcast
datagrams, therefore, hosts are required to check for a
link-layer ...
... transport
protocol (e.g., UDP) is unable to demultiplex the
datagram but has no protocol mechanism to inform the
sender ...
... host MAY send a Source Quench message if it is
approaching, or has reached, the point at which it is forced
to discard incoming datagrams due to a shortage of
reassembly buffers or other resources. See Section 2.2.3 of
...
... application layer SHOULD implement
a mechanism to respond to Source Quench for any protocol
that can send a sequence of datagrams to the same
destination and which can reasonably be expected to maintain
...
... IP:14] to make the IP
layer respond directly to Source Quench by controlling
the rate at which datagrams are sent, however, this
proposal is currently experimental and not currently
...
... A gateway will send a Time Exceeded Code 0 (In Transit)
message when it discards a datagram due to an expired
TTL field. This indicates either a gateway ...
... Timeout) message from a destination host that has timed
out and discarded an incomplete datagram; see Section
3.3.2 below. In the future, receipt of this message
might be part of some "MTU discovery ...
... might be part of some "MTU discovery" procedure, to
discover the maximum datagram size that can be sent on
the path without fragmentation.
...
... Echo Reply requires intentional fragmentation that is
not implemented, the datagram MUST be truncated to maximum
transmission size (see Section 3.3.3) and sent.
...
... The IP layer chooses the correct next hop for each datagram it
sends. If the destination is on a connected network ...
... destination is on a connected network, the
datagram is sent directly to the destination host; otherwise,
it has to be routed to a gateway ...
... destination is on the
corresponding connected network, and the datagram is to
be transmitted directly to the destination host.
...
... broadcast or a multicast address, simply
pass the datagram to the link layer for the appropriate
interface ...
... algorithm on this cache to route a datagram; this
algorithm is designed to put the primary routing ...
... host chooses a "default"
gateway and sends the datagram to it. It also builds a
corresponding Route Cache entry.
...
... gateway in the appropriate route cache entry,
so later datagrams to the same destination will go
directly to the best gateway ...
... cache data on the properties of the path. Examples of
such properties might be the maximum unfragmented
datagram size (see Section 3.3.3), or the average
round-trip delay measured by a transport protocol ...
... overhead of
scanning the route cache for every datagram to be
transmitted. This may be accomplished with a hash
...
... re-routing,
a gateway failure may cause datagrams to apparently
vanish into a "black hole". This failure can be
...
...
Note that positive advice that is given for every
datagram received may cause unacceptable overhead in
the implementation.
...
... target gateway will probably forward the
datagram to the failed gateway and send a Redirect back
to the host ...
...
The IP layer MUST implement reassembly of IP datagrams.
...
...
We designate the largest datagram size that can be reassembled
by EMTU_R ("Effective MTU to receive"); this is sometimes
...
... An implementation may use a contiguous reassembly buffer
for each datagram, or it may use a more complex data
structure that places no definite limit on the reassembled
datagram ...
... datagram, or it may use a more complex data
structure that places no definite limit on the reassembled
datagram size; in the latter case, EMTU_R is said to be
"indefinite".
...
...
The tricky part of reassembly is the bookkeeping to
determine when all bytes of the datagram have been
reassembled. We recommend Clark's algorithm [IP:10 ...
... MMS_R, the maximum message size that can be received and
reassembled in an IP datagram (see GET_MAXSIZES calls in
Section 3.4). If EMTU_R is not indefinite, then the value of
MMS ...
... It is recommended that the value lie between 60 seconds and 120
seconds. If this timeout expires, the partially-reassembled
datagram MUST be discarded and an ICMP Time Exceeded message
...
... hop count rather than an elapsed time. If the
reassembly timeout is too small, datagrams will be
discarded unnecessarily, and communication may fail. The
timeout needs to be at least as large as the typical
...
... TCP:1] will be
larger than necessary. The MSL controls the maximum rate
at which fragmented datagrams can be sent using distinct
values of the 16-bit Ident field; a larger MSL lowers the
...
... We designate by EMTU_S ("Effective MTU for sending") the
maximum IP datagram size that may be sent, for a particular
combination of IP source and destination addresses ...
... MTU of the network
interface corresponding to the source address of the datagram.
Note that <IP header size> in this equation will be 20, unless
...
...
(a) In general, no host is required to accept an IP
datagram larger than 576 bytes (including header and
data), so a host ...
... header and
data), so a host must not send a larger datagram
without explicit knowledge or prior arrangement with
the destination host ...
... destination host. Thus, MMS_S is only an upper
bound on the datagram size that a transport protocol
may send; even when MMS ...
... explicitly inform the sender about the largest
datagram the other end can receive and reassemble
[IP:7]. There is no corresponding mechanism in the
...
... A transport protocol that assumes an EMTU_R larger
than 576 (see Section 3.3.2), can send a datagram of
this larger size to another host that implements the
...
... support an MTU of 576 or greater, we strongly recommend
the use of 576 for datagrams sent to non-local networks.
...
... host could determine the MTU
over a given path by sending a zero-offset datagram
fragment and waiting for the receiver ...
... containing an embedded gateway, i.e., without
forwarding datagrams from one connected network to
another.
...
...
The following general rules apply to the selection of an IP
source address for sending a datagram from a multihomed
host.
...
... (1) If the datagram is sent in response to a received
datagram, the source address for the response SHOULD be
the specific-destination address ...
... (A) A host MAY silently discard an incoming datagram whose
destination address does not correspond to the physical
interface ...
... (B) A host MAY restrict itself to sending (non-source-
routed) IP datagrams only through the physical
interface that corresponds to the IP source address of
...
... routing
mechanisms could not route a datagram to a
physical interface that did not correspond to the
...
... The Weak ES Model may cause the Redirect mechanism
to fail. If a datagram is sent out a physical
interface that does not correspond to the
destination address ...
...
It will be noted that this process is essentially the
same as datagram routing (see Section 3.3.1), and
therefore hosts ...
... as an intermediate hop in a source route, forwarding a source-
routed datagram to the next specified hop.
...
... MUST obey all the relevant rules for a gateway forwarding
source-routed datagrams [INTRO:2]. This includes the following
specific provisions, which override the corresponding host ...
...
The TTL field MUST be decremented and the datagram perhaps
discarded as specified for a gateway in [INTRO:2 ...
... Fragmentation Required but DF Set) when a source-
routed datagram cannot be fragmented to fit into the
target network ...
...
5 (Source Route Failed) when a source-routed datagram
cannot be forwarded, e.g., because of a routing
problem or because the next hop ...
... IP Source Address (ref. Section 3.2.1.3)
A source-routed datagram being forwarded MAY (and normally
will) have a source address that is not one of the IP
addresses ...
... To define the rules restricting host forwarding of source-
routed datagrams, we use the term "local source-routing" if the
next hop ...
... next hop will be through the same physical interface through
which the datagram arrived; otherwise, it is "non-local
source-routing ...
...
If a host receives a datagram with an incomplete source route
but does not forward it for some reason, the host ...
... ICMP Destination Unreachable (code 5, Source Route Failed)
message, unless the datagram was itself an ICMP error message.
...
... A host MUST recognize any of these forms in the destination
address of an incoming datagram.
...
... addresses as the destination address of an incoming datagram.
A host MAY optionally have a configuration option to choose the
...
... for local IP multicasting includes sending multicast datagrams,
joining multicast groups and receiving ...
... multicast groups and receiving multicast datagrams, and
leaving multicast groups. This implies support for all of
...
... gateways or
that do not need to receive multicast datagrams
originating on other networks, IGMP ...
... links): no mapping required. All IP multicast datagrams
are sent as-is, inside the local framing.
...
... Wherever practical, hosts MUST return ICMP error datagrams on
detection of an error, except in those cases where returning an
ICMP error message ...
... datagram networks is the "black
hole disease": datagrams are sent out, but nothing comes
back. Without any error datagrams ...
... datagrams are sent out, but nothing comes
back. Without any error datagrams, it is difficult for
the user to figure out what the problem is.
...
... Id
parameter is optional; see Section 3.2.1.5.
* Receive Datagram
RECV(BufPTR, prot
...
...
SpecDest = specific-destination address of datagram
(defined in Section 3.2.1.3)
...
... (defined in Section 3.2.1.3)
The result parameter dst contains the datagram's destination
address. Since this may be a broadcast or multicast address ...
... The parameter opt contains all the IP options received in the
datagram; these MUST also be passed to the transport layer.
...
... multihoming |3.1 | | |x| | |
Meet gateway specs if forward datagrams |3.1 |x| | | | |
Configuration switch for embedded gateway ...
... Auto-config based on number of interfaces |3.1 | | | | |x|1
Able to log discarded datagrams |3.1 | |x| | | |
Record in counter |3.1 | |x| | | |
...
... IP address |3.2.1.3 |x| | | | |
Silently discard datagram with bad dest addr |3.2.1.3 |x| | | | |
Silently discard datagram ...
... datagram with bad dest addr |3.2.1.3 |x| | | | |
Silently discard datagram with bad src addr |3.2.1.3 |x| | | | |
Support reassembly |3.2.1.4 |x| | | | |
Retain same Id field in identical datagram ...
... datagram with bad src addr |3.2.1.3 |x| | | | |
Support reassembly |3.2.1.4 |x| | | | |
Retain same Id field in identical datagram |3.2.1.5 | | |x| | |
| | | | | | |
TOS: | | | | | | |
...
... Originate & terminate Source Route options |3.2.1.8c|x| | | | |
Datagram with completed SR passed up to TL |3.2.1.8c|x| | | | |
Build correct (non-redundant) return route |3.2.1.8c|x| | | | |
...
... ICMP msg with unknown type |3.2.2 |x| | | | |
Include more than 8 octets of orig datagram |3.2.2 | | |x| | |
Included octets same as received |3.2.2 |x| | | | |
Demux ICMP ...
... - Non-initial fragment |3.2.2 | | | | |x|
- Datagram with non-unique src address |3.2.2 | | | | |x|
Return ICMP ...
... Addr Mask Reply when init. |3.2.2.9 |x| | | | |3
| | | | | | |
ROUTING OUTBOUND DATAGRAMS: | | | | | | |
Use address mask in local/remote ...
... REASSEMBLY and FRAGMENTATION: | | | | | | |
Able to reassemble incoming datagrams |3.3.2 |x| | | | |
At least 576 byte datagrams |3.3.2 |x| | | | |
...
... Able to reassemble incoming datagrams |3.3.2 |x| | | | |
At least 576 byte datagrams |3.3.2 |x| | | | |
EMTU_R configurable or indefinite |3.3.2 | |x| | | |
Transport layer ...
... SOURCE-ROUTE FORWARDING: | | | | | | |
Forward datagram with Source Route option |3.3.5 | | |x| | |1
Obey corresponding gateway ...
... USER DATAGRAM PROTOCOL -- UDP ...
... UDP:1] offers only a minimal
transport service -- non-guaranteed datagram delivery -- and
gives applications direct access to the datagram ...
... datagram delivery -- and
gives applications direct access to the datagram service of the
IP layer ...
...
If a datagram arrives addressed to a UDP port for which
there is no pending LISTEN call, UDP ...
... UDP will need to obtain a
source route from a request datagram and supply a
reversed route for sending the corresponding reply.
...
... ICMP error messages resulting from sending a
UDP datagram are received asynchronously. A UDP-based
...
... zero and invalid, UDP MUST silently discard the datagram.
An application MAY optionally be able to control whether UDP
...
... An application MAY optionally be able to control whether UDP
datagrams without checksums should be discarded or passed to
the application.
...
...
When a UDP datagram is received, its specific-destination
address MUST be passed up to the application layer.
...
... An application program MUST be able to specify the IP source
address to be used for sending a UDP datagram or to leave it
unspecified (in which case the networking software will
choose an appropriate source address ...
... application layer (e.g, so that the application can later
receive a reply datagram only from the corresponding
interface).
...
... GET_MAXSIZES() can be used to learn the effective maximum UDP
maximum datagram size for a particular {interface,remote
host,TOS ...
... TOS values as well as IP options for sending a UDP datagram,
and these values must be passed transparently to the IP layer.
...
... throughput by
amortizing header size and per-datagram processing
overhead over more data bytes; however, if the packet
...
... heuristic to select
the latest window update despite possible datagram
reordering; as a result, it may ignore a window update
...
... Source Route: | | | | | | |
ALP can specify |4.2.3.8 |x| | | | |1
Overrides src rt in datagram |4.2.3.8 |x| | | | |
Build return route from src rt |4.2.3.8 |x| | | | |
...
... "A Standard for the Transmission of IP Datagrams over Ethernet Networks," C. Hornig, RFC-894std41, April 1984. ...
... "A Standard for the Transmission of IP Datagrams over IEEE 802 "Networks," J. Postel and J. Reynolds, RFC-1042std43 ...
... 879, November 1983. Discusses and clarifies the relationship between the TCP Maximum Segment Size option and the IP datagram size. ...
... "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July 1982. This and the following paper should be read by every implementor ...
... "Broadcasting Internet Datagrams in the Presence of Subnets," J. Mogul, RFC-922std5, October 1984. ...
... "User Datagram Protocol," J. Postel, RFC-768std6, August 1980. ...
... security mechanism
that is based upon verifying the IP source address of a datagram
should be treated with suspicion. However, in restricted
environments some source-address ...
... gateway to the rest of the
Internet discarded any incoming datagram with a source address that
spoofed the LAN ...
... is complicated by source routing, and some have suggested that
source-routed datagram forwarding by hosts (see Section 3.3.5) should
be outlawed for security ...