Internet DRAFT - draft-herbert-int-area-limits
draft-herbert-int-area-limits
INTERNET-DRAFT T. Herbert
Intended Status: Informational Facebook
Expires: February 2017
August 10, 2016
Guidance to limit size of protocol headers in packets
draft-herbert-int-area-limits-00
Abstract
This specification provides guidance for limiting the size of
protocol headers in packets. Intermediate nodes that perform deep
packet inspection (DPI), particularly hardware implementations, are
often limited as to how many bytes of protocol headers they can
process. We recommend that 256 bytes be established as the minimum
number of bytes of headers that intermediate nodes are expected to be
able to process. This limit is explicitly not intended to be a
standard requirement, however it can be used as a guideline in
hardware design, protocol design, as well as a useful constraint in
implementation or configuration.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
T. Herbert Expires February 11, 2017 [Page 1]
INTERNET DRAFT draft-int-area-header-limits-00 August 10, 2016
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Derivation of the limit . . . . . . . . . . . . . . . . . . . . 3
2.1 Limit without extensibility . . . . . . . . . . . . . . . . 3
2.2 Limit with extensibility . . . . . . . . . . . . . . . . . . 4
3 Application of the limit . . . . . . . . . . . . . . . . . . . 5
3.1 Limits on extensibility in protocols . . . . . . . . . . . . 5
3.2 Limit on IPv6 Hop-by-hop options . . . . . . . . . . . . . . 5
3.3 Hardware implementation . . . . . . . . . . . . . . . . . . 5
3.4 Limits on sender . . . . . . . . . . . . . . . . . . . . . . 5
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1 Normative References . . . . . . . . . . . . . . . . . . . 6
6.2 Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
T. Herbert Expires February 11, 2017 [Page 2]
INTERNET DRAFT draft-int-area-header-limits-00 August 10, 2016
1 Introduction
In this specification we recommend that 256 bytes be established as
the minimum size of protocol headers in a packet that nodes are
expected to be capable of processing. This limit can be taken as a
guideline for hardware design, protocol design, as well as a
potential constraint in implementation or configuration. This packet
header size limit is a recommendation only, not a requirement.
Intermediate nodes often perform deep packet inspection (DPI) in
order to implement various functions in the network. DPI occurs when
an intermediate node parses a packet beyond network layer headers.
Hardware devices often have constraints on how much of the headers in
a packet can be parsed for DPI. A typical design is that some portion
of the beginning of a received packet is loaded into a memory buffer
for header parsing. The size of this buffer is often fixed.
To derive the size limit for protocol headers we need to take into
account headers in a packet that might be subject to DPI which
include the link layer header through the transport layer header.
Additionally, we need to consider the headers associated with
encapsulation as well as protocol extensions such as header options,
extension headers, and network service headers (NSH). Note that this
limit only applies to protocol headers that an intermediate device
can parse, if the protocol layers are encrypted (as in transports
over UDP [I-D.transports-over-udp]) they would not be subject to the
limit.
This specification only provides a recommendation for a limit on the
cumulative size of packet headers; it does not explicitly provide
guidance on limiting the number of protocol headers or nested
protocol encapsulations. Coarse limits for those can be inferred from
a limit on the size of protocol headers.
2 Derivation of the limit
2.1 Limit without extensibility
To derive a limit for the size protocol headers we first consider a
representative "simple" packet in network virtualization. Such a
packet has two IP headers, a UDP header and an encapsulation header
(using Generic UDP Encapsulation for example [I-D.ietf-nvo3-gue]). We
assume that there are no extensions or protocol options present and
that intermediate nodes may want to parse an encapsulated TCP header
(excluding TCP options). IPv6 over IPv6 encapsulation creates the
largest packet in this scenario.
T. Herbert Expires February 11, 2017 [Page 3]
INTERNET DRAFT draft-int-area-header-limits-00 August 10, 2016
The size of protocol headers for such a packet are:
14 bytes for Ethernet header
40 bytes for outer IPv6 header
8 bytes for UDP encapsulation header
8 bytes for encapsulation header
40 bytes for inner IPv6 header
20 bytes for TCP header
So the size of the headers for this representative packet is 130
bytes. The Ethernet header can be rounded up to sixteen for alignment
and the last four bytes of the TCP header (containing checksum and
urgent pointer) should not be particularly interesting to
intermediate nodes. Hence 128 bytes seems like a reasonable minimum
limit for simple packets that contain no extensions.
2.2 Limit with extensibility
To account for protocol extensions such as IP options, IPv6 extension
headers, extensions within encapsulation protocols, and network
service headers we propose that extensibility is allotted 128 bytes
which brings the total limit for protocol headers up to 256 bytes.
The motivations for a 256 byte limit are:
* It is a tradeoff between a minimal limit too small to permit any
extensibility in protocol headers and a limit too large that it
can't be practically implemented in hardware.
* It is a power of two. This is compatible with sizes of cache
lines and memory buffers that are typically powers of two.
* The 256 byte limit implies a limit to the amount of protocol
overhead. For instance, with the standard 1500 byte MTU protocol
overhead is 17% with the 256 byte limit. For 512 bytes, the next
power of two step, the maximum overhead would be 34%.
* The 256 byte limit implies a limit on the number of headers in
header chains and the number of nested encapsulations. For
instance, the minimum size of most IPv6 extension headers is
eight bytes. With a 1500 byte MTU and no header size limit a
packet can contain 182 extension headers; with a 256 byte header
limit a packet contains up to twenty-five extension headers.
T. Herbert Expires February 11, 2017 [Page 4]
INTERNET DRAFT draft-int-area-header-limits-00 August 10, 2016
3 Application of the limit
3.1 Limits on extensibility in protocols
As pointed out the header limit applies to all protocol headers in a
packet. When a protocol is being designed there is no means to
determine how many bytes will be used in other protocol headers (for
instance the designer of an encapsulation protocol can not predict
the number of bytes used for extension headers in packets). Thus the
recommendation for a protocol header or extension header with
variable length is that header size should be limited to 128 bytes.
The 128 byte limit is a maximum value, however because of the
possibility of other extensions being present in a packet, protocol
designers should be judicious in the use of extensions and employ an
efficient format of extension data to minimize overhead. An
implementation may allow configuration of options and headers in
packets to adhere to the cumulative 256 byte limit at runtime.
3.2 Limit on IPv6 Hop-by-hop options
Hop-by-hop options (HBH)[RFC2460] are required to be processed by
intermediate nodes (2460bis relaxes this requirement [I-D.ietf-6man-
rfc2460bis]). Processing HBH options is therefore not DPI. In order
to facilitate processing of HBH options in intermediate nodes we
specifically recommend that the HBH option should be limited to 128
bytes in size.
Note that the HBH options must be the first extension header in
packet so that if the HBH option is less than 128 bytes in size it
should be ensured that the HBH options lie within a 256 byte protocol
header limit and can be processed.
3.3 Hardware implementation
Intermediate nodes that perform DPI or process IPv6 HBH options
should be able to parse packets with a minimum of 256 bytes of
headers. If a packet is received with an accumulative size of packet
headers that exceeds its parsing limit, the packet may take a slow
path or be processed with degraded functionality.
3.4 Limits on sender
Packet senders should try to minimize the amount of header overhead
in a packet to respect the 256 byte limit. This can enforced in the
implementation or as at runtime through configuration.
T. Herbert Expires February 11, 2017 [Page 5]
INTERNET DRAFT draft-int-area-header-limits-00 August 10, 2016
4 Security Considerations
The recommendation of a limit for size of protocol headers should not
impact security.
5 IANA Considerations
There are no IANA considerations in this document.
6 References
6.1 Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
6.2 Informative References
[I-D.ietf-6man-rfc2460bis] Deering, S. and R. Hinden, "Internet
Protocol, Version 6 (IPv6) Specification", draft-ietf-6man-
rfc2460bis-05.
[I-D.ietf-nvo3-gue] Herbert, T., Yong, L., and Zia, O., "Generic UNP
Encapsulation", draft-ietf-nvo3-gue-01
[I-D.transports-over-udp] Herbert, T., "Transport layer protocols
over UDP", draft-herbert-transports-over-udp-00
[I-D.ietf-nvo3-gue] Herbert, T., Yong, L., and Zia, O., "Generic UNP
Encapsulation", draft-ietf-nvo3-gue-01
Author's Address
Tom Herbert
Facebook
Menlo Park, CA
USA
Email: tom@herbertland.com
T. Herbert Expires February 11, 2017 [Page 6]
INTERNET DRAFT draft-int-area-header-limits-00 August 10, 2016
T. Herbert Expires February 11, 2017 [Page 7]
