draft-ietf-v6ops-ipsec-tunnels-05.txt   rfc4891.txt 
IPv6 Operations WG R. Graveman Network Working Group R. Graveman
Internet-Draft RFG Security, LLC Request for Comments: 4891 RFG Security, LLC
Intended status: Informational M. Parthasarathy Category: Informational M. Parthasarathy
Expires: July 19, 2007 Nokia Nokia
P. Savola P. Savola
CSC/FUNET CSC/FUNET
H. Tschofenig H. Tschofenig
Siemens Nokia Siemens Networks
January 15, 2007
Using IPsec to Secure IPv6-in-IPv4 Tunnels Using IPsec to Secure IPv6-in-IPv4 Tunnels
draft-ietf-v6ops-ipsec-tunnels-05.txt
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 19, 2007. 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 Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document gives guidance on securing manually configured IPv6-in- This document gives guidance on securing manually configured IPv6-in-
IPv4 tunnels using IPsec in Transport Mode. No additional protocol IPv4 tunnels using IPsec in transport mode. No additional protocol
extensions are described beyond those available with the IPsec extensions are described beyond those available with the IPsec
framework. framework.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3 2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3
2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4 2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4
2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5 2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5
3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5 3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5
3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5 3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 6
3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6 3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6
3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8 3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8
4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 8 4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 9
5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 9 5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 10
5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 10 5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 11
5.2. Peer Authorization Database and Identities . . . . . . . . 12 5.2. Peer Authorization Database and Identities . . . . . . . . 12
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 17
Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 15 A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 17
A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 16 A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18
A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 17 A.3. Specific SPD for Host-to-Router Scenario . . . . . . . . . 19
A.3. Specific SPD for Host-to-Router scenario . . . . . . . . . 17 Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 20
Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 18 B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 20
B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 18 B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 20
B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 18 B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 21
B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
The IPv6 operations (v6ops) working group has selected (manually The IPv6 Operations (v6ops) working group has selected (manually
configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6 configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6
transition mechanisms for IPv6 deployment. transition mechanisms for IPv6 deployment.
[RFC4213] identified a number of threats that had not been adequately [RFC4213] identified a number of threats that had not been adequately
analyzed or addressed in its predecessor [RFC2893]. The most analyzed or addressed in its predecessor [RFC2893]. The most
complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling. complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling.
The document was intentionally not expanded to include the details on The document was intentionally not expanded to include the details on
how to set up an IPsec-protected tunnel in an interoperable manner, how to set up an IPsec-protected tunnel in an interoperable manner,
but instead the details were deferred to this memo. but instead the details were deferred to this memo.
First four sections of this document analyze the threats and The first four sections of this document analyze the threats and
scenarios that can be addressed by IPsec and assumptions made by this scenarios that can be addressed by IPsec and assumptions made by this
document for successful IPsec Security Association (SA) document for successful IPsec Security Association (SA)
establishment. Section 5 gives the details of Internet Key Exchange establishment. Section 5 gives the details of Internet Key Exchange
(IKE) and IP security (IPsec) exchange with packet formats and (IKE) and IP security (IPsec) exchange with packet formats and
Security Policy Database (SPD) entries. Section 6 gives Security Policy Database (SPD) entries. Section 6 gives
recommendations. Appendices further discuss tunnel mode usage and recommendations. Appendices further discuss tunnel mode usage and
optional extensions. optional extensions.
This document does not address the use of IPsec for tunnels that are This document does not address the use of IPsec for tunnels that are
not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably, not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably,
some form of opportunistic encryption or "better-than-nothing some form of opportunistic encryption or "better-than-nothing
security" might or might not be applicable. Similarly, propagating security" might or might not be applicable. Similarly, propagating
quality of service attributes (apart from Explicit Congestion quality-of-service attributes (apart from Explicit Congestion
Notification bits [RFC4213]) from the encapsulated packets to the Notification bits [RFC4213]) from the encapsulated packets to the
tunnel path is out of scope. tunnel path is out of scope.
The use of the word "interface" or the phrase "IP interface" refers 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 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" or receive IPv6 packets. The use of the phrase "tunnel interface"
refers to the interface that receives the IPv6-in-IPv4 tunneled refers to the interface that receives the IPv6-in-IPv4 tunneled
packets over IPv4. packets over IPv4.
2. Threats and the Use of IPsec 2. Threats and the Use of IPsec
skipping to change at page 4, line 41 skipping to change at page 4, line 43
Authentication Header (AH) security association (SA) is established Authentication Header (AH) security association (SA) is established
to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = to protect the traffic defined by (IPv4-source, IPv4-dest, protocol =
41). On receiving such an IPsec packet, the receiver first applies 41). On receiving such an IPsec packet, the receiver first applies
the IPsec transform (e.g., ESP) and then matches the packet against the IPsec transform (e.g., ESP) and then matches the packet against
the Security Parameter Index (SPI) and the inbound selectors the Security Parameter Index (SPI) and the inbound selectors
associated with the SA to verify that the packet is appropriate for associated with the SA to verify that the packet is appropriate for
the SA via which it was received. A successful verification implies the SA via which it was received. A successful verification implies
that the packet came from the right IPv4 endpoint, because the SA is that the packet came from the right IPv4 endpoint, because the SA is
bound to the IPv4 source address. bound to the IPv4 source address.
This prevents threat (1) but not the threat (2). IPsec in transport This prevents threat (1) but not threat (2). IPsec in transport mode
mode does not verify the contents of the payload itself where the does not verify the contents of the payload itself where the IPv6
IPv6 addresses are carried. That is, two nodes using IPsec transport addresses are carried. That is, two nodes using IPsec transport mode
mode to secure the tunnel can spoof the inner payload. The packet to secure the tunnel can spoof the inner payload. The packet will be
will be decapsulated successfully and accepted. decapsulated successfully and accepted.
This shortcoming can be partially mitigated by IPv6 ingress filtering This shortcoming can be partially mitigated by IPv6 ingress
i.e., check that the packet is arriving from the interface in the filtering, i.e., check that the packet is arriving from the interface
direction of the route towards the tunnel end-point, similar to a in the direction of the route towards the tunnel endpoint, similar to
Strict Reverse Path Forwarding (RPF) check [RFC3704]. a Strict Reverse Path Forwarding (RPF) check [RFC3704].
In most implementations, a transport mode SA is applied to a normal In most implementations, a transport mode SA is applied to a normal
IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in
the tunnel interface. (Transport mode is often also used in other the tunnel interface. (Transport mode is often also used in other
kind of tunnels such as GRE [RFC4023] and L2TP [RFC3193].) kinds of tunnels such as Generic Routing Encapsulation (GRE)
[RFC4023] and Layer 2 Tunneling Protocol (L2TP) [RFC3193].)
2.2. IPsec in Tunnel Mode 2.2. IPsec in Tunnel Mode
In tunnel mode, the IPsec SA is established to protect the traffic In tunnel mode, the IPsec SA is established to protect the traffic
defined by (IPv6-source, IPv6-destination). On receiving such an defined by (IPv6-source, IPv6-destination). On receiving such an
IPsec packet, the receiver first applies the IPsec transform (e.g., IPsec packet, the receiver first applies the IPsec transform (e.g.,
ESP) and then matches the packet against the SPI and the inbound ESP) and then matches the packet against the SPI and the inbound
selectors associated with the SA to verify that the packet is selectors associated with the SA to verify that the packet is
appropriate for the SA via which it was received. The successful appropriate for the SA via which it was received. The successful
verification implies that the packet came from the right endpoint. verification implies that the packet came from the right endpoint.
The outer IPv4 addresses may be spoofed and IPsec cannot detect this The outer IPv4 addresses may be spoofed, and IPsec cannot detect this
in tunnel mode; the packets will be demultiplexed based on the SPI in tunnel mode; the packets will be demultiplexed based on the SPI
and possibly the IPv6 address bound to the SA. Thus, the outer and possibly the IPv6 address bound to the SA. Thus, the outer
address spoofing is irrelevant as long as the decryption succeeds and address spoofing is irrelevant as long as the decryption succeeds and
the inner IPv6 packet can be verified to come from the right tunnel the inner IPv6 packet can be verified to have come from the right
endpoint. tunnel endpoint.
As described in Section 5, using tunnel mode is more difficult than As described in Section 5, using tunnel mode is more difficult than
applying transport mode to a tunnel interface, and as a result this applying transport mode to a tunnel interface, and as a result this
document recommends transport mode. Note that even though transport document recommends transport mode. Note that even though transport
rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel
specified by Protocol 41 still exists. specified by protocol 41 still exists [RFC4213].
3. Scenarios and Overview 3. Scenarios and Overview
There are roughly three scenarios: There are roughly three scenarios:
1. (generic) router-to-router tunnels. 1. (Generic) router-to-router tunnels.
2. site-to-router or router-to-site tunnels. These refer to 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 between a site's IPv6 (border) device and an IPv6 upstream
provider's router. A degenerate case of a site is a single host. provider's router. A degenerate case of a site is a single host.
3. Host-to-host tunnels. 3. Host-to-host tunnels.
3.1. Router-to-Router Tunnels 3.1. Router-to-Router Tunnels
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
IPv4 forwarding topology by encapsulating them within IPv4 packets. IPv4 forwarding topology by encapsulating them within IPv4 packets.
Tunneling can be used in a variety of ways. Tunneling can be used in a variety of ways.
skipping to change at page 6, line 33 skipping to change at page 6, line 39
ingress filtering must be performed to mitigate the IPv6 address ingress filtering must be performed to mitigate the IPv6 address
spoofing threat. spoofing threat.
A specific case of router-to-router tunnels, when one router resides A specific case of router-to-router tunnels, when one router resides
at an end site, is described in the next section. at an end site, is described in the next section.
3.2. Site-to-Router/Router-to-Site Tunnels 3.2. Site-to-Router/Router-to-Site Tunnels
This is a generalization of host-to-router and router-to-host This is a generalization of host-to-router and router-to-host
tunneling, because the issues when connecting a whole site (using a tunneling, because the issues when connecting a whole site (using a
router), and connecting a single host are roughly equal. router) and connecting a single host are roughly equal.
_----_ .---------. IPsec _----_ IPsec .-------. _----_ .---------. IPsec _----_ IPsec .-------.
_( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 | _( IPv6 )_ |v6-in-v4 | Tunnel _( IPv4 )_ Tunnel | V4/V6 |
( Internet )<--->| Router |<=======( Internet )=======>| Site B | ( Internet )<--->| Router |<=======( Internet )=======>| Site B |
(_ _) | A | (_ _) '--------' (_ _) | A | (_ _) '--------'
'----' '---------' '----' '----' '---------' '----'
^ ^
| |
V V
.--------. .--------.
skipping to change at page 7, line 31 skipping to change at page 7, line 50
+---------------------+ +---------------------+
Figure 3: Site-to-Router Scenario. Figure 3: Site-to-Router Scenario.
In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an
intermediary IPv6/IPv4 router that is reachable via an IPv4 intermediary IPv6/IPv4 router that is reachable via an IPv4
infrastructure. This type of tunnel spans the first segment of the infrastructure. This type of tunnel spans the first segment of the
packet's end-to-end path. packet's end-to-end path.
The hosts in the site originate the packets with IPv6 source The hosts in the site originate the packets with IPv6 source
addresses coming from a well known prefix, whereas the destination addresses coming from a well-known prefix, whereas the destination
addresses could be any nodes on the Internet. addresses could be any nodes on the Internet.
In this case, an IPsec tunnel mode SA could be bound to the prefix 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 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 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 will not be able to do a similar verification for the packets it
receives. This may be quite reasonable for most of the deployment receives. This may be quite reasonable for most of the deployment
cases, for example, an Internet Service Provider (ISP) allocating a cases, for example, an Internet Service Provider (ISP) allocating a
/48 to a customer. The Customer Premises Equipment (CPE) where the /48 to a customer. The Customer Premises Equipment (CPE) where the
tunnel is terminated "trusts" (in a weak sense) the ISP's router, and 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 the ISP's router can verify that Site B is the only one that can
originate packets within the /48. originate packets within the /48.
IPv6 spoofing must be prevented, and setting up ingress filtering may IPv6 spoofing must be prevented, and setting up ingress filtering may
skipping to change at page 9, line 14 skipping to change at page 9, line 37
Note that the existing implementations based on IKEv1 may already be Note that the existing implementations based on IKEv1 may already be
able to support the [RFC4301] features described in (1) and (2). If able to support the [RFC4301] features described in (1) and (2). If
appropriate, the deployment may choose to use either version of the appropriate, the deployment may choose to use either version of the
security architecture. security architecture.
IKEv2 supports features useful for configuring and securing tunnels IKEv2 supports features useful for configuring and securing tunnels
not present with IKEv1. not present with IKEv1.
1. IKEv2 supports legacy authentication methods by carrying them in 1. IKEv2 supports legacy authentication methods by carrying them in
EAP payloads. This can be used to authenticate hosts or sites to Extensible Authentication Protocol (EAP) payloads. This can be
an ISP using EAP methods that support username and password. 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 2. IKEv2 supports dynamic address configuration, which may be used
to configure the IPv6 address of the host. to configure the IPv6 address of the host.
NAT traversal works with both the old and revised IPsec Network Address Translation (NAT) traversal works with both the old
architectures, but the negotiation is integrated with IKEv2. and revised IPsec architectures, but the negotiation is integrated
with IKEv2.
For the purposes of this document, where the confidentiality of ESP For the purposes of this document, where the confidentiality of ESP
[RFC4303] is not required, AH [RFC4302] can be used as an alternative [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 to ESP. The main difference is that AH is able to provide integrity
protection for certain fields in the outer IPv4 header and IPv4 protection for certain fields in the outer IPv4 header and IPv4
options. However, as the outer IPv4 header will be discarded in any options. However, as the outer IPv4 header will be discarded in any
case, and those particular fields are not believed to be relevant in case, and those particular fields are not believed to be relevant in
this particular application, there is no particular reason to use AH. this particular application, there is no particular reason to use AH.
5. IPsec Configuration Details 5. IPsec Configuration Details
The following section describes the SPD entries for setting up the This section describes the SPD entries for setting up the IPsec
IPsec transport mode SA to protect the IPv6 traffic. transport mode SA to protect the IPv6 traffic.
Several requirements arise when IPsec is used to protect the IPv6 Several requirements arise when IPsec is used to protect the IPv6
traffic (inner header) for the scenarios listed in Section 3. traffic (inner header) for the scenarios listed in Section 3.
1. All of IPv6 traffic should be protected, including link-local 1. All of IPv6 traffic should be protected, including link-local
(e.g., Neighbor Discovery) and multicast traffic. Without this, (e.g., Neighbor Discovery) and multicast traffic. Without this,
an attacker can pollute the IPv6 neighbor cache causing an attacker can pollute the IPv6 neighbor cache causing
disruption in communication between the two routers. disruption in communication between the two routers.
2. In router-to-router tunnels, the source and destination addresses 2. In router-to-router tunnels, the source and destination addresses
skipping to change at page 10, line 32 skipping to change at page 11, line 8
than configured in SPDs) for proper source address selection. than configured in SPDs) for proper source address selection.
If the IPsec tunnel mode SA is modeled as interface, the traffic that If the IPsec tunnel mode SA is modeled as interface, the traffic that
needs protection can be modeled as routes pointing to the interface. needs protection can be modeled as routes pointing to the interface.
But the second requirement is difficult to satisfy, because the But the second requirement is difficult to satisfy, because the
traffic needing protection is not necessarily known a priori. The traffic needing protection is not necessarily known a priori. The
third requirement is easily solved, because IPsec is modeled as an third requirement is easily solved, because IPsec is modeled as an
interface. interface.
In practice, (2) has been solved by protecting all the traffic In practice, (2) has been solved by protecting all the traffic
(::/0), but no inter-operable implementations support this feature. (::/0), but no interoperable implementations support this feature.
For a detailed list of issues pertaining to this, see For a detailed list of issues pertaining to this, see [VLINK].
[I-D.duffy-ppvpn-ipsec-vlink].
Because applying transport mode to protect a tunnel is a much simpler Because applying transport mode to protect a tunnel is a much simpler
solution and also easily protects link-local and multicast traffic, solution and also easily protects link-local and multicast traffic,
we do not recommend using tunnel mode in this context. Tunnel mode we do not recommend using tunnel mode in this context. Tunnel mode
is, however, discussed further in Appendix A. is, however, discussed further in Appendix A.
This document assumes that tunnels are manually configured on both This document assumes that tunnels are manually configured on both
sides and the ingress filtering is manually setup to discard spoofed sides and the ingress filtering is manually setup to discard spoofed
packets. packets.
skipping to change at page 12, line 11 skipping to change at page 12, line 38
The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2, 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 and protocol value 41 as phase 2 identities. With IKEv2, the traffic
selectors are used to carry the same information. selectors are used to carry the same information.
5.2. Peer Authorization Database and Identities 5.2. Peer Authorization Database and Identities
The Peer Authorization Database (PAD) provides the link between SPD The Peer Authorization Database (PAD) provides the link between SPD
and the key management daemon [RFC4306]. This is defined in and the key management daemon [RFC4306]. This is defined in
[RFC4301] and hence relevant only when used with IKEv2. [RFC4301] and hence relevant only when used with IKEv2.
As there is no currently defined way to discover the PAD-related As there is currently no defined way to discover the PAD-related
parameters dynamically, it is assumed that these are manually parameters dynamically, it is assumed that these are manually
configured: configured:
o The Identity of the peer asserted in the IKEv2 exchange: Many o The Identity of the peer asserted in the IKEv2 exchange: Many
different types of identities can be used. At least, the IPv4 different types of identities can be used. At least, the IPv4
address of the peer should be supported. address of the peer should be supported.
o IKEv2 can authenticate the peer by several methods. Pre-shared o IKEv2 can authenticate the peer by several methods. Pre-shared
key and X.509 certificate-based authentication is required by key and X.509 certificate-based authentication is required by
[RFC4301]. At least, pre-shared key should be supported, because [RFC4301]. At least, pre-shared key should be supported, because
it interoperates with a larger number of implementations. it interoperates with a larger number of implementations.
o The child SA authorization data should contain the IPv4 address of o The child SA authorization data should contain the IPv4 address of
the peer. the peer.
IPv4 address should be supported as Identity during the key exchange. IPv4 address should be supported as Identity during the key exchange.
As this not provide Identity protection, main mode or aggressive mode As this does not provide Identity protection, main mode or aggressive
can be used with IKEv1. mode can be used with IKEv1.
6. Recommendations 6. Recommendations
In Section 5, we examined the differences between setting up an IPsec In Section 5, we examined the differences between setting up an IPsec
IPv6-in-IPv4 tunnel using either transport or tunnel mode. We IPv6-in-IPv4 tunnel using either transport or tunnel mode. We
observe that applying transport mode to a tunnel interface is the observe that applying transport mode to a tunnel interface is the
simplest and therefore recommended solution. simplest and therefore recommended solution.
In Appendix A, we also explore what it would take to use so-called In Appendix A, we also explore what it would take to use so-called
Specific SPD (SSPD) tunnel mode. Such usage is more complicated Specific SPD (SSPD) tunnel mode. Such usage is more complicated
because IPv6 prefixes need to be known a priori and multicast and because IPv6 prefixes need to be known a priori, and multicast and
link-local traffic do not work over such a tunnel. Fragment handling link-local traffic do not work over such a tunnel. Fragment handling
in tunnel mode is also more difficult. However, because MOBIKE in tunnel mode is also more difficult. However, because the Mobility
[RFC4555] supports only tunnel mode, when the IPv4 endpoints of a and Multihoming Protocol (MOBIKE) [RFC4555] supports only tunnel
tunnel are dynamic and the other constraints are not applicable, mode, when the IPv4 endpoints of a tunnel are dynamic and the other
using tunnel mode may be an acceptable solution. constraints are not applicable, using tunnel mode may be an
acceptable solution.
Therefore our primary recommendation is to use transport mode applied Therefore, our primary recommendation is to use transport mode
to a tunnel interface. Source address spoofing can be limited by applied to a tunnel interface. Source address spoofing can be
enabling ingress filtering on the tunnel interface. limited by enabling ingress filtering on the tunnel interface.
Manual keying must not be used as large amounts of IPv6 traffic may 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 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 attacker to recover the keys. IKEv1 or IKEv2 must be used for
establishing the IPsec SAs. IKEv2 should be used where supported and establishing the IPsec SAs. IKEv2 should be used where supported and
available; if not, IKEv1 may be used instead. available; if not, IKEv1 may be used instead.
7. IANA Considerations 7. Security Considerations
This memo makes no request to IANA. [[ RFC-editor: please remove this
section prior to publication. ]]
8. Security Considerations
When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it
is possible to "inject" packets into the tunnel by spoofing the is possible to "inject" packets into the tunnel by spoofing the
source address (data plane security), or if the tunnel is signaled source address (data plane security), or if the tunnel is signaled
somehow (e.g., using authentication protocol and obtaining a static somehow (e.g., using authentication protocol and obtaining a static
v6 prefix), someone might be able to spoof the signaling (control v6 prefix), someone might be able to spoof the signaling (control
plane security). plane security).
The IPsec framework plays an important role in adding security to The IPsec framework plays an important role in adding security to
both the protocol for tunnel setup and data traffic. both the protocol for tunnel setup and data traffic.
skipping to change at page 13, line 43 skipping to change at page 14, line 19
confidentiality. confidentiality.
IPsec provides access control mechanisms through the distribution of IPsec provides access control mechanisms through the distribution of
keys and also through the application of policies dictated by the keys and also through the application of policies dictated by the
Security Policy Database (SPD). Security Policy Database (SPD).
The NAT traversal mechanism provided by IKEv2 introduces some The NAT traversal mechanism provided by IKEv2 introduces some
weaknesses into IKE and IPsec. These issues are discussed in more weaknesses into IKE and IPsec. These issues are discussed in more
detail in [RFC4306]. detail in [RFC4306].
Please note that using IPsec for the scenarios described in Figure 3, Please note that using IPsec for the scenarios described in Figures
Figure 2 and Figure 1 does not aim to protect the end-to-end 1, 2, and 3 does not aim to protect the end-to-end communication. It
communication. It protects just the tunnel part. It is still protects just the tunnel part. It is still possible for an IPv6
possible for an IPv6 endpoint not attached to the IPsec tunnel to endpoint not attached to the IPsec tunnel to spoof packets.
spoof packets.
9. Contributors 8. Contributors
The authors are listed in alphabetical order. The authors are listed in alphabetical order.
Suresh Satapati also participated in the initial discussions on this Suresh Satapati also participated in the initial discussions on this
topic. topic.
10. Acknowledgments 9. Acknowledgments
The authors would like to thank Stephen Kent, Michael Richardson, The authors would like to thank Stephen Kent, Michael Richardson,
Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred
Hoenes, Francis Dupont, and David Black for their substantive Hoenes, Francis Dupont, and David Black for their substantive
feedback. feedback.
We would like to thank Pasi Eronen for his text contributions and We would like to thank Pasi Eronen for his text contributions and
suggestions for improvement. suggestions for improvement.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
skipping to change at page 15, line 5 skipping to change at page 15, line 34
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
11.2. Informative References 10.2. Informative References
[I-D.duffy-ppvpn-ipsec-vlink]
Duffy, M., "Framework for IPsec Protected Virtual Links
for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in
progress), October 2002.
[I-D.palet-v6ops-tun-auto-disc]
Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03
(work in progress), January 2005.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000. IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001. "Securing L2TP using IPsec", RFC 3193, November 2001.
skipping to change at page 15, line 46 skipping to change at page 16, line 18
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006. 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 Appendix A. Using Tunnel Mode
First, we describe the different tunnel mode implementation methods. First, we describe the different tunnel mode implementation methods.
We note that, in this context, only the so-called Specific SPD (SSPD) 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 model (without a tunnel interface) can be made to work, but it has
reduced applicability, and the use of a transport mode tunnel is reduced applicability, and the use of a transport mode tunnel is
recommended instead. However, we will describe how the SSPD Tunnel recommended instead. However, we will describe how the SSPD tunnel
Mode might look if one would like to use it in any case. mode might look if one would like to use it in any case.
A.1. Tunnel Mode Implementation Methods A.1. Tunnel Mode Implementation Methods
Tunnel mode could (in theory) be deployed in two very different ways Tunnel mode could (in theory) be deployed in two very different ways
depending on the implementation: depending on the implementation:
1. "Generic SPDs": some implementations model the tunnel mode SA as 1. "Generic SPDs": some implementations model the tunnel mode SA as
an IP interface. In this case, an IPsec tunnel interface is an IP interface. In this case, an IPsec tunnel interface is
created and used with "any" addresses ("::/0 <-> ::/0" ) as IPsec created and used with "any" addresses ("::/0 <-> ::/0" ) as IPsec
traffic selectors while setting up the SA. Though this allows traffic selectors while setting up the SA. Though this allows
all traffic between the two nodes to be protected by IPsec, the all traffic between the two nodes to be protected by IPsec, the
routing table would decide what traffic gets sent over the routing table would decide what traffic gets sent over the
tunnel. Ingress filtering must be separately applied on the tunnel. Ingress filtering must be separately applied on the
tunnel interface as the IPsec policy checks do not check the IPv6 tunnel interface as the IPsec policy checks do not check the IPv6
addresses at all. Routing protocols, multicast, etc. will work addresses at all. Routing protocols, multicast, etc. will work
through this tunnel. This mode is similar to transport mode. through this tunnel. This mode is similar to transport mode.
The SPDs must be interface-specific. However, because IKE uses The SPDs must be interface-specific. However, because IKE uses
IPv4 but the tunnel is IPv6, there is no standard solution to map IPv4 but the tunnel is IPv6, there is no standard solution to map
the IPv4 interface to IPv6 interface the IPv4 interface to IPv6 interface [VLINK] and this approach is
[I-D.duffy-ppvpn-ipsec-vlink] and this approach is not feasible. not feasible.
2. "Specific SPDs": some implementations do not model the tunnel 2. "Specific SPDs": some implementations do not model the tunnel
mode SA as an IP interface. Traffic selection is based on mode SA as an IP interface. Traffic selection is based on
specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8: specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8:
2::/48". As the IPsec session between two endpoints does not 2::/48". As the IPsec session between two endpoints does not
have an interface (though an implementation may have a common have an interface (though an implementation may have a common
pseudo-interface for all IPsec traffic), there is no DAD, MLD, or 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 link-local traffic to protect; multicast is not possible over
such a tunnel. Ingress filtering is performed automatically by such a tunnel. Ingress filtering is performed automatically by
the IPsec traffic selectors. the IPsec traffic selectors.
Ingress filtering is guaranteed by IPsec processing when option (2) Ingress filtering is guaranteed by IPsec processing when option (2)
is chosen, whereas the operator has to enable it explicitly when is chosen, whereas the operator has to enable it explicitly when
transport mode or option (1) is chosen. transport mode or option (1) is chosen.
In summary, there does not appear to be a standard solution in this In summary, there does not appear to be a standard solution in this
context for the first implementation approach. context for the first implementation approach.
skipping to change at page 17, line 38 skipping to change at page 19, line 5
3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP, 3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP,
tunnel{IPV4-TEP2,IPV4-TEP1}) tunnel{IPV4-TEP2,IPV4-TEP1})
"IKE" refers to UDP destination port 500 and possibly also "IKE" refers to UDP destination port 500 and possibly also
port 4500 if NAT traversal is used. port 4500 if NAT traversal is used.
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 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 as phase 2 identities. With IKEv2, the traffic selectors are used to
carry the same information. carry the same information.
A.3. Specific SPD for Host-to-Router scenario A.3. Specific SPD for Host-to-Router Scenario
The following SPD entries assume that the host has the IPv6 address The following SPD entries assume that the host has the IPv6 address
IPV6-EP1 and the tunnel end points of the host and router are IPV4- IPV6-EP1 and the tunnel end points of the host and router are IPV4-
TEP1 and IPV4-TEP2 respectively. If the tunnel is between a router TEP1 and IPV4-TEP2, respectively. If the tunnel is between a router
and a host where the router has allocated a IPV6-PREF/48 to the host, and a host where the router has allocated an IPV6-PREF/48 to the
the corresponding SPD entries can be derived by replacing IPV6-EP1 host, the corresponding SPD entries can be derived by replacing IPV6-
with IPV6-PREF/48. EP1 with IPV6-PREF/48.
Please note the bypass entry for host's SPD, absent in router's SPD. 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 While this might be an implementation matter for host-to-router
tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6- tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6-
PREF/48" is critical for site-to-router tunneling. PREF/48", is critical for site-to-router tunneling.
Host's SPD: Host's SPD:
Next Layer Next Layer
Rule Local Remote Protocol Action Rule Local Remote Protocol Action
---- ----- ------ ---------- -------- ---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS 1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS 2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPV6-EP1 IPV6-EP1 ANY BYPASS 3 IPV6-EP1 IPV6-EP1 ANY BYPASS
4 IPV6-EP1 ANY ANY PROTECT(ESP, 4 IPV6-EP1 ANY ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2}) tunnel{IPV4-TEP1,IPV4-TEP2})
skipping to change at page 18, line 36 skipping to change at page 20, line 10
identities. The starting address is zero and the end address is all 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 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 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With
IKEv2, the traffic selectors are used to carry the same information. IKEv2, the traffic selectors are used to carry the same information.
Appendix B. Optional Features Appendix B. Optional Features
B.1. Dynamic Address Configuration B.1. Dynamic Address Configuration
With the exchange of protected configuration payloads, IKEv2 is able With the exchange of protected configuration payloads, IKEv2 is able
to provide the IKEv2 peer with DHCP-like information payloads. These to provide the IKEv2 peer with Dynamic Host Configuration Protocol
configuration payloads are exchanged between the IKEv2 initiator and (DHCP)-like information payloads. These configuration payloads are
responder. exchanged between the IKEv2 initiator and responder.
This could be used (for example) by the host in the host-to-router 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 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 the IPsec tunnel mode SA. The details of these procedures are out of
scope for this memo. scope for this memo.
B.2. NAT Traversal and Mobility B.2. NAT Traversal and Mobility
Network address (and port) translation devices are commonly found in Network address (and port) translation devices are commonly found in
today's networks. A detailed description of the problem of IPsec- today's networks. A detailed description of the problem and
protected data traffic traversing a NAT including requirements are requirements of IPsec-protected data traffic traversing a NAT is
discussed in [RFC3715]. provided in [RFC3715].
IKEv2 can detect the presence of a NAT automatically by sending IKEv2 can detect the presence of a NAT automatically by sending
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in
the initial IKE_SA_INIT exchange. Once a NAT is detected and both the initial IKE_SA_INIT exchange. Once a NAT is detected and both
end points support IPsec NAT traversal extensions, UDP encapsulation end points support IPsec NAT traversal extensions, UDP encapsulation
can be enabled. can be enabled.
More details about UDP encapsulation of IPsec-protected IP packets More details about UDP encapsulation of IPsec-protected IP packets
can be found in [RFC3948]. can be found in [RFC3948].
skipping to change at page 19, line 44 skipping to change at page 21, line 19
way to re-establish the IPsec tunnel if the IP address changes would way to re-establish the IPsec tunnel if the IP address changes would
be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is
used, but it only supports tunnel mode. used, but it only supports tunnel mode.
B.3. Tunnel Endpoint Discovery B.3. Tunnel Endpoint Discovery
The IKEv2 initiator needs to know the address of the IKEv2 responder 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 to start IKEv2 signaling. A number of ways can be used to provide
the initiator with this information, for example: the initiator with this information, for example:
o Using out-of-band mechanisms, e.g., from the ISP's web page. 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 o Using DNS to look up a service name by appending it to the DNS
search path provided by DHCPv4 (e.g. "tunnel- search path provided by DHCPv4 (e.g., "tunnel-
service.example.com"). service.example.com").
o Using a DHCP option. o Using a DHCP option.
o Using a pre-configured or pre-determined IPv4 anycast address. o Using a pre-configured or pre-determined IPv4 anycast address.
o Using other, unspecified or proprietary methods. o Using other, unspecified or proprietary methods.
For the purpose of this document it is assumed that this address can For the purpose of this document, it is assumed that this address can
be obtained somehow. Once the address has been learned, it is be obtained somehow. Once the address has been learned, it is
configured as the tunnel end-point for the configured IPv6-in-IPv4 configured as the tunnel endpoint for the configured IPv6-in-IPv4
tunnel. tunnel.
This problem is also discussed at more length in This problem is also discussed at more length in [TUNN-AD].
[I-D.palet-v6ops-tun-auto-disc].
However, simply discovering the tunnel endpoint is not sufficient for However, simply discovering the tunnel endpoint is not sufficient for
establishing an IKE session with the peer. The PAD information (see establishing an IKE session with the peer. The PAD information (see
Section 5.2) also needs to be learned dynamically. Hence, currently, Section 5.2) also needs to be learned dynamically. Hence, currently,
automatic endpoint discovery provides benefit only if PAD information automatic endpoint discovery provides benefit only if PAD information
is chosen in such a manner that it is not IP-address specific. is chosen in such a manner that it is not IP-address specific.
Authors' Addresses Authors' Addresses
Richard Graveman Richard Graveman
RFG Security, LLC RFG Security, LLC
15 Park Avenue 15 Park Avenue
Morristown, New Jersey 07960 Morristown, NJ 07960
USA USA
Email: rfg@acm.org EMail: rfg@acm.org
Mohan Parthasarathy Mohan Parthasarathy
Nokia Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View CA-94043 Mountain View, CA 94043
USA USA
Email: mohanp@sbcglobal.net EMail: mohanp@sbcglobal.net
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finland Finland
Email: psavola@funet.fi EMail: psavola@funet.fi
Hannes Tschofenig Hannes Tschofenig
Siemens Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bayern 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@nsn.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 22, line 45 skipping to change at page 23, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 62 change blocks. 
153 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/