draft-ietf-tsvwg-udp-options-00.txt   draft-ietf-tsvwg-udp-options-01.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Standards Track June 8, 2017 Intended status: Standards Track June 27, 2017
Intended updates: 768 Intended updates: 768
Expires: December 2017 Expires: December 2017
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-00.txt draft-ietf-tsvwg-udp-options-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to format it and derivative works of it may not be created, except to format it
for publication as an RFC or to translate it into languages other for publication as an RFC or to translate it into languages other
than English. than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 35 skipping to change at page 1, line 35
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 8, 2017. This Internet-Draft will expire on December 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
location, syntax, and semantics for UDP transport layer options. location, syntax, and semantics for UDP transport layer options.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
3. Background.....................................................3 3. Background.....................................................3
4. The UDP Option Area............................................4 4. The UDP Option Area............................................4
5. UDP Options....................................................7 5. UDP Options....................................................7
5.1. End of Options List (EOL).................................8 5.1. End of Options List (EOL).................................8
5.2. No Operation (NOP)........................................8 5.2. No Operation (NOP)........................................9
5.3. Option Checksum (OCS).....................................9 5.3. Option Checksum (OCS).....................................9
5.4. Alternate Checksum (ACS).................................10 5.4. Alternate Checksum (ACS).................................10
5.5. Lite (LITE)..............................................10 5.5. Lite (LITE)..............................................10
5.6. Maximum Segment Size (MSS)...............................12 5.6. Maximum Segment Size (MSS)...............................12
5.7. Timestamps (TIME)........................................13 5.7. Timestamps (TIME)........................................13
5.8. Fragmentation (FRAG).....................................13 5.8. Fragmentation (FRAG).....................................13
5.8.1. Coupling FRAG with LITE.............................16 5.8.1. Coupling FRAG with LITE.............................16
5.9. Authentication and Encryption (AE).......................16 5.9. Authentication and Encryption (AE).......................16
5.10. Experimental (EXP)......................................17 5.10. Experimental (EXP)......................................17
6. UDP API Extensions............................................17 6. UDP API Extensions............................................17
7. Whose options are these?......................................18 7. Whose options are these?......................................18
8. UDP options vs. UDP-Lite......................................18 8. UDP options vs. UDP-Lite......................................19
9. Interactions with Legacy Devices..............................19 9. Interactions with Legacy Devices..............................19
10. Options in a Stateless, Unreliable Transport Protocol........20 10. Options in a Stateless, Unreliable Transport Protocol........20
11. UDP Option State Caching.....................................20 11. UDP Option State Caching.....................................21
12. Security Considerations......................................21 12. Multicast Considerations.....................................21
13. IANA Considerations..........................................22 13. Security Considerations......................................21
14. References...................................................22 14. IANA Considerations..........................................22
14.1. Normative References....................................22 15. References...................................................22
14.2. Informative References..................................22 15.1. Normative References....................................22
15. Acknowledgments..............................................24 15.2. Informative References..................................23
16. Acknowledgments..............................................24
Appendix A. Implementation Information...........................26 Appendix A. Implementation Information...........................26
1. Introduction 1. Introduction
Transport protocols use options as a way to extend their Transport protocols use options as a way to extend their
capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340]
include space for these options but UDP [RFC768] currently does not. include space for these options but UDP [RFC768] currently does not.
This document defines an experimental extension to UDP that provides This document defines an experimental extension to UDP that provides
space for transport options including their generic syntax and space for transport options including their generic syntax and
semantics for their use in UDP's stateless, unreliable message semantics for their use in UDP's stateless, unreliable message
skipping to change at page 8, line 5 skipping to change at page 7, line 49
a "*" above: EOL, NOP, and OCS. a "*" above: EOL, NOP, and OCS.
[QUESTION: Should we extend these, e.g., through #7?] [QUESTION: Should we extend these, e.g., through #7?]
>> All other options (without a "*") MAY be implemented, and their >> All other options (without a "*") MAY be implemented, and their
use SHOULD be determined either out-of-band or negotiated. use SHOULD be determined either out-of-band or negotiated.
>> Receivers MUST silently ignore unknown options. That includes >> Receivers MUST silently ignore unknown options. That includes
options whose length does not indicate the specified value. options whose length does not indicate the specified value.
>> Only ACS and AE options depend on the contents of the option
area. AE is always computed as if both the AE hash and ACS checksum
are zero; ACS is computed as if the ACS checksum is zero. Future
options MUST NOT be defined as having a value independent of the
contents of the option area. Otherwise, interactions between those
values, ACS, and UDP-AE could be unpredictable.
Receivers cannot treat unexpected option lengths as invalid, as this Receivers cannot treat unexpected option lengths as invalid, as this
would unnecessarily limit future revision of options (e.g., defining would unnecessarily limit future revision of options (e.g., defining
a new ACS that is defined by having a different length). a new ACS that is defined by having a different length).
>> Option lengths MUST NOT exceed the IP length of the packet. If >> Option lengths MUST NOT exceed the IP length of the packet. If
this occurs, the packet MUST be treated as malformed and dropped, this occurs, the packet MUST be treated as malformed and dropped,
and the event MAY be logged for diagnostics (logging SHOULD be rate and the event MAY be logged for diagnostics (logging SHOULD be rate
limited). limited).
>> Required options MUST come before other options. Each required >> Required options MUST come before other options. Each required
option MUST NOT occur more than once (if they are repeated in a option MUST NOT occur more than once (if they are repeated in a
received segment, all except the first MUST be silently ignored). received segment, all except the first MUST be silently ignored).
The requirement that required options come before others is intended The requirement that required options come before others is intended
to allow for endpoints to implement DOS protection, as discussed to allow for endpoints to implement DOS protection, as discussed
further in Section 12. further in Section 13.
5.1. End of Options List (EOL) 5.1. End of Options List (EOL)
The End of Options List (EOL) option indicates that there are no The End of Options List (EOL) option indicates that there are no
more options. It is used to indicate the end of the list of options more options. It is used to indicate the end of the list of options
without needing to pad the options to fill all available option without needing to pad the options to fill all available option
space. space.
+--------+ +--------+
| Kind=0 | | Kind=0 |
skipping to change at page 9, line 16 skipping to change at page 9, line 22
| Kind=1 | | Kind=1 |
+--------+ +--------+
Figure 6 UDP NOP option format Figure 6 UDP NOP option format
>> If options longer than one byte are used, NOP options SHOULD be >> If options longer than one byte are used, NOP options SHOULD be
used at the beginning of the UDP options area to achieve alignment used at the beginning of the UDP options area to achieve alignment
as would be more efficient for active (i.e., non-NOP) options. as would be more efficient for active (i.e., non-NOP) options.
>> Segments SHOULD NOT use more than three consecutive NOPs. NOPs >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs
are intended to assig with alignment, not other padding or fill. are intended to assist with alignment, not other padding or fill.
[NOTE: Tom Herbert suggested we declare "more than 3 consecutive [NOTE: Tom Herbert suggested we declare "more than 3 consecutive
NOPs" a fatal error to reduce the potential of using NOPs as a DOS NOPs" a fatal error to reduce the potential of using NOPs as a DOS
attack, but IMO there are other equivalent ways (e.g., using attack, but IMO there are other equivalent ways (e.g., using
RESERVED or other UNASSIGNED values) and the "no more than 3" RESERVED or other UNASSIGNED values) and the "no more than 3"
creates its own DOS vulnerability) creates its own DOS vulnerability)
5.3. Option Checksum (OCS) 5.3. Option Checksum (OCS)
The Option Checksum (OCS) is an 8-bit ones-complement sum (Ones8) The Option Checksum (OCS) is an 8-bit ones-complement sum (Ones8)
skipping to change at page 10, line 30 skipping to change at page 10, line 34
CRC-CCITT (polynomial x^16 + x^12 + x^5 + x or polynomial 0x1021) CRC-CCITT (polynomial x^16 + x^12 + x^5 + x or polynomial 0x1021)
has been chosen because of its ubiquity and use in other packet has been chosen because of its ubiquity and use in other packet
protocols, such as X.25, HDLC, and Bluetooth. protocols, such as X.25, HDLC, and Bluetooth.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=3 | Len=4 | CRC16sum | | Kind=3 | Len=4 | CRC16sum |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
Figure 8 UDP ACS option format Figure 8 UDP ACS option format
When ACS is computed, its checksum (CRC) area is zeroed. No other
options are zeroed before computing ACS.
5.5. Lite (LITE) 5.5. Lite (LITE)
The Lite option (LITE) is intended to provide equivalent capability The Lite option (LITE) is intended to provide equivalent capability
to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the
UDP checksum to cover only a prefix of the UDP data payload, to UDP checksum to cover only a prefix of the UDP data payload, to
protect critical information (e.g., application headers) but allow protect critical information (e.g., application headers) but allow
potentially erroneous data to be passed to the user. This feature potentially erroneous data to be passed to the user. This feature
helps protect application headers but allows for application data helps protect application headers but allows for application data
errors. Some applications are impacted more by a lack of data than errors. Some applications are impacted more by a lack of data than
errors in data, e.g., voice and video. errors in data, e.g., voice and video.
skipping to change at page 17, line 16 skipping to change at page 17, line 16
endpoints have populated Master Key Tuples (MKTs), used to exclude endpoints have populated Master Key Tuples (MKTs), used to exclude
non-protected traffic. non-protected traffic.
TCP-AO generates unique traffic keys from a hash of TCP connection TCP-AO generates unique traffic keys from a hash of TCP connection
parameters. UDP lacks a three-way handshake to coordinate parameters. UDP lacks a three-way handshake to coordinate
connection-specific values, such as TCP's Initial Sequence Numbers connection-specific values, such as TCP's Initial Sequence Numbers
(ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses (ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses
zeroes as the value for both ISNs. This means that the UDP-AE reuses zeroes as the value for both ISNs. This means that the UDP-AE reuses
keys when socket pairs are reused, unlike TCP-AO. keys when socket pairs are reused, unlike TCP-AO.
UDP-AE can be configured to either include or exclude TCP options,
the same way as can TCP-AO. When UDP options are covered, the ACS
option area checksum and UDP-AE hash areas are zeroed before
computing the AE hash. It is important to consider that options not
yet defined might yield unpredictable results if not confirmed as
supported, e.g., if they contain other hashes or checksums that
depend on the option area contents.
Similar to TCP-AO-NAT, UDP-AE can be configured to support NAT
traversal, excluding one or both of the UDP ports [RFC6978].
5.10. Experimental (EXP) 5.10. Experimental (EXP)
The Experimental option (EXP) is reserved for experiments [RFC3692]. The Experimental option (EXP) is reserved for experiments [RFC3692].
Only one such value is reserved because experiments are expected to Only one such value is reserved because experiments are expected to
use an Experimental ID (ExIDs) to differentiate concurrent use for use an Experimental ID (ExIDs) to differentiate concurrent use for
different purposes, using UDP ExIDs registered with IANA according different purposes, using UDP ExIDs registered with IANA according
to the approach developed for TCP experimental options [RFC6994]. to the approach developed for TCP experimental options [RFC6994].
>> The length of the experimental option MUST be at least 4 to >> The length of the experimental option MUST be at least 4 to
account for the Kind, Length, and the minimum 16-bit UDP ExID account for the Kind, Length, and the minimum 16-bit UDP ExID
skipping to change at page 21, line 21 skipping to change at page 21, line 28
Updates to RFC 768 Updates to RFC 768
This document updates RFC 768 as follows: This document updates RFC 768 as follows:
o This document defines the meaning of the IP payload area beyond o This document defines the meaning of the IP payload area beyond
the UDP length but within the IP length. the UDP length but within the IP length.
o This document extends the UDP API to support the use of options. o This document extends the UDP API to support the use of options.
12. Security Considerations 12. Multicast Considerations
UDP options are primarily intended for unicast use. Using these
options over multicast IP requires careful consideration, e.g., to
ensure that the options used are safe for different endpoints to
interpret differently (e.g., either to support or silently ignore)
or to ensure that all receivers of a multicast group confirm support
for the options in use.
13. Security Considerations
The use of UDP packets with inconsistent IP and UDP Length fields The use of UDP packets with inconsistent IP and UDP Length fields
has the potential to trigger a buffer overflow error if not properly has the potential to trigger a buffer overflow error if not properly
handled, e.g., if space is allocated based on the smaller field and handled, e.g., if space is allocated based on the smaller field and
copying is based on the larger. However, there have been no reports copying is based on the larger. However, there have been no reports
of such vulnerability and it would rely on inconsistent use of the of such vulnerability and it would rely on inconsistent use of the
two fields for memory allocation and copying. two fields for memory allocation and copying.
UDP options are not covered by DTLS (datagram transport-layer UDP options are not covered by DTLS (datagram transport-layer
security). Despite the name, neither TLS [RFC5246] (transport layer security). Despite the name, neither TLS [RFC5246] (transport layer
skipping to change at page 22, line 7 skipping to change at page 22, line 22
is known to require serial processing and may pose a DOS risk, e.g., is known to require serial processing and may pose a DOS risk, e.g.,
if an attacker adds large numbers of unknown options that must be if an attacker adds large numbers of unknown options that must be
parsed in their entirety. Implementations concerned with the parsed in their entirety. Implementations concerned with the
potential for this vulnerability MAY implement only the required potential for this vulnerability MAY implement only the required
options and MAY also limit NOPs (e.g., no more than three options and MAY also limit NOPs (e.g., no more than three
consecutive NOPs or some total number that might occur between the consecutive NOPs or some total number that might occur between the
required options, if all are present). Because the required options required options, if all are present). Because the required options
come first and at most once each (and all later duplicates silently come first and at most once each (and all later duplicates silently
ignored), this limits the DOS impact. ignored), this limits the DOS impact.
13. IANA Considerations 14. IANA Considerations
Upon publication, IANA is hereby requested to create a new registry Upon publication, IANA is hereby requested to create a new registry
for UDP Option Kind numbers, similar to that for TCP Option Kinds. for UDP Option Kind numbers, similar to that for TCP Option Kinds.
Initial values of this registry are as listed in Section 5. Initial values of this registry are as listed in Section 5.
Additional values in this registry are to be assigned by IESG Additional values in this registry are to be assigned by IESG
Approval or Standards Action [RFC5226]. Approval or Standards Action [RFC8126].
Upon publication, IANA is hereby requested to create a new registry Upon publication, IANA is hereby requested to create a new registry
for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for
use in a similar manner as TCP ExIDs [RFC6994]. This registry is use in a similar manner as TCP ExIDs [RFC6994]. This registry is
initially empty. Values in this registry are to be assigned by IANA initially empty. Values in this registry are to be assigned by IANA
using first-come, first-served (FCFS) rules [RFC5226]. using first-come, first-served (FCFS) rules [RFC8126].
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC768] Postel, J., "User Datagram Protocol", RFC 768, August [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August
1980. 1980.
[RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981.
14.2. Informative References 15.2. Informative References
[Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User
Datagrams (SPUD) Prototype," draft-hildebrand-spud- Datagrams (SPUD) Prototype," draft-hildebrand-spud-
prototype-03, Mar. 2015. prototype-03, Mar. 2015.
[RFC793] Postel, J., "Transmission Control Protocol" RFC 793, [RFC793] Postel, J., "Transmission Control Protocol" RFC 793,
September 1981. September 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers," RFC 1122, Oct. 1989. Communication Layers," RFC 1122, Oct. 1989.
skipping to change at page 23, line 30 skipping to change at page 23, line 48
[RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful," RFC 3692, Jan. 2004. Considered Useful," RFC 3692, Jan. 2004.
[RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.),
G. Fairhurst (Ed.), "The Lightweight User Datagram G. Fairhurst (Ed.), "The Lightweight User Datagram
Protocol (UDP-Lite)," RFC 3828, July 2004. Protocol (UDP-Lite)," RFC 3828, July 2004.
[RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs," RFC 5226, May 2008.
[RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2," RFC 5246, Aug. 2008. (TLS) Protocol Version 1.2," RFC 5246, Aug. 2008.
[RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication
Option," RFC 5925, June 2010. Option," RFC 5925, June 2010.
[RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer
Security Version 1.2," RFC 6347, Jan. 2012. Security Version 1.2," RFC 6347, Jan. 2012.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS),"
skipping to change at page 24, line 12 skipping to change at page 24, line 27
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC
6994, Aug. 2013. 6994, Aug. 2013.
[RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger
(Ed.), "TCP Extensions for High Performance," RFC 7323, (Ed.), "TCP Extensions for High Performance," RFC 7323,
Sep. 2014. Sep. 2014.
[RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage
Guidelines," RFC 8085, Feb. 2017. Guidelines," RFC 8085, Feb. 2017.
[RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing
an IANA Considerations Section in RFCs," RFC 8126, June
2017.
[To17ao] Touch, J., "A TCP Authentication Option Extension for [To17ao] Touch, J., "A TCP Authentication Option Extension for
Payload Encryption", draft-touch-tcp-ao-encrypt, Apr. Payload Encryption", draft-touch-tcp-ao-encrypt, Apr.
2017. 2017.
[To17cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block [To17cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block
Interdependence," draft-touch-tcpm-2140bis, Jan. 2017. Interdependence," draft-touch-tcpm-2140bis, Jan. 2017.
[Tr15] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for [Tr15] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for
the design of a Substrate Protocol for User Datagrams the design of a Substrate Protocol for User Datagrams
(SPUD)," draft-trammell-spud-req-04, May 2016. (SPUD)," draft-trammell-spud-req-04, May 2016.
15. Acknowledgments 16. Acknowledgments
This work benefitted from feedback from Bob Briscoe, Ken Calvert, This work benefitted from feedback from Bob Briscoe, Ken Calvert,
Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE
combination), Tom Herbert, and Mark Smith, as well as discussions on combination), Tom Herbert, and Mark Smith, as well as discussions on
the IETF TSVWG and SPUD email lists. the IETF TSVWG and SPUD email lists.
This work is partly supported by USC/ISI's Postel Center. This work is partly supported by USC/ISI's Postel Center.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Joe Touch Joe Touch
USC/ISI USC/ISI
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 USA Marina del Rey, CA 90292 USA
Phone: +1 (310) 448-9151 Phone: +1 (310) 448-9151
Email: touch@isi.edu Email: touch@isi.edu
Appendix A. Implementation Information Appendix A. Implementation Information
The following information is provided to encourage interoperable API The following information is provided to encourage interoperable API
implementations. implementations.
System-level variables (sysctl): System-level variables (sysctl):
Name default meaning Name default meaning
---------------------------------------------------- ----------------------------------------------------
net.ipv4.udp_opt 0 UDP options available net.ipv4.udp_opt 0 UDP options available
net.ipv4.udp_opt_ocs 1 Default include OCS net.ipv4.udp_opt_ocs 1 Default include OCS
 End of changes. 22 change blocks. 
26 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/