Use a distinct protocol within its limits
06IP protocol136 selects UDP-Lite. UDP uses17. Sharing UDP’s port-number space does not make the two transports interchangeable.
Transport acceptance and application validity are separate from authenticity and delivery guarantees.
Source for this drawing: RFC 3828 · Read RFC section 5 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
RFC6335 updates UDP service-name/port assignment procedures, which also apply to UDP-Lite’s shared port space. It does not replace protocol136 or redefine the Checksum Coverage field.
Read the updated RFC section ↗A peer unaware of UDP-Lite will in general return an ICMP or ICMPv6 error as described in §5; this is not a guaranteed notification or automatic conversion to UDP.
- A peer unaware of UDP-Lite will in general return an ICMP or ICMPv6 error as described in §5; this is not a guaranteed notification or automatic conversion to UDP.
- The16-bit coverage field reaches65535. For a jumbogram,0 covers the whole datagram; nonzero coverage can protect at most its first65535 octets (§3.5).
- UDP-Lite adds no authentication or encryption. Authentication covering a changed tail fails; some encryption spreads damage. Do not omit integrity protection as a workaround (§6).
The jumbogram strip is schematic, with byte counts shown explicitly. This guide teaches RFC3828’s mechanism and limits; it is not evidence that a particular network or application supports UDP-Lite.
Read the RFC section ↗