RFC 4891
Using IPsec to Secure IPv6-in-IPv4 Tunnels
RFC 4891: Using IPsec to Secure IPv6-in-IPv4 Tunnels 🎀
okay bestie, RFC 4891 is from the Network Working Group and it's labeled Informational (so it's guidance, not a standard ✨). It came out in May 2007. The authors are R. Graveman (RFG Security, LLC), M. Parthasarathy (Nokia), P. Savola (CSC/FUNET), and H. Tschofenig (Nokia Siemens Networks). The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own 💅
Status of This Memo 🌸
This memo gives information to the Internet community. It isn't an Internet standard of any kind, and distribution of it is unlimited.
Copyright Notice 🧚
Copyright (C) The IETF Trust (2007).
Abstract 💖
This doc explains how to lock down manually configured IPv6-in-IPv4 tunnels with IPsec, specifically in transport mode. It doesn't describe any new protocol extensions beyond what the IPsec framework already has.
Table of Contents 📖
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3
2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4
2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5
3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5
3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 6
3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6
3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8
4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 9
5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 10
5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 11
5.2. Peer Authorization Database and Identities . . . . . . . . 12
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 17
A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 17
A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18
A.3. Specific SPD for Host-to-Router Scenario . . . . . . . . . 19
Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 20
B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 20
B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 20
B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 211. Introduction ✨
The IPv6 Operations (v6ops) working group picked (manually configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6 transition mechanisms for rolling out IPv6.
[RFC4213] pointed out a bunch of threats that weren't properly analyzed or handled in its predecessor, [RFC2893]. The most complete fix is to use IPsec to protect IPv6-in-IPv4 tunneling. The document didn't go into detail on how to set up an interoperable IPsec-protected tunnel. Instead, that detail was saved for this memo, so it's giving "part two energy" 🫶
The first four sections of this doc look at the threats and scenarios IPsec can address, plus the assumptions this document makes for a successful IPsec Security Association (SA) setup. Section 5 covers the details of the Internet Key Exchange (IKE) and IP security (IPsec) exchange, including packet formats and Security Policy Database (SPD) entries. Section 6 has the recommendations. The appendices go deeper on tunnel mode and optional extensions.
This document doesn't cover IPsec for tunnels that aren't manually configured (for example, 6to4 tunnels [RFC3056]). Presumably some form of opportunistic encryption or "better-than-nothing security" might or might not work there. Propagating quality-of-service attributes from the encapsulated packets to the tunnel path is also out of scope, except for the Explicit Congestion Notification bits [RFC4213] 🦋
When this doc says "interface" or "IP interface," it means the IPv6 interface that every IPv6 node has to have in order to send or receive IPv6 packets. "Tunnel interface" means the interface that receives the IPv6-in-IPv4 tunneled packets over IPv4.
2. Threats and the Use of IPsec 😭
[RFC4213] is mostly worried about address spoofing threats:
- The IPv4 source address of the encapsulating ("outer") packet can be spoofed.
- The IPv6 source address of the encapsulated ("inner") packet can be spoofed.
Threat (1) exists because IPv4 ingress filtering [RFC3704] isn't universally deployed. Threat (2) exists because the IPv6 packet is wrapped in IPv4, so it can slip past IPv6 ingress filtering. [RFC4213] lists these strict address checks as mitigations:
- To mitigate threat (1), the decapsulator checks that the IPv4 source address of the packet is the same as the address of the configured tunnel endpoint. The decapsulator may also implement IPv4 ingress filtering, meaning it checks whether the packet arrived on a legit interface.
- To mitigate threat (2), the decapsulator checks whether the inner IPv6 address is a valid IPv6 address and also applies IPv6 ingress filtering before it accepts the IPv6 packet.
This memo proposes using IPsec for stronger protection against these threats. On top of that, IPsec gives you integrity, confidentiality, replay protection, and origin protection between tunnel endpoints. 🔥
IPsec can be used in two ways, transport mode and tunnel mode. Section 5 has the detailed discussion of how each one applies here.
2.1. IPsec in Transport Mode 💅
In transport mode, an IPsec Encapsulating Security Payload (ESP) or Authentication Header (AH) security association (SA) is set up to protect traffic defined by (IPv4-source, IPv4-dest, protocol = 41). When the receiver gets one of these IPsec packets, it first applies the IPsec transform (for example, ESP). Then it matches the packet against the Security Parameter Index (SPI) and the inbound selectors tied to the SA, to confirm the packet is right for the SA it came in on. If that check passes, it means the packet came from the right IPv4 endpoint, because the SA is bound to the IPv4 source address.
This stops threat (1) but not threat (2). IPsec in transport mode doesn't verify the contents of the payload where the IPv6 addresses live. So two nodes using IPsec transport mode to secure the tunnel can still spoof the inner payload. The packet will get decapsulated successfully and accepted anyway 🙈
IPv6 ingress filtering can partially fix this shortcoming. You check that the packet is arriving from the interface in the direction of the route toward the tunnel endpoint, similar to a Strict Reverse Path Forwarding (RPF) check [RFC3704].
In most implementations, a transport mode SA gets applied to a normal IPv6-in-IPv4 tunnel. That means ingress filtering can be applied on the tunnel interface. (Transport mode is also used a lot with other kinds of tunnels, like Generic Routing Encapsulation (GRE) [RFC4023] and Layer 2 Tunneling Protocol (L2TP) [RFC3193].)
2.2. IPsec in Tunnel Mode 🧚
In tunnel mode, the IPsec SA is set up to protect traffic defined by (IPv6-source, IPv6-destination). When the receiver gets one of these IPsec packets, it first applies the IPsec transform (for example, ESP). Then it matches the packet against the SPI and the inbound selectors tied to the SA, to confirm the packet is right for the SA it came in on. A successful check means the packet came from the right endpoint.
The outer IPv4 addresses can be spoofed, and IPsec can't detect that in tunnel mode. Packets get demultiplexed based on the SPI and possibly the IPv6 address bound to the SA. So outer address spoofing doesn't matter as long as decryption succeeds and the inner IPv6 packet can be verified as coming from the right tunnel endpoint.
As Section 5 explains, tunnel mode is harder to set up than applying transport mode to a tunnel interface. Because of that, this document recommends transport mode. Even though transport mode is the recommendation, an IPv6-in-IPv4 tunnel specified by protocol 41 still exists [RFC4213] 🌈
3. Scenarios and Overview 🦋
There are roughly three scenarios:
- (Generic) router-to-router tunnels.
- Site-to-router or router-to-site tunnels. These are tunnels between a site's IPv6 (border) device and an IPv6 upstream provider's router. A degenerate case of a site is a single host.
- Host-to-host tunnels.
3.1. Router-to-Router Tunnels 🍓
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv4 forwarding topology by wrapping them inside IPv4 packets. Tunneling can be used in a bunch of different ways.
.--------. _----_ .--------.
|v6-in-v4| _( IPv4 )_ |v6-in-v4|
| Router | <======( Internet )=====> | Router |
| A | (_ _) | B |
'--------' '----' '--------'
^ IPsec tunnel between ^
| Router A and Router B |
V V
Figure 1: Router-to-Router Scenario.IPv6/IPv4 routers hooked up through an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel covers one segment of the end-to-end path the IPv6 packet takes. 💜
The source and destination addresses of the IPv6 packets crossing the tunnel could come from a wide range of IPv6 prefixes. So binding the IPv6 addresses to the SA isn't generally feasible. IPv6 ingress filtering must be performed to mitigate the IPv6 address spoofing threat. ⭐
A specific case of router-to-router tunnels, where one router sits at an end site, is covered in the next section 👑
3.2. Site-to-Router/Router-to-Site Tunnels 🎀
okay so this one is basically host-to-router and router-to-host tunneling's glow-up 💅 connecting a whole site (through a router) and connecting one single host have roughly the same issues, iykyk 🫶
_----_ .---------. IPsec _----_ IPsec .-------.
_( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |
( Internet )<--->| Router |<=======( Internet )=======>| Site B |
(_ _) | A | (_ _) '--------'
'----' '---------' '----'
^
|
V
.--------.
| Native |
| IPv6 |
| node |
'--------'Figure 2: Router-to-Site Scenario.
IPv6/IPv4 routers can tunnel IPv6 packets all the way to their final destination IPv6/IPv4 site ✨ this tunnel only covers the last segment of the end-to-end path, so it's giving last-mile energy 🦋
+---------------------+
| IPv6 Network |
| |
.--------. _----_ | .--------. |
| V6/V4 | _( IPv4 )_ | |v6-in-v4| |
| Site B |<====( Internet )==========>| Router | |
'--------' (_ _) | | A | |
'----' | '--------' |
IPsec tunnel between | ^ |
IPv6 Site and Router A | | |
| V |
| .-------. |
| | V6 | |
| | Hosts | |
| '--------' |
+---------------------+Figure 3: Site-to-Router Scenario.
In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable via an IPv4 infrastructure 🧚 this type of tunnel spans the first segment of the packet's end-to-end path.
The hosts in the site originate the packets with IPv6 source addresses coming from a well-known prefix, whereas the destination addresses could be any nodes on the Internet 🌈
In this case, an IPsec tunnel mode SA could be bound to the prefix that was allocated to the router at Site B, and Router A could verify that the source address of the packet matches the prefix. Site B will not be able to do a similar verification for the packets it receives 👀 This may be quite reasonable for most of the deployment cases, for example, an Internet Service Provider (ISP) allocating a /48 to a customer. The Customer Premises Equipment (CPE) where the tunnel is terminated "trusts" (in a weak sense) the ISP's router, and the ISP's router can verify that Site B is the only one that can originate packets within the /48 💖
IPv6 spoofing must be prevented, and setting up ingress filtering may require some amount of manual configuration; see more of these options in Section 5 🔥
3.3. Host-to-Host Tunnels 🍓
.--------. _----_ .--------.
| V6/V4 | _( IPv4 )_ | V6/V4 |
| Host | <======( Internet )=====> | Host |
| A | (_ _) | B |
'--------' '----' '--------'
IPsec tunnel between
Host A and Host BFigure 4: Host-to-Host Scenario.
IPv6/IPv4 hosts interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves 💜 in this case, the tunnel spans the entire end-to-end path, which is the whole vibe 👑
In this case, the source and the destination IPv6 addresses are known a priori. A tunnel mode SA could be bound to these specific addresses. Address verification prevents IPv6 source address spoofing completely 🙈
As noted in the Introduction, automatic host-to-host tunneling methods (e.g., 6to4) are out of scope for this memo 🚫
4. IKE and IPsec Versions 🧚
okay this section is the tea on the different versions of IKE and the IPsec security architecture, and how they apply to this document 📚
The IPsec security architecture was previously defined in [RFC2401] and is now superseded by [RFC4301]. IKE was originally defined in [RFC2409] (which is called IKEv1 in this document) and is now superseded by [RFC4306] (called IKEv2; see also [RFC4718]). There are several differences between them, and the ones that matter for this document are below 💅
- [RFC2401] does not require allowing IP as the next layer protocol in traffic selectors when an IPsec SA is negotiated. In contrast, [RFC4301] requires supporting IP as the next layer protocol (like TCP or UDP) in traffic selectors ✨
- [RFC4301] assumes IKEv2, as some of the new features cannot be negotiated using IKEv1 😭 it is valid to negotiate multiple traffic selectors for a given IPsec SA in [RFC4301]. This is possible only with IKEv2. If IKEv1 is used, then multiple SAs need to be set up, one for each traffic selector.
Note that the existing implementations based on IKEv1 may already be able to support the [RFC4301] features described in (1) and (2). If appropriate, the deployment may choose to use either version of the security architecture 🌸
IKEv2 supports features useful for configuring and securing tunnels that are not present with IKEv1 🎀
- IKEv2 supports legacy authentication methods by carrying them in Extensible Authentication Protocol (EAP) payloads. This can be used to authenticate hosts or sites to an ISP using EAP methods that support username and password.
- IKEv2 supports dynamic address configuration, which may be used to configure the IPv6 address of the host.
Network Address Translation (NAT) traversal works with both the old and revised IPsec architectures, but the negotiation is integrated with IKEv2 🦋
For the purposes of this document, where the confidentiality of ESP [RFC4303] is not required, AH [RFC4302] can be used as an alternative to ESP. The main difference is that AH is able to provide integrity protection for certain fields in the outer IPv4 header and IPv4 options. However, as the outer IPv4 header will be discarded in any case, and those particular fields are not believed to be relevant in this particular application, there is no particular reason to use AH 🙄
5. IPsec Configuration Details 🔐
this section walks through the SPD entries for setting up the IPsec transport mode SA that protects the IPv6 traffic, and it's giving "read this carefully" energy 🫶
Several requirements arise when IPsec is used to protect the IPv6 traffic (inner header) for the scenarios listed in Section 3 💖
- All of IPv6 traffic should be protected, including link-local (e.g., Neighbor Discovery) and multicast traffic. Without this, an attacker can pollute the IPv6 neighbor cache causing disruption in communication between the two routers 😱
- In router-to-router tunnels, the source and destination addresses of the traffic could come from a wide range of prefixes that are normally learned through routing. As routing can always learn a new prefix, one cannot assume that all the prefixes are known a priori [RFC3884]. This mainly affects scenario (1).
- Source address selection depends on the notions of routes and interfaces. This implies that the reachability to the various IPv6 destinations appear as routes in the routing table. This affects scenarios (2) and (3).
The IPv6 traffic can be protected using transport or tunnel mode. There are many problems when using tunnel mode, as implementations may or may not model the IPsec tunnel mode SA as an interface as described in Appendix A.1 🤔
If IPsec tunnel mode SA is not modeled as an interface (e.g., as of this writing, popular in many open source implementations), the SPD entries for protecting all traffic between the two endpoints must be described. Evaluating against the requirements above, all link-local traffic multicast traffic would need to be identified, possibly resulting in a long list of SPD entries. The second requirement is difficult to satisfy, because the traffic needing protection is not necessarily (e.g., router-to-router tunnel) known a priori [RFC3884]. The third requirement is also problematic, because almost all implementations assume addresses are assigned on interfaces (rather than configured in SPDs) for proper source address selection 😩
If the IPsec tunnel mode SA is modeled as interface, the traffic that needs protection can be modeled as routes pointing to the interface. But the second requirement is difficult to satisfy, because the traffic needing protection is not necessarily known a priori. The third requirement is easily solved, because IPsec is modeled as an interface ✨
In practice, (2) has been solved by protecting all the traffic (::/0), but no interoperable implementations support this feature. For a detailed list of issues pertaining to this, see [VLINK] 🌈
Because applying transport mode to protect a tunnel is a much simpler solution and also easily protects link-local and multicast traffic, we do not recommend using tunnel mode in this context. Tunnel mode is, however, discussed further in Appendix A 💅
This document assumes that tunnels are manually configured on both sides and the ingress filtering is manually set up to discard spoofed packets 🎀
5.1. IPsec Transport Mode ✨
okay so transport mode is usually the go-to for L2TP, GRE, and other tunneling methods 🎀, especially when you wanna tunnel non-IP traffic 🫶. [RFC3884], [RFC3193], and [RFC4023] are literally examples of using transport mode to protect tunnel traffic that only covers part of an end-to-end path 🦋.
IPv6 ingress filtering MUST be applied on the tunnel interface on all the packets that pass the inbound IPsec processing 💅.
The SPD entries below assume there are two routers, Router1 and Router2, with tunnel endpoint IPv4 addresses IPV4-TEP1 and IPV4-TEP2, respectively. (In other scenarios, the SPDs get set up similarly 🌸.)
Router1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS
2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS
3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport)
Router2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS
2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS
3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport)In both SPD entries, "IKE" means UDP destination port 500, and possibly port 4500 too if NAT traversal is being used 🧚.
The packet format is shown in Table 1 ✨.
+----------------------------+------------------------------------+
| Components (first to last) | Contains |
+----------------------------+------------------------------------+
| IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) |
| ESP header | |
| IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | |
+----------------------------+------------------------------------+
Table 1: Packet Format for IPv6/IPv4 Tunnels.The IDci and IDcr payloads of IKEv1 carry IPV4-TEP1, IPV4-TEP2, and protocol value 41 as phase 2 identities. With IKEv2, the traffic selectors carry that same info 💜.
5.2. Peer Authorization Database and Identities
The Peer Authorization Database (PAD) is the link between the SPD and the key management daemon [RFC4306] 🔗. It's defined in [RFC4301], so it's only relevant when you're using IKEv2 🦋.
There's currently no defined way to discover the PAD-related parameters dynamically, so these get manually configured 🛠️:
- The Identity of the peer asserted in the IKEv2 exchange: there are lots of identity types you can use. At least, the IPv4 address of the peer SHOULD be supported.
- IKEv2 can authenticate the peer with several methods. Pre-shared key and X.509 certificate-based authentication are REQUIRED by [RFC4301]. At least, pre-shared key SHOULD be supported, because it interoperates with a larger number of implementations 👑.
- The child SA authorization data SHOULD contain the IPv4 address of the peer.
IPv4 address SHOULD be supported as Identity during the key exchange. Since this doesn't give you Identity protection, main mode or aggressive mode can be used with IKEv1 🙈.
6. Recommendations ✨
In Section 5, we looked at the differences between setting up an IPsec IPv6-in-IPv4 tunnel with transport mode versus tunnel mode 💅. We observe that applying transport mode to a tunnel interface is the simplest and therefore recommended solution 🔥.
In Appendix A, we also explore what it would take to use the so-called Specific SPD (SSPD) tunnel mode 🧐. It's way more complicated because IPv6 prefixes need to be known a priori, and multicast and link-local traffic do not work over such a tunnel 💀. Fragment handling in tunnel mode is also harder. However, because the Mobility and Multihoming Protocol (MOBIKE) [RFC4555] supports only tunnel mode, when the IPv4 endpoints of a tunnel are dynamic and the other constraints don't apply, using tunnel mode may be an acceptable solution 🦋.
So our main recommendation is to use transport mode applied to a tunnel interface 🎀. Source address spoofing can be limited by enabling ingress filtering on the tunnel interface 🛡️.
Manual keying MUST NOT be used, bestie 🚫. Large amounts of IPv6 traffic may be carried over the tunnels, and doing so would make it easier for an attacker to recover the keys 😭. IKEv1 or IKEv2 MUST be used for establishing the IPsec SAs. IKEv2 SHOULD be used where supported and available; if not, IKEv1 MAY be used instead 🫶.
7. Security Considerations ✨😭
When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it's possible to "inject" packets into the tunnel by spoofing the source address (data plane security). If the tunnel is signaled somehow (e.g., using an authentication protocol and obtaining a static v6 prefix), someone might be able to spoof the signaling (control plane security) 💀.
The IPsec framework plays a huge role in adding security to both the tunnel setup protocol and the data traffic 🔐.
Either IKEv1 or IKEv2 provides a secure signaling protocol for establishing, maintaining, and deleting an IPsec tunnel 👑.
IPsec, with ESP, offers integrity and data origin authentication, confidentiality, and OPTIONAL (at the discretion of the receiver) anti-replay features. Using confidentiality without integrity is discouraged 🙅. ESP also provides limited traffic flow confidentiality 🫣.
IPsec provides access control through the distribution of keys, and also through the application of policies dictated by the Security Policy Database (SPD) 🚪.
The NAT traversal mechanism provided by IKEv2 introduces some weaknesses into IKE and IPsec 😬. These issues are discussed in more detail in [RFC4306].
Please note that using IPsec for the scenarios described in Figures 1, 2, and 3 does not aim to protect the end-to-end communication. It protects just the tunnel part. It's still possible for an IPv6 endpoint that isn't attached to the IPsec tunnel to spoof packets 🙈.
8. Contributors ✨
The authors are listed in alphabetical order 💖.
Suresh Satapati also participated in the initial discussions on this topic 🧚.
9. Acknowledgments ✨
The authors would like to thank Stephen Kent, Michael Richardson, Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred Hoenes, Francis Dupont, and David Black for their substantive feedback 🫶🌈.
We would also like to thank Pasi Eronen for his text contributions and suggestions for improvement 💜.
10. References ✨
10.1. Normative References
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
- [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
- [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
10.2. Informative References
- [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
- [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
- [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
- [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004.
- [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
- [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
- [TUNN-AD] Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005.
- [VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links for PPVPNs", Work in Progress, October 2002.
Appendix A. Using Tunnel Mode ✨
First, we describe the different tunnel mode implementation methods 🧁. In this context, only the so-called Specific SPD (SSPD) model (without a tunnel interface) can be made to work, but it has reduced applicability, so the use of a transport mode tunnel is recommended instead 💅. We'll still describe how the SSPD tunnel mode might look if you'd like to use it anyway 🌈.
A.1. Tunnel Mode Implementation Methods
okay so tunnel mode could (in theory) be deployed in two very different ways, depending on the implementation 🧚
- "Generic SPDs" 🌈: some implementations model the tunnel mode SA as an IP interface. An IPsec tunnel interface gets created and used with "any" addresses (
"::/0 <-> ::/0") as IPsec traffic selectors while the SA is being set up. This lets all traffic between the two nodes get protected by IPsec, but the routing table decides what traffic actually goes over the tunnel. Ingress filtering must be applied separately on the tunnel interface, because the IPsec policy checks don't look at the IPv6 addresses at all. Routing protocols, multicast, etc. will work through this tunnel. This mode is similar to transport mode. The SPDs must be interface-specific. However, because IKE uses IPv4 but the tunnel is IPv6, there's no standard way to map the IPv4 interface to the IPv6 interface [VLINK], so this approach is not feasible 😭 - "Specific SPDs" 💅: some implementations don't model the tunnel mode SA as an IP interface. Traffic selection is based on specific SPD entries, e.g.,
2001:db8:1::/48 <-> 2001:db8:2::/48. Because the IPsec session between two endpoints doesn't have an interface (though an implementation may have a common pseudo-interface for all IPsec traffic), there's no Duplicate Address Detection (DAD), Multicast Listener Discovery (MLD), or link-local traffic to protect, and multicast is not possible over such a tunnel. Ingress filtering is performed automatically by the IPsec traffic selectors 🔥
Ingress filtering is guaranteed by IPsec processing when option (2) is chosen, whereas the operator has to enable it explicitly when transport mode or option (1) is chosen.
In summary, there doesn't appear to be a standard solution in this context for the first implementation approach 🙈
The second approach can be made to work, but it's only applicable in host-to-host or site-to-router/router-to-site scenarios (i.e., when the IPv6 prefixes can be known a priori). It also offers only a limited set of features (e.g., no multicast) compared with a transport mode tunnel ✨
When tunnel mode is used, fragment handling [RFC4301] may also be more difficult compared with transport mode and, depending on the implementation, may need to be reflected in SPDs.
A.2. Specific SPD for Host-to-Host Scenario
bestie, this one's a host-to-host example 🎀 It assumes there are two hosts, Host1 and Host2, whose IPv6 addresses are denoted IPV6-EP1 and IPV6-EP2 (global addresses). The IPv4 addresses of the tunnel endpoints are denoted IPV4-TEP1 and IPV4-TEP2, respectively.
Host1's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})Host2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP,
tunnel{IPV4-TEP2,IPV4-TEP1})"IKE" refers to UDP destination port 500 and possibly also port 4500 if NAT traversal is used.
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 as phase 2 identities. With IKEv2, the traffic selectors are used to carry the same information 💖
A.3. Specific SPD for Host-to-Router Scenario
this one's the host-to-router version 🦋 It assumes the host has the IPv6 address IPV6-EP1, and that the tunnel endpoints of the host and router are IPV4-TEP1 and IPV4-TEP2, respectively. If the tunnel is between a router and a host, and the router has allocated an IPV6-PREF/48 to the host, the matching SPD entries can be derived by replacing IPV6-EP1 with IPV6-PREF/48.
Please note the bypass entry for the host's SPD, which is absent in the router's SPD. While this might be an implementation matter for host-to-router tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6-PREF/48", is critical for site-to-router tunneling 👑
Host's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPV6-EP1 IPV6-EP1 ANY BYPASS
4 IPV6-EP1 ANY ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})Router's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 ANY IPV6-EP1 ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as their phase 2 identities. The starting address is zero and the end address is all ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With IKEv2, the traffic selectors are used to carry the same information 🧚
Appendix B. Optional Features
okay, these are the extras that are optional but seriously iconic ✨
B.1. Dynamic Address Configuration
with the exchange of protected configuration payloads, IKEv2 can hand the IKEv2 peer DHCP-like information payloads 💅 These configuration payloads are exchanged between the IKEv2 initiator and responder.
For example, the host in the host-to-router scenario could use this to get an IPv6 address from the ISP as part of setting up the IPsec tunnel mode SA. The details of these procedures are out of scope for this memo 🫶
B.2. NAT Traversal and Mobility
network address (and port) translation devices are everywhere in today's networks 🌸 A detailed description of the problem, and of the requirements for IPsec-protected data traffic traversing a NAT, is provided in [RFC3715].
IKEv2 can detect the presence of a NAT automatically by sending NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in the initial IKE_SA_INIT exchange. Once a NAT is detected and both endpoints support IPsec NAT traversal extensions, UDP encapsulation can be enabled.
More details about UDP encapsulation of IPsec-protected IP packets can be found in [RFC3948].
For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two reasons 🦋
- One of the tunnel endpoints is often behind a NAT, and configured tunneling, using protocol 41, is not guaranteed to traverse the NAT. Hence, using IPsec tunnels would enable one to set up both a secure tunnel and a tunnel that might not always be possible without other tunneling mechanisms.
- Using NAT traversal allows the outer address to change without having to renegotiate the SAs. This could be beneficial for a crude form of mobility and in scenarios where the NAT changes the IP addresses frequently. However, as the outer address may change, this might introduce new security issues, and using tunnel mode would be most appropriate.
When NAT is not applied, the second benefit would still be desirable. In particular, using manually configured tunneling is an operational challenge with dynamic IP addresses, because both ends need to be reconfigured if an address changes. Therefore, an easy and efficient way to re-establish the IPsec tunnel if the IP address changes would be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is used, but it only supports tunnel mode 🍓
B.3. Tunnel Endpoint Discovery
the IKEv2 initiator needs to know the address of the IKEv2 responder before it can start IKEv2 signaling 🧚 There are a bunch of ways to give the initiator this info, for example:
- Using out-of-band mechanisms, e.g., from the ISP's Web page.
- Using DNS to look up a service name by appending it to the DNS search path provided by DHCPv4 (e.g.,
tunnel-service.example.com). - Using a DHCP option.
- Using a pre-configured or pre-determined IPv4 anycast address.
- Using other, unspecified or proprietary methods.
For the purpose of this document, it's assumed that this address can be obtained somehow. Once the address has been learned, it is configured as the tunnel endpoint for the configured IPv6-in-IPv4 tunnel.
This problem is also discussed at more length in [TUNN-AD].
However, simply discovering the tunnel endpoint isn't enough to establish an IKE session with the peer. The PAD information (see Section 5.2) also needs to be learned dynamically. Hence, currently, automatic endpoint discovery only provides benefit if the PAD information is chosen in such a manner that it is not IP-address specific 💜
Authors' Addresses
the authors, the squad 🫶
Richard Graveman
RFG Security, LLC
15 Park Avenue
Morristown, NJ 07960
USA
EMail: rfg@acm.org
Mohan Parthasarathy
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
EMail: mohanp@sbcglobal.net
Pekka Savola
CSC/FUNET
Espoo
Finland
EMail: psavola@funet.fi
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@nsn.comFull Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property ✨
okay bestie, let's talk legal stuff but make it cute 💅 the IETF takes no position on whether any Intellectual Property Rights or other rights that might be claimed over the tech in this doc are valid or in scope 🫶 it also doesn't say whether any license under those rights might or might not be available, and it doesn't claim it has made any independent effort to find such rights. ngl that's the vibe: the IETF isn't the rights police 👑 if you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 💜
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights can all be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🌸
the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 🦋
Acknowledgement
funding for the RFC Editor function is currently provided by the Internet Society 🌈
📦 where this page comes from
- ietf: rfc4891 2007-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms