[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 draft-ietf-intarea-tunnels
Internet Area WG J. Touch
Internet Draft USC/ISI
Intended status: Informational M. Townsley
Expires: September 2010 Cisco
March 5, 2010
Tunnels in the Internet Architecture
draft-touch-intarea-tunnels-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 September 5, 2010.
Touch, Townsley Expires September 1, 2010 [Page 1]
Internet-Draft Tunnels in the Internet March 2010
Copyright Notice
Copyright (c) 2010 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.
Abstract
This document discusses the role of tunnels in the Internet
architecture. It explains their relationship to existing protocol
layers, and the challenges in supporting tunneling.
Table of Contents
1. Introduction...................................................3
2. Conventions used in this document..............................4
3. Known Issues...................................................4
3.1. MTU discovery.............................................5
3.2. Fragmentation.............................................6
3.2.1. Outer Fragmentation..................................6
3.2.2. Inner Fragmentation..................................7
3.2.3. Fragmentation efficiency.............................8
3.2.4. Packing (ala GigE bursting).........................10
3.2.5. IP ID exhaustion....................................11
3.3. Signaling................................................12
4. Current Tunnel Standards......................................13
4.1. IP in IP.................................................13
4.1.1. MTU discovery.......................................13
4.1.2. Fragmentation.......................................14
4.1.3. Signaling...........................................14
4.2. IPsec....................................................14
4.2.1. MTU discovery.......................................15
4.2.2. Fragmentation.......................................15
4.2.3. Signaling...........................................15
5. Issues........................................................15
5.1. Tunnel model.............................................15
5.2. Parties participating....................................16
Touch, Townsley Expires September 1, 2010 [Page 2]
Internet-Draft Tunnels in the Internet March 2010
6. Potential Ways Forward........................................17
7. Notes for future updates......................................18
8. Security Considerations.......................................19
9. IANA Considerations...........................................19
10. References...................................................20
10.1. Normative References....................................20
10.2. Informative References..................................20
11. Acknowledgments..............................................22
1. Introduction
The Internet is loosely based on the ISO seven layer stack, in which
data units traverse the stack by being wrapped inside data units one
layer down (Figure 1). A tunnel is a mechanism for transmitting data
units between endpoints by wrapping them inside data units other
layers, e.g., IP in IP, or IP in UDP (Figure 2).
+------+----+-----+--------------+
+ Eth | IP | TCP | Data |
+------+----+-----+--------------+
Figure 1 TCP inside IP inside Ethernet
+------+----+-----+----+-----+--------------+
+ Eth | IP'| UDP | IP | TCP | Data |
+------+----+-----+----+-----+--------------+
Figure 2 IP in UDP in IP in Ethernet
Tunnels help decouple topology from that provided by the physical
network components. For example, they were critical in the
development of multicast, where not all routers were capable of
processing multicast packets. Multicast routers were interconnected
by tunnels where not directly connected. Similar techniques have been
used to support other protocols, such as IPv6.
Use of tunnels is common in the Internet. The word "tunnel" occurs in
over 100 RFCs, and is supported within numerous protocols, including:
o IPsec - hides the original traffic destination [RFC4301]
o L2TP - Tunnels PPP over IP, used largely in DSL/FTTH access
networks to extend a subscriber's connection from an access line
provider to an ISP [RFC3931]
o Mobile IP - forwards traffic to the home agent [RFC2003]
Touch, Townsley Expires September 1, 2010 [Page 3]
Internet-Draft Tunnels in the Internet March 2010
o L2VPNs - provides a link topology different from that provided by
physical links [RFC4664]
o L3VPNs - provides a network topology different from that provided
by ISPs [RFC4176]
o SEAL - a generic mechanism for IP in IP tunneling designed to
overcome the limitations of RFC2003 [RFC5320]
o LISP - reduces routing table load within an enclave of routers
[Fa10]
o TRILL - enables L3 routing in an enclave of bridges
[Pe10][RFC5556]
o MPLS - ? {need description/ref}
o PWE3 - ? {need description/ref}
The variety of tunnel mechanisms begs the question of the roles of
tunnels in the Internet architecture, and the potential need for
coordination of these mechanisms. In particular, the ways in which
MTU mismatch, error signals (e.g., ICMP), and is handled may benefit
from a coordinated approach.
It is useful to note that, regardless of the layer in which
encapsulation occurs, tunnels emulate a link. As links, they are
subject to link issues, e.g., MTU discovery, signaling, and the
potential utility of native support for broadcast and multicast
[RFC3819]. They have advantages over native links, being potentially
easier to reconfigure and control.
2. Conventions used in this document
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].
3. Known Issues
Most of the known issues with tunnels arise from the complications of
encapsulation, or from the introduction of artificial endpoints along
a data path. Encapsulation exacerbates MTU issues, often because a
data unit will traverse at least one layer of a protocol stack more
than once (e.g., as in Figure 2), which requires space for additional
headers. This space complicates MTU discovery, and often results in
fragmentation.
Touch, Townsley Expires September 1, 2010 [Page 4]
Internet-Draft Tunnels in the Internet March 2010
Tunnel encapsulation and decapsulation nodes act as network
endpoints. They may source and sink much higher bandwidth streams
from single IP addresses, and thus can be affected by many of the
issues of other high bandwidth edge devices, such as fragmentation
efficiency and IP ID exhaustion (in IPv4). These endpoints also
introduce complexity in end-to-end and path signaling, in the
translation between signals inside a tunnel and signals outside on
the end-to-end path.
3.1. MTU discovery
MTU discovery is a known challenge in the current Internet, and
tunnels can complicate its proper operation. Encapsulation increases
the size of a packet during tunnel transit that can exceed the MTU of
the links of the tunnel path. This is especially true for recursive
tunnels, i.e., tunnels that reuse layers of the protocol stack (e.g.,
IPv4 over IPv4). These issues are discussed in detail in [RFC4459];
the following provides a brief overview of the issues. Note that the
impact of tunnels on MTU discovery may be mitigated somewhat by the
ubiquity of workarounds already needed in the Internet, e.g., the
deduction of a 'tunnel tax' for all MTUs (i.e., maxing out the MTU at
1200-1400 bytes, rather than 1500).
Conventional path MTU discovery (PMTUD) relies on explicit negative
feedback from routers along the path (ICMP "message to big" signals)
[RFC1191]. This technique is susceptible to the "black hole"
phenomenon, in which the ICMP messages never return to the source
[RFC2923]. In the typical Internet case, lost ICMPs are often the
result of filtering, e.g., for policy reasons.
A more recent alternative is packetization-layer path MTU discovery
(PLPMTUD) [RFC4821]. This variant relies on feedback from the
endpoint, indicating either the success or failure of probe packets.
It is not susceptible to "black holing", but requires explicit
participation by the receiver.
Either of these techniques (PMTUD, PLPMTUD) can be applied to
tunnels. The encapsulator must react to "message to big" signals in
either case, by either adjusting its fragmentation, relaying a
corresponding signal to the packet origin outside the tunnel, or
both. Fragmentation adjustment is easy to incorporate, but can result
in inefficient transmission of packets over the tunnel (e.g., where
every source packet is fragmented). Relaying the signal to the source
can be much more efficient, but it can be difficult to determine what
signal to forward. E.g., in PMTUD, routers along the tunnel may not
return a sufficiently long prefix to determine the decapsulated
packet origin.
Touch, Townsley Expires September 1, 2010 [Page 5]
Internet-Draft Tunnels in the Internet March 2010
Tunnels thus may need to participate in MTU discovery, either
forwarding or recomputing ICMPs received inside the tunnel path. The
tunnel may incorporate its own MTU discovery between ingress and
egress, e.g., as proposed in SEAL [RFC5320].
3.2. Fragmentation
There are two places where fragmentation can occur in a tunnel,
called Outer Fragmentation and Inner Fragmentation.
3.2.1. Outer Fragmentation
The simplest case is Outer Fragmentation, as shown in Figure 3. The
bottom of the figure shows the network toplogy, where packets start
at the source, enter the tunnel at the encapsulator, exit the tunnel
at the decapsulator, and arrive finally at the destination. The
packet traffic is shown above the topology, where the end-to-end
packets are shown at the top. The packets are composed of an inner
header (iH) and inner data (iD); the term "inner") is relative to the
tunnel, as will become apparent. When the packet (iH,iD) arrives at
the encapsulator, it is placed inside the tunnel packet structure,
here shown as adding just an outer header, oH, in step (a).
When the encapsulated packet exceeds the MTU of the tunnel, the
packet needs to be fragmented. In this case we fragment the packet at
the outer header, with the fragments shown as (b1) and (b2). Note
that the outer header indicates fragmentation (as ' and "),the inner
header occurs only in the first fragment, and the inner data is
broken across the two packets. These fragments are reassembled at the
encapsulator in step (c), and the resulting packet is decapsulated
and sent on to the destination.
Touch, Townsley Expires September 1, 2010 [Page 6]
Internet-Draft Tunnels in the Internet March 2010
+----+----+ +----+----+
| iH | iD |------+ - - - - - - - - - - +------>| iH | iD |
+----+----+ | | +----+----+
v |
+----+----+----+ +----+----+----+
(a) | oH | iH | iD | | oH | iH | iD | (c)
+----+----+----+ +----+----+----+
| ^
| +----+----+-----+ |
(b1) +----- >| oH'| iH | iD1 |-------+
| +----+----+-----+ |
| |
| +----+-----+ |
(b2) +----- >| oH"| iD2 |------------+
+----+-----+
+-----+ +---+ +---+ +-----+
| | / \ ======================= / \ | |
| Src |=======| Enc |=======================| Dec |=======| Dst |
| | \ / ======================= \ / | |
+-----+ +---+ +---+ +-----+
Figure 3 Fragmentation of the outer packet
Outer fragmentation isolates Source and Destination from tunnel
encapsulation duties. This can be considered a benefit in clean,
layered network design, but also may result in complex decapsulator
design, especially where tunnels aggregate large amounts of traffic,
such as IP ID overload (see Sec. 3.2.5). Outer fragmentation is valid
for any tunnel encapsulation protocol that supports fragmentation
(e.g., IPv4 or IPv6), where the tunnel endpoints act as the host
endpoints of that protocol.
Along the tunnel, the inner header is contained only in the first
fragment, which can interfere with mechanisms that 'peek' into lower
layer headers, e.g., as for ICMP, as discussed in Sec. 3.3.
3.2.2. Inner Fragmentation
Inner Fragmentation distributes the impact of tunneling across both
the decapsulator and destination, and is shown in Figure 4. Again,
the network topology is shown at the bottom of the figure, and the
original packets show at the top. Packets arrive at the encapsulator,
and are fragmented there based on the inner header into (a1) and
(a2). The fragments arrive at the decapsulator, which removes the
outer header and forwards the resulting fragments on to the
Touch, Townsley Expires September 1, 2010 [Page 7]
Internet-Draft Tunnels in the Internet March 2010
destination. The destination is then responsible for reassembling the
fragments into the original packet.
+----+----+ +----+----+
| iH | iD |-------+- - - - - - - - - - - - - >| iH | iD |
+----+----+ | +----+----+
v ^
+----+-----+ +----+-----+ |
(a1) | iH'| iD1 | | iH'| iD1 |------+
+----+-----+ +----+-----+ |
|
+----+--- +----+-----+ |
(a2) | iH"| iD2 | | iH"| iD2 |------+
+----+-----+ +----+-----+
| ^
| +----+----+----- |
(b1) +----- >| oH | iH'| iD1 |-------+
| +----+----+-----+ |
| |
| +----+----+-----+ |
(b2) +----- >| oH | iH"| iD2 |-------+
+----+----+-----+
+-----+ +---+ +---+ +-----+
| | / \ ======================= / \ | |
| Src |=======| Enc |=======================| Dec |=======| Dst |
| | \ / ======================= \ / | |
+-----+ +---+ +---+ +-----+
Figure 4 Fragmentation of the inner packet
As noted, inner fragmentation distributes the effort of tunneling
across the decapsulator and destinations; this can be especially
important when the tunnel aggregates large amounts of traffic. Note
that this mechanism is thus valid only when the original source
packets can be fragmented on-path, e.g., as in IPv4.
Along the tunnel, the inner headers are copied into each fragment,
and so are available to mechanisms that 'peek' into headers (e.g.,
ICMP, as discussed in Sec. 3.3). Because fragmentation happens on the
inner header, the impact of IP ID is reduced.
3.2.3. Fragmentation efficiency
There are different ways to fragment a packet. Consider a network
with an MTU as shown in Figure 5, where packets are encapsulated over
the same network layer as they arrive on (e.g., IP in IP). If a
Touch, Townsley Expires September 1, 2010 [Page 8]
Internet-Draft Tunnels in the Internet March 2010
packet as large as the MTU arrives, it must be fragmented to
accommodate the additional header.
X===========================X (MTU)
+----+----------------------+
| iH | DDDDDDDDDDDDDDDDDDDD |
+----+----------------------+
|
| X===========================X (MTU)
| +---+----+------------------+
(a) +->| H'| iH | DDDDDDDDDDDDDDDD |
| +---+----+------------------+
| |
| | X===========================X (MTU)
| | +----+---+----+-------------+
| (a1) +->| nH'| H | iH | DDDDDDDDDDD |
| | +----+---+----+-------------+
| |
| | +----+-------+
| (a2) +->| nH"| DDDDD |
| +----+-------+
|
| +---+------+
(b) +->| H"| DDDD |
+---+------+
|
| +----+---+------+
(b1) +->| nH'| H"| DDDD |
+----+---+------+
Figure 5 Fragmenting via maximum fit
Figure 5 shows this process, using Outer Fragmentation as an example
(the situation is the same for Inner Fragmentation, but the headers
that are affected differ). The arriving packet is first split into
(a) and (b), where (a) is of the MTU of the network. However, this
tunnel then traverses over another tunnel, whose impact the first
tunnel ingress has not accommodated. The packet (a) arrives at the
second tunnel ingress, and needs to be encapsulated again, but
because it is already at the MTU, it needs to be fragmented as well,
into (a1) and (a2). In this case, packet (b) arrives at the second
tunnel ingress and is encapsulated into (b1) without fragmentation,
because it is already below the MTU size.
In Figure 6, the fragmentation is done evenly, i.e., by splitting the
original packet into two roughly equal-sized components, (c) and (d).
Note that (d) contains more packet data, because (c) includes the
Touch, Townsley Expires September 1, 2010 [Page 9]
Internet-Draft Tunnels in the Internet March 2010
original packet header because this is an example of Outer
Fragmentation. The packets (c) and (d) arrive at the second tunnel
encapsulator, and are encapsulated again; this time, neither packet
exceeds the MTU, and neither requires further fragmentation.
X===========================X (MTU)
+----+----------------------+
| iH | DDDDDDDDDDDDDDDDDDDD |
+----+----------------------+
|
| X===========================X (MTU)
| +---+----+----------+
(c) +->| H'| iH | DDDDDDDD |
| +---+----+----------+
| |
| | X===========================X (MTU)
| | +----+---+----+----------+
| (c1) +->| nH | H'| iH | DDDDDDDD |
| +----+---+----+----------+
|
| +---+--------------+
(d) +->| H"| DDDDDDDDDDDD |
+---+--------------+
|
| +----+---+--------------+
(d1) +->| nH | H"| DDDDDDDDDDDD |
+----+---+--------------+
Figure 6 Fragmenting evenly
3.2.4. Packing (ala GigE bursting)
Encapsulating individual packets to traverse a tunnel can be
inefficient, especially where headers are large relative to the
packets being carried. In that case, it can be more efficient to
encapsulate many small packets in a single, larger tunnel payload.
This technique, similar to the effect of packet bursting in Gigabit
Ethernet, reduces the overhead of the encapsulation headers (Figure
7). It reduces the work of header addition and removal at the tunnel
endpoints, but increases other work involving the packing and
unpacking of the component packets carried.
Touch, Townsley Expires September 1, 2010 [Page 10]
Internet-Draft Tunnels in the Internet March 2010
+-----+-----+
| iHa | iDa |
+-----+-----+
|
| +-----+-----+
| | iHb | iDb |
| +-----+-----+
| |
| | +-----+-----+
| | | iHc | iDc |
| | +-----+-----+
| | |
v v v
+----+-----+-----+-----+-----+-----+-----+
| oH | iHa | iHa | iHb | iDb | iHc | iDc |
+----+-----+-----+-----+-----+-----+-----+
Figure 7 Packing packets into a tunnel
3.2.5. IP ID exhaustion
In IPv4, the IP Identification (ID) field is a 16-bit value that is
unique for every packet for a given source address, destination
address, and protocol, such that it does not repeat within the
Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. Although the ID
field was originally intended for fragmentation and reassembly, it
can also be used to detect and discard duplicate packets, e.g., at
congested routers (see Sec. 3.2.1.5 of [RFC1122]). For this reason,
and even more so that IPv4 packets can be fragmented anywhere along a
path, all packets between a source and destination of a given
protocol must have unique ID values over a period of an MSL, which is
typically interpreted as two minutes (120 seconds).
The uniqueness of the IP ID is a known problem for high speed
devices, because it limits the speed of a single protocol between two
endpoints [RFC4963]. With the maximum IP packet size of 64KB, a 16-
bit ID field that does not repeat within 120 seconds means that the
sum of all TCP connections between two endpoints is limited to
roughly 286 Mbps; for more typical MTUs of 1500 bytes, this drops to
6.4 Mbps.
Although this strongly suggests that the uniqueness of the IP ID is
moot, tunnels exacerbate this condition. A tunnel often aggregates
traffic from a number of different source and destination addresses,
of different protocols, and encapsulates them in a header with the
same ingress and egress addresses, all using a single encapsulation
protocol. The result is one of the following:
Touch, Townsley Expires September 1, 2010 [Page 11]
Internet-Draft Tunnels in the Internet March 2010
1. The IP ID rules are enforced, and the tunnel throughput is
severely limited.
2. The IP ID rules are enforced, and the tunnel consumes large
numbers of ingress/egress IP addresses solely to ensure ID
uniqueness.
3. The IP ID rules are ignored.
The last case is the most obvious solution, because it corresponds to
how endpoints currently behave. Fortunately, fragmentation is
somewhat rare in the current Internet at large, but it can be common
along a tunnel. Fragments that repeat the IP ID risk being
reassembled incorrectly, especially when fragments are reordered or
lost. Although such errors may be detected at the transport layer,
this results in excessive overall packet loss, as well as wasting
bandwidth between the egress and ultimate packet destination.
3.3. Signaling
In the current Internet architecture, signals tend to go upstream,
either from routers along a path or from the destination, back toward
the source (Figure 8). Such signals are typically contained in ICMP
messages, but can involve other protocols such as RSVP, transport
protocol signals (e.g., TCP RSTs), or multicast.
+--------------------------------------------------------------+
| |
| +---------------------------+ |
| | | |
v v | |
+-----+ | +-----+
| | | | |
| Src |=========================R=============================| Dst |
| | | |
+-----+ +-----+
Figure 8 Signaling paths in an Internet
Tunnels interfere with these known signaling paths. As shown in
Figure 9, signals from routers along the tunnel path (R2), as well as
those from the tunnel egress, need to be relayed by the ingress. This
relaying may be difficult, because R2 may not return enough
information to the ingress to support relaying (e.g., when ICMP
returns only the outermost headers in a "message to big", and the
source transport port information is lost). Signals from routers
Touch, Townsley Expires September 1, 2010 [Page 12]
Internet-Draft Tunnels in the Internet March 2010
downstream of the egress (R3 in Figure 9) need to traverse the tunnel
in reverse.
In all cases, the tunnel ingress needs to determine how to relay the
signals from inside the tunnel into signals back to the source. For
some protocols this is either simple or impossible (such as for
ICMP), for others, it can even be undefined (e.g., multicast).
+ - - - - +-------------------------------+
| | |
v v |
+-----+ +---+ +---+ +-----+
| | / \ ======================= / \ | |
| Src |==R1===| Enc |==========R2===========| Dec |===R3==| Dst |
| | \ / ======================= \ / | |
+-----+ +---+ | +---+ +-----+
^ ^ |
| | |
+ - - - - +---------------+
Figure 9 Signaling paths introduced by a tunnel
4. Current Tunnel Standards
This section reviews two common Internet tunnel standards. They are
notable because they both ultimately rely on IP in IP encapsulation,
although they each handle MTU discovery, fragmentation, and signaling
differently.
[There are other tunnel mechanisms, such as IPv4 in IPv6, which may
be added to this discussion later.]
4.1. IP in IP
The simplest tunnel encapsulation mechanism is IP in IP, explained
here for IPv4 [RFC2003]. This protocol was standardized for use in
mobile IP, so that packets sent from a source to a Home Agent could
be forwarded unmodified to the different address of the Mobile Node
[RFC3344]. It has come to be used much more generally, e.g., to
support multicast, as well as in overlay network systems
[Er94][To01].
4.1.1. MTU discovery
When an IPv4 packet arrives at an IP-in-IP ingress, the DF flag from
the inner packet is copied to the outer header. This enforces DF of
the packet within the tunnel when requested by the packet source.
Touch, Townsley Expires September 1, 2010 [Page 13]
Internet-Draft Tunnels in the Internet March 2010
Packets which are too large are dropped at the ingress, and a
corresponding ICMP "message to big" is returned to the source.
Internally, IP-in-IP tunneling requires that the tunnel MUST support
ICMP-based path MTU discovery (i.e., PMTUD). Note that due to common
filtering of ICMP messages, this requirement is impossible to
determine and thus to enforce.
4.1.2. Fragmentation
IP-in-IP tunneling supports Inner Fragmentation. The inner packet MAY
be fragmented if DF=0, otherwise the packet would have been dropped
if too big, as noted earlier. The tunnel MUST NOT fragment at the
outer header if DF=1 is set, i.e., this tunnel protocol assumes the
network honors the DF bit (note that some tunnels, as well as some
network devices, do not honor the DF bit). Further, if the DF bit is
set in the inner header, it MUST be set in the outer; if not, it MAY
be set in the outer.
4.1.3. Signaling
IP-in-IP tunnels MAY relay ICMPs from inside the tunnel to the
source, i.e., at the ingress. They SHOULD relay network and host
unreachable messages, and MUST relay "message too big" messages;
these reflect network conditions that the source should be informed
about. They MUST NOT relay port unreachable messages, because these
are meaningless for encapsulated packets, and thus reflect internal
link conditions that the source should not care about at all. They
MUST NOT relay and SHOULD handle locally messages that affect the
ingress as if it were a host, e.g., source quench and router errors.
Most notably, IP-in-IP notes that the tunnel SHOULD keep sufficient
soft state to assist with relaying. Such state may involve keeping
copies of recently sent packets, to have sufficient context to relay
when lacking in the received ICMP message.
4.2. IPsec
The Internet network security standard, IPsec, incorporates IP-in-IP
encapsulation as part of its tunnel mode of operation [RFC4301].
Although IP-in-IP packets can be secured via IPsec transport mode,
resulting in identical packets [RFC3884], the rules affecting IPsec
tunnel mode MTU discovery, fragmentation, and signaling mode are
specified by IPsec, rather than IP-in-IP.
Touch, Townsley Expires September 1, 2010 [Page 14]
Internet-Draft Tunnels in the Internet March 2010
4.2.1. MTU discovery
Tunnel mode IPsec MTU discovery supports ICMP-based path MTU
discovery (PMTUD), but only as a SHOULD. If an IPv4 packet arrives
with DF=1, or an IPv6 packet arrives, and either is too large for the
tunnel, the ingress SHOULD discard and send an ICMP to the source. If
IPv4 and DF=0, the ingress SHOULD perform Outer Fragmentation, and
SHOULD NOT send an ICMP to the source.
4.2.2. Fragmentation
IPsec performs only Outer Fragmentation; this distinguishes it from
IP-in-IP, which performs only Inner Fragmentation.
It requires that implementations of tunnel mode allow the security
policy to decide how the IPv4 DF bit should propagate from the inner
to the outer header. It may be copied, cleared, or set, again,
differing from IP-in-IP which allows only copy or set.
4.2.3. Signaling
IPsec, like IP-in-IP, relays ICMP "message to big" signals from the
ingress back to the source. The size indicated is adjusted to take
into account for the space for both encapsulation and security
information. Further, it allows that any ICMP message may be blocked,
on a per-security association basis; this filtering is for security
reasons, but also can directly result in "black holing".
5. Issues
As has been shown in only two examples, even similar mechanisms for
encapsulation can result in very different approaches to tunneling.
Although these approaches result in different MTU discovery,
fragmentation, and signaling mechanisms, they result from different
architectural perspectives on the role of tunnels in the Internet.
This section discusses these more fundamental perspectives, and their
impact on the mechanisms.
5.1. Tunnel model
The Internet architecture is composed of hosts, gateways (i.e.,
routers), and links [Cl88]. A host is a source or sink of network
packet traffic, a router redirects packets from one set of links to
another, and links interconnect hosts and routers. Although
originally described for the Internet's network layer, this
architecture, with a bit of renaming (e.g., routers become bridges),
applies equally well for link layers.
Touch, Townsley Expires September 1, 2010 [Page 15]
Internet-Draft Tunnels in the Internet March 2010
Tunnels could, in principle, be related to this basic model in one of
three ways:
o Tunnel as a link
o Tunnel as a router/bridge
o Tunnel as invisible
Tunnels require distinct ingress and egress addresses, to use during
encapsulation, and to direct encapsulated traffic from the ingress to
the egress. As a result, a tunnel is most usefully considered a link
in the architecture in which they are deployed. As a result, tunnel
designers should consider and apply link design issues [RFC3819].
This also implies that operating systems designers should represent
tunnels as links; this may be conveniently represented as virtual
interfaces.
[this includes tunnel as point-point vs. tunnel as multipoint]
5.2. Parties participating
The description of a tunnel focuses on the functions of the ingress
and egress, but not all functions need be located at one of these two
points. Recall inner fragmentation, in which fragment reassembly
occurs at the destination, not the egress - this imposes load on the
destination as a result of behavior of the ingress.
Containing all tunnel functions solely inside the tunnel endpoints,
as with outer fragmentation, is architecturally clean. It also obeys
the 'clean up your own mess' principle; the impact of encapsulation
and fragmentation caused by the ingress is then handled by the
egress, without imposing load on the destination.
Distributing tunnel functions across both egress and destination, as
with inner fragmentation, can be more efficient. The impact of the
limited IPv4 IP ID space is more prominent in the outer header, due
to aggregation of traffic at the ingress. Using the inner header for
fragmentation allows use of a larger effective IP ID space because of
the additional IP source/destination addresses present there.
Reassembly can be distributed among a large number of destinations
(where present), and the impact of reassembly can be isolated to only
affected destinations. Further, fragmenting once at the ingress can
avoid repeated fragmentation/reassembly steps when packets traverse
multiple tunnels in succession.
Touch, Townsley Expires September 1, 2010 [Page 16]
Internet-Draft Tunnels in the Internet March 2010
The primary case in favor of distributed tunnel functions, and thus
inner encapsulation is that high speed ingress devices can be
implemented, but that corresponding high speed egresses are difficult
or costly. Unfortunately, network operators cannot always know in
advance that high-speed ingresses are being deployed where the
destination traffic is sufficiently diffuse; deploying such a device
where the traffic focuses on a single destination puts an undue
burden on that destination.
6. Potential Ways Forward
There are a number of issues which may benefit from a coordinated
review. These include unification of various tunneling standards, and
revision of tunnel standards to address:
o Relation of inner/outer headers (i.e., which fields are copied,
derived, etc.)
o MTU discovery
o Fragmentation
o Signaling
This revision may suggest the utility of a single, configurable
tunnel mechanism that includes various solutions as alternatives,
rather than developing custom tunnel solutions on-demand. It may also
suggest the development of new solutions, such as:
o The use of PLPMTUD for tunnels
o Addressing the IP ID issue and fragmentation
o New ICMP signals
o Optimization solutions, such as packing
SEAL addresses a few of these issues, notably the first two
[RFC5320]. It adds an active signal exchange between ingress and
egress for intra-tunnel MTU discovery, and an extension to the IP ID
space to detect collisions.
Tunnels are further evidence that the current requirements for IPv4
ID uniqueness may need revision. In particular, it is clear that even
moderate speed transport connections already violate these
requirements. We recommend revisiting the requirements as suggested
in [To10].
Touch, Townsley Expires September 1, 2010 [Page 17]
Internet-Draft Tunnels in the Internet March 2010
Note that this document does not argue for a single, generic
tunneling protocol or mechanism. Such a mechanism is no more likely
to be useful than would a 'one size fits all' transport protocol. It
does argue, however, for consistency in tunnel design, and
abstraction and reuse of mechanism where possible.
7. Notes for future updates
[This area includes notes for future updates which have been reported
but not yet fully included - it represents a holding area for
comments, and should not appear in the final document.]
tunnel as virtualization - Stewart Bryant (SB)
tunnel as endpoint only, not on-path (not MPLS, e.g.) - JT/coauthor
gigE packing like PWE3 ATM packing - SB
PPP chopping and coalescing - MT/coauthor
end sec 2 "we need large seq num and to frag at the tunnel" / maybe,
but do we want recommendations? - SB
security should add addr management and ACLs (?) - SB
MTU as part of BGP? - SB (Will this even work - JT)
section 2 it says: "The IPv6 fragment header is present only when a
packet has been fragmented", but I know of at least one effort in
MANET that is proposing to include the fragment header even for
unfragmented IPv6 packets. That would seem to bend the rules set
forth in RFC2460, but I just thought it might be worth pointing out
that some people are considering bending them. - Fred Templin
NATs - i.e., One other thought; where the IP ID problem becomes truly
pathological is for tunnels that traverse IPv4 NATs. First, the NATs
could rewrite the ID to something the ingress tunnel endpoint never
intended. Secondly, multiple ingress tunnel endpoints that traverse
the same NAT could have IP ID "collisions" from the perspective of
the outside world. This may deserve a section unto itself? - FT
NAT as half-tunnel - JT
tunnel endpoint as following host rules - JT (as with ECN in CAPWAP,
per Magnus' email of 10/10/08)
the need for larger min MTU - FT (see SEAL)
Touch, Townsley Expires September 1, 2010 [Page 18]
Internet-Draft Tunnels in the Internet March 2010
describe relationship to [Ho08] - JT (as per INTAREA meeting notes,
don't cover Teredo-specific issues in Ho08, but include generic
issues here)
8. Security Considerations
Tunnels may introduce vulnerabilities, or add to the potential for
receiver overload and thus DOS attacks. These issues are primarily
related to the fact that a tunnel is a link that traverses a network
path, and to fragmentation and reassembly. Regarding ICMP signals,
tunnels have similar security issues to routers, in that they SHOULD
throttle ICMPs sent to a given source, and SHOULD send ICMPs that
correspond to events inside the tunnel. Such ICMPs MUST have the
tunnel ingress IP address as the source IP, because IP addresses
inside a tunnel path may have no meaning outside the tunnel.
Tunnels traverse multiple hops of a network path from ingress to
egress. Traffic along such tunnels may be susceptible to on-path and
off-path attacks, including fragment injection, reassembly buffer
overload, and ICMP attacks. Some of these attacks may not be as
visible to the endpoints of the architecture into which tunnels are
deployed, and may result in these attacks being more difficult to
detect.
Inner fragmentation can present an undue burden on destinations where
traffic is not sufficiently diffuse; tunnels SHOULD NOT employ inner
fragmentation except where such diffusion is confirmed either by the
tunnel mechanism or network designer. All tunnel fragmentation -
inner and outer - MUST obey all existing fragmentation requirements,
i.e., IPv6 tunnels MUST NOT employ inner fragmentation, and IPv4
tunnels MUST NOT use inner fragmentation where the inner header DF=1.
Tunnels MUST obey all existing IP requirements, such as the
uniqueness of the IP ID field, until otherwise exceptioned or
revoked. Failure to either limit encapsulation traffic, or use
additional ingress/egress IP addresses, can result in high speed
traffic fragments being incorrectly reassembled.
9. IANA Considerations
This document has no IANA considerations.
The RFC Editor should remove this section prior to publication.
Touch, Townsley Expires September 1, 2010 [Page 19]
Internet-Draft Tunnels in the Internet March 2010
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[Cl88] Clark, D., "The design philosophy of the DARPA internet
protocols," Proc. Sigcomm 1988, p.106-114, 1988.
[Er94] Eriksson, H., "MBone: The Multicast Backbone,"
Communications of the ACM, Aug. 1994, pp.54-60.
[Fa10] Farinacci, D., V. Fuller, D. Meyer, D. Lewis, "Locator/ID
Separation Protocol (LISP)," (work in progress), draft-
ietf-lisp-06, Jan. 2010.
[Ho08] Hoagland, J., S. Krishnan, D. Thaler, "Security Concerns
With IP Tunneling," (work in progress), draft-ietf-v6ops-
tunnel-security-concerns-01, Oct. 2008.
[Pe10] Perlman, R., D. Eastlake, D. Dutt, S. Gai, A. Ghanwani,
"RBridges: Base Protocol Specification," (work in
progress), trill draft-ietf-trill-rbridge-protocol-15, Jan.
2010.
[RFC791] Postel, J., "Internet Protocol," RFC 791 / STD 5, September
1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers," RFC 1122 / STD 3, October 1989.
[RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191,
November 1990.
[RFC2003] Perkins, C., "IP Encapsulation within IP," RFC 2003,
October 1996.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC
2923, September 2000.
[RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4," RFC 3344,
August 2002.
Touch, Townsley Expires September 1, 2010 [Page 20]
Internet-Draft Tunnels in the Internet March 2010
[RFC3819] Karn, P., Ed., C. Bormann, G. Fairhurst, D. Grossman, R.
Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood,
"Advice for Internet Subnetwork Designers," RFC 3819 / BCP
89, July 2004.
[RFC3884] Touch, J., L. Eggert, Y. Wang, "Use of IPsec Transport Mode
for Dynamic Routing," RFC 3884, September 2004.
[RFC3931] Lau, J., Ed., M. Townsley, Ed., I. Goyret, Ed., "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)," RFC 3931, March
2005.
[RFC4176] El Mghazli, Y., Ed., T. Nadeau, M. Boucadair, K. Chan, A.
Gonguet, "Framework for Layer 3 Virtual Private Networks
(L3VPN) Operations and Management," RFC 4176, October 2005.
[RFC4301] Kent, S., and K. Seo, "Security Architecture for the
Internet Protocol," RFC 4301, December 2005.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling," RFC 4459, April 2006.
[RFC4664] Andersson, L., Ed., E. Rosen, Ed., "Framework for Layer 2
Virtual Private Networks (L2VPNs)," RFC 4664, September
2006.
[RFC4821] Mathis, M., J. Heffner, "Packetization Layer Path MTU
Discovery," RFC 4821, March 2007.
[RFC4963] Heffner, J., M. Mathis, B. Chandler, "IPv4 Reassembly
Errors at High Data Rates," RFC 4963, July 2007.
[RFC5320] Templin, F., Ed., "The Subnetwork Encapsulation and
Adaptation Layer (SEAL)," RFC 5320, Feb. 2010.
[RFC5556] Touch, J., R. Perlman, "Transparently Interconnecting Lots
of Links (TRILL): Problem and Applicability Statement," RFC
5556, May 2009.
[To01] Touch, J., "Dynamic Internet Overlay Deployment and
Management Using the X-Bone," Computer Networks, July 2001,
pp. 117-135.
[To10] Touch, J., "Updated Specification of the IPv4 ID Field,"
(work in progress), draft-touch-intarea-ipv4-id-update,
Feb. 2010.
Touch, Townsley Expires September 1, 2010 [Page 21]
Internet-Draft Tunnels in the Internet March 2010
11. Acknowledgments
This document originated as the result of numerous discussions among
the authors, Jari Arkko, Stuart Bryant, Lars Eggert, Dino Farinacci,
Matt Mathis, and Fred Templin, as well as members participating in
the Internet Area Working Group.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292-6695
U.S.A.
Phone: +1 (310) 448-9151
Email: touch@isi.edu
W. Mark Townsley
Cisco
L'Atlantis, 11, Rue Camille Desmoulins
Issy Les Moulineaux, ILE DE FRANCE 92782
Email: townsley@cisco.com
Touch, Townsley Expires September 1, 2010 [Page 22]
Html markup produced by rfcmarkup 1.128, available from
https://tools.ietf.org/tools/rfcmarkup/