Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Informational December 03, 2007 Expires: June 5, 2008 DHCP Fragmentation and Reassembly draft-templin-dhcpmtu-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 5, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract IP fragmentation has been shown to be problematic through operational experience and through studies conducted over the course of many years. Some transports (e.g., TCP) have the ability to adjust their message sizes to avoid IP fragmentation, however no such capability is built into the UDP transport. UDP applications must therefore have a means to perform their own fragmentation and reassembly prior to submitting their data to UDP/IP. This document specifies a fragmentation/reassembly capability for DHCP. Templin Expires June 5, 2008 [Page 1] Internet-Draft DHCP Fragmentation December 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Concept of Operation . . . . . . . . . . . . . . . . . . . . . 3 4. Minimum Reassembly Size Requirement . . . . . . . . . . . . . 3 5. The DHCP Fragment Option . . . . . . . . . . . . . . . . . . . 3 6. DHCP Fragmentation and Reassembly . . . . . . . . . . . . . . 4 6.1. Client/Server Negotiation . . . . . . . . . . . . . . . . 4 6.2. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 5 6.3. Reassembly . . . . . . . . . . . . . . . . . . . . . . . . 6 7. sprite-mtu Checksum Calculation . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Templin Expires June 5, 2008 [Page 2] Internet-Draft DHCP Fragmentation December 2007 1. Introduction IP fragmentation has been shown to be problematic through operational experience and through studies conducted over the course of many years [FRAG][RFC4459][RFC4821][RFC4963][RFC4963][I-D.templin-inetmtu]. Some transports (e.g., TCP) have the ability to adjust their message sizes to avoid IP fragmentation, however no such capability is built into the UDP transport. UDP applications must therefore have a means to perform their own fragmentation and reassembly prior to submitting their data to UDP/IP. This document specifies an application-layer fragmentation/reassembly capability for DHCP. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Concept of Operation A new DHCP option called the DHCP Fragment option is defined. DHCP clients and servers include this option in their exchanges to inform the other party that the option is supported. When both parties support the service, DHCP fragmentation/reassembly can be used as specified in this document. 4. Minimum Reassembly Size Requirement DHCP clients and servers that implement this protocol MUST be capable of reassembling DHCP messages of at least 2048 bytes and SHOULD provide a configuration knob to enable still larger reassembly sizes. 5. The DHCP Fragment Option A new DHCP option [RFC2132] called the "DHCP fragment option" is defined with the following format: Templin Expires June 5, 2008 [Page 3] Internet-Draft DHCP Fragmentation December 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum-A | Checksum-B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The DHCP Fragment Option Code the DHCP option code (TBD; see Section 6). Length the DHCP option length. Set to 10 for the final fragment; 6 for non-final fragments. Flags a 3-bit Flags field; reserved for future use. Fragment Offset the 13-bit offset from the beginning of the DHCP message, in units of 8 octets. Identification a 32-bit identification for this DHCP message. Chosen randomly; SHOULD be different from the 'xid' in the DHCP message header. Checksum-A The 16-bit A portion of the sprite-mtu checksum (see: Section 7) - included only in the final fragment. The value 0 means that no checksum is included. Checksum-B The 16-bit B portion of the sprite-mtu checksum (see: Section 7) - included only in the final fragment. The value 0 means that no checksum is included. 6. DHCP Fragmentation and Reassembly 6.1. Client/Server Negotiation A DHCP client that wishes to enable DHCP fragmentation/reassembly MUST include a DHCP fragment option as the first option in its DHCP messages. The DHCP client SHOULD send its DHCP messages as single Templin Expires June 5, 2008 [Page 4] Internet-Draft DHCP Fragmentation December 2007 fragments (i.e., with a final DHCP fragment option) until the server has indicated that it also supports the protocol. Thereafter, the client MAY fragment long DHCP messages by including the DHCP fragment option in multiple messages with the same 'xid' and 'Identification' as specified in Section 5.2. When the server does not support the protocol, the client MAY omit the DHCP fragment option from further messages but MUST NOT attempt to fragment any of the DHCP messages it sends to the server using this protocol. DHCP servers that support DHCP fragmentation/reassembly MUST include a DHCP fragment option as the first option in any of their responses to a client that has included a DHCP fragment option in its requests. The DHCP server MAY send fragmented DHCP messages to the client by including a DHCP fragment option in multiple messages with the same 'xid' and 'Identification' as specified in Section 6.2. 6.2. Fragmentation When a DHCP fragmentation/reassembly-capable client or server (i.e., the sender) has a DHCP message to send that might exceed the path MTU, and the other party has also indicated support for the protocol, the sender MAY fragment the message into multiple DHCP messages. The fragmentation method parallels IP fragmentation [RFC0791], with the exception that the sender MUST NOT fragment the message into overlapping fragments, i.e., each successive fragment MUST begin immediately after the end of the preceding fragment. The sender first prepares a whole DHCP message per [RFC2131] without including a DHCP fragment option, then calculates the sprite-mtu checksum as specified in Section 7 beginning with the first byte of the DHCP message header to the end of the message (including all options). The sender then fragments the options section beginning with the first byte of the options field into blocks that are small enough such that the length of the block plus the lengths of the DHCP header, the DHCP fragment option and encapsulating UDP/IP headers is less than the anticipated (or actual) path MTU to the destination. Each block must be an integral multiple of 8 bytes in length except for the final block which may include a non-integral multiple of 8bytes. During fragmentation, the sender encapsulates each option field fragment in an identical DHCP message header followed immediately by a DHCP fragment option followed by the fragment itself. Each fragment except the final fragment includes a non-final DHCP fragment option with length=6, while the final fragment includes a final DHCP fragment option with length=10. The sender writes the offset from the beginning of the options field (divided by 8) in the "Fragment Offset" field of the fragment option in each fragment. The sender Templin Expires June 5, 2008 [Page 5] Internet-Draft DHCP Fragmentation December 2007 next writes an identical randomly-chosen Identification value in the fragment option of each fragment, and records the sprite-mtu checksum in the A and B checksum fields in the fragment option of the final fragment. The sender finally wraps each fragment in a UDP/IP header and sends each fragment as an independent IP packet. Note that the sender MAY include a final DHCP fragment option with length=10 in a DHCP message to be sent as a single fragment, e.g., to inform the other party that the protocol is supported. In that case, the sender has the option to either calculate and include the sprite- mtu checksum as specified above or record the value 0 in the Checksum A and B fields to indicate that no checksum is used. The sender must determine a maximum IP packet length that is likely to be small enough to fit within the path MTU on the path to the receiver and use this length as an upper bound for the size of the DHCP fragments it creates. The sender sets the Don't Fragment (DF) bit in the IP header to 0 if IP fragmentation is to be allowed, and sets the DF bit to 1 otherwise. 6.3. Reassembly When a DHCP fragmentation/reassembly-capable client or server (i.e., the receiver) receives an initial DHCP message that includes a DHCP fragment option, it creates a reassembly buffer indexed by: o the IP source and destination addresses o the 'xid' in the DHCP message header o the Identification field in the DHCP fragment option The receiver performs reassembly in a manner that parallels IP reassembly [RFC0791]; it maintains the reassembly buffer until all fragments of the DHCP message arrive or until there is strong evidence that one or more of the fragments have been lost (note that other hints of lost fragments than simple timer expirations are permissible). The receiver retains the DHCP message header included in the first fragment and concatenates the option field fragment from each successive message until the whole DHCP message has been fully reassembled. During the concatenation of non-initial fragments, the receiver first discards the DHCP message header and DHCP fragment option, but it retains the Checksum value coded in the DHCP fragment option of the final fragment. When the DHCP message is fully reassembled, the receiver calculates the sprite-mtu checksum across the entire message and compares the results with the checksum that was included in the Templin Expires June 5, 2008 [Page 6] Internet-Draft DHCP Fragmentation December 2007 final fragment of the DHCP message. If the checksums match, the receiver accepts and processes the DHCP message; otherwise it discards the message. When a DHCP message that was sent as a single fragment with the value 0 recorded in the checksum is received, the receiver accepts and processes the message without performing the checksum calculation described above. Unlike IP reassembly, the receiver SHOULD NOT attempt to send ICMP feedback when reassembly fails. Also, the receiver MUST discard any overlapping fragments, e.g., each fragment must begin immediately after the preceding fragment and end immediately before the next fragment in succession. 7. sprite-mtu Checksum Calculation DHCP entities that implement the DHCP fragmentation/reassembly protocol use a checksum calculation known as the "sprite-mtu" checksum. The DHCP entity calculates the sprite-mtu checksum beginning with the DHCP header up to the end of the DHCP message by summing every 10th byte of the message beginning with the first byte of the header up to the end of the message according to the algorithm below, which is reproduced from [I-D.templin-inetmtu]: The sprite-mtu checksum is calculated over a sequence of unsigned data octets (call them D[0] through D[N-1]) by maintaining unsigned 1's-complement 16-bit accumulators A and B whose contents are initially zero, and performing the following loop where i ranges from 1 to N (where N is the length of the message): A := A + D[i] B := B + A i := i + 10 If, at the end of the loop, either or both of the A and B accumulators encode the value 0x0000, invert the value in the accumulator(s) to 0xffff. 8. IANA Considerations A new DHCP option code for the DHCP fragment option is requested. 9. Security Considerations Security considerations for DHCP fragmentation/reassembly are the Templin Expires June 5, 2008 [Page 7] Internet-Draft DHCP Fragmentation December 2007 same as for IP fragmentation, except that overlapping fragment attacks are not possible due to the requirement that DHCP fragments MUST NOT overlap with other fragments. 10. Acknowledgments This work was inspired by discussions on the IETF int-area mailing list in the 11/01/07 timeframe; the author acknowledges those who participated in the discussions. 11. References 11.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. 11.2. Informative References [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", October 1987. [I-D.templin-inetmtu] Templin, F., "Simple Protocol for Robust IP/*/IP Tunnel Endpoint MTU Determination (sprite-mtu)", draft-templin-inetmtu-06 (work in progress), November 2007. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, April 2006. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. Templin Expires June 5, 2008 [Page 8] Internet-Draft DHCP Fragmentation December 2007 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007. Author's Address Fred L. Templin (editor) Boeing Phantom Works P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires June 5, 2008 [Page 9] Internet-Draft DHCP Fragmentation December 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Templin Expires June 5, 2008 [Page 10]