This appendix addresses the conformance of Digital UNIX to Internet host requirements as specified by Request for Comments (RFC) 1122: Requirements for Internet Hosts - Communication Layers and RFC 1123: Requirements for Internet Hosts - Applications and Support, and the RFCs that they reference. (RFCs 1122 and 1123 are referred to as Host Requirements RFCs throughout this appendix.)
Note
Although there are RFCs that specify internetworking protocols not referenced in the Host Requirements RFCs, the conformance of Digital UNIX to the requirements specified in those RFCs is beyond the scope of this appendix. The Digital UNIX Software Product Description (SPD) contains additional technical information about the networking component of Digital UNIX and a complete list of RFCs implemented in Digital UNIX.
This appendix contains the following information:
The Internet Architecture Board (IAB) issues specifications, and updates to the specifications, in the form of RFCs. RFCs describe protocols (as well as other information) of interest to the Internet community.
The Host Requirements RFCs are a statement of requirements for host system implementations of the Internet protocol suite, when these host systems are connected to the Internet. They do the following:
The Host Requirements RFCs also indicate whether the requirements they discuss are must, must not, should, should not, or may level requirements. If an implementation complies with all must and should level requirements, it is considered unconditionally compliant. If an implementation complies with all must level requirements, but not necessarily all should requirements, it is considered conditionally compliant.
Note
This appendix describes Digital UNIX's conformance to must and must not level requirements only. Although Digital UNIX complies with the vast majority of should, should not, and may level requirements described in the Host Requirements RFCs, compliance with should, should not, and may level requirements is beyond the scope of this appendix.
RFCs are frequently issued or updated. When updates are issued, earlier versions of the RFC are rendered obsolete. The Host Requirements RFCs were issued in October 1989. Where RFCs referenced by the Host Requirements RFCs have been updated since October 1989, the RFC number of the updated version, as well as the number of the version it rendered obsolete, are noted.
The following two RFCs are of general importance to the Internet community because they contain information that has an impact on all implementations of all protocols:
RFC 1122 covers requirements for communication protocols for the data link, internetworking, and transport layers of host Internet software. RFC 1123 covers requirements for the application and support protocols for Internet host software.
This section contains tables that list and briefly describe the RFCs that
Digital UNIX
was
validated against and that are referenced in the Host
Requirement RFCs. Additionally,
Table A-8
and
Table A-9
list the total
must/must not
level requirements explicitly stated by the Host Requirements RFCs.
Table A-1
lists the RFCs that RFC 1122 references for the link layer. For
a discussion of link layer requirements, see Chapter 2
of RFC 1122.
Table Notes:
Table A-2
lists the RFCs that RFC 1122 references for the Internet layer. For
a discussion of Internet layer requirements, see Chapter 3 of
RFC 1122.
Table Notes:
Table A-3
lists the RFCs that RFC 1122 references for the transport layer. For
a discussion of transport layer requirements for
UDP and TCP, see Chapter 4 of RFC 1122.
Table A-4
lists the RFCs that RFC 1123 references for the TELNET protocol. For
a discussion of TELNET protocol requirements, see Chapter 3 of RFC 1123.
Table Notes:
Table A-5
lists the RFCs that RFC 1123 references for the file transfer protocols FTP and
TFTP. For a discussion of file transfer protocol requirements, see Chapter 4
of RFC 1123.
Table Notes:
Table A-6
lists the RFCs that RFC 1123 references for the SMTP protocol. For
a discussion of SMTP protocol requirements, see Chapter 5 of RFC 1123.
Table A-7
lists the RFCs that RFC 1123 references for the Domain Name System,
Host Initialization,
and
Remote Management support services.
For
a discussion of Domain Name System,
Host Initialization,
and Remote Management requirements,
see Chapter 6 of RFC 1123.
Table Notes:
RFC 1123 references RFC 1066:
Management Information Base for Network Management of TCP/IP-based Internets.
RFC 1158 renders both RFC 1066 and RFC 1156:
Management Information Base for Network Management of TCP/IP-based Internets
obsolete.
RFC 1213, in turn, renders RFC 1158 obsolete.
Table A-8
summarizes the
must/must not
level requirements, per layer, explicitly stated
by RFC 1122.
Table A-9
summarizes the
must/must not
level requirements explicitly stated
by RFC 1123.
The following sections describe how to configure
your system to conditionally comply
to the specifications described in the Host Requirements RFCs when your system
is acting as an Internet host. Under each heading is a description of a
must
level item with which
Digital UNIX
does not comply by default.
Along with each item is
a discussion about why
Digital UNIX
does not comply, and information about how
to configure your system to comply with that item.
When the IP datagram reassembly timeout expires,
the partially reassembled datagram
must be discarded and an ICMP Time Exceeded message sent to the
source host, if fragment zero has been received (RFC 1122, Section 3.3.2).
Digital UNIX
discards the partially reassembled datagram when the
reassembly timeout expires. However,
by default,
Digital UNIX
does not generate an ICMP Time Exceeded
message.
At the time this host requirement was written, it was believed
that a form of path MTU discovery procedure might find this
message useful (RFC 1122, Section 3.2.2.4). RFC 1191:
Path MTU Discovery,
however, does not use this mechanism.
Receiving an ICMP Time Exceeded message may be
useful for TCP connections, because TCP is required to act on
receipt of ICMP error messages. UDP has no such requirement.
While fragmentation is now generally prevented with TCP, this
is not the case with UDP. Large UDP messages, for example
those generated by NFS, can cause storms of ICMP Time
Exceeded messages, if these messages were generated by default.
For these reasons, Digital does not recommend that
Digital UNIX
be configured to generate ICMP Time Exceeded messages.
Digital UNIX
records the number of fragments dropped due to reassembly
timeout; you can run the
netstat -p
command to display
this number. The following example shows the display for IP of the
netstat -p
command. Ten fragments were dropped due to
reassembly timeout:
%
/usr/sbin/netstat -p ip
To configure the system to send ICMP Time Exceeded on Reassembly messages,
set the kernel variable
ipsendreastimo
to 1. The default for this variable is zero (0).
To set the
ipsendreastimo
variable, become superuser and patch the kernel disk image using the
dbx patch
command as follows:
#
dbx -k /vmunix
Reboot your system with the
shutdown -r
command to have the change take effect.
For more information,
see the
shutdown(8)
reference page.
The Urgent Data pointer must point to the last octet of the
sequence of urgent data (RFC 1122, Section 4.2.2.4).
RFC 793:
Transmission Control Protocol
contains
conflicting statements about the octet that is
referenced by the urgent pointer in a sequence of urgent
TCP data. The first of these statements indicates that the
urgent pointer "points to the sequence number of the
octet following the urgent data."
RFC 1122, Section 4.2.2.4, however, indicates that the "urgent
pointer points to the sequence number of the LAST octet (not
LAST + 1) in a sequence of urgent data." This requirement
reflects the second, and conflicting, definition of the urgent
pointer as described in RFC 793.
BSD has traditionally applied the first definition of the
urgent pointer that appears in RFC 793. To maximize
interoperability,
Digital UNIX
uses the BSD default which
means that the urgent pointer points to the sequence number
of the LAST octet plus one in a sequence of urgent data.
This behavior is controlled by the
tcp_urgent_42
kernel variable which applies system-wide and therefore affects all
TCP connections.
To configure the system to point to the
last octet in a sequence of urgent data, set the kernel variable
tcp_urgent_42
to zero (0). The default for this variable is 1.
To set the
tcp_urgent_42
variable, become superuser and patch
the kernel disk image using the
dbx patch
command as follows:
#
dbx -k /vmunix
Reboot your system with the
shutdown -r
command to have the change take effect.
For more information,
see the
shutdown(8)
reference page.
Table A-1: Referenced RFCs for the Link Layer
Referenced RFC
Description
RFC 1042:
Internet Protocol on IEEE 802 (IP-IEEE)
Specifies a standard method of encapsulating the
IP datagrams and ARP requests and replies on IEEE 802 Networks.
RFC 894:
Internet Protocol on Ethernet Networks (IP-E)
Specifies a standard method of encapsulating
IP datagrams on an Ethernet.
RFC 826:
Address Resolution Protocol (ARP)
Presents a method for converting
protocol addresses (IP addresses) to local network
addresses (Ethernet addresses).
Table A-2: Referenced RFCs for the Internet Layer
Referenced RFC
Description
RFC 1112:
Host Extensions for IP Multicasting (IGMP)
Specifies the extensions required of a host implementation
of the IP to support multicasting.
RFC 1009
Documents the requirements for
IP routers connected to the Internet.
RFC 950:
Internet Standard Subnetting Procedures
Discusses standards for subnet addressing within internet networks.
RFC 792:
Internet Control Message Protocol (ICMP)
Describes a protocol for exchanging informational and error messages
between hosts, or between gateways and hosts.
RFC 791:
Internet Protocol (IP)
Specifies an unreliable connectionless protocol for the delivery
of datagrams between systems.
Table A-3: Referenced RFCs for the Transport Layer
Referenced RFC
Description
RFC 793:
Transmission Control Protocol (TCP)
Specifies a connection-oriented reliable protocol for the
delivery of stream data between ports.
RFC 768:
User Datagram Protocol (UDP)
Defines an unreliable connectionless protocol for the delivery
of data between ports.
Table A-4: Referenced RFCs for the TELNET Protocol
Referenced RFC
Description
RFC 1184
Describes terminal character processing on
the client side of a Telnet connection.
RFC 1091:
Telnet Terminal Type Option
Specifies a standard for hosts on the Internet that exchange terminal
type information within the Telnet protocol.
RFC 1080:
Telnet Remote Flow Control Option
Specifies a standard for hosts on the Internet
that use remote flow control within the Telnet protocol.
RFC 1079:
Telnet Terminal Speed Option
Specifies a standard for hosts on the Internet
that exchange terminal speed information within the
Telnet protocol.
RFC 1073:
Telnet Window Size Option
Describes Telnet options that allow a client to
convey window size to a Telnet server.
RFC 861:
Telnet Extended Options List
Describes an extended Telnet option that allows an additional 256
Telnet options.
RFC 860:
Telnet Timing Mark Option
Provides a mechanism for a user or process at one end of a Telnet
connection to be sure that previously transmitted data has been
completely processed, printed, discarded, or otherwise disposed of.
RFC 859:
Telnet Status Option
Allows one end of a Telnet connection to verify the current status of
Telnet options (for example, echoing) as viewed by the
other end of the connection.
RFC 858:
Telnet Suppress Go Ahead (SGA) Option
Allows a full duplex connection between a full duplex terminal and a
host optimized to handle full duplex terminals to suppress
the transmission of GO AHEADS.
RFC 857:
Telnet Echo Option
Allows the two ends of a Telnet connection to agree
on NVT keyboard characters.
RFC 856:
Telnet Binary Option
Provides the option of binary transmission in a
natural way for Telnet connections to INTERPRET the characters transmitted
over a Telnet connection as binary data.
RFC 855:
Telnet Option Specification
Specifies a method of option code assignment and standards
for documenting options for the Telnet protocol.
RFC 854:
Telnet Protocol Specification
Provides a general,
bidirectional, 8-bit byte-oriented communications facility whose
primary goal is to allow a standard method of interfacing terminal
devices and terminal-oriented processes to each other.
RFC 736:
Telnet SUPDUP Option
Allows a host to provide SUPDUP service on the normal
Telnet socket (27 octal) instead of 137 (octal) which is the normal
SUPDUP ICP socket.
RFC 734:
SUPDUP Protocol
Describes a highly efficient display Telnet protocol.
RFC 732:
Data Entry Terminal Option
Describes the DET option to Telnet. The DET option uses five classes of subcommands:
1) to establish the
requirements and capabilities of the application and the terminal, 2)
to format the screen, and to control the 3) edit, 4) erasure, and 5)
transmission functions.
Table A-5: Referenced RFCs for the File Transfer Protocols
Protocol
Referenced RFC
Description
FTP
RFC 959:
File Transfer Protocol (FTP)
Specifies a protocol whose objectives are:
1) to promote sharing of files (computer programs and/or data),
2) to encourage indirect or implicit (via
programs) use of remote computers, 3) to shield a user from
variations in file storage systems among hosts, and 4) to transfer
data reliably and efficiently.
RFC 678:
Standard File Formats
Specifies standard formats for files and describes the expected final form for
printed copies of such files.
TFTP
RFC 1350
Describes a very simple protocol
used to transfer files in which each nonterminal packet is acknowledged separately.
Table A-6: Referenced RFCs for the SMTP Protocol
Referenced RFC
Description
RFC 1049:
A Content-Type Field for Internet Messages
Specifies additions to the
Internet Mail Protocol,
RFC-822, for the Internet community.
RFC 1047:
Duplicate Messages and SMTP
Examines a synchronization problem in the
SMTP that can cause a message to be delivered multiple times.
RFC 974:
Mail Routing and the Domain System
Describes how mail systems on the Internet
are expected to route messages based on information from the domain
system described in RFCs 882, 883, and 973.
RFC 822:
Standard for the Format of ARPA Internet Text Messages
Specifies a syntax for text messages that are
sent among computer users within the framework of electronic
mail.
RFC 821:
Simple Mail Transfer Protocol (SMTP)
Describes a protocol designed to be
independent of the particular transmission subsystem and that
requires only a reliable ordered data stream channel
to transfer mail reliably and efficiently.
Table A-7: Referenced RFCs for the Support Services
Service
Referenced RFC
Description
Domain Name System
RFC 1035:
Domain Names - Implementation and Specification
Describes the details of the domain system and protocol.
Assumes that the reader is familiar with the concepts discussed in a
companion RFC,
Domain Names - Concepts and Facilities.
RFC 1034:
Domain Names - Concepts and Facilities
Introduces the Domain Name System (DNS).
RFC 974:
Mail Routing and the Domain System
Describes how mail systems on the Internet
are expected to route messages based on information from the domain
system described in RFCs 882, 883, and 973.
Host Initialization
RFC 903:
A Reverse Address Resolution Protocol
Describes a link-layer
protocol that allows a host to find its
IP address.
Network
Management
RFC 1213
Defines the second version of the Management Information
Base (MIB-II) for use with network management protocols in TCP/IP-
based Internets.
RFC 1157
Defines a simple protocol by which management information for a
network element can be inspected or altered by logically remote
users.
Table A-8: Total must/must not Requirements in RFC 1122
Link
Internet
Transport
Layer
Layer
Layer
10
92
79
(7 must, 3 must not)
(80 must, 12 must not)
(74 must, 5 must not)
Table A-9: Total must/must not Requirements in RFC 1123
General Requirements
TELNET Protocol
File Transfer Protocols
SMTP Protocol
DNS Protocol
9
24
50
41
33
(9 must)
(22 must, 2 must not)
(46 must, 4 must not)
(32 must, 9 must not)
(29 must, 4 must not)
A.3 Configuring Digital UNIX to Conditionally Comply to the Host Requirements RFCs
A.3.1 Internet Layer[Footnote 2] (RFC 1122)
ip:
1831450 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
3542 fragments received
0 fragments dropped (dup or out of space)
10 fragment dropped after timeout
0 packets forwarded
0 packets not forwardable
0 redirects sent
A.3.1.1 Configuration Information
dbx version 11.0.1
Type 'help' for help.
stopped at [thread_block:1403 ,0xfffffc000032d860] \
Source not available
(dbx)
patch ipsendreastimo = 1
1
(dbx)
quit
A.3.2 Transmission Control Protocol (RFC 1122)
A.3.2.1 Configuration Information
dbx version 11.0.1
Type 'help' for help.
stopped at [thread_block:1403 ,0xfffffc000032d860] \
Source not available
(dbx)
patch tcp_urgent_42 = 0
0
(dbx)
quit