FW: RFC 4963 on IPv4 Reassembly Errors at High Data Rates

FYI - IPv4 fragmentation can be harmful at high speed.  The
best bet is to not to allow fragmentation, but the RFC says:
"stronger error checking at any level above IP" is a mitigation
measure.  iSCSI digests and the end-to-end use of the FC frame
CRC by FCIP and iFCP are examples of this sort of "stronger
error checking".

--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Friday, July 27, 2007 5:34 PM
To: [email protected]; [email protected]
Cc: [email protected]
Subject: RFC 4963 on IPv4 Reassembly Errors at High Data Rates


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4963

        Title:      IPv4 Reassembly Errors at High 
                    Data Rates 
        Author:     J. Heffner, M. Mathis,
                    B. Chandler
        Status:     Informational
        Date:       July 2007
        Mailbox:    [email protected], 
                    [email protected], 
                    [email protected]
        Pages:      10
        Characters: 22399
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-heffner-frag-harmful-05.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4963.txt

IPv4 fragmentation is not sufficiently robust for use under some
conditions in today's Internet.  At high data rates, the 16-bit IP
identification field is not large enough to prevent frequent
incorrectly assembled IP fragments, and the TCP and UDP checksums are
insufficient to prevent the resulting corrupted datagrams from being
delivered to higher protocol layers.  This note describes some easily
reproduced experiments demonstrating the problem, and discusses some
of the operational implications of these observations.  This memo
provides information for the Internet community.


INFORMATIONAL: This memo provides information for the Internet
community. 
It does not specify an Internet standard of any kind. 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

...


_______________________________________________
IETF-Announce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf-announce


_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips