5. Références (REFERENCES)

Références introductives (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.
Ce document est republicé périodiquement avec de nouveaux numéros RFC ; la dernière version doit être utilisée.

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

Références secondaires (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.

Références de la couche de liaison (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.
Ce RFC contient beaucoup d'informations importantes pour les implémenteurs Internet prévoyant d'utiliser les réseaux IEEE 802.

Références de la couche Internet (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.
Cette spécification, telle que modifiée par RFC-963, est destinée à décrire le protocole Internet mais présente quelques omissions sérieuses (par exemple, l'extension de sous-réseau obligatoire [IP:3] et l'extension de multicast optionnelle [IP:4]). Elle est également obsolète. En cas de conflit, RFC-791, RFC-792 et RFC-950 doivent être considérés comme faisant autorité, tandis que le présent document est autoritaire sur tous.

[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.
Discuté et clarifie la relation entre l'option Taille Maximale de Segment TCP et la taille du datagramme IP.

[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.
Cet article utile discute des problèmes créés par la fragmentation Internet et présente des solutions alternatives.

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

This and the following paper should be read by every implementor.
Ce document et le suivant devraient être lus par chaque implémenteur.

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

Références IP secondaires (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.
Ce RFC a d'abord décrit les adresses de diffusion dirigée. Cependant, la majeure partie du RFC concerne les passerelles, pas les hôtes.

Références UDP (UDP REFERENCES):

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

Références TCP (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.
Cette spécification telle que modifiée par RFC-964 est destinée à décrire le même protocole que RFC-793 [TCP:1]. En cas de conflit, RFC-793 prime, et le présent document est autoritaire sur les deux.

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

Références TCP secondaires (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.

Considérations de sécurité (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.
Il existe de nombreux problèmes de sécurité dans les couches de communication des logiciels hôtes, mais une discussion complète dépasse la portée de ce 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.
L'architecture Internet offre généralement peu de protection contre l'usurpation d'adresses source IP, donc tout mécanisme de sécurité basé sur la vérification de l'adresse source IP d'un datagramme doit être traité avec méfiance. Cependant, dans des environnements restreints, certaines vérifications d'adresse source peuvent être possibles. Par exemple, il pourrait y avoir un LAN sécurisé dont la passerelle vers le reste de l'Internet rejetterait tout datagramme entrant avec une adresse source usurpant l'adresse LAN. Dans ce cas, un hôte sur le LAN pourrait utiliser l'adresse source pour tester si la source est locale ou distante. Ce problème est compliqué par le routage de source, et certains ont suggéré que le transfert de datagrammes à routage de source par les hôtes (voir section 3.3.5) devrait être interdit pour des raisons de sécurité.

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).
Des questions liées à la sécurité sont mentionnées dans les sections concernant l'option de sécurité IP (section 3.2.1.8), le message ICMP Paramètre Problème (section 3.2.2.5), les options IP dans les datagrammes UDP (section 4.1.3.2), et les ports TCP réservés (section 4.2.2.1).

Adresse de l'auteur (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]