5. REFERENCES
INTRODUCTORY REFERENCES
[INTRO:1] "Requirements for Internet Hosts -- Application and Support," IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,
[INTRO:2] "Requirements for Internet Gateways," R. Braden and J. Postel, RFC-1009, June 1987.
[INTRO:3] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.
[INTRO:4] "Official Internet Protocols," J. Reynolds and J. Postel, RFC-1011, May 1987.
This document is republished periodically with new RFC numbers; the latest version must be used.
[INTRO:5] "Protocol Document Order Information," O. Jacobsen and J. Postel, RFC-980, March 1986.
[INTRO:6] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May 1987.
This document is republished periodically with new RFC numbers; the latest version must be used.
[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D. Clark, RFC-817, July 1982.
[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM SOSP, Orcas Island, Washington, December 1985.
Secondary References:
[INTRO:9] "A Protocol for Packet Network Intercommunication," V. Cerf and R. Kahn, IEEE Transactions on Communication, May 1974.
[INTRO:10] "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D. Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
[INTRO:11] "The DARPA Internet Protocol Suite," B. Leiner, J. Postel, R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,
March 1985. Also in: IEEE Communications Magazine, March 1985. Also available as ISI-RS-85-153.
[INTRO:12] "Final Text of DIS8473, Protocol for Providing the Connectionless Mode Network Service," ANSI, published as RFC-994, March 1986.
[INTRO:13] "End System to Intermediate System Routing Exchange Protocol," ANSI X3S3.3, published as RFC-995, April 1986.
LINK LAYER REFERENCES
[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893, April 1984.
[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826, November 1982.
[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet Networks," C. Hornig, RFC-894, April 1984.
[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802 "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988.
This RFC contains a great deal of information of importance to Internet implementers planning to use IEEE 802 networks.
IP LAYER REFERENCES
[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981.
[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792, September 1981.
[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel, RFC-950, August 1985.
[IP:4] "Host Extensions for IP Multicasting," S. Deering, RFC-1112, August 1989.
[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department of Defense, August 1983.
This specification, as amended by RFC-963, is intended to describe
the Internet Protocol but has some serious omissions (e.g., the mandatory subnet extension [IP:3] and the optional multicasting extension [IP:4]). It is also out of date. If there is a conflict, RFC-791, RFC-792, and RFC-950 must be taken as authoritative, while the present document is authoritative over all.
[IP:6] "Some Problems with the Specification of the Military Standard Internet Protocol," D. Sidhu, RFC-963, November 1985.
[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel, RFC-879, November 1983.
Discusses and clarifies the relationship between the TCP Maximum Segment Size option and the IP datagram size.
[IP:8] "Internet Protocol Security Options," B. Schofield, RFC-1108,
[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM SIGCOMM-87, August 1987. Published as ACM Comp Comm Review, Vol. 17, no. 5.
This useful paper discusses the problems created by Internet fragmentation and presents alternative solutions.
[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July 1982.
This and the following paper should be read by every implementor.
[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.
SECONDARY IP REFERENCES:
[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J. Mogul, RFC-922, October 1984.
[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July 1982.
[IP:14] "Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July 1987.
This RFC first described directed broadcast addresses. However, the bulk of the RFC is concerned with gateways, not hosts.
UDP REFERENCES:
[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.
TCP REFERENCES:
[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September 1981.
[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of Defense, August 1984.
This specification as amended by RFC-964 is intended to describe the same protocol as RFC-793 [TCP:1]. If there is a conflict, RFC-793 takes precedence, and the present document is authoritative over both.
[TCP:3] "Some Problems with the Specification of the Military Standard Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964, November 1985.
[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel, RFC-879, November 1983.
[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813, July 1982.
[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM SIGCOMM-87, August 1987.
[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88, August 1988.
SECONDARY TCP REFERENCES:
[TCP:8] "Modularity and Efficiency in Protocol Implementation," D. Clark, RFC-817, July 1982.
[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.
[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C. Partridge, RFC-1071, September 1988.
[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden, RFC-1072, October 1988.
Security Considerations
There are many security issues in the communication layers of host software, but a full discussion is beyond the scope of this RFC.
The Internet architecture generally provides little protection against spoofing of IP source addresses, so any 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 checking may be possible. For example, there might be a secure LAN whose gateway to the rest of the Internet discarded any incoming datagram with a source address that spoofed the LAN address. In this case, a host on the LAN could use the source address to test for local vs. remote source. This problem 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 reasons.
Security-related issues are mentioned in sections concerning the IP Security option (Section 3.2.1.8), the ICMP Parameter Problem message (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and reserved TCP ports (Section 4.2.2.1).
Author's Address
Robert Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
Phone: (213) 822 1511
EMail: [email protected]