[Int-area] FW: RFC 4884 on Extended ICMP to Support Multi-Part Messages

[Jari Arkko <jari.arkko at piuha.net>]

> 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:    rbonica at juniper.net, 
>                     derhwagan at yahoo.com, 
>                     Dan.Tappan at gmail.com, cpignata at cisco.com
>         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 IETF-REQUEST at IETF.ORG.  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG.
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body 
>
> help: ways_to_get_rfcs. For example:
>
>         To: rfc-info at RFC-EDITOR.ORG
>         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 RFC-Manager at RFC-EDITOR.ORG.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> RFC-EDITOR at RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
> Authors, for further information.
>
>
> The RFC Editor Team
> USC/Information Sciences Institute
>
> ...
>   


_______________________________________________
Int-area mailing list
Int-area at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area