[Return to Library] [Contents] [Previous Chapter] [Next Section] [Index] [Help]


A    Conformance to Internet Host Requirements

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:


[Return to Library] [Contents] [Previous Chapter] [Next Section] [Index] [Help]


A.1    Background

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:


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Index] [Help]


A.2    The Host Requirements RFCs (RFC 1122 and RFC 1123)

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 A-1: Referenced RFCs for the Link Layer

Referenced RFC[Table Note 1] 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 Notes:

  1. Digital UNIX is also validated against the following RFCs that are not referenced in RFC 1122:

    • RFC 1103: Transmission of IP over FDDI (IP-FDDI)

    • RFC 1055: A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP

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 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[Table Note 1]: Requirements for Internet Gateways 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 Notes:

  1. RFC 1009: Requirements for Internet Gateways references the Exterior Gateway Protocol (EGP) and the Routing Information Protocol (RIP). The EGP is described in RFC 904 and the RIP is described in RFC 1058.

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-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 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 A-4: Referenced RFCs for the TELNET Protocol

Referenced RFC Description
RFC 1184[Table Note 1]: Telnet Linemode Option 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 Notes:

  1. RFC 1184: Telnet Linemode Option renders RFC 1116: Telnet Linemode Option obsolete, and it references RFC 885: TELNET End of Record Option.

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 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[Table Note 1]: The TFTP Protocol Describes a very simple protocol used to transfer files in which each nonterminal packet is acknowledged separately.

Table Notes:

  1. RFC 1350: The TFTP Protocol renders RFC 783: The TFTP Protocol obsolete.

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-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 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 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[Table Note 1]: Management Information Base for Network Management of TCP/IP-based internets: MIB II Defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based Internets.
  RFC 1157[Table Note 2]: A Simple Network Management Protocol (SNMP) Defines a simple protocol by which management information for a network element can be inspected or altered by logically remote users.

Table Notes:

  1. Digital UNIX is validated against RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets: MIB-II.

    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.

  2. RFC 1157: A Simple Network Management Protocol (SNMP) supercedes RFC 1098: A Simple Network Management Protocol (SNMP), which is referenced in RFC 1123.

Table A-8 summarizes the must/must not level requirements, per layer, explicitly stated by RFC 1122.

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 summarizes the must/must not level requirements explicitly stated by RFC 1123.

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)


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Index] [Help]


A.3    Configuring Digital UNIX to Conditionally Comply to the Host Requirements RFCs

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.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Index] [Help]


A.3.1    Internet Layer[Footnote 2] (RFC 1122)

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

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


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Index] [Help]


A.3.1.1    Configuration Information

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

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

Reboot your system with the shutdown -r command to have the change take effect. For more information, see the shutdown(8) reference page.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Next Section] [Index] [Help]


A.3.2    Transmission Control Protocol (RFC 1122)

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.


[Return to Library] [Contents] [Previous Chapter] [Previous Section] [Index] [Help]


A.3.2.1    Configuration Information

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

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

Reboot your system with the shutdown -r command to have the change take effect. For more information, see the shutdown(8) reference page.