Network Working Group F. Templin, Ed. Internet-Draft Boeing Phantom Works Intended status: Informational July 30, 2008 Expires: January 31, 2009 DHCP Segmentation/Reassembly using SEAL draft-templin-dhcpmtu-01.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 January 31, 2009. 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 abilitiy to adjust their message sizes to avoid IP fragmentation, however no such capability is built into the UDP transport. UDP applications such as DHCP must therefore have a means to perform their own segmentation prior to submitting their data to UDP/IP in order to avoid IP fragmentation. This document specifies a segmentation/reassembly capability for DHCP using SEAL. Templin Expires January 31, 2009 [Page 1] Internet-Draft SEAL for DHCP July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Concept of Operation . . . . . . . . . . . . . . . . . . . . . 3 4. Minimum Reassembly Size Requirement . . . . . . . . . . . . . . 3 5. SEAL Option Format . . . . . . . . . . . . . . . . . . . . . . 3 6. DHCP Segmentation and Reassembly using SEAL . . . . . . . . . . 4 6.1. Client/Server Negotiotiation . . . . . . . . . . . . . . . 4 6.2. Segmentation . . . . . . . . . . . . . . . . . . . . . . . 5 6.3. Reassembly . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Templin Expires January 31, 2009 [Page 2] Internet-Draft SEAL for DHCP July 2008 1. Introduction IP fragmentation is a core mechanism of the Internet Protocol [RFC0791], but its unrestricted use can lead to a number of well- known operational issues [FRAG][RFC4963]. These issues are further exacerbated when a suitable IP source address is unavailable, such as during DHCP address configuration bootstrapping. Some transports (e.g., TCP) have the abilitiy 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 segmentation prior to submitting their data to UDP/IP in order to avoid IP fragmentation. This document specifies a segmentation/reassembly capability for DHCP using an adaptation of the mechanisms specified in SEAL [I-D.templin-seal]. 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 SEAL 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, a DHCP segmentation/reassembly capabilitiy based on SEAL [I-D.templin-seal] 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 segmented DHCP messages of at least 2048 bytes and SHOULD provide a configuration knob to enable still larger reassembly sizes. (DHCP clients can optionally use the Maximum DHCP Message Size option to inform the server as to larger sizes that the client is willing to accept.) 5. SEAL Option Format A new DHCP option [RFC2132] called the "SEAL" option is defined with the following format: Templin Expires January 31, 2009 [Page 3] Internet-Draft SEAL for DHCP July 2008 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 |M| Segment | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (0 thru 249 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Figure 1: The DHCP SEAL Option Code the DHCP option code (TBD; see Section 7). Length the DHCP option length. Set to 1 plus the length of the Data field. M the More Segments bit. Set to 1 in non-final segments and 0 in the final segment. Segment a SEAL segment number from 0 to 127; monotonically increasing for each SEAL segment. Reserved a 1 byte reserved field. Identification a 32bit identification field, randomly chosen. Data a 0 - 249 byte segment of the segmented DHCP message. 6. DHCP Segmentation and Reassembly using SEAL 6.1. Client/Server Negotiotiation DHCP clients that wish to enable DHCP segmentation/reassembly include a SEAL option with Length=6, M=0 and Segment=0 as the first option in their DHCPDISCOVER messages. The client SHOULD send its DHCP messages as single segments until the server has indicated that it also supports the protocol. Thereafter, the client MAY segment long DHCP messages by including the SEAL option in multiple messages with the same 'xid' value in the DHCP header and Identification value in Templin Expires January 31, 2009 [Page 4] Internet-Draft SEAL for DHCP July 2008 the SEAL option as specified in Section 6.2. DHCP servers that support DHCP segmentation/reassembly MUST include a SEAL option with Length=6, M=0 and Segment=0 option as the first option in their response to a client's DHCPDISCOVER message that includes a SEAL option. Thereafter, the DHCP server MAY send segmented DHCP messages to the client by including a SEAL option in multiple messages with the same 'xid' value in the DHCP header and Identification value in the SEAL option as specified in Section 6.2. 6.2. Segmentation When a SEAL-capable client or server (i.e., the sender) has a DHCP message to send that might exceed the path MTU and cause IPv4 fragmentation, it MAY segment the message across multiple DHCP messages. The sender must estimate 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 to determine the size of the DHCP segments it creates. The segmentation is performed in a manner that exactly parallels the SEAL segmentation procedures specified in ( [I-D.templin-seal], Section 4.2.3). The sender first prepares a whole DHCP message per [RFC2131] without including a SEAL option, then segments the options section beginning with the first byte of the options. The sender segments the options into segments that are small enough such that the length of the segment plus the lengths of the SEAL option header, the DHCP header and the encapsulating UDP/IP headers is less than the anticipated path MTU to the destination. Each segment MUST be no larger than 249 bytes, and each segment except the final segment MUST be exactly the same length; the final segment MUST be no larger than each non-final segment. During segmentation, the sender first selects a randomly-chosen DHCP 'xid' and a randomly-chosen SEAL option Identification value that will be used for each segment. It then encapsulates each segment in a SEAL option then encapsulates the SEAL option in an identical DHCP message header. Each segment except the final segment sets M=1 in the SEAL option, while the final segment sets M=0. Each consecutive segment sets a monotonically-increasing Segment value in the SEAL option beginning with 0 up to 127. The sender finally wraps each such individual DHCP message in a UDP/IP header then sends each segment as an independent IP packet. 6.3. Reassembly When a SEAL-capable client or server (i.e., the reassembler) receives an initial DHCP message that includes a SEAL option, it creates a Templin Expires January 31, 2009 [Page 5] Internet-Draft SEAL for DHCP July 2008 reassembly buffer indexed by the 'xid' in the DHCP message header and the Identification field in the SEAL option. The reassembler performs reassembly in a manner that exactly parallels the SEAL reasssembly procedures specified in ([I-D.templin-seal], Section 4.3.4); it maintains the reassembly buffer until all segments of the DHCP message arrive or until there is strong evidence that one or more of the segments has been lost. The reassembler retains the DHCP message header included in the first segment and concatenates the option field segment from each successive segment until the whole DHCP message has been fully reassembled. During the concatenation, the reassembler gathers all segments that have the same DHCP 'xid' and SEAL option Identification values. It first discards the DHCP message header and SEAL option header and concatenates each segment in-order beginning with segment 0 to segment n (n <= 127). If any segment except the final segment has a different length than the other non-final segments, the receiver records a reassembly error and discards the reassembly. Note that DHCP relays may insert relay agent options after the SEAL option, however the reassembler simply ignores these during the reassembly. Note also that for the sake of simplicity each DHCP message is restricted to containing only a single SEAL option even if the path MTU would support inserting multiple such options (TODO - this restriction may be relaxed in future document versions). 7. IANA Considerations A new DHCP option code for the DHCP fragment option is requested. 8. Security Considerations Security considerations for DHCP segmentation/reassembly are the same as for IP fragmentation, except that overlapping fragment attacks are not possible due to the requirement that DHCP segmentss MUST NOT overlap. 9. Acknowledgments This work was inspired by discussions on the IETF int-area mailing list in the 11/01/07 timeframe, and the author acknowledges those who participated in the discussions. Further discussion took place on the int-area and dhc mailing lists in the 07/28/08 timeframe. Templin Expires January 31, 2009 [Page 6] Internet-Draft SEAL for DHCP July 2008 10. References 10.1. Normative References [I-D.templin-seal] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", draft-templin-seal-22 (work in progress), June 2008. [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. 10.2. Informative References [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful", October 1987. [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: fred.l.templin@boeing.com Templin Expires January 31, 2009 [Page 7] Internet-Draft SEAL for DHCP July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Templin Expires January 31, 2009 [Page 8]