Internet DRAFT - draft-templin-dhcpmtu
draft-templin-dhcpmtu
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]
