5. Riferimenti (REFERENCES)

Riferimenti introduttivi (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.
Questo documento viene ripubblicato periodicamente con nuovi numeri RFC; deve essere utilizzata l'ultima versione.

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

Riferimenti secondari (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.

Riferimenti del livello di collegamento (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.
Questo RFC contiene molte informazioni importanti per gli implementatori Internet che prevedono di utilizzare reti IEEE 802.

Riferimenti del livello 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.
Questa specifica, così come emendata da RFC-963, intende descrivere il protocollo Internet ma presenta alcune omissioni gravi (ad es. l'estensione subnet obbligatoria [IP:3] e l'estensione multicast opzionale [IP:4]). È inoltre obsoleta. In caso di conflitto, RFC-791, RFC-792 e RFC-950 devono essere considerati autorevoli, mentre il presente documento è autorevole su tutti.

[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.
Discute e chiarisce la relazione tra l'opzione TCP Maximum Segment Size e la dimensione del datagramma 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.
Questo utile articolo discute i problemi creati dalla frammentazione Internet e presenta soluzioni alternative.

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

This and the following paper should be read by every implementor.
Questo e il seguente articolo dovrebbero essere letti da ogni implementatore.

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

Riferimenti IP secondari (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.
Questo RFC ha descritto per primo gli indirizzi di broadcast diretto. Tuttavia, la maggior parte del RFC riguarda i gateway, non gli host.

Riferimenti UDP (UDP REFERENCES):

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

Riferimenti 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.
Questa specifica, così come emendata da RFC-964, intende descrivere lo stesso protocollo di RFC-793 [TCP:1]. In caso di conflitto, RFC-793 ha la precedenza e il presente documento è autorevole su entrambi.

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

Riferimenti TCP secondari (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.

Considerazioni sulla sicurezza (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.
Ci sono molte questioni di sicurezza nei livelli di comunicazione del software host, ma una discussione completa va oltre l'ambito di questo 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'architettura Internet fornisce generalmente poca protezione contro lo spoofing degli indirizzi sorgente IP, quindi qualsiasi meccanismo di sicurezza basato sulla verifica dell'indirizzo sorgente IP di un datagramma dovrebbe essere trattato con sospetto. Tuttavia, in ambienti ristretti alcune verifiche dell'indirizzo sorgente possono essere possibili. Ad esempio, potrebbe esserci una LAN sicura il cui gateway verso il resto di Internet scarta qualsiasi datagramma in arrivo con un indirizzo sorgente che spoofa l'indirizzo LAN. In questo caso, un host sulla LAN potrebbe usare l'indirizzo sorgente per verificare se la sorgente è locale o remota. Questo problema è complicato dal source routing, e alcuni hanno suggerito che l'inoltro di datagrammi con source route da parte degli host (vedere sezione 3.3.5) dovrebbe essere vietato per motivi di sicurezza.

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).
Questioni relative alla sicurezza sono menzionate nelle sezioni concernenti l'opzione di sicurezza IP (sezione 3.2.1.8), il messaggio ICMP Parameter Problem (sezione 3.2.2.5), le opzioni IP nei datagrammi UDP (sezione 4.1.3.2) e i port TCP riservati (sezione 4.2.2.1).

Indirizzo dell'autore (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]