> A new Request for Comments is now available in online RFC libraries. > > > RFC 4884 > > Title: Extended ICMP to Support Multi-Part > Messages > Author: R. Bonica, D. Gan, > D. Tappan, C. Pignataro > Status: Standards Track > Date: April 2007 > Mailbox: [EMAIL PROTECTED], > [EMAIL PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED] > Pages: 19 > Characters: 42169 > Updates: RFC0792, RFC4443 > See-Also: > > I-D Tag: draft-bonica-internet-icmp-16.txt > > URL: http://www.rfc-editor.org/rfc/rfc4884.txt > > This document redefines selected ICMP messages to support multi-part > operation. A multi-part ICMP message carries all of the information > that ICMP messages carried previously, as well as additional > information that applications may require. > > Multi-part messages are supported by an ICMP extension structure. > The extension structure is situated at the end of the ICMP message. > It includes an extension header followed by one or more extension > objects. Each extension object contains an object header and object > payload. All object headers share a common format. > > This document further redefines the above mentioned ICMP messages by > specifying a length attribute. All of the currently defined ICMP > messages to which an extension structure can be appended include an > "original datagram" field. The "original datagram" field contains > the initial octets of the datagram that elicited the ICMP error > message. Although the original datagram field is of variable length, > the ICMP message does not include a field that specifies its length. > Therefore, in order to facilitate message parsing, this document > allocates eight previously reserved bits to reflect the length of the > "original datagram" field. > > The proposed modifications change the requirements for ICMP > compliance. The impact of these changes on compliant implementations > is discussed, and new requirements for future implementations are > presented. > > This memo updates RFC 792 and RFC 4443. [STANDARDS TRACK] > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions for improvements.Please refer to the current edition of the > Internet Official Protocol Standards (STD 1) for the standardization > state and status of this protocol. Distribution of this memo is > unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to [EMAIL PROTECTED] Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to [EMAIL PROTECTED] > > Details on obtaining RFCs via FTP or EMAIL may be obtained by sending > an EMAIL message to [EMAIL PROTECTED] with the message body > > help: ways_to_get_rfcs. For example: > > To: [EMAIL PROTECTED] > Subject: getting rfcs > > help: ways_to_get_rfcs > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to [EMAIL PROTECTED] Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > Submissions for Requests for Comments should be sent to > [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC > Authors, for further information. > > > The RFC Editor Team > USC/Information Sciences Institute > > ... >
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
