5. Referenzen (REFERENCES)

Einführende Referenzen (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.
Dieses Dokument wird periodisch mit neuen RFC-Nummern neu veröffentlicht; die neueste Version muss verwendet werden.

[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.

[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.

Sekundäre Referenzen (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.

Referenzen der Sicherungsschicht (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.
Dieses RFC enthält viele wichtige Informationen für Internet-Implementierer, die IEEE-802-Netzwerke verwenden möchten.

Referenzen der Internetschicht (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.
Diese Spezifikation, geändert durch RFC-963, soll das Internet-Protokoll beschreiben, weist jedoch einige schwerwiegende Auslassungen auf (z. B. die zwingende Subnetz-Erweiterung [IP:3] und die optionale Multicast-Erweiterung [IP:4]). Sie ist zudem veraltet. Bei einem Konflikt müssen RFC-791, RFC-792 und RFC-950 als maßgeblich angesehen werden, während das vorliegende Dokument über allen autoritativ ist.

[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.
Erörtert und klärt die Beziehung zwischen der TCP Maximum Segment Size-Option und der IP-Datagrammgröße.

[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.
Dieses nützliche Papier erörtert die durch Internet-Fragmentierung verursachten Probleme und stellt alternative Lösungen vor.

[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July 1982.

This and the following paper should be read by every implementor.
Dieses und das folgende Papier sollten von jedem Implementierer gelesen werden.

[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.

Sekundäre IP-Referenzen (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.
Dieses RFC beschrieb erstmals gerichtete Broadcast-Adressen. Der Großteil des RFC befasst sich jedoch mit Gateways, nicht mit Hosts.

UDP-Referenzen (UDP REFERENCES):

[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.

TCP-Referenzen (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.
Diese Spezifikation, geändert durch RFC-964, soll dasselbe Protokoll wie RFC-793 [TCP:1] beschreiben. Bei einem Konflikt hat RFC-793 Vorrang, und das vorliegende Dokument ist über beiden autoritativ.

[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.

Sekundäre TCP-Referenzen (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.

Sicherheitsüberlegungen (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.
Es gibt viele Sicherheitsprobleme in den Kommunikationsschichten der Host-Software, aber eine vollständige Diskussion liegt außerhalb des Rahmens dieses 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.
Die Internet-Architektur bietet im Allgemeinen wenig Schutz gegen das Spoofing von IP-Quelladressen, sodass jeder Sicherheitsmechanismus, der auf der Überprüfung der IP-Quelladresse eines Datagramms basiert, mit Misstrauen betrachtet werden sollte. In eingeschränkten Umgebungen können jedoch einige Quelladressenprüfungen möglich sein. Beispielsweise könnte es ein sicheres LAN geben, dessen Gateway zum Rest des Internets jedes eingehende Datagramm mit einer IP-Quelladresse verwirft, die die LAN-Adresse fälscht. In diesem Fall könnte ein Host im LAN die Quelladresse verwenden, um eine lokale gegenüber einer entfernten Quelle zu testen. Dieses Problem wird durch Source-Routing kompliziert, und einige haben vorgeschlagen, dass das Weiterleiten von Source-Route-Datagrammen durch Hosts (siehe Abschnitt 3.3.5) aus Sicherheitsgründen verboten werden sollte.

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).
Sicherheitsrelevante Themen werden in Abschnitten erwähnt, die sich auf die IP-Sicherheitsoption (Abschnitt 3.2.1.8), die ICMP Parameter Problem-Nachricht (Abschnitt 3.2.2.5), IP-Optionen in UDP-Datagrammen (Abschnitt 4.1.3.2) und reservierte TCP-Ports (Abschnitt 4.2.2.1) beziehen.

Adresse des Autors (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]