Security Requirements for IP Tunnel Nodes
draft-gai-intarea-ip-tunnel-node-security-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Lin He , 盖乐 , Zedong Jia , Ying Liu | ||
| Last updated | 2026-09-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-gai-intarea-ip-tunnel-node-security-01
Internet Area L. He
Internet-Draft L. Gai
Intended status: Standards Track Z. Jia
Expires: 4 March 2027 Y. Liu
Tsinghua University
9 September 2026
Security Requirements for IP Tunnel Nodes
draft-gai-intarea-ip-tunnel-node-security-01
Abstract
IP tunnels conceal passenger-packet fields from devices on the
delivery path and create a new forwarding and policy boundary at
decapsulation. If a tunnel node accepts delivery packets from an
unauthorized source, or if it forwards a decapsulated passenger
packet without applying the policy for the exposed packet and
forwarding domain, the node can enable source-address spoofing,
unauthorized transit, policy bypass, or resource-exhaustion attacks.
This document specifies generic security requirements for IP tunnel
ingress, egress, and relay nodes. The requirements cover explicit
enablement, peer and passenger-packet authorization, source and
forwarding-scope validation, nested tunneling, IPv6 extension
headers, ICMP and Path MTU Discovery, resource controls, and
telemetry. They apply to configured IP-in-IP, IPv6 tunneling, GRE,
and enabled IPv4/IPv6 transition mechanisms. This document does not
define a new encapsulation or replace protocol-specific processing
rules.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 4 March 2027.
He, et al. Expires 4 March 2027 [Page 1]
Internet-Draft IP Tunnel Node Security August 2026
Copyright Notice
Copyright (c) 2026 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope and Relationship to Existing Specifications . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Threat Model and Security Objectives . . . . . . . . . . . . 5
3. Tunnel Node Processing Model . . . . . . . . . . . . . . . . 6
4. Default Configuration and Policy Requirements . . . . . . . . 7
5. Peer Authentication and Packet Authorization . . . . . . . . 8
6. Address and Forwarding-Scope Validation . . . . . . . . . . . 9
6.1. Delivery-Packet Validation . . . . . . . . . . . . . . . 9
6.2. Passenger Source Validation . . . . . . . . . . . . . . . 10
6.3. Destination, Local-Delivery, and Forwarding-Scope
Validation . . . . . . . . . . . . . . . . . . . . . . . 10
7. Nested and Recursive Tunneling . . . . . . . . . . . . . . . 11
8. IPv6 Extension Headers and Fragmentation Policy . . . . . . . 11
9. Protocol-Specific Requirements . . . . . . . . . . . . . . . 12
9.1. IP-in-IP and IPv6 Tunneling . . . . . . . . . . . . . . . 12
9.2. GRE and GRE over IPv6 . . . . . . . . . . . . . . . . . . 13
9.3. Configured IPv4/IPv6 Transition Tunnels . . . . . . . . . 13
9.4. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. ICMP, TTL, Hop Limit, MTU, and Fragmentation . . . . . . . . 14
10.1. TTL and Hop Limit . . . . . . . . . . . . . . . . . . . 14
10.2. ICMP Generation and Processing . . . . . . . . . . . . . 14
10.3. MTU and Path MTU Discovery . . . . . . . . . . . . . . . 15
10.4. Fragmentation and Reassembly Resources . . . . . . . . . 15
11. Resource-Exhaustion Controls . . . . . . . . . . . . . . . . 15
12. Operational Management and Telemetry . . . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
He, et al. Expires 4 March 2027 [Page 2]
Internet-Draft IP Tunnel Node Security August 2026
17.1. Normative References . . . . . . . . . . . . . . . . . . 19
17.2. Informative References . . . . . . . . . . . . . . . . . 21
Changes from -00 . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
IP tunneling carries a passenger packet inside a delivery packet.
The delivery header is routed across a delivery network, and a tunnel
egress removes that encapsulation before locally delivering,
forwarding, or re-encapsulating the exposed passenger packet. This
model is used by IP-in-IP [RFC2003], generic packet tunneling in IPv6
[RFC2473], Generic Routing Encapsulation (GRE) [RFC2784], GRE over
IPv6 [RFC7676], and IPv4/IPv6 transition mechanisms [RFC4213].
Encapsulation moves passenger source and destination addresses,
upper-layer protocol identifiers, and ports away from their normal
locations. Consequently, security devices on the delivery path may
be unable to apply controls that would have been applied to native
traffic. This concern is described for IP-in-IP in [RFC2003] and
more generally in [RFC6169]. Decapsulation then creates a trust
boundary: acceptance of the delivery packet is not, by itself,
authorization to deliver or forward the exposed passenger packet.
This document consolidates generic requirements for making that
boundary explicit, bounded, and observable. It does not deprecate IP
tunneling. It also does not assume that every tunnel is a point-to-
point tunnel; protocol-specific mechanisms such as 6to4 require role-
and direction-specific validation instead of a static peer-address
check.
1.1. Scope and Relationship to Existing Specifications
This document applies to hosts, routers, firewalls, tunnel brokers,
customer-edge devices, provider-edge devices, and middleboxes that
encapsulate, decapsulate, locally deliver, forward, or re-encapsulate
IP passenger packets in IPv4 or IPv6 delivery packets. The generic
requirements apply to configured tunnels and to automatic or
transition mechanisms only when those mechanisms are explicitly
enabled.
He, et al. Expires 4 March 2027 [Page 3]
Internet-Draft IP Tunnel Node Security August 2026
This document specifies no new packet format, authentication
exchange, key-management protocol, ICMP message, or IANA code point.
It does not replace the TTL, Hop Limit, fragmentation, reassembly,
ICMP, or MTU procedures in the specification for a particular tunnel.
An implementation claiming conformance with this document MUST also
follow the applicable tunnel and passenger protocol specifications.
If a protocol-specific specification requires behavior that differs
from a generic rule in this document, the protocol-specific behavior
takes precedence.
Link-layer tunnels, application-layer proxies, and non-IP passenger
protocols are outside the normative scope. The same design
principles may be useful for them. IPsec tunnel mode is not re-
specified here; [RFC4301] defines the IPsec security architecture,
and [RFC4891] discusses its use for IPv6-in-IPv4 tunnels.
1.2. Terminology
Delivery packet and delivery header:
The packet transmitted across a tunnel and the header used to
deliver it to a tunnel egress. These are also commonly called the
outer packet and outer header.
Passenger packet and passenger header:
The packet carried by the tunnel and the header exposed by
decapsulation. These are also commonly called the inner packet
and inner header.
Tunnel node:
A node that performs tunnel encapsulation, decapsulation, local
delivery of a decapsulated packet, forwarding, or tunnel relay
processing.
Ingress tunnel node:
A tunnel node that receives or originates a passenger packet and
encapsulates it for delivery across a tunnel.
Egress tunnel node:
A tunnel node that receives a delivery packet, removes one tunnel
encapsulation, and locally delivers or forwards the exposed
passenger packet according to tunnel policy.
Relay tunnel node:
A tunnel node that decapsulates a packet and then forwards or re-
encapsulates the exposed packet into another forwarding domain,
address family, or tunnel.
He, et al. Expires 4 March 2027 [Page 4]
Internet-Draft IP Tunnel Node Security August 2026
Tunnel peer:
A remote tunnel ingress, egress, or relay that is authorized by a
tunnel policy. Authorization can be based on authenticated
identity, configured topology, protocol-specific derivation, or a
combination of these.
Tunnel policy:
The configuration and authenticated control-plane state that bind
a delivery-packet selector and peer authorization context to
permitted passenger packets, dispositions, forwarding domains, and
resource limits.
Nested encapsulation:
Encapsulation in which a passenger packet is itself a tunnel
packet, as defined by [RFC2473].
Recursive encapsulation:
Encapsulation in which a packet reenters a tunnel before exiting
it, as defined by [RFC2473]. Recursive encapsulation is a
hazardous special case of nested encapsulation.
Decapsulation depth:
The number of tunnel headers removed from a packet during a local
processing sequence.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Threat Model and Security Objectives
The assets protected by this document are: (1) authorization of
decapsulation, local delivery, forwarding, and re-encapsulation; (2)
source-address validity and accountability for passenger traffic; (3)
consistency between policy for native traffic and policy for traffic
exposed by decapsulation; (4) separation among forwarding domains;
and (5) data-plane and control-plane availability at the tunnel node.
He, et al. Expires 4 March 2027 [Page 5]
Internet-Draft IP Tunnel Node Security August 2026
The attacker is assumed to be able to send delivery packets to an
address of the tunnel node and to choose passenger headers, extension
headers, fragments, and nested encapsulations. Where source address
spoofing is possible on the delivery network, the attacker may also
choose a forged delivery source address. The attacker may instead be
an authorized tunnel peer that sends a passenger packet outside its
authorized source, destination, protocol, or forwarding scope.
The principal trust boundaries are the transition from the delivery
network into tunnel processing, the transition from tunnel processing
into a passenger forwarding domain, and every subsequent
decapsulation or re-encapsulation boundary. Successful attack events
include unauthorized decapsulation, local delivery, forwarding, or
re-encapsulation; acceptance of an unauthorized passenger source;
placement of a packet in the wrong forwarding domain; bypass of a
configured policy selector; and exhaustion of parsing, reassembly,
logging, or control-plane resources.
Administrative compromise of the tunnel node, compromise of
cryptographic keys or authenticated control-plane state, and attacks
on the cryptographic algorithms themselves are out of scope. This
document does not prevent an authorized peer from sending harmful
traffic that remains within its authorized passenger scope. Address-
based peer checks do not provide cryptographic data-origin
authentication when delivery source addresses can be spoofed.
3. Tunnel Node Processing Model
A tunnel node compliant with this document applies the following
logical stages to each candidate tunnel packet:
1. Determine whether the addressed tunnel mechanism is enabled.
2. Select a candidate tunnel policy using the local delivery
address, delivery protocol, receiving interface or forwarding
domain, and authenticated control-plane state.
3. Validate the delivery source and destination and authorize the
candidate peer for that policy.
4. Perform delivery-packet processing required by the applicable IP
and tunnel specifications, subject to resource limits.
5. Authorize and perform exactly one decapsulation step.
He, et al. Expires 4 March 2027 [Page 6]
Internet-Draft IP Tunnel Node Security August 2026
6. Validate the exposed passenger packet, including its address
validity, authorized source, permitted destination and forwarding
scope, fragmentation state, and any configured upper-layer
policy.
7. Apply the policy for the first processing depth at which each
required selector is visible.
8. Authorize local delivery, forwarding, re-encapsulation, or an
additional decapsulation step.
9. Update counters and emit any permitted, rate-limited logs or
control messages.
An implementation MAY combine these stages internally or execute them
in a different order, but it MUST preserve their externally visible
security properties. In particular, a fast path MUST NOT forward,
locally deliver, or re-encapsulate a packet solely because its
delivery header matched a tunnel policy.
Unless a protocol-specific specification requires another action, a
packet that fails authorization or a configured validation rule MUST
be discarded. Failure of logging or telemetry export MUST NOT cause
an otherwise unauthorized packet to be accepted.
4. Default Configuration and Policy Requirements
Tunnel decapsulation and tunnel relay behavior MUST be disabled
unless enabled by explicit configuration or authenticated control-
plane state. Support for an automatic tunnel mechanism does not
constitute enablement. A permissive, multipoint, or automatic mode
MUST require explicit administrative action and MUST NOT be enabled
merely by enabling IP forwarding.
A tunnel policy MUST identify at least:
* the delivery and passenger address families and enabled
encapsulation type;
* the local tunnel endpoint address or other local delivery
selector;
* the expected receiving interface or delivery forwarding domain
where that selector is stable;
* the authorized peer address set, authenticated peer identity, or
protocol-specific peer-derivation rule;
He, et al. Expires 4 March 2027 [Page 7]
Internet-Draft IP Tunnel Node Security August 2026
* the passenger source prefixes, destination scope, and passenger
protocols authorized for each peer or peer class;
* the permitted disposition and passenger forwarding domain;
* the permitted next tunnel policy, maximum decapsulation depth, and
re-encapsulation behavior;
* IPv6 extension-header, fragmentation, ICMP, and PMTU handling
policy; and
* per-peer, per-tunnel, and global resource, logging, and rate
limits.
By default, a policy MUST authorize removal of only the tunnel header
that matched that policy. A further decapsulation or re-
encapsulation step MUST require an explicitly configured next policy.
This default is a local authorization rule; it does not replace the
Tunnel Encapsulation Limit mechanism in [RFC2473].
When authenticated control-plane state is required to authorize a
peer or passenger prefix, loss or expiration of that state MUST NOT
authorize new decapsulation state. Implementations SHOULD provide a
bounded, operator-configurable behavior for existing state during
control-plane failure.
5. Peer Authentication and Packet Authorization
Peer authentication and packet authorization are distinct.
Authentication establishes an identity or data origin. Authorization
determines which delivery packets and passenger packets that identity
may inject and where those packets may be delivered or forwarded.
A configured tunnel crossing a network in which delivery source
spoofing or on-path modification is within the threat model SHOULD
use cryptographic data-origin authentication and integrity
protection. If a security decision depends on a peer identity that
cannot be reliably established by the delivery topology, the tunnel
node MUST use an authenticated mechanism. IPsec [RFC4301] is one
such mechanism; this document does not mandate a single mechanism.
He, et al. Expires 4 March 2027 [Page 8]
Internet-Draft IP Tunnel Node Security August 2026
An address match, receiving interface, IPv6 Flow Label, local
interface identifier, or predictable address format MUST NOT be
represented as cryptographic peer authentication. The GRE Key field
defined by [RFC2890] identifies a logical traffic flow. Absent an
additional specification and protected secret provisioning, it MUST
NOT be treated as cryptographic authentication. Such fields MAY be
used as authorization selectors after the applicable peer check has
succeeded.
Successful peer authentication MUST NOT, by itself, authorize every
passenger source, destination, protocol, local service, forwarding
domain, or deeper tunnel layer. The tunnel node MUST bind the
authenticated or configured peer to the complete tunnel policy used
for the packet. This requirement applies equally to packets that
will be forwarded and packets addressed to a local service after
decapsulation.
Where the selected authentication mechanism provides anti-replay
protection and replay is relevant to the deployment, operators SHOULD
enable that protection. Replay protection does not replace
passenger-packet authorization.
6. Address and Forwarding-Scope Validation
6.1. Delivery-Packet Validation
Before decapsulation, a configured tunnel egress MUST verify that the
delivery destination identifies a local enabled tunnel endpoint and
that the delivery protocol, source address, receiving context, and
any authentication result match the selected policy. For a
configured IPv6-over-IPv4 tunnel, the IPv4 source-address check
required by [RFC4213] applies.
A node receiving packets for a standards-defined automatic or
multipoint mechanism MUST apply that mechanism's role- and direction-
specific consistency checks. It MUST NOT substitute a static point-
to-point source-address rule when the mechanism explicitly permits
packets from a broader peer set.
Delivery-source validation SHOULD also use the receiving interface
and routing information where doing so is compatible with multihoming
and asymmetric routing. BCP 38 [RFC2827] and BCP 84 [RFC3704]
[RFC8704] describe applicable source-address validation techniques.
He, et al. Expires 4 March 2027 [Page 9]
Internet-Draft IP Tunnel Node Security August 2026
A packet that fails delivery-source, peer, or tunnel-policy
validation MUST be discarded before its passenger packet is admitted
to a forwarding or local-delivery path. Unless an applicable
specification requires an error, such a discard SHOULD be silent to
avoid reflection and information disclosure.
6.2. Passenger Source Validation
After each decapsulation step, the tunnel node MUST validate the
exposed passenger source address using the passenger address family's
validity rules and the authorized source-prefix set or other source
rule bound to the peer and tunnel policy. An authenticated delivery
packet does not exempt the passenger packet from this check.
If the passenger source is invalid or outside its authorized scope,
the packet MUST NOT be forwarded, re-encapsulated, reflected, or
delivered to a local service. The packet MUST be discarded unless an
applicable protocol specification requires a different action.
Before encapsulating a packet received from another node, a tunnel
ingress MUST apply source-address validation appropriate to the
passenger forwarding domain. Operators SHOULD select strict,
feasible-path, enhanced feasible-path, access-list, or equivalent
validation according to the routing properties of the deployment.
Strict uRPF SHOULD NOT be used where legitimate multihoming or
asymmetry would cause unacceptable false drops.
6.3. Destination, Local-Delivery, and Forwarding-Scope Validation
Before locally delivering or forwarding a decapsulated packet, a
tunnel node MUST verify that the passenger destination, passenger
protocol, requested disposition, and destination forwarding domain
are permitted by the tunnel policy. A forwarding domain or tenant
context MUST NOT be selected solely from an unauthenticated packet
field.
A tunnel node MUST NOT provide arbitrary transit merely because a
delivery packet reached an enabled tunnel endpoint. A node
intentionally providing transit MUST explicitly configure the
authorized peer class, passenger source scope, passenger destination
scope, and destination forwarding domain for that service.
Policy that depends on passenger fields MUST be applied at the first
processing depth at which those fields are visible. If a later
decapsulation step exposes a new passenger packet or new policy
selectors, the node MUST perform a new authorization decision.
Authorization of a carrier packet MUST NOT be inherited as
authorization of a newly exposed passenger flow.
He, et al. Expires 4 March 2027 [Page 10]
Internet-Draft IP Tunnel Node Security August 2026
7. Nested and Recursive Tunneling
A tunnel node that supports more than one local decapsulation step
MUST maintain the decapsulation depth and selected policy chain for
the packet. It MUST perform another decapsulation only when the
exposed packet matches an explicitly configured next tunnel policy.
Recognition of an IP protocol number or GRE header alone is not
sufficient authorization for the next step.
An implementation MUST provide a configurable upper bound on local
decapsulation depth and on the work performed for a nested packet. A
packet that exceeds either bound MUST be discarded. The bounds MUST
be applied across fast and slow paths and MUST NOT be reset by a
local forwarding-domain or interface transition.
For IPv6 tunnel encapsulation, an implementation MUST process the
Tunnel Encapsulation Limit option as specified in Section 4.1.1 of
[RFC2473]. In particular, a tunnel ingress examines an existing
option, rejects a zero limit with the specified ICMPv6 Parameter
Problem behavior, decrements a nonzero limit when adding an
encapsulation, and inserts a configured limit when required. A local
decapsulation-depth limit complements, but does not replace, this on-
wire mechanism.
Implementations MUST prevent loopback and routing-loop encapsulation.
IP-in-IP implementations MUST follow the routing failure checks in
[RFC2003], and IPv6 tunnel implementations SHOULD implement the
configuration and packet checks in Sections 4.1.2 and 4.1.3 of
[RFC2473]. Automatic re-encapsulation of a decapsulated packet MUST
be disabled unless an explicit route and tunnel policy authorize it.
Peer authorization, passenger source validation, destination and
forwarding-scope validation, extension-header policy, and resource
accounting MUST be applied independently at every applicable layer.
8. IPv6 Extension Headers and Fragmentation Policy
Decapsulation can expose an IPv6 header chain that was not visible to
devices on the delivery path. A tunnel node MUST therefore apply any
configured passenger IPv6 policy after each decapsulation and before
local delivery, forwarding, or re-encapsulation. The policy and
parser MUST conform to [RFC8200] and [RFC7045].
He, et al. Expires 4 March 2027 [Page 11]
Internet-Draft IP Tunnel Node Security August 2026
Decapsulation by itself is not justification for a blanket discard of
packets containing standard IPv6 extension headers. Consistent with
[RFC7045], a forwarding node that operates as a firewall MUST discard
a packet containing a standard extension header only as the result of
an intentionally configured policy and MUST be capable of permitting
standard extension headers when configured to do so.
If a configured policy requires an upper-layer selector, the tunnel
node MUST parse the IPv6 header chain far enough to locate that
selector or determine that it is unavailable. It MUST NOT treat an
unavailable selector as an implicit match for an allow rule. The
node MAY discard the packet or send it to a resource-limited
inspection path. The operational tradeoffs of these choices are
described in [RFC9098].
Implementations MUST provide configurable processing limits for IPv6
header-chain length, parsing work, and slow-path admission. Such
limits are resource controls, not permission to process standard
extension headers contrary to [RFC7045]. A node that cannot enforce
its configured policy within the limit MUST fail closed for that
policy decision.
Routing Header Type 0 MUST be rejected as specified by [RFC5095].
Segment Routing Header processing and SR domain-boundary filtering
MUST follow [RFC8754]. Other routing-header types MUST be handled
according to their defining specifications and configured policy.
IPv6 fragmentation and reassembly MUST follow [RFC8200]. A First
Fragment that does not contain the complete IPv6 header chain is
handled as specified by [RFC7112]. If fragmentation prevents
enforcement of a configured policy, the tunnel node MUST either
perform validated, resource-bounded reassembly or discard the
fragments associated with that policy decision. It MUST NOT admit
later fragments as a means of bypassing a decision made on the First
Fragment.
9. Protocol-Specific Requirements
9.1. IP-in-IP and IPv6 Tunneling
For IP-in-IP [RFC2003] and IPv6 tunneling [RFC2473], a packet using
IP protocol number 4 or 41 MUST NOT be decapsulated merely because it
is addressed to a local IP address. It MUST match an enabled tunnel
policy and the delivery-source and peer checks for that policy.
The TTL in an IPv4 passenger header is decremented during
encapsulation when encapsulation is performed as part of forwarding,
but it is not changed merely by decapsulation, as specified in
He, et al. Expires 4 March 2027 [Page 12]
Internet-Draft IP Tunnel Node Security August 2026
[RFC2003]. The analogous passenger Hop Limit or TTL processing for
IPv6 delivery tunnels is specified by [RFC2473]. Subsequent
forwarding performs the normal decrement for the passenger protocol.
An implementation MUST NOT add an extra decrement solely because a
packet was decapsulated.
9.2. GRE and GRE over IPv6
GRE implementations MUST validate GRE header fields according to
[RFC2784] and, when implemented, the Key and Sequence Number
extensions according to [RFC2890]. GRE over IPv6 implementations
MUST also follow [RFC7676].
A tunnel node MUST complete the applicable delivery-peer check before
using a GRE Key or passenger Protocol Type to select a forwarding
domain. A GRE Key MAY select a tunnel policy, tenant, or virtual
routing table, but it does not remove the requirement to authorize
the peer and passenger packet as described in Section 5.
A GRE policy MUST enumerate the permitted passenger Protocol Types
and MUST define source, destination, and forwarding-scope rules for
every enabled IP passenger address family. Unknown or unauthorized
passenger Protocol Types MUST be discarded.
9.3. Configured IPv4/IPv6 Transition Tunnels
A configured IPv6-over-IPv4 tunnel MUST perform the delivery IPv4
source-address and passenger IPv6 validity checks specified in
Section 3.6 of [RFC4213]. The configured delivery peer MUST also be
bound to the passenger prefixes and forwarding scope that it is
authorized to inject.
Cross-protocol encapsulation MUST NOT bypass source-address
validation for either address family. Operators SHOULD audit IPv4
and IPv6 policy together because the delivery and passenger
forwarding paths can be administered by different systems.
9.4. 6to4
6to4 [RFC3056] is an automatic multipoint mechanism; its authorized
delivery-peer set cannot be modeled as a single configured peer. A
6to4 router or relay that remains enabled MUST perform all role- and
direction-applicable encapsulation, decapsulation, and address sanity
checks in Section 5 of [RFC3964]. The implementation MUST apply the
exact role-specific rules rather than a generalized equality test
between every delivery and passenger address.
He, et al. Expires 4 March 2027 [Page 13]
Internet-Draft IP Tunnel Node Security August 2026
As required by [RFC7526], anycast 6to4 and unicast 6to4 in hosts, and
6to4 in routers, MUST be disabled by default. Enabling IPv6
forwarding MUST NOT automatically enable 6to4. The basic unicast
6to4 mechanism and 2002::/16 are not themselves deprecated by
[RFC7526]; the anycast relay mechanism and 192.88.99.1 are
deprecated.
A 6to4 relay service MUST be deliberately configured, monitored, and
rate limited. Its forwarding behavior MUST be restricted by the
checks in [RFC3964] and by the role-specific service policy; it MUST
NOT be treated as an authenticated point-to-point tunnel.
10. ICMP, TTL, Hop Limit, MTU, and Fragmentation
10.1. TTL and Hop Limit
A tunnel node MUST follow the TTL and Hop Limit rules in the
applicable delivery, passenger, and tunnel specifications.
Decapsulation alone MUST NOT cause an additional passenger TTL or Hop
Limit decrement. If the exposed packet is subsequently forwarded,
normal passenger-protocol forwarding rules apply.
10.2. ICMP Generation and Processing
ICMP and ICMPv6 errors generated or relayed by a tunnel node MUST
follow the applicable requirements of [RFC1812], [RFC4443], and the
tunnel specification. Error generation MUST be rate limited. A
security-policy discard SHOULD be silent unless an applicable
specification requires an error or an operator deliberately enables
one.
A tunnel node MUST NOT generate an error to a passenger source that
failed passenger-source validation. It MUST NOT generate a response
to a delivery source that failed peer or delivery-source validation
unless a protocol-specific requirement applies and the response is
safe under the deployment's reflection threat model.
Before an incoming ICMP or ICMPv6 error changes tunnel PMTU,
reachability, or other forwarding state, the tunnel ingress MUST
validate that the quoted packet and available context identify an
active tunnel and a packet that the node could have sent. Unmatched
or insufficiently quoted errors MUST NOT update tunnel state.
Accepted updates SHOULD be scoped to the identified tunnel and SHOULD
have bounded lifetimes. Examples of forged ICMP attacks and
validation techniques for TCP are discussed in [RFC5927].
He, et al. Expires 4 March 2027 [Page 14]
Internet-Draft IP Tunnel Node Security August 2026
10.3. MTU and Path MTU Discovery
A tunnel ingress MUST account for encapsulation overhead and MUST
implement the MTU, fragmentation, and ICMP translation or relay
behavior required by its tunnel specification. Relevant procedures
are specified by [RFC2003], [RFC2473], [RFC4213], and [RFC7676]. The
operational tradeoffs for in-the-network tunneling are described in
[RFC4459].
IPv4 Path MTU Discovery is specified by [RFC1191], and IPv6 Path MTU
Discovery is specified by [RFC8201]. A tunnel implementation using
these mechanisms MUST follow the applicable specification together
with the ICMP handling rules of its tunnel protocol.
An implementation MUST NOT use a reported PMTU outside the bounds
permitted by the applicable IP and tunnel specifications. It SHOULD
expose accepted and rejected PMTU updates through counters.
Packetization Layer PMTUD [RFC8899] MAY be used where supported by
the packetization layer and deployment.
10.4. Fragmentation and Reassembly Resources
Fragmentation MUST NOT be used to bypass delivery-peer or passenger
policy. Where a tunnel specification requires delivery-packet
reassembly at an egress, the egress MUST perform that reassembly
before decapsulation and MUST apply the reassembly rules of the
delivery IP version.
Reassembly and fragment-tracking state MUST be bounded per source or
peer, per tunnel, and globally. Implementations MUST bound at least
the number of incomplete datagrams, bytes retained, fragment count
per datagram, and retention time. When resources are exhausted, the
node MUST fail closed for packets that require reassembly or fragment
state to complete authorization.
Operators and implementers SHOULD avoid fragmentation where a
compliant MTU or PMTUD strategy is available. The fragility and
denial-of-service implications of IP fragmentation are described in
BCP 230 [RFC8900].
11. Resource-Exhaustion Controls
Tunnel nodes MUST provide independent, configurable limits for work
performed before peer authorization and work performed after peer
authorization. An unauthorized source MUST NOT be able to consume an
unbounded amount of decapsulation, parsing, reassembly,
cryptographic, ICMP-generation, logging, or control-plane work.
He, et al. Expires 4 March 2027 [Page 15]
Internet-Draft IP Tunnel Node Security August 2026
Implementations MUST support limits for at least:
* candidate tunnel packets and bytes per peer or source class and
per tunnel;
* nested decapsulation depth and total parsing work per packet;
* fragment-tracking and reassembly state;
* IPv6 extension-header slow-path or inspection admission;
* ICMP and ICMPv6 generation and accepted state updates; and
* log generation and telemetry export.
Resource exhaustion MUST NOT cause the implementation to bypass a
mandatory authorization or validation step. Implementations SHOULD
isolate management and routing-control traffic from data-plane tunnel
processing and SHOULD provide a bounded recovery path after a limit
is reached.
12. Operational Management and Telemetry
Operators deploying tunnel nodes SHOULD:
* inventory enabled tunnel mechanisms, endpoint addresses, peer
identities, and passenger forwarding domains;
* disable unused tunnel mechanisms on hosts, borders, and
intermediate systems;
* bind every configured peer or peer class to explicit passenger and
forwarding scopes;
* review IPv4 and IPv6 source-validation policy together for cross-
protocol tunnels;
* configure and test nested-tunnel, extension-header, fragment,
ICMP, PMTU, and resource limits;
* protect tunnel configuration and telemetry using access control
and authenticated management channels; and
* periodically verify, using authorized testing, that tunnel nodes
do not provide unintended local delivery, transit, or re-
encapsulation.
A tunnel node MUST provide counters for at least:
He, et al. Expires 4 March 2027 [Page 16]
Internet-Draft IP Tunnel Node Security August 2026
* packets and bytes accepted by tunnel policy and resulting
disposition;
* unknown or disabled tunnel mechanisms;
* delivery-source, receiving-context, peer-authentication, and
replay failures;
* passenger source, destination, protocol, local-delivery, and
forwarding-scope failures;
* nested-policy and decapsulation-depth failures;
* IPv6 extension-header, fragment, reassembly, and resource-limit
failures;
* ICMP or ICMPv6 errors generated, rate limited, accepted for state
update, and rejected; and
* PMTU updates accepted and rejected.
Implementations SHOULD support rate-limited, sampled event logging.
When available, a log entry SHOULD identify the tunnel policy and
version, receiving context, decapsulation depth, peer or peer class,
delivery and passenger address families, disposition, and specific
failure reason. Logs SHOULD NOT contain passenger payload and SHOULD
minimize capture of headers not needed for diagnosis.
Tunnel configuration changes and authenticated control-plane changes
that alter peer or passenger authorization SHOULD be auditable.
Telemetry loss SHOULD be reported, but it MUST NOT weaken packet
authorization.
13. IANA Considerations
This document has no IANA actions.
14. Security Considerations
This entire document specifies security requirements. The principal
threats are unauthorized tunnel use, forged delivery or passenger
source addresses, unintended local delivery or transit, forwarding-
domain confusion, policy bypass at a decapsulation boundary,
recursive or looping encapsulation, extension-header or fragment
evasion, forged ICMP state changes, and exhaustion of parsing,
reassembly, cryptographic, control-plane, or logging resources.
He, et al. Expires 4 March 2027 [Page 17]
Internet-Draft IP Tunnel Node Security August 2026
The requirements reduce these threats by binding an authorized peer
and delivery context to permitted passenger traffic and disposition,
applying policy at every visibility and decapsulation boundary,
bounding work, and making security-relevant outcomes observable.
They do not prove that a tunnel is safe for every deployment.
Address-based peer authorization remains vulnerable where an attacker
can spoof a permitted delivery source. Cryptographic peer
authentication reduces that risk but does not authorize arbitrary
passenger traffic. Conversely, passenger source validation does not
authenticate the delivery peer. Deployments requiring both
properties need both controls.
A compromised authorized peer can still send harmful traffic within
its assigned passenger and forwarding scope. An encrypted passenger
may prevent a tunnel node from applying upper-layer policy; an
operator MUST either rely on an authorized endpoint that can enforce
that policy or restrict the encrypted traffic to a scope where the
missing visibility is acceptable. Resource limits reduce but do not
eliminate denial-of-service risk.
Incorrect source-prefix, destination-scope, interface, or uRPF
configuration can cause either unauthorized acceptance or legitimate
traffic loss, particularly with multihoming, mobility, and asymmetric
routing. Operators need change control and tests that cover both
security failure and legitimate reachability.
Tunnel telemetry can reveal customer prefixes, peer relationships,
forwarding domains, policy, and traffic patterns. Implementations
and operators SHOULD restrict access, minimize collection, protect
export, define retention limits, and aggregate or pseudonymize data
when exact identifiers are not required. Measurement results that
identify source-validation gaps SHOULD be handled as sensitive
operational security information.
15. Contributors
The following individuals contributed to this document:
Daguo Cheng
Tsinghua University
Beijing
China
Email: cdg22@mails.tsinghua.edu.cn
He, et al. Expires 4 March 2027 [Page 18]
Internet-Draft IP Tunnel Node Security August 2026
Chentian Wei
Tsinghua University
Beijing
China
Email: wct24@mails.tsinghua.edu.cn
16. Acknowledgments
The authors thank the IETF community for prior work on IP tunneling,
source-address validation, IPv6 extension-header processing, and
operational security guidance.
17. References
17.1. Normative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<https://www.rfc-editor.org/info/rfc1812>.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
DOI 10.17487/RFC2003, October 1996,
<https://www.rfc-editor.org/info/rfc2003>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <https://www.rfc-editor.org/info/rfc2827>.
He, et al. Expires 4 March 2027 [Page 19]
Internet-Draft IP Tunnel Node Security August 2026
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004,
<https://www.rfc-editor.org/info/rfc3964>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213,
DOI 10.17487/RFC4213, October 2005,
<https://www.rfc-editor.org/info/rfc4213>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<https://www.rfc-editor.org/info/rfc7045>.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112,
DOI 10.17487/RFC7112, January 2014,
<https://www.rfc-editor.org/info/rfc7112>.
[RFC7526] Troan, O. and B. Carpenter, Ed., "Deprecating the Anycast
Prefix for 6to4 Relay Routers", BCP 196, RFC 7526,
DOI 10.17487/RFC7526, May 2015,
<https://www.rfc-editor.org/info/rfc7526>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015,
<https://www.rfc-editor.org/info/rfc7676>.
He, et al. Expires 4 March 2027 [Page 20]
Internet-Draft IP Tunnel Node Security August 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced
Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
RFC 8704, DOI 10.17487/RFC8704, February 2020,
<https://www.rfc-editor.org/info/rfc8704>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
17.2. Informative References
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April
2006, <https://www.rfc-editor.org/info/rfc4459>.
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC 4891, DOI 10.17487/RFC4891, May 2007,
<https://www.rfc-editor.org/info/rfc4891>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010,
<https://www.rfc-editor.org/info/rfc5927>.
He, et al. Expires 4 March 2027 [Page 21]
Internet-Draft IP Tunnel Node Security August 2026
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169,
DOI 10.17487/RFC6169, April 2011,
<https://www.rfc-editor.org/info/rfc6169>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
Changes from -00
* Added an explicit threat model, trust boundaries, security
objectives, and exclusions.
* Clarified scope and the precedence of protocol-specific processing
rules.
* Separated peer authentication from delivery- and passenger-packet
authorization.
* Corrected nested and recursive encapsulation terminology and
aligned limits with RFC 2473.
* Aligned IPv6 extension-header policy with RFC 7045 and added
fragment-policy requirements.
* Expanded protocol-specific requirements for IP-in-IP, GRE,
configured transition tunnels, and 6to4.
* Reworked TTL, Hop Limit, ICMP, PMTU, fragmentation, and reassembly
requirements to defer to the applicable RFCs.
* Added explicit resource-exhaustion controls and expanded
operational telemetry.
* Added and corrected RFC references, including RFCs 1191, 2890,
4301, 4459, 6169, 7112, 7526, 8201, 8754, 8899, and 8900.
He, et al. Expires 4 March 2027 [Page 22]
Internet-Draft IP Tunnel Node Security August 2026
Authors' Addresses
Lin He
Tsinghua University
Beijing
China
Email: he-lin@tsinghua.edu.cn
Le Gai
Tsinghua University
Beijing
China
Email: gl25@mails.tsinghua.edu.cn
Zedong Jia
Tsinghua University
Beijing
China
Email: jzd25@mails.tsinghua.edu.cn
Ying Liu
Tsinghua University
Beijing
China
Email: liuying@cernet.edu.cn
He, et al. Expires 4 March 2027 [Page 23]