< draft-wkumari-long-headers-01.txt   draft-wkumari-long-headers-02.txt >
6MAN W. Kumari 6MAN W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Best Current Practice J. Jaeggli Intended status: Best Current Practice J. Jaeggli
Expires: January 05, 2014 Zynga Expires: April 24, 2014 Zynga
R. Bonica R. Bonica
Juniper Networks Juniper Networks
July 04, 2013 October 21, 2013
Operational Issues Associated With Long IPv6 Extension Header Chains Operational Issues Associated With Long IPv6 Header Chains
draft-wkumari-long-headers-01 draft-wkumari-long-headers-02
Abstract Abstract
This document explains why IPv6 header chain length affects the cost This memo specifies requirements for IPv6 forwarders as they process
of ASIC-based packet forwarding. It also explains why some network packets with long header chains. It also provides guidance for
service providers discard packets with exceptionally long header application developers whose applications might rely on long headers
chains. Finally, it identifies a reasonable header chain length. chains.
While a network service provider can enforce any filtering policy
that supports its security model, a network service provider should As background, this memo explains how many ASIC-based IPv6 forwarders
not discard IPv6 packets based solely upon header chain length if the process packets and why processing of packets with long header chains
header chain is not longer than the value specified herein. might be problematic.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 05, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Termnology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Forwarder Information Requirements . . . . . . . . . . . . . 4
3. Need to see upper-layer to filter . . . . . . . . . . . . . . 5 3. Requirements For IPv6 Forwarders . . . . . . . . . . . . . . 5
4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6 4. Recommendations For Application Developers . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
In order to make a forwarding decision, the forwarding device may IPv6 [RFC2460] forwarders can acquire information from the following
require information from both the IPv6 header and an upper layer sources:
header. When a software-based forwarder encounters an IPv6 datagram
that includes a long header chain, it parses the header chain,
acquires the required information and makes its forwarding decision.
Typically, software-based forwarders are not required to process a
large number of packets per second. Therefore, they can perform the
above mentioned procedure within their processing budget.
By contrast, ASIC-based forwarders are engineered to forward many o The IPv6 header
more packets per second. In order to fulfill this requirement, the
forwarder copies a fixed number of bytes from the beginning of the o One or more IPv6 extension headers
packet to on-chip memory. The ASIC does this because it can access
on-chip memory much more quickly than it can access off-chip memory. o An upper-layer header
Once the beginning of the packet has been transferred to on-chip
memory, subsequent processing and forwarding decisions can be made Section 2 of this document explains how IPv6 forwarders use
very quickly. information from the IPv6 header and IPv6 extension headers to
provide traditional forwarding services. It also explains how IPv6
forwarders use information from the upper-layer header to provide
enhanced forwarding services.
When a software-based forwarder processes an IPv6 datagram, it parses
the header chain, regardless of its length, acquires the required
information and makes a forwarding decision. Typically, software-
based forwarders process a relatively small number of packets per
second. Therefore, they can perform the above mentioned procedure
within the constraints of their processing budget.
By contrast, ASIC-based forwarders process many more packets per
second. In order to fulfill this requirement, ASIC-based forwarders
copy a fixed number of bytes from the beginning of the packet to on-
chip memory. Forwarders do this because they can access on-chip
memory much more quickly than they can access off-chip memory. Once
the beginning of the packet has been transferred to on-chip memory,
subsequent processing can proceed very quickly.
The act of copying bytes from the beginning of a packet to on-chip The act of copying bytes from the beginning of a packet to on-chip
memory consumes both wall-time and processor cycles. Therefore, the memory consumes:
number of bytes copied to on-chip memory must be chosen wisely. If a
forwarder copies more bytes than it needs, it wastes resources,
significantly increasing cost and decreasing maximum performance. If
it copies too few bytes, it cannot parse the header chain and make a
correct forwarding decision.
As currently specified in [RFC2460], the IPv6 header chain can exceed o Processor cycles
64 kilobytes. However, packets with header chains exceeding 128
bytes are rarely observed on the Internet. Therefore, most ASIC-
based forwarders copy a relatively small number of bytes from the
beginning of the packet into on-chip memory.
This document explains why IPv6 header chain length affects the cost o On-chip memory
of ASIC-based packet forwarding. It also explains why some network
service providers discard packets with exceptionally long header
chains. Finally, it identifies a reasonable header chain length.
While a network service provider can enforce any filtering policy
that supports its security model, a network service provider SHOULD
NOT discard IPv6 packets based upon header chain length if the header
chain is not longer than the value specified herein.
1.1. Termnology o Wall-time
For the purposes of this document, the terms Extension Header, Header Therefore, the number of bytes copied to on-chip memory must be
Chain and Upper-layer Header are used as follows: chosen wisely. If a forwarder copies more bytes than it needs, it
wastes resources and adversely impacts performance. If it copies too
few bytes, it may not have sufficient information to make a correct
forwarding decision.
Extension Header : The IPv6 header chain is a variable-length data structure, whose size
can exceed 64 kilobytes. However, packets with header chains
exceeding 256 bytes are rarely observed on the Internet. Therefore,
most ASIC-based forwarders copy a relatively small number of bytes
from the beginning of a packet into on-chip memory. While this small
number varies from platform to platform, it is generally much closer
to 256 bytes than it is to 64 kilobytes.
Extension Headers are defined in Section 4 of [RFC2460]. IPv6 forwarders MUST behave in a predictable manner when they process
Currently, six extension header types are defined. [RFC2460] a packet whose header chain length exceeds the number of bytes copied
defines the hop-by-hop, routing, fragment and destination options to on-chip memory. Section 3 of this memo defines required
extension header types. [RFC4302] defines the authentication behaviors.
header (AH) type and [RFC4303] defines the encapsulating security
payload (ESP) header type.
Header Chain : Application developers should be aware of how ASIC-based forwarders
process packets with long extension header chains. Therefore,
Section 4 of this document provides guidance to application
developers.
The initial portion of an IPv6 datagram containing headers. The 1.1. Terminology
first member of the header chain is always an IPv6 header. For a For the purposes of this document, the terms "header chain" and
subsequent header to qualify as a member of the header chain, it "upper-layer" header are used as defined in
must be referenced by the "Next Header" field of the previous [I-D.ietf-6man-oversized-header-chain].
member of the header chain. The header chain can include IPv6
headers, IPv6 extension headers and an upper-layer header. If the
header chain includes two IPv6 headers, as is the case when IPv6
is tunneled over IPv6, the second IPv6 header terminates the
header chain. Any headers following the second IPv6 headers are
not members of the header chain. Likewise, if the header chain
includes an ESP header, the ESP header terminates the header
chain. Only the first 8 bytes of the ESP header contribute to the
header chain length. Any headers following ESP header are not
members of the header chain.
Upper-layer Header : This document also introduces the following terms:
In the general case, the upper-layer header is the first member of o forwarding service - a service that accepts a packet from one
the header chain that is neither an IPv6 header nor an IPv6 interface and forwards it through another
extension header. Typically, the upper-layer header represents a
transport protocol (e.g., TCP, UDP, SCTP). However, it can
represent a non-transport layer protocol. For example, when IPv4
is tunneled over IPv6, the upper-layer header is an IPv4 header.
If the header chain includes two IPv6 headers, as is the case when
IPv6 is tunneled over IPv6, the second IPv6 header is considered
to be the upper-layer header and terminates the header chain.
For the purposes of this document, when the upper-layer protocol o traditional forwarding service - a forwarding service in which all
is ICMPv6, the first 32 bits of the ICMPv6 message (i.e., the parameters to the forwarding algorithm are drawn from the IPv6
type, code fields and checksum fields) are considered to be the header, the hop-by-hop extension header, and the routing extension
ICMPv6 header. header
The upper-layer payload is not part of the upper-layer header and o enhanced forwarding service - a forwarding service in which
therefore, is not part of the IPv6 header chain. For example, if parameters to the forwarding algorithm can be drawn from any
the upper-layer protocol is TCP, the TCP payload is not part of portion of the IPv6 header chain
the TCP header or the IPv6 header chain.
2. Background 2. Forwarder Information Requirements
When IPv6 was first conceived, forwarding was largely performed in When an IPv6 forwarder provides traditional forwarding services, it
software running on general-purpose processors. Due to the required extracts all information required by the forwarding algorithm from
performance, parsing a long header chain was not an issue. the IPv6 header, the hop-by-hop extension header (if present), and
the routing extension header (if present). In the nominal case, the
IPv6 header contains all information required by the forwarding
algorithm. However, the hop-by-hop and routing extension headers can
also impact forwarding behavior.
In the years between the conception of IPv6 and publication of this Section 4.2 of [RFC2460] explains how the hop-by-hop extension header
documentation, the Internet evolved as follows: impacts forwarding behavior. When the forwarder processes a hop-by-
hop extension header, it examines each option contained by the
header. If forwarder encounters an unrecognized hop-by-hop option,
and the high-order bits of the option type are "00", the forwarder
skips over the option and continues to process subsequent options.
However, if an forwarder encounters an unrecognized option, and the
high-order bits of the option type are "01", "10" or "11", the
forwarder discards the packet.
o Throughput requirements increased dramatically, requiring the Section 4.4 of [RFC2460] explains how the routing extension header
deployment of ASIC-based forwarders in both core and edge networks impacts forwarding behavior. When the forwarder processes a packet
whose destination address is local to itself, it scans the header
chain, searching for a routing extension header. If the packet
contains a routing extension header and the forwarder recognizes the
routing header type, it processes the header. If the forwarder does
not recognize the routing header type, the required behavior depends
upon the Segments Left field. If the Segments Left field is equal to
zero, the forwarder ignores the routing extension header. Otherwise,
the forwarder discards the packet. [RFC6275] and [RFC6554] describe
currently defined routing extension header types.
o New network types emerged, including very large enterprises, Some IPv6 forwarders provide enhanced forwarding services, such as
social networks, data centers and "clouds". Like core networks, firewall filtering, rate limiting and load balancing. In order to
these network require very high throughput. Like edge networks, provide these services, the forwarder requires access to an upper
these networks require "high-touch" edge services, which require layer header. The following are examples of enhanced services that
the forwarder to access the entire header chain require the forwarder to examine the upper layer header:
o Requirements for "high-touch" service, which require the forwarder o Discard all packets directed to TCP port 25
to access the entire header chain, increased in networks of all
kinds
During those years, IPv4 [RFC0791] was the most commonly deployed o Rate limit packets destined for a particular address whose payload
protocol on the Internet. ASIC-based forwarders could meet the is TCP and have the TCP SYN bit set
requirements of the evolving Internet because ASICs could predict the
number of bytes that needed to be copied into on-chip memory in order
to make a forwarding decision.
Today, as IPv6 is being deployed, ASIC-forwarders cannot safely o Load balance packets across parallel links so that all packet
predict the size of the header chain. This leads to complexity and belonging to particular TCP session traverse the same link
vulnerability in handling extension headers. For this reason, many
network operators filter all IPv6 packets containing extension
headers.
3. Need to see upper-layer to filter 3. Requirements For IPv6 Forwarders
There is a school of thought that ISPs, content-providers and The following requirements apply to all IPv6 forwarders:
enterprises should not be performing any sort of filtering in the
network and that the filtering is more appropriately performed at the
end hosts. Unfortunately this solution, while clean and elegant,
simply doesn't work in the real world. Filtering unknown traffic at
the edge (and / or in the core) of the network is needed for a number
of reasons, some of which are discussed below.
o ISPs (and cloud providers) are routinely called upon to filter DoS o REQ-1: An IPv6 forwarder SHOULD NOT discard a valid packet because
traffic aimed at their customers (for example to block multi-Gbps of its header chain length. However, the forwarder MAY support a
DNS reflection attacks aimed at web servers, etc). At Large Edge configuration option that causes it to discard packets whose
Sites this is often a large part of the "service" provided by the header chain length exceeds a specified value.
network team.
o IPv6 stacks are still relatively immature and operators still have o REQ-2: When processing packet that contains a hop-by-hop extension
concerns that stack or kernel vulnerabilities may still surface. header, an IPv6 forwarder MUST process the entire hop-by-hop
If this turns out to be the case, a means to protect the end nodes extension header, regardless of its length. The forwarder MUST
is needed. process each option as specified in Section 4.2 of [RFC2460].
o In many enterprises the end systems are not sufficiently hardened o REQ-3: When processing a packet whose destination address is local
to be exposed on the public Internet. Even if there were no to itself, an IPv6 forwarder MUST scan the entire header chain,
remotely exploitable operating system vulnerabilities there is regardless of its length, in order to determine whether the packet
significant risk that an employee may install vulnerable software, contains a routing extension header. If the packet contains a
accidentally share confidential files or folders publicly or start routing extension header, the forwarder MUST process routing
offering (unauthorized) services. extension header as specified in Section 4.4 of [RFC2460].
o Content providers (and similar) need to be able to filter traffic The length of the IPv6 header plus the length of the hop-by-hop
and only allow "expected" traffic into their networks. This is extension header can exceed the number of bytes that an ASIC-based
needed both for DoS protection, but also to ensure that forwarder copies into on-chip memory. Therefore, in order to support
development systems, databases, test systems, etc are not REQ-2, ASIC-based forwarders typically support a special processing
accidentally exposed. mechanism for packets containing hop-by-hop extensions.
o While it would be nice if all employees, system and database Also, the combined length of all headers preceding the routing
administrators could be trusted to always ensure that only the extension header may exceed the number of bytes that an ASIC-based
"correct" services were listening on ports, that all software was forwarder copies into on-chip memory. Therefore, in order to support
always fully patches (and contained no vulnerabilities), that REQ-3, ASIC-based forwarders typically support a special processing
confidential data was only shared with internal addressed and that mechanism for packets whose IPv6 destination address is local to the
all credentials were strong and regularly changed, this simply forwarder. This forwarding mechanism is capable of processing the
does not reflect reality. routing extension header, even if it begins beyond of the portion of
the packet that was copied to on-chip memory.
All of these lead to the requirement that operators be able to filter The following requirements apply to IPv6 forwarders that provide
at Layer 3 and Layer 4, at line rate, in the network. Obviously, to enhanced forwarding services:
be able to filter at layers 3 and 4, the router needs to be able to
see the layer 3 and 4 information. Unfortunately, if the size of
extension header chain varies between 0 and 64 kilobytes, extension
headers cannot be processed efficiently in ASICs.
Because many implementation do not process IPv6 extension headers o REQ-4: If a forwarder's ability to deliver enhanced services is
well, many operators filter all IPv6 packets that include them. limited in any way by extension header length, that limitation
MUST be reflected in user documentation. For example, assume that
a forwarder provides a load balancing service, and that it
acquires information required by the service from the IPv6 header
and the upper-layer header. If the service behaves in one manner
when all required information is contained by the first N bytes of
the header chain and in another manner when all required
information is not contained by the first N bytes of the header
chain, user documentation MUST reflect both behaviors as well as
the value of N.
4. Recommendations o REQ-5: If a forwarder's ability to deliver an enhanced service is
limited by extension header length, the policy specification
language used to configure the enhanced service MUST be
sufficiently robust to address the limitation. For example,
assume that the forwarder provides a firewall service. The
firewall service is capable of filtering packets directed to a
particular TCP port, but only if the TCP header is contained by
the first N bytes of the header chain. In this case, it MUST be
possible to configure one policy for packets directed to the
specified port, another policy for packet not directed to the
specified port, and a third policy for packets whose TCP
destination port is unknown.
An ISP SHOULD NOT discard IPv6 packets based solely upon header chain 4. Recommendations For Application Developers
length if the header chain contains 128 bytes or fewer. However, it
is common practice ISPs to filter IPv6 packets with long extension
header chains. This document offers no recommendation regarding the
maximum extension header chain length that an ISP should forward.
See Section 1.1 for a formal definition of the header chain. Applications developers should be aware that many ISPs and
enterprises filter or severely rate limit packets containing long
header chains. They do this because of limitations imposed by the
ASIC-based forwarders deployed at their edges. ISPs and enterprises
accept these limitations as part of an engineering trade off, in
which high-speed forwarding is achieved at the cost of limiting
enhanced services for packets with long extension headers.
For example, assume that an enterprise deploys the following firewall
filtering policy at its edge:
o Permit all packets whose destination is TCP port 80
o Discard all packets whose destination is not TCP port 80
o Discard all packets whose header chain is so long that TCP port
information is not accessible to the filtering function
In this case, the enterprise discards all packets whose destination
cannot be determined by the filtering function.
Aside from the issue of header chain length, operators may filter
packets containing extension headers that may either compromise the
network's security posture or require inordinate processing
resources.
This memo does not specify a maximum header chain length. However,
this memo does note that at the time of its publication, the number
of bytes that ASIC-based forwarders copy from the beginning of a
packet to on-chip memory varies from platform to platform. Typical
platforms copy between 128 and 384 bytes. Therefore, application
developers should avoid sending packets who header chain length is in
that range, unless they have some assurance that their packets will
not be discarded.
5. IANA Considerations 5. IANA Considerations
This document makes no requests of the IANA This document makes no requests of the IANA
6. Security Considerations 6. Security Considerations
There are potential implications to the filtering or acceptances of TBD
packets which cannot be processed according to the configuration of
the network operator. It is clear from the vantage point of the
authors that implementors and operators should be aware of
implications of relying on extension header chains or apply policies
that must necessarily discard packets which contain them.
7. Acknowledgements 7. Acknowledgements
The authors wish to thank Paul Hoffman, KK and Fernando Gont. The
authors also express their gratitude to an anonymous donor, without
whom this document would not have been written.
The authors wish to thank Paul Hoffman, KK and Fernando Gont. 8. References
8. Normative References 8.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [I-D.ietf-6man-oversized-header-chain]
1981. Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", draft-ietf-6man-oversized-
header-chain-08 (work in progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
2005. "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 8.2. Informative References
4303, December 2005.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, March
2012.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ] [RFC Editor: Please remove this section before publication ]
Template to -00 Template to -00
o Initial submission. o Initial submission.
-00 to -01 -00 to -01
 End of changes. 49 change blocks. 
190 lines changed or deleted 240 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/