doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc4891.txt b/doc/rfc/rfc4891.txt
new file mode 100644
index 0000000..db12775
--- /dev/null
+++ b/doc/rfc/rfc4891.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                        R. Graveman
+Request for Comments: 4891                             RFG Security, LLC
+Category: Informational                                 M. Parthasarathy
+                                                                   Nokia
+                                                               P. Savola
+                                                               CSC/FUNET
+                                                           H. Tschofenig
+                                                  Nokia Siemens Networks
+                                                                May 2007
+
+
+               Using IPsec to Secure IPv6-in-IPv4 Tunnels
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document gives guidance on securing manually configured IPv6-in-
+   IPv4 tunnels using IPsec in transport mode.  No additional protocol
+   extensions are described beyond those available with the IPsec
+   framework.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                      [Page 1]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+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  . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                      [Page 2]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+1.  Introduction
+
+   The IPv6 Operations (v6ops) working group has selected (manually
+   configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6
+   transition mechanisms for IPv6 deployment.
+
+   [RFC4213] identified a number of threats that had not been adequately
+   analyzed or addressed in its predecessor [RFC2893].  The most
+   complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling.
+   The document was intentionally not expanded to include the details on
+   how to set up an IPsec-protected tunnel in an interoperable manner,
+   but instead the details were deferred to this memo.
+
+   The first four sections of this document analyze the threats and
+   scenarios that can be addressed by IPsec and assumptions made by this
+   document for successful IPsec Security Association (SA)
+   establishment.  Section 5 gives the details of Internet Key Exchange
+   (IKE) and IP security (IPsec) exchange with packet formats and
+   Security Policy Database (SPD) entries.  Section 6 gives
+   recommendations.  Appendices further discuss tunnel mode usage and
+   optional extensions.
+
+   This document does not address the use of IPsec for tunnels that are
+   not manually configured (e.g., 6to4 tunnels [RFC3056]).  Presumably,
+   some form of opportunistic encryption or "better-than-nothing
+   security" might or might not be applicable.  Similarly, propagating
+   quality-of-service attributes (apart from Explicit Congestion
+   Notification bits [RFC4213]) from the encapsulated packets to the
+   tunnel path is out of scope.
+
+   The use of the word "interface" or the phrase "IP interface" refers
+   to the IPv6 interface that must be present on any IPv6 node to send
+   or receive IPv6 packets.  The use of the phrase "tunnel interface"
+   refers to the interface that receives the IPv6-in-IPv4 tunneled
+   packets over IPv4.
+
+2.  Threats and the Use of IPsec
+
+   [RFC4213] is mostly concerned about address spoofing threats:
+
+   1.  The IPv4 source address of the encapsulating ("outer") packet can
+       be spoofed.
+
+   2.  The IPv6 source address of the encapsulated ("inner") packet can
+       be spoofed.
+
+
+
+
+
+
+Graveman, et al.             Informational                      [Page 3]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   The reason threat (1) exists is the lack of universal deployment of
+   IPv4 ingress filtering [RFC3704].  The reason threat (2) exists is
+   that the IPv6 packet is encapsulated in IPv4 and hence may escape
+   IPv6 ingress filtering.  [RFC4213] specifies the following strict
+   address checks as mitigating measures:
+
+   o  To mitigate threat (1), the decapsulator verifies 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, i.e., check whether the packet is received
+      on a legitimate interface.
+
+   o  To mitigate threat (2), the decapsulator verifies whether the
+      inner IPv6 address is a valid IPv6 address and also applies IPv6
+      ingress filtering before accepting the IPv6 packet.
+
+   This memo proposes using IPsec for providing stronger security in
+   preventing these threats and additionally providing integrity,
+   confidentiality, replay protection, and origin protection between
+   tunnel endpoints.
+
+   IPsec can be used in two ways, in transport and tunnel mode; detailed
+   discussion about applicability in this context is provided in
+   Section 5.
+
+2.1.  IPsec in Transport Mode
+
+   In transport mode, the IPsec Encapsulating Security Payload (ESP) or
+   Authentication Header (AH) security association (SA) is established
+   to protect the traffic defined by (IPv4-source, IPv4-dest, protocol =
+   41).  On receiving such an IPsec packet, the receiver first applies
+   the IPsec transform (e.g., ESP) and then matches the packet against
+   the Security Parameter Index (SPI) and the inbound selectors
+   associated with the SA to verify that the packet is appropriate for
+   the SA via which it was received.  A successful verification implies
+   that the packet came from the right IPv4 endpoint, because the SA is
+   bound to the IPv4 source address.
+
+   This prevents threat (1) but not threat (2).  IPsec in transport mode
+   does not verify the contents of the payload itself where the IPv6
+   addresses are carried.  That is, two nodes using IPsec transport mode
+   to secure the tunnel can spoof the inner payload.  The packet will be
+   decapsulated successfully and accepted.
+
+   This shortcoming can be partially mitigated by IPv6 ingress
+   filtering, i.e., check that the packet is arriving from the interface
+   in the direction of the route towards the tunnel endpoint, similar to
+   a Strict Reverse Path Forwarding (RPF) check [RFC3704].
+
+
+
+Graveman, et al.             Informational                      [Page 4]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   In most implementations, a transport mode SA is applied to a normal
+   IPv6-in-IPv4 tunnel.  Therefore, ingress filtering can be applied in
+   the tunnel interface.  (Transport mode is often also used in other
+   kinds of tunnels such as 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 established to protect the traffic
+   defined by (IPv6-source, IPv6-destination).  On receiving such an
+   IPsec packet, the receiver first applies the IPsec transform (e.g.,
+   ESP) and then matches the packet against the SPI and the inbound
+   selectors associated with the SA to verify that the packet is
+   appropriate for the SA via which it was received.  The successful
+   verification implies that the packet came from the right endpoint.
+
+   The outer IPv4 addresses may be spoofed, and IPsec cannot detect this
+   in tunnel mode; the packets will be demultiplexed based on the SPI
+   and possibly the IPv6 address bound to the SA.  Thus, the outer
+   address spoofing is irrelevant as long as the decryption succeeds and
+   the inner IPv6 packet can be verified to have come from the right
+   tunnel endpoint.
+
+   As described in Section 5, using tunnel mode is more difficult than
+   applying transport mode to a tunnel interface, and as a result this
+   document recommends transport mode.  Note that even though transport
+   rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel
+   specified by protocol 41 still exists [RFC4213].
+
+3.  Scenarios and Overview
+
+   There are roughly three scenarios:
+
+   1.  (Generic) router-to-router tunnels.
+
+   2.  Site-to-router or router-to-site tunnels.  These refer to 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.
+
+   3.  Host-to-host tunnels.
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                      [Page 5]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+3.1.  Router-to-Router Tunnels
+
+   IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
+   IPv4 forwarding topology by encapsulating them within IPv4 packets.
+   Tunneling can be used in a variety of 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 interconnected by an IPv4 infrastructure can tunnel
+   IPv6 packets between themselves.  In this case, the tunnel spans one
+   segment of the end-to-end path that the IPv6 packet takes.
+
+   The source and destination addresses of the IPv6 packets traversing
+   the tunnel could come from a wide range of IPv6 prefixes, so binding
+   IPv6 addresses to be used to the SA is not generally feasible.  IPv6
+   ingress filtering must be performed to mitigate the IPv6 address
+   spoofing threat.
+
+   A specific case of router-to-router tunnels, when one router resides
+   at an end site, is described in the next section.
+
+3.2.  Site-to-Router/Router-to-Site Tunnels
+
+   This is a generalization of host-to-router and router-to-host
+   tunneling, because the issues when connecting a whole site (using a
+   router) and connecting a single host are roughly equal.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                      [Page 6]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+      _----_        .---------. 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 to their final destination
+   IPv6/IPv4 site.  This tunnel spans only the last segment of the end-
+   to-end path.
+
+                                   +---------------------+
+                                   |      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.
+
+
+
+
+Graveman, et al.             Informational                      [Page 7]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   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 B
+
+                     Figure 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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                      [Page 8]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+4.  IKE and IPsec Versions
+
+   This section discusses the different versions of the IKE and IPsec
+   security architecture and their applicability 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.  The differences relevant to
+   this document are discussed below.
+
+   1.  [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.
+
+   2.  [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
+   not present with IKEv1.
+
+   1.  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.
+
+   2.  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
+
+
+
+Graveman, et al.             Informational                      [Page 9]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   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 describes the SPD entries for setting up the IPsec
+   transport mode SA to protect the IPv6 traffic.
+
+   Several requirements arise when IPsec is used to protect the IPv6
+   traffic (inner header) for the scenarios listed in Section 3.
+
+   1.  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.
+
+   2.  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).
+
+   3.  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
+
+
+
+Graveman, et al.             Informational                     [Page 10]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   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
+
+   Transport mode has typically been applied to L2TP, GRE, and other
+   tunneling methods, especially when the user wants to tunnel non-IP
+   traffic.  [RFC3884], [RFC3193], and [RFC4023] provide examples of
+   applying transport mode to protect tunnel traffic that spans only a
+   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 following SPD entries assume that there are two routers, Router1
+   and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1
+   and IPV4-TEP2, respectively.  (In other scenarios, the SPDs are 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)
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 11]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+     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" refers to UDP destination port 500
+     and possibly also port 4500 if NAT traversal is used.
+
+   The packet format is as 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 the IPv4-TEP1, IPV4-TEP2,
+   and protocol value 41 as phase 2 identities.  With IKEv2, the traffic
+   selectors are used to carry the same information.
+
+5.2.  Peer Authorization Database and Identities
+
+   The Peer Authorization Database (PAD) provides the link between SPD
+   and the key management daemon [RFC4306].  This is defined in
+   [RFC4301] and hence relevant only when used with IKEv2.
+
+   As there is currently no defined way to discover the PAD-related
+   parameters dynamically, it is assumed that these are manually
+   configured:
+
+   o  The Identity of the peer asserted in the IKEv2 exchange: Many
+      different types of identities can be used.  At least, the IPv4
+      address of the peer should be supported.
+
+   o  IKEv2 can authenticate the peer by several methods.  Pre-shared
+      key and X.509 certificate-based authentication is required by
+      [RFC4301].  At least, pre-shared key should be supported, because
+      it interoperates with a larger number of implementations.
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 12]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   o  The child SA authorization data should contain the IPv4 address of
+      the peer.
+
+   IPv4 address should be supported as Identity during the key exchange.
+   As this does not provide Identity protection, main mode or aggressive
+   mode can be used with IKEv1.
+
+6.  Recommendations
+
+   In Section 5, we examined the differences between setting up an IPsec
+   IPv6-in-IPv4 tunnel using either transport or 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 so-called
+   Specific SPD (SSPD) tunnel mode.  Such usage is 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 more difficult.  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 are not applicable, using tunnel mode may be an
+   acceptable solution.
+
+   Therefore, our primary 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 as 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
+   is possible to "inject" packets into the tunnel by spoofing the
+   source address (data plane security), or if the tunnel is signaled
+   somehow (e.g., using authentication protocol and obtaining a static
+   v6 prefix), someone might be able to spoof the signaling (control
+   plane security).
+
+   The IPsec framework plays an important role in adding security to
+   both the protocol for tunnel setup and data traffic.
+
+   Either IKEv1 or IKEv2 provides a secure signaling protocol for
+   establishing, maintaining, and deleting an IPsec tunnel.
+
+
+
+Graveman, et al.             Informational                     [Page 13]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   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 furthermore provides limited traffic flow
+   confidentiality.
+
+   IPsec provides access control mechanisms 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 is still possible for an IPv6
+   endpoint not 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 like to thank Pasi Eronen for his text contributions and
+   suggestions for improvement.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 14]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+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.
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 15]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 16]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+Appendix A.  Using Tunnel Mode
+
+   First, we describe the different tunnel mode implementation methods.
+   We note that, 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, and the use of a transport mode tunnel is
+   recommended instead.  However, we will describe how the SSPD tunnel
+   mode might look if one would like to use it in any case.
+
+A.1.  Tunnel Mode Implementation Methods
+
+   Tunnel mode could (in theory) be deployed in two very different ways
+   depending on the implementation:
+
+   1.  "Generic SPDs": some implementations model the tunnel mode SA as
+       an IP interface.  In this case, an IPsec tunnel interface is
+       created and used with "any" addresses ("::/0 <-> ::/0" ) as IPsec
+       traffic selectors while setting up the SA.  Though this allows
+       all traffic between the two nodes to be protected by IPsec, the
+       routing table would decide what traffic gets sent over the
+       tunnel.  Ingress filtering must be separately applied on the
+       tunnel interface as the IPsec policy checks do not check 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 is no standard solution to map
+       the IPv4 interface to IPv6 interface [VLINK] and this approach is
+       not feasible.
+
+   2.  "Specific SPDs": some implementations do not 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".  As the IPsec session between two endpoints does not
+       have an interface (though an implementation may have a common
+       pseudo-interface for all IPsec traffic), there is no Duplicate
+       Address Detection (DAD), Multicast Listener Discovery (MLD), or
+       link-local traffic to protect; 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 does not appear to be a standard solution in this
+   context for the first implementation approach.
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 17]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   The second approach can be made to work, but is 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), and it 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
+   implementation, may need to be reflected in SPDs.
+
+A.2.  Specific SPD for Host-to-Host Scenario
+
+   The following SPD entries assume that there are two hosts, Host1 and
+   Host2, whose IPv6 addresses are denoted IPV6-EP1 and IPV6-EP2 (global
+   addresses), and 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.
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 18]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+A.3.  Specific SPD for Host-to-Router Scenario
+
+   The following SPD entries assume that the host has the IPv6 address
+   IPV6-EP1 and 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 where the router has allocated an IPV6-PREF/48 to the
+   host, the corresponding SPD entries can be derived by replacing IPV6-
+   EP1 with IPV6-PREF/48.
+
+   Please note the bypass entry for host's SPD, absent in 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.
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 19]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+Appendix B.  Optional Features
+
+B.1.  Dynamic Address Configuration
+
+   With the exchange of protected configuration payloads, IKEv2 is able
+   to provide the IKEv2 peer with Dynamic Host Configuration Protocol
+   (DHCP)-like information payloads.  These configuration payloads are
+   exchanged between the IKEv2 initiator and responder.
+
+   This could be used (for example) by the host in the host-to-router
+   scenario to obtain 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 commonly found in
+   today's networks.  A detailed description of the problem and
+   requirements of 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:
+
+   1.  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.
+
+   2.  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.
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 20]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+   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
+   to start IKEv2 signaling.  A number of ways can be used to provide
+   the initiator with this information, for example:
+
+   o  Using out-of-band mechanisms, e.g., from the ISP's Web page.
+
+   o  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").
+
+   o  Using a DHCP option.
+
+   o  Using a pre-configured or pre-determined IPv4 anycast address.
+
+   o  Using other, unspecified or proprietary methods.
+
+   For the purpose of this document, it is 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 is not sufficient for
+   establishing an IKE session with the peer.  The PAD information (see
+   Section 5.2) also needs to be learned dynamically.  Hence, currently,
+   automatic endpoint discovery provides benefit only if PAD information
+   is chosen in such a manner that it is not IP-address specific.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 21]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+Authors' Addresses
+
+   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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 22]
+
+RFC 4891            IPsec with IPv6-in-IPv4 Tunnels             May 2007
+
+
+Full 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
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from 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.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Graveman, et al.             Informational                     [Page 23]
+