< draft-wkumari-long-headers-00.txt   draft-wkumari-long-headers-01.txt >
template W. Kumari 6MAN W. Kumari
Internet-Draft Google Internet-Draft Google
Intended status: Informational J. Jaeggli Intended status: Best Current Practice J. Jaeggli
Expires: August 8, 2013 Zynga Expires: January 05, 2014 Zynga
R. Bonica R. Bonica
Juniper Networks Juniper Networks
February 4, 2013 July 04, 2013
Operational Issues Associated With Long IPv6 Extension Header Chains Operational Issues Associated With Long IPv6 Extension Header Chains
draft-wkumari-long-headers-00 draft-wkumari-long-headers-01
Abstract Abstract
This document outlines a set of issues with the use of long IPv6 This document explains why IPv6 header chain length affects the cost
extension header chains. It considers their use in the context of of ASIC-based packet forwarding. It also explains why some network
today's IPv6 Internet and potential interaction with forwarding service providers discard packets with exceptionally long header
devices that require upper-layer headers. 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 solely upon header chain length if the
header chain is not longer than the value specified herein.
Status of this Memo Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 8, 2013. This Internet-Draft will expire on January 05, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Termnology . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Understanding the scale. . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Different types of networks. . . . . . . . . . . . . . . . 5 3. Need to see upper-layer to filter . . . . . . . . . . . . . . 5
2.3. Large Edge Site Operators. . . . . . . . . . . . . . . . . 5 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
3. Need to see upper-layer to filter . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Recomendations . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Many forwarding devices make forwarding decisions based upon In order to make a forwarding decision, the forwarding device may
information that is drawn from both the IPv6 and transport require information from both the IPv6 header and an upper layer
headers.When a software-based forwarding device encounters an IPv6 header. When a software-based forwarder encounters an IPv6 datagram
datagram that includes a long extension header chain, it parses the that includes a long header chain, it parses the header chain,
header chain, acquires required information and makes its forwarding acquires the required information and makes its forwarding decision.
decision. Typically, software-based forwarders are not required to Typically, software-based forwarders are not required to process a
process a large number of packets per second. Therefore, they can large number of packets per second. Therefore, they can perform the
perform the above mentioned procedure within a specified time and above mentioned procedure within their processing budget.
processing budget.
By contrast, ASIC-based forwarders are typically required to forward By contrast, ASIC-based forwarders are engineered to forward many
many more packets per second. In order to fulfill this requirement, more packets per second. In order to fulfill this requirement, the
the forwarder copies an arbitrarily chosen number of bytes for the forwarder copies a fixed number of bytes from the beginning of the
beginning of the packet to on-chip memory. The ASIC does this packet to on-chip memory. The ASIC does this because it can access
because it can access on-chip memory much more quickly than it can on-chip memory much more quickly than it can access off-chip memory.
access off-chip memory. Having copied the beginning of the packet to Once the beginning of the packet has been transferred to on-chip
on-chip memory, the forwarder can make its forwarding decision very memory, subsequent processing and forwarding decisions can be made
quickly, because subsequent packet processing can all be achieved on- very quickly.
chip.
The act of copying the beginning of a packet to on-chip memory The act of copying bytes from the beginning of a packet to on-chip
consumes both wall-time and processor cycles. The number of bytes memory consumes both wall-time and processor cycles. Therefore, the
copied is directly proportional to the amount of wall-time and number of bytes copied to on-chip memory must be chosen wisely. If a
processing cycles consumed. Therefore, the number of bytes copied to forwarder copies more bytes than it needs, it wastes resources,
on-chip memory must be chosen wisely. If a forwarder copies more significantly increasing cost and decreasing maximum performance. If
bytes than it needs, it wastes resources. If it copies too few it copies too few bytes, it cannot parse the header chain and make a
bytes, it cannot parse the extension header chain and make the
correct forwarding decision. correct forwarding decision.
This memo describes problems that are caused by IPv6 packets As currently specified in [RFC2460], the IPv6 header chain can exceed
containing large extension header chains. Specifically, it describes 64 kilobytes. However, packets with header chains exceeding 128
how ASIC-based forwarding devices may fail when both of the following bytes are rarely observed on the Internet. Therefore, most ASIC-
conditions are true: based forwarders copy a relatively small number of bytes from the
beginning of the packet into on-chip memory.
o The forwarder is required to make a forwarding decision based upon This document explains why IPv6 header chain length affects the cost
information that is drawn from both the IPv6 and transport layer of ASIC-based packet forwarding. It also explains why some network
headers service providers discard packets with exceptionally long header
o The forwarder encounters a packet in which the length of the IPv6 chains. Finally, it identifies a reasonable header chain length.
header plus the length of the extension header chain is greater While a network service provider can enforce any filtering policy
than the number of bytes that the ASIC copies to on-chip memory that supports its security model, a network service provider SHOULD
This memo also presents recommendations, and is intended to spark NOT discard IPv6 packets based upon header chain length if the header
discussions. chain is not longer than the value specified herein.
2. Background 1.1. Termnology
Router architectures have evolved over time, and routers have become For the purposes of this document, the terms Extension Header, Header
more specialized devices. Initially (and in some cases still), Chain and Upper-layer Header are used as follows:
routers were "software switched" - a packet would arrive at the
router and software running on a general purpose microprocessor would
look at the packet, make forwarding decisions, perform additional
packet processing (decrement TTL, recalculate checksum, perhaps
process source route options) and then send the packet towards the
destination. This approach began to run into scaling / performance
issues for "core" type routers. More and more of the forwarding
logic has moved to Application Specific Integrated Circuits (ASICs)
and Network Processors. Networks that need to shift a large amount
of traffic (for example, large ISPs, enterprises, and content
providers generally purchase these "core" style devices.
As the amount of traffic (and correspondingly interface speeds Extension Header :
increased), the buses between linecards and to the forwarding ASICs
have become a bottleneck. In order to scale to the required speeds,
router manufacturers began segmenting the incoming packet into a
number of "cells" and only sending the first cell to the forwarding
logic.. Once this decision is made, the forwarding ASIC notifies the
output interface, which then sucks all of the other cells across the
switch fabric, assembles them into the correct order and ships the
packet. While this is more complex than simply shipping the entire
packet to the forwarding logic, it dramatically decreases the amount
of very fast memory associated with the forwarding logic, it works in
general quite well with IPv4 packets and it was needed to allow
routers to scale to the current demands.
In IPv4 this first cell contains all of the information required to Extension Headers are defined in Section 4 of [RFC2460].
make forwarding (and filtering!) decisions, but this is not Currently, six extension header types are defined. [RFC2460]
necessarily the case in IPv6. defines the hop-by-hop, routing, fragment and destination options
extension header types. [RFC4302] defines the authentication
header (AH) type and [RFC4303] defines the encapsulating security
payload (ESP) header type.
Readers of this document are expected to be familiar with [RFC2460] Header Chain :
Section 4.
2.1. Understanding the scale. The initial portion of an IPv6 datagram containing headers. The
first member of the header chain is always an IPv6 header. For a
subsequent header to qualify as a member of the header chain, it
must be referenced by the "Next Header" field of the previous
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.
In order to understand why designs like this have evolved, it is Upper-layer Header :
useful to be able to get a rough idea of the sorts of scale we are
discussing.
A single 100Gbps Ethernet interface, filled with 64byte packets In the general case, the upper-layer header is the first member of
receives approximately 148.8 million packets per second, and so has the header chain that is neither an IPv6 header nor an IPv6
approximerik ately 6.7 nanoseconds to forward the packet in order to extension header. Typically, the upper-layer header represents a
keep up with the input rate (for comparison, this is 26 clock cycles transport protocol (e.g., TCP, UDP, SCTP). However, it can
on a 3.8Ghz CPU core). 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.
A (current) large router contains multiple distributed packet For the purposes of this document, when the upper-layer protocol
processing engines, and a single chassis might have an aggregate is ICMPv6, the first 32 bits of the ICMPv6 message (i.e., the
switching capacity of around 4.5Tbps. type, code fields and checksum fields) are considered to be the
ICMPv6 header.
2.2. Different types of networks. The upper-layer payload is not part of the upper-layer header and
therefore, is not part of the IPv6 header chain. For example, if
the upper-layer protocol is TCP, the TCP payload is not part of
the TCP header or the IPv6 header chain.
The classic view of the Internet is that there are a large number of 2. Background
"edge" networks that connect to a "core" network, comprised of large
ISPs. The edge networks create (and consume) the data, the core
simply transits the traffic between the edge networks. Because the
core aggregates all of traffic from the edge networks it is made up
of huge, fast routers. Because the edge networks shift much less
traffic they use much smaller routers. While this makes a pretty
(and easily understood) picture, the reality is much more complex --
and messier.
There exist a number of "edge" networks whose scale of traffic make When IPv6 was first conceived, forwarding was largely performed in
them look much more like, and employ technology associated, with software running on general-purpose processors. Due to the required
"core" networks - these are entities like video distribution performance, parsing a long header chain was not an issue.
networks, "cloud providers", social networks, large enterprises and
similar. For the purpose of this document we will call these Large
Edge Sites. This is relevant to this document because these large
edge sites often have network requirements that differ from
traditional ISPs, and often wish to perform more filtering of
traffic.
2.3. Large Edge Site Operators. In the years between the conception of IPv6 and publication of this
documentation, the Internet evolved as follows:
Some properties common to large edge site operators. o Throughput requirements increased dramatically, requiring the
deployment of ASIC-based forwarders in both core and edge networks
o Run their own "backbone". o New network types emerged, including very large enterprises,
o Push or Sink significant amounts of traffic from peers or social networks, data centers and "clouds". Like core networks,
providers. these network require very high throughput. Like edge networks,
o They lack customer routes, e.g. they are their own customer, not a these networks require "high-touch" edge services, which require
transit ISP in the traditional sense. the forwarder to access the entire header chain
o Peer with a large number of ISPs and other LES / edges.
o Look sort of like an enterprise. Apply ingress policy on upsteam
edge or locations other than end systems. The principle is to
only allow in traffic that is expected (incoming connections are
by nature unsolicited)
o Filter out any traffic that does not conform to expectations.
This is as much an availability/performance/protocol requirement
(as we will see) as it is a security posture.
o The operator is not an Internet Service Provider in the
traditional sense; the customer is an application which in turn is
leveraged over the Internet.
Operator goals (in this order): o Requirements for "high-touch" service, which require the forwarder
to access the entire header chain, increased in networks of all
kinds
1. Keeping their (and their users) data secure. During those years, IPv4 [RFC0791] was the most commonly deployed
2. Keeping the networks up and running. protocol on the Internet. ASIC-based forwarders could meet the
3. Keeping the network performing well. requirements of the evolving Internet because ASICs could predict the
4. Architect the network to be scalable. number of bytes that needed to be copied into on-chip memory in order
5. Costs to make a forwarding decision.
6. Standards compliance.
This should in no way be considered to mean that operators throw away Today, as IPv6 is being deployed, ASIC-forwarders cannot safely
packets capriciously, but in a decision between security and predict the size of the header chain. This leads to complexity and
availability, and standards compliance, the former considerations may vulnerability in handling extension headers. For this reason, many
trump the later. network operators filter all IPv6 packets containing extension
headers.
3. Need to see upper-layer to filter 3. Need to see upper-layer to filter
There is a school of thought that ISPs, content-providers and There is a school of thought that ISPs, content-providers and
enterprises should not be performing any sort of filtering in the enterprises should not be performing any sort of filtering in the
network and that the filtering is more appropriately performed at the network and that the filtering is more appropriately performed at the
end hosts. Unfortinalty this solution, while clean and elegant, end hosts. Unfortunately this solution, while clean and elegant,
simply doesn't work in the real world. Filtering unknown traffic at 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 the edge (and / or in the core) of the network is needed for a number
of reasons, some of which are discussed below (these are not really of reasons, some of which are discussed below.
germane to the draft, but discussing them here may help head off many
discussions).
o ISPs (and cloud providers) are routinely called upon to filter DoS o ISPs (and cloud providers) are routinely called upon to filter DoS
traffic aimed at their customers (for example to block multi-Gbps traffic aimed at their customers (for example to block multi-Gbps
DNS reflection attacks aimed at web servers, etc). At Large Edge DNS reflection attacks aimed at web servers, etc). At Large Edge
Sites this is often a large part of the "service" provided by the Sites this is often a large part of the "service" provided by the
network team. network team.
o IPv6 stacks are still relatively immature and operators still have o IPv6 stacks are still relatively immature and operators still have
concerns that stack or kernel vulnerabilities may still surface. concerns that stack or kernel vulnerabilities may still surface.
If this turns out to be the case, a means to protect the end nodes If this turns out to be the case, a means to protect the end nodes
is needed. is needed.
o In many enterprises the end systems are not sufficiently hardened o In many enterprises the end systems are not sufficiently hardened
to be exposed on the public Internet. Even if there were no to be exposed on the public Internet. Even if there were no
remotely exploitable operating system vulnerabilities there is remotely exploitable operating system vulnerabilities there is
significant risk that an employee may install vulnerable software, significant risk that an employee may install vulnerable software,
accidentally share confidential files or folders publicly or start accidentally share confidential files or folders publicly or start
offering (unauthorized) services. offering (unauthorized) services.
o Content providers (and similar) need to be able to filter traffic o Content providers (and similar) need to be able to filter traffic
and only allow "expected" traffic into their networks. This is and only allow "expected" traffic into their networks. This is
needed both for DoS protection, but also to ensure that needed both for DoS protection, but also to ensure that
development systems, databases, test systems, etc are not development systems, databases, test systems, etc are not
accidentally exposed. accidentally exposed.
While it would be nice if all employees, system and database
administrators could be trusted to always ensure that only the o While it would be nice if all employees, system and database
"correct" services were listening on ports, that all software was administrators could be trusted to always ensure that only the
always fully patches (and contained no vulnerabilities), that "correct" services were listening on ports, that all software was
confidential data was only shared with internal addressed and that always fully patches (and contained no vulnerabilities), that
all credentials were strong and regularly changed, this simply does confidential data was only shared with internal addressed and that
not reflect reality. all credentials were strong and regularly changed, this simply
does not reflect reality.
All of these lead to the requirement that operators be able to filter All of these lead to the requirement that operators be able to filter
at Layer 3 and Layer 4, at line rate, in the network. Obviously, to at Layer 3 and Layer 4, at line rate, in the network. Obviously, to
be able to filter at layers 3 and 4, the router needs to be able to 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 upper layer see the layer 3 and 4 information. Unfortunately, if the size of
header is not available in the first cell / segment of the larger extension header chain varies between 0 and 64 kilobytes, extension
packet we may not be able to see it. This applies to cases where headers cannot be processed efficiently in ASICs.
extension headers pad the variable length portion of the header,
beyond the cell size or, the presumably rarer and probably
deliberately malicious case of initial fragments which do not contain
an upper layer header.
In one widely deployed router architecture, if there are any
extension headers between the IPv6 header and the upper-layer header,
the forwarding logic never sees the upper-layer header, and so is not
able to filter on it. This means that the operator has no visibility
into the packet contents, and so many operators choose to simply drop
all packets with any extension headers.
Network operators may filter traffic with extention header, because Because many implementation do not process IPv6 extension headers
of the lack of fixed extention header size, the complexity of well, many operators filter all IPv6 packets that include them.
following header chains, and the inability of deployed routers to
look sufficently deep into packets to see the upper-layer header.
For this reason, appplications and IPv6 stacks should avoid the use 4. Recommendations
of extention headers whenever possaible, and applications should be
designed to deal with the posibility that packets containing
extention headers may not be delivered.
4. Recomendations An ISP SHOULD NOT discard IPv6 packets based solely upon header chain
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.
This document discourages the use of IPv6 Extension headers, and See Section 1.1 for a formal definition of the header chain.
advises the community that some operators currently filter ingress
packets that contain more than one extension header (and / or headers
that exceed a small number of bytes).
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 There are potential implications to the filtering or acceptances of
packets which cannot be processed according to the configuration of packets which cannot be processed according to the configuration of
the network operator. It is clear from the vantage point of the the network operator. It is clear from the vantage point of the
authors that implementors and operators should be aware of authors that implementors and operators should be aware of
implications of relying on extension header chains or apply policies implications of relying on extension header chains or apply policies
that must necessarily discard packets which contain them. 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 wish to thank Paul Hoffman, KK and Fernando Gont.
They also wish to thank folk for not getting all up in arms :-P
8. Normative References 8. 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.
[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
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
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
o Initial submission. o Initial submission.
-00 to -01
o Added maximum header chain recommendation.
o Rewrite the forwarding description.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: warren@kumari.net Email: warren@kumari.net
Joel Jaeggli Joel Jaeggli
skipping to change at page 9, line 18 skipping to change at page 8, line 18
USA USA
Email: jjaeggli@zynga.com Email: jjaeggli@zynga.com
Ronald P Bonica Ronald P Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, VA Herndon, VA
USA USA
Email: internet-drafts@bonica.org Email: rbonica@juniper.net
 End of changes. 49 change blocks. 
194 lines changed or deleted 181 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/