added MOBIKE rfc

1 files changed, 1851 insertions, 0 deletions

diff --git a/doc/standards/rfc4555.txt b/doc/standards/rfc4555.txt
new file mode 100644
index 000000000..9b2a58978
--- /dev/null
+++ b/doc/standards/rfc4555.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group                                     P. Eronen, Ed.
+Request for Comments: 4555                                         Nokia
+Category: Standards Track                                      June 2006
+
+
+            IKEv2 Mobility and Multihoming Protocol (MOBIKE)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the MOBIKE protocol, a mobility and
+   multihoming extension to Internet Key Exchange (IKEv2).  MOBIKE
+   allows the IP addresses associated with IKEv2 and tunnel mode IPsec
+   Security Associations to change.  A mobile Virtual Private Network
+   (VPN) client could use MOBIKE to keep the connection with the VPN
+   gateway active while moving from one address to another.  Similarly,
+   a multihomed host could use MOBIKE to move the traffic to a different
+   interface if, for instance, the one currently being used stops
+   working.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                     [Page 1]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Scope and Limitations  . . . . . . . . . . . . . . . . . .  4
+     1.3.  Terminology and Notation . . . . . . . . . . . . . . . . .  4
+   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  5
+     2.1.  Basic Operation  . . . . . . . . . . . . . . . . . . . . .  5
+     2.2.  Example Protocol Exchanges . . . . . . . . . . . . . . . .  6
+     2.3.  MOBIKE and Network Address Translation (NAT) . . . . . . .  9
+   3.  Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
+     3.1.  Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
+     3.2.  Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
+     3.3.  Initial Tunnel Header Addresses  . . . . . . . . . . . . . 11
+     3.4.  Additional Addresses . . . . . . . . . . . . . . . . . . . 11
+     3.5.  Changing Addresses in IPsec SAs  . . . . . . . . . . . . . 12
+     3.6.  Updating Additional Addresses  . . . . . . . . . . . . . . 15
+     3.7.  Return Routability Check . . . . . . . . . . . . . . . . . 17
+     3.8.  Changes in NAT Mappings  . . . . . . . . . . . . . . . . . 18
+     3.9.  NAT Prohibition  . . . . . . . . . . . . . . . . . . . . . 19
+     3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
+     3.11. Failure Recovery and Timeouts  . . . . . . . . . . . . . . 20
+     3.12. Dead Peer Detection  . . . . . . . . . . . . . . . . . . . 20
+   4.  Payload Formats  . . . . . . . . . . . . . . . . . . . . . . . 21
+     4.1.  Notify Messages - Error Types  . . . . . . . . . . . . . . 21
+     4.2.  Notify Messages - Status Types . . . . . . . . . . . . . . 21
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
+     5.1.  Traffic Redirection and Hijacking  . . . . . . . . . . . . 24
+     5.2.  IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
+     5.3.  Denial-of-Service Attacks against Third Parties  . . . . . 25
+     5.4.  Spoofing Network Connectivity Indications  . . . . . . . . 26
+     5.5.  Address and Topology Disclosure  . . . . . . . . . . . . . 27
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 29
+   Appendix A.  Implementation Considerations . . . . . . . . . . . . 31
+     A.1.  Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
+     A.2.  Creating Outbound SAs  . . . . . . . . . . . . . . . . . . 31
+
+
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                     [Page 2]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+1.  Introduction
+
+1.1.  Motivation
+
+   IKEv2 is used for performing mutual authentication, as well as
+   establishing and maintaining IPsec Security Associations (SAs).  In
+   the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec
+   SAs are created implicitly between the IP addresses that are used
+   when the IKE_SA is established.  These IP addresses are then used as
+   the outer (tunnel header) addresses for tunnel mode IPsec packets
+   (transport mode IPsec SAs are beyond the scope of this document).
+   Currently, it is not possible to change these addresses after the
+   IKE_SA has been created.
+
+   There are scenarios where these IP addresses might change.  One
+   example is mobility: a host changes its point of network attachment
+   and receives a new IP address.  Another example is a multihoming host
+   that would like to change to a different interface if, for instance,
+   the currently used interface stops working for some reason.
+
+   Although the problem can be solved by creating new IKE and IPsec SAs
+   when the addresses need to be changed, this may not be optimal for
+   several reasons.  In some cases, creating a new IKE_SA may require
+   user interaction for authentication, such as entering a code from a
+   token card.  Creating new SAs often involves expensive calculations
+   and possibly a large number of round-trips.  For these reasons, a
+   mechanism for updating the IP addresses of existing IKE and IPsec SAs
+   is needed.  The MOBIKE protocol described in this document provides
+   such a mechanism.
+
+   The main scenario for MOBIKE is enabling a remote access VPN user to
+   move from one address to another without re-establishing all security
+   associations with the VPN gateway.  For instance, a user could start
+   from fixed Ethernet in the office and then disconnect the laptop and
+   move to the office's wireless LAN.  When the user leaves the office,
+   the laptop could start using General Packet Radio Service (GPRS);
+   when the user arrives home, the laptop could switch to the home
+   wireless LAN.  MOBIKE updates only the outer (tunnel header)
+   addresses of IPsec SAs, and the addresses and other traffic selectors
+   used inside the tunnel stay unchanged.  Thus, mobility can be
+   (mostly) invisible to applications and their connections using the
+   VPN.
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                     [Page 3]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   MOBIKE also supports more complex scenarios where the VPN gateway
+   also has several network interfaces: these interfaces could be
+   connected to different networks or ISPs, they may be a mix of IPv4
+   and IPv6 addresses, and the addresses may change over time.
+   Furthermore, both parties could be VPN gateways relaying traffic for
+   other parties.
+
+1.2.  Scope and Limitations
+
+   This document focuses on the main scenario outlined above and
+   supports only tunnel mode IPsec SAs.
+
+   The mobility support in MOBIKE allows both parties to move, but does
+   not provide a "rendezvous" mechanism that would allow simultaneous
+   movement of both parties or discovery of the addresses when the
+   IKE_SA is first established.  Therefore, MOBIKE is best suited for
+   situations where the address of at least one endpoint is relatively
+   stable and can be discovered using existing mechanisms such as DNS
+   (see Section 3.1).
+
+   MOBIKE allows both parties to be multihomed; however, only one pair
+   of addresses is used for an SA at a time.  In particular, load
+   balancing is beyond the scope of this specification.
+
+   MOBIKE follows the IKEv2 practice where a response message is sent to
+   the same address and port from which the request was received.  This
+   implies that MOBIKE does not work over address pairs that provide
+   only unidirectional connectivity.
+
+   Network Address Translators (NATs) introduce additional limitations
+   beyond those listed above.  For details, refer to Section 2.3.
+
+   The base version of the MOBIKE protocol does not cover all potential
+   future use scenarios, such as transport mode, application to securing
+   SCTP, or optimizations desirable in specific circumstances.  Future
+   extensions may be defined later to support additional requirements.
+   Please consult the MOBIKE design document [Design] for further
+   information and rationale behind these limitations.
+
+1.3.  Terminology and Notation
+
+   When messages containing IKEv2 payloads are described, optional
+   payloads are shown in brackets (for instance, "[FOO]"), and a plus
+   sign indicates that a payload can be repeated one or more times (for
+   instance, "FOO+").  To provide context, some diagrams also show what
+   existing IKEv2 payloads would typically be included in the exchanges.
+   These payloads are shown for illustrative purposes only; see [IKEv2]
+   for an authoritative description.
+
+
+
+Eronen                      Standards Track                     [Page 4]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   When this document describes updating the source/destination
+   addresses of an IPsec SA, it means updating IPsec-related state so
+   that outgoing Encapsulating Security Payload (ESP)/Authentication
+   Header (AH) packets use those addresses in the tunnel header.
+   Depending on how the nominal divisions between Security Association
+   Database (SAD), Security Policy Database (SPD), and Peer
+   Authorization Database (PAD) described in [IPsecArch] are actually
+   implemented, an implementation can have several different places that
+   have to be updated.
+
+   In this document, the term "initiator" means the party who originally
+   initiated the first IKE_SA (in a series of possibly several rekeyed
+   IKE_SAs); "responder" is the other peer.  During the lifetime of the
+   IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA
+   exchanges; in this case, the terms "exchange initiator" and "exchange
+   responder" are used.  The term "original initiator" (which in [IKEv2]
+   refers to the party who started the latest IKE_SA rekeying) is not
+   used in this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KEYWORDS].
+
+2.  Protocol Overview
+
+2.1.  Basic Operation
+
+   MOBIKE allows both parties to have several addresses, and there are
+   up to N*M pairs of IP addresses that could potentially be used.  The
+   decision of which of these pairs to use has to take into account
+   several factors.  First, the parties may have preferences about which
+   interface should be used due to, for instance, performance and cost
+   reasons.  Second, the decision is constrained by the fact that some
+   of the pairs may not work at all due to incompatible IP versions,
+   outages in the network, problems at the local link at either end, and
+   so on.
+
+   MOBIKE solves this problem by taking a simple approach: the party
+   that initiated the IKE_SA (the "client" in a remote access VPN
+   scenario) is responsible for deciding which address pair is used for
+   the IPsec SAs and for collecting the information it needs to make
+   this decision (such as determining which address pairs work or do not
+   work).  The other party (the "gateway" in a remote access VPN
+   scenario) simply tells the initiator what addresses it has, but does
+   not update the IPsec SAs until it receives a message from the
+   initiator to do so.  This approach applies to the addresses in the
+   IPsec SAs; in the IKE_SA case, the exchange initiator can decide
+   which addresses are used.
+
+
+
+Eronen                      Standards Track                     [Page 5]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   Making the decision at the initiator is consistent with how normal
+   IKEv2 works: the initiator decides which addresses it uses when
+   contacting the responder.  It also makes sense, especially when the
+   initiator is a mobile node: it is in a better position to decide
+   which of its network interfaces should be used for both upstream and
+   downstream traffic.
+
+   The details of exactly how the initiator makes the decision, what
+   information is used in making it, how the information is collected,
+   how preferences affect the decision, and when a decision needs to be
+   changed are largely beyond the scope of MOBIKE.  This does not mean
+   that these details are unimportant: on the contrary, they are likely
+   to be crucial in any real system.  However, MOBIKE is concerned with
+   these details only to the extent that they are visible in IKEv2/IPsec
+   messages exchanged between the peers (and thus need to be
+   standardized to ensure interoperability).
+
+   Many of these issues are not specific to MOBIKE, but are common with
+   the use of existing hosts in dynamic environments or with mobility
+   protocols such as Mobile IP [MIP4] [MIP6].  A number of mechanisms
+   already exist or are being developed to deal with these issues.  For
+   instance, link-layer and IP-layer mechanisms can be used to track the
+   status of connectivity within the local link [RFC2461]; movement
+   detection is being specified for both IPv4 and IPv6 in [DNA4],
+   [DNA6], and so on.
+
+   Naturally, updating the addresses of IPsec SAs has to take into
+   account several security considerations.  MOBIKE includes two
+   features designed to address these considerations.  First, a "return
+   routability" check can be used to verify the addresses provided by
+   the peer.  This makes it more difficult to flood third parties with
+   large amounts of traffic.  Second, a "NAT prohibition" feature
+   ensures that IP addresses have not been modified by NATs, IPv4/IPv6
+   translation agents, or other similar devices.  This feature is
+   enabled only when NAT Traversal is not used.
+
+2.2.  Example Protocol Exchanges
+
+   A simple MOBIKE exchange in a mobile scenario is illustrated below.
+   The notation is based on [IKEv2], Section 1.2.  In addition, the
+   source/destination IP addresses and ports are shown for each packet:
+   here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by
+   the initiator and the responder.
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                     [Page 6]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+      Initiator                  Responder
+     -----------                -----------
+   1) (IP_I1:500 -> IP_R1:500)
+      HDR, SAi1, KEi, Ni,
+           N(NAT_DETECTION_SOURCE_IP),
+           N(NAT_DETECTION_DESTINATION_IP)  -->
+
+                            <--  (IP_R1:500 -> IP_I1:500)
+                                 HDR, SAr1, KEr, Nr,
+                                      N(NAT_DETECTION_SOURCE_IP),
+                                      N(NAT_DETECTION_DESTINATION_IP)
+
+   2) (IP_I1:4500 -> IP_R1:4500)
+      HDR, SK { IDi, CERT, AUTH,
+                CP(CFG_REQUEST),
+                SAi2, TSi, TSr,
+                N(MOBIKE_SUPPORTED) }  -->
+
+                            <--  (IP_R1:4500 -> IP_I1:4500)
+                                 HDR, SK { IDr, CERT, AUTH,
+                                           CP(CFG_REPLY),
+                                           SAr2, TSi, TSr,
+                                           N(MOBIKE_SUPPORTED) }
+
+   (Initiator gets information from lower layers that its attachment
+   point and address have changed.)
+
+   3) (IP_I2:4500 -> IP_R1:4500)
+      HDR, SK { N(UPDATE_SA_ADDRESSES),
+                N(NAT_DETECTION_SOURCE_IP),
+                N(NAT_DETECTION_DESTINATION_IP) }  -->
+
+                            <-- (IP_R1:4500 -> IP_I2:4500)
+                                HDR, SK { N(NAT_DETECTION_SOURCE_IP),
+                                     N(NAT_DETECTION_DESTINATION_IP) }
+
+   (Responder verifies that the initiator has given it a correct IP
+   address.)
+
+   4)                       <-- (IP_R1:4500 -> IP_I2:4500)
+                                HDR, SK { N(COOKIE2) }
+
+      (IP_I2:4500 -> IP_R1:4500)
+      HDR, SK { N(COOKIE2) }  -->
+
+   Step 1 is the normal IKE_INIT exchange.  In step 2, the peers inform
+   each other that they support MOBIKE.  In step 3, the initiator
+   notices a change in its own address, and informs the responder about
+
+
+
+Eronen                      Standards Track                     [Page 7]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   this by sending an INFORMATIONAL request containing the
+   UPDATE_SA_ADDRESSES notification.  The request is sent using the new
+   IP address.  At this point, it also starts to use the new address as
+   a source address in its own outgoing ESP traffic.  Upon receiving the
+   UPDATE_SA_ADDRESSES notification, the responder records the new
+   address and, if it is required by policy, performs a return
+   routability check of the address.  When this check (step 4)
+   completes, the responder starts to use the new address as the
+   destination for its outgoing ESP traffic.
+
+   Another protocol run in a multihoming scenario is illustrated below.
+   In this scenario, the initiator has one address but the responder has
+   two.
+
+      Initiator                  Responder
+     -----------                -----------
+   1) (IP_I1:500 -> IP_R1:500)
+      HDR, SAi1, KEi, Ni,
+           N(NAT_DETECTION_SOURCE_IP),
+           N(NAT_DETECTION_DESTINATION_IP)  -->
+
+                            <--  (IP_R1:500 -> IP_I1:500)
+                                 HDR, SAr1, KEr, Nr,
+                                      N(NAT_DETECTION_SOURCE_IP),
+                                      N(NAT_DETECTION_DESTINATION_IP)
+
+   2) (IP_I1:4500 -> IP_R1:4500)
+      HDR, SK { IDi, CERT, AUTH,
+                CP(CFG_REQUEST),
+                SAi2, TSi, TSr,
+                N(MOBIKE_SUPPORTED) }  -->
+
+                            <--  (IP_R1:4500 -> IP_I1:4500)
+                                 HDR, SK { IDr, CERT, AUTH,
+                                           CP(CFG_REPLY),
+                                           SAr2, TSi, TSr,
+                                           N(MOBIKE_SUPPORTED),
+                                           N(ADDITIONAL_IP4_ADDRESS) }
+
+   (The initiator suspects a problem in the currently used address pair
+   and probes its liveness.)
+
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                     [Page 8]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   3) (IP_I1:4500 -> IP_R1:4500)
+      HDR, SK { N(NAT_DETECTION_SOURCE_IP),
+                N(NAT_DETECTION_DESTINATION_IP) }  -->
+
+      (IP_I1:4500 -> IP_R1:4500)
+      HDR, SK { N(NAT_DETECTION_SOURCE_IP),
+                N(NAT_DETECTION_DESTINATION_IP) }  -->
+
+      ...
+
+   (Eventually, the initiator gives up on the current address pair and
+   tests the other available address pair.)
+
+   4) (IP_I1:4500 -> IP_R2:4500)
+      HDR, SK { N(NAT_DETECTION_SOURCE_IP),
+                N(NAT_DETECTION_DESTINATION_IP) }
+
+                            <--  (IP_R2:4500 -> IP_I1:4500)
+                                 HDR, SK { N(NAT_DETECTION_SOURCE_IP),
+                                      N(NAT_DETECTION_DESTINATION_IP) }
+
+   (This worked, and the initiator requests the peer to switch to new
+   addresses.)
+
+   5) (IP_I1:4500 -> IP_R2:4500)
+      HDR, SK { N(UPDATE_SA_ADDRESSES),
+                N(NAT_DETECTION_SOURCE_IP),
+                N(NAT_DETECTION_DESTINATION_IP),
+                N(COOKIE2) }  -->
+
+                            <--  (IP_R2:4500 -> IP_I1:4500)
+                                 HDR, SK { N(NAT_DETECTION_SOURCE_IP),
+                                      N(NAT_DETECTION_DESTINATION_IP),
+                                      N(COOKIE2) }
+
+2.3.  MOBIKE and Network Address Translation (NAT)
+
+   In some MOBIKE scenarios, the network may contain NATs or stateful
+   packet filters (for brevity, the rest of this document simply
+   describes NATs).  The NAT Traversal feature specified in [IKEv2]
+   allows IKEv2 to work through NATs in many cases, and MOBIKE can
+   leverage this functionality: when the addresses used for IPsec SAs
+   are changed, MOBIKE can enable or disable IKEv2 NAT Traversal, as
+   needed.
+
+   Nevertheless, there are some limitations because NATs usually
+   introduce an asymmetry into the network: only packets coming from the
+   "inside" cause state to be created.  This asymmetry leads to
+
+
+
+Eronen                      Standards Track                     [Page 9]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   restrictions on what MOBIKE can do.  To give a concrete example,
+   consider a situation where both peers have only a single address, and
+   the initiator is behind a NAT.  If the responder's address now
+   changes, it needs to send a packet to the initiator using its new
+   address.  However, if the NAT is, for instance, of the common
+   "restricted cone" type (see [STUN] for one description of different
+   NAT types), this is not possible.  The NAT will drop packets sent
+   from the new address (unless the initiator has previously sent a
+   packet to that address -- which it cannot do until it knows the
+   address).
+
+   For simplicity, MOBIKE does not attempt to handle all possible NAT-
+   related scenarios.  Instead, MOBIKE assumes that if NATs are present,
+   the initiator is the party "behind" the NAT, and the case where the
+   responder's addresses change is not fully supported (meaning that no
+   special effort is made to support this functionality).  Responders
+   may also be unaware of NATs or specific types of NATs they are
+   behind.  However, when a change has occurred that will cause a loss
+   of connectivity, MOBIKE responders will still attempt to inform the
+   initiator of the change.  Depending on, for instance, the exact type
+   of NAT, it may or may not succeed.  However, analyzing the exact
+   circumstances when this will or will not work is not done in this
+   document.
+
+3.  Protocol Exchanges
+
+3.1.  Initial IKE Exchange
+
+   The initiator is responsible for finding a working pair of addresses
+   so that the initial IKE exchange can be carried out.  Any information
+   from MOBIKE extensions will only be available later, when the
+   exchange has progressed far enough.  Exactly how the addresses used
+   for the initial exchange are discovered is beyond the scope of this
+   specification; typical sources of information include local
+   configuration and DNS.
+
+   If either or both of the peers have multiple addresses, some
+   combinations may not work.  Thus, the initiator SHOULD try various
+   source and destination address combinations when retransmitting the
+   IKE_SA_INIT request.
+
+3.2.  Signaling Support for MOBIKE
+
+   Implementations that wish to use MOBIKE for a particular IKE_SA MUST
+   include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
+   case of multiple IKE_AUTH exchanges, in the message containing the SA
+   payload).
+
+
+
+
+Eronen                      Standards Track                    [Page 10]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   The format of the MOBIKE_SUPPORTED notification is described in
+   Section 4.
+
+3.3.  Initial Tunnel Header Addresses
+
+   When an IPsec SA is created, the tunnel header IP addresses (and
+   port, if doing UDP encapsulation) are taken from the IKE_SA, not the
+   IP header of the IKEv2 message requesting the IPsec SA.  The
+   addresses in the IKE_SA are initialized from the IP header of the
+   first IKE_AUTH request.
+
+   The addresses are taken from the IKE_AUTH request because IKEv2
+   requires changing from port 500 to 4500 if a NAT is discovered.  To
+   simplify things, implementations that support both this specification
+   and NAT Traversal MUST change to port 4500 if the correspondent also
+   supports both, even if no NAT was detected between them (this way,
+   there is no need to change the ports later if a NAT is detected on
+   some other path).
+
+3.4.  Additional Addresses
+
+   Both the initiator and responder MAY include one or more
+   ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in
+   the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the
+   message containing the SA payload).  Here "ADDITIONAL_*_ADDRESS"
+   means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS
+   notification.
+
+      Initiator                  Responder
+     -----------                -----------
+      HDR, SK { IDi, [CERT], [IDr], AUTH,
+                [CP(CFG_REQUEST)]
+                SAi2, TSi, TSr,
+                N(MOBIKE_SUPPORTED),
+                [N(ADDITIONAL_*_ADDRESS)+] }  -->
+
+                            <--  HDR, SK { IDr, [CERT], AUTH,
+                                           [CP(CFG_REPLY)],
+                                           SAr2, TSi, TSr,
+                                           N(MOBIKE_SUPPORTED)
+                                           [N(ADDITIONAL_*_ADDRESS)+] }
+
+   The recipient stores this information, but no other action is taken
+   at this time.
+
+   Although both the initiator and responder maintain a set of peer
+   addresses (logically associated with the IKE_SA), it is important to
+   note that they use this information for slightly different purposes.
+
+
+
+Eronen                      Standards Track                    [Page 11]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   The initiator uses the set of responder addresses as an input to its
+   address selection policy; it may, at some later point, decide to move
+   the IPsec traffic to one of these addresses using the procedure
+   described in Section 3.5.  The responder normally does not use the
+   set of initiator addresses for anything: the addresses are used only
+   when the responder's own addresses change (see Section 3.6).
+
+   The set of addresses available to the peers can change during the
+   lifetime of the IKE_SA.  The procedure for updating this information
+   is described in Section 3.6.
+
+   Note that if some of the initiator's interfaces are behind a NAT
+   (from the responder's point of view), the addresses received by the
+   responder will be incorrect.  This means the procedure for changing
+   responder addresses described in Section 3.6 does not fully work when
+   the initiator is behind a NAT.  For the same reason, the peers also
+   SHOULD NOT use this information for any other purpose than what is
+   explicitly described either in this document or a future
+   specification updating it.
+
+3.5.  Changing Addresses in IPsec SAs
+
+   In MOBIKE, the initiator decides what addresses are used in the IPsec
+   SAs.  That is, the responder does not normally update any IPsec SAs
+   without receiving an explicit UPDATE_SA_ADDRESSES request from the
+   initiator.  (As described below, the responder can, however, update
+   the IKE_SA in some circumstances.)
+
+   The reasons why the initiator wishes to change the addresses are
+   largely beyond the scope of MOBIKE.  Typically, triggers include
+   information received from lower layers, such as changes in IP
+   addresses or link-down indications.  Some of this information can be
+   unreliable: for instance, ICMP messages could be spoofed by an
+   attacker.  Unreliable information SHOULD be treated only as a hint
+   that there might be a problem, and the initiator SHOULD trigger Dead
+   Peer Detection (that is, send an INFORMATIONAL request) to determine
+   if the current path is still usable.
+
+   Changing addresses can also be triggered by events within IKEv2.  At
+   least the following events can cause the initiator to re-evaluate its
+   local address selection policy, possibly leading to changing the
+   addresses.
+
+   o  An IKEv2 request has been re-transmitted several times, but no
+      valid reply has been received.  This suggests the current path is
+      no longer working.
+
+
+
+
+
+Eronen                      Standards Track                    [Page 12]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   o  An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS,
+      ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
+      received.  This means the peer's addresses may have changed.  This
+      is particularly important if the announced set of addresses no
+      longer contains the currently used address.
+
+   o  An UNACCEPTABLE_ADDRESSES notification is received as a response
+      to address update request (described below).
+
+   o  The initiator receives a NAT_DETECTION_DESTINATION_IP notification
+      that does not match the previous UPDATE_SA_ADDRESSES response (see
+      Section 3.8 for a more detailed description).
+
+   The description in the rest of this section assumes that the
+   initiator has already decided what the new addresses should be.  When
+   this decision has been made, the initiator:
+
+   o  Updates the IKE_SA with the new addresses, and sets the
+      "pending_update" flag in the IKE_SA.
+
+   o  Updates the IPsec SAs associated with this IKE_SA with the new
+      addresses (unless the initiator's policy requires a return
+      routability check before updating the IPsec SAs, and the check has
+      not been done for this responder address yet).
+
+   o  If the IPsec SAs were updated in the previous step: If NAT
+      Traversal is not enabled, and the responder supports NAT Traversal
+      (as indicated by NAT detection payloads in the IKE_SA_INIT
+      exchange), and the initiator either suspects or knows that a NAT
+      is likely to be present, enables NAT Traversal (that is, enables
+      UDP encapsulation of outgoing ESP packets and sending of NAT-
+      Keepalive packets).
+
+   o  If there are outstanding IKEv2 requests (requests for which the
+      initiator has not yet received a reply), continues retransmitting
+      them using the addresses in the IKE_SA (the new addresses).
+
+   o  When the window size allows, sends an INFORMATIONAL request
+      containing the UPDATE_SA_ADDRESSES notification (which does not
+      contain any data), and clears the "pending_update" flag.  The
+      request will be as follows:
+
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 13]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+      Initiator                  Responder
+     -----------                -----------
+      HDR, SK { N(UPDATE_SA_ADDRESSES),
+                [N(NAT_DETECTION_SOURCE_IP),
+                 N(NAT_DETECTION_DESTINATION_IP)],
+                [N(NO_NATS_ALLOWED)],
+                [N(COOKIE2)] } -->
+
+   o  If a new address change occurs while waiting for the response,
+      starts again from the first step (and ignores responses to this
+      UPDATE_SA_ADDRESSES request).
+
+   When processing an INFORMATIONAL request containing the
+   UPDATE_SA_ADDRESSES notification, the responder:
+
+   o  Determines whether it has already received a newer
+      UPDATE_SA_ADDRESSES request than this one (if the responder uses a
+      window size greater than one, it is possible that requests are
+      received out of order).  If it has, a normal response message
+      (described below) is sent, but no other action is taken.
+
+   o  If the NO_NATS_ALLOWED notification is present, processes it as
+      described in Section 3.9.
+
+   o  Checks that the (source IP address, destination IP address) pair
+      in the IP header is acceptable according to local policy.  If it
+      is not, replies with a message containing the
+      UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
+
+   o  Updates the IP addresses in the IKE_SA with the values from the IP
+      header.  (Using the address from the IP header is consistent with
+      normal IKEv2, and allows IKEv2 to work with NATs without needing
+      unilateral self-address fixing [UNSAF].)
+
+   o  Replies with an INFORMATIONAL response:
+
+      Initiator                  Responder
+     -----------                -----------
+                            <--  HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
+                                      N(NAT_DETECTION_DESTINATION_IP)],
+                                      [N(COOKIE2)] }
+
+   o  If necessary, initiates a return routability check for the new
+      initiator address (see Section 3.7) and waits until the check is
+      completed.
+
+   o  Updates the IPsec SAs associated with this IKE_SA with the new
+      addresses.
+
+
+
+Eronen                      Standards Track                    [Page 14]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   o  If NAT Traversal is supported and NAT detection payloads were
+      included, enables or disables NAT Traversal.
+
+   When the initiator receives the reply:
+
+   o  If an address change has occurred after the request was first
+      sent, no MOBIKE processing is done for the reply message because a
+      new UPDATE_SA_ADDRESSES is going to be sent (or has already been
+      sent, if window size greater than one is in use).
+
+   o  If the response contains the UNEXPECTED_NAT_DETECTED notification,
+      the initiator processes the response as described in Section 3.9.
+
+   o  If the response contains an UNACCEPTABLE_ADDRESSES notification,
+      the initiator MAY select another addresses and retry the exchange,
+      keep on using the previously used addresses, or disconnect.
+
+   o  It updates the IPsec SAs associated with this IKE_SA with the new
+      addresses (unless this was already done earlier before sending the
+      request; this is the case when no return routability check was
+      required).
+
+   o  If NAT Traversal is supported and NAT detection payloads were
+      included, the initiator enables or disables NAT Traversal.
+
+   There is one exception to the rule that the responder never updates
+   any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request.  If
+   the source address that the responder is currently using becomes
+   unavailable (i.e., sending packets using that source address is no
+   longer possible), the responder is allowed to update the IPsec SAs to
+   use some other address (in addition to initiating the procedure
+   described in the next section).
+
+3.6.  Updating Additional Addresses
+
+   As described in Section 3.4, both the initiator and responder can
+   send a list of additional addresses in the IKE_AUTH exchange.  This
+   information can be updated by sending an INFORMATIONAL exchange
+   request message that contains either one or more
+   ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the
+   NO_ADDITIONAL_ADDRESSES notification.
+
+   If the exchange initiator has only a single IP address, it is placed
+   in the IP header, and the message contains the
+   NO_ADDITIONAL_ADDRESSES notification.  If the exchange initiator has
+   several addresses, one of them is placed in the IP header, and the
+   rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.
+
+
+
+
+Eronen                      Standards Track                    [Page 15]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   The new list of addresses replaces the old information (in other
+   words, there are no separate add/delete operations; instead, the
+   complete list is sent every time these notifications are used).
+
+   The message exchange will look as follows:
+
+      Initiator                  Responder
+     -----------                -----------
+      HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
+                [N(NO_ADDITIONAL_ADDRESSES)],
+                [N(NO_NATS_ALLOWED)],
+                [N(COOKIE2)] }  -->
+
+                            <--  HDR, SK { [N(COOKIE2)] }
+
+   When a request containing an ADDITIONAL_IP4_ADDRESS,
+   ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
+   received, the exchange responder:
+
+   o  Determines whether it has already received a newer request to
+      update the addresses (if a window size greater than one is used,
+      it is possible that the requests are received out of order).  If
+      it has, a response message is sent, but the address set is not
+      updated.
+
+   o  If the NO_NATS_ALLOWED notification is present, processes it as
+      described in Section 3.9.
+
+   o  Updates the set of peer addresses based on the IP header and the
+      ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and
+      NO_ADDITIONAL_ADDRESSES notifications.
+
+   o  Sends a response.
+
+   The initiator MAY include these notifications in the same request as
+   UPDATE_SA_ADDRESSES.
+
+   If the request to update the addresses is retransmitted using several
+   different source addresses, a new INFORMATIONAL request MUST be sent.
+
+   There is one additional complication: when the responder wants to
+   update the address set, the currently used addresses may no longer
+   work.  In this case, the responder uses the additional address list
+   received from the initiator, and the list of its own addresses, to
+   determine which addresses to use for sending the INFORMATIONAL
+   request.  This is the only time the responder uses the additional
+   address list received from the initiator.
+
+
+
+
+Eronen                      Standards Track                    [Page 16]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   Note that both peers can have their own policies about what addresses
+   are acceptable to use, and certain types of policies may simplify
+   implementation.  For instance, if the responder has a single fixed
+   address, it does not need to process the ADDITIONAL_IP4_ADDRESS and
+   ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring
+   unrecognized status notifications, as already required in [IKEv2]).
+   Furthermore, if the initiator has a policy saying that only the
+   responder address specified in local configuration is acceptable, it
+   does not have to send its own additional addresses to the responder
+   (since the responder does not need them except when changing its own
+   address).
+
+3.7.  Return Routability Check
+
+   Both parties can optionally verify that the other party can actually
+   receive packets at the claimed address.  By default, this "return
+   routability check" SHOULD be performed.  In environments where the
+   peer is expected to be well-behaved (many corporate VPNs, for
+   instance), or the address can be verified by some other means (e.g.,
+   a certificate issued by an authority trusted for this purpose), the
+   return routability check MAY be omitted.
+
+   The check can be done before updating the IPsec SAs, immediately
+   after updating them, or continuously during the connection.  By
+   default, the return routability check SHOULD be done before updating
+   the IPsec SAs, but in some environments it MAY be postponed until
+   after the IPsec SAs have been updated.
+
+   Any INFORMATIONAL exchange can be used for return routability
+   purposes, with one exception (described later in this section): when
+   a valid response is received, we know the other party can receive
+   packets at the claimed address.
+
+   To ensure that the peer cannot generate the correct INFORMATIONAL
+   response without seeing the request, a new payload is added to
+   INFORMATIONAL messages.  The sender of an INFORMATIONAL request MAY
+   include a COOKIE2 notification, and if included, the recipient of an
+   INFORMATIONAL request MUST copy the notification as-is to the
+   response.  When processing the response, the original sender MUST
+   verify that the value is the same one as sent.  If the values do not
+   match, the IKE_SA MUST be closed.  (See also Section 4.2.5 for the
+   format of the COOKIE2 notification.)
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 17]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   The exception mentioned earlier is as follows: If the same
+   INFORMATIONAL request has been sent to several different addresses
+   (i.e., the destination address in the IKE_SA has been updated after
+   the request was first sent), receiving the INFORMATIONAL response
+   does not tell which address is the working one.  In this case, a new
+   INFORMATIONAL request needs to be sent to check return routability.
+
+3.8.  Changes in NAT Mappings
+
+   IKEv2 performs Dead Peer Detection (DPD) if there has recently been
+   only outgoing traffic on all of the SAs associated with the IKE_SA.
+
+   In MOBIKE, these messages can also be used to detect if NAT mappings
+   have changed (for example, if the keepalive interval is too long, or
+   the NAT box is rebooted).  More specifically, if both peers support
+   both this specification and NAT Traversal, the
+   NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
+   notifications MAY be included in any INFORMATIONAL request; if the
+   request includes them, the responder MUST also include them in the
+   response (but no other action is taken, unless otherwise specified).
+
+   When the initiator is behind a NAT (as detected earlier using the
+   NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
+   notifications), it SHOULD include these notifications in DPD messages
+   and compare the received NAT_DETECTION_DESTINATION_IP notifications
+   with the value from the previous UPDATE_SA_ADDRESSES response (or the
+   IKE_SA_INIT response).  If the values do not match, the IP address
+   and/or port seen by the responder has changed, and the initiator
+   SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5.  If the
+   initiator suspects that the NAT mapping has changed, it MAY also skip
+   the detection step and send UPDATE_SA_ADDRESSES immediately.  This
+   saves one roundtrip if the NAT mapping has indeed changed.
+
+   Note that this approach to detecting NAT mapping changes may cause an
+   extra address update when the IKE_SA is rekeyed.  This is because the
+   NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security
+   Parameter Indexes (SPIs), which change when performing rekeying.
+   This unnecessary update is harmless, however.
+
+   When MOBIKE is in use, the dynamic updates (specified in [IKEv2],
+   Section 2.23), where the peer address and port are updated from the
+   last valid authenticated packet, work in a slightly different
+   fashion.  The host not behind a NAT MUST NOT use these dynamic
+   updates for IKEv2 packets, but MAY use them for ESP packets.  This
+   ensures that an INFORMATIONAL exchange that does not contain
+   UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
+   used for, e.g., testing whether a particular path works.
+
+
+
+
+Eronen                      Standards Track                    [Page 18]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+3.9.  NAT Prohibition
+
+   Basic IKEv2/IPsec without NAT Traversal support may work across some
+   types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in
+   tunnel mode.  This is because the IKEv2 integrity checksum does not
+   cover the addresses in the IP header.  This may be considered a
+   problem in some circumstances, because in some sense any modification
+   of the IP addresses can be considered an attack.
+
+   This specification addresses the issue by protecting the IP addresses
+   when NAT Traversal has not been explicitly enabled.  This means that
+   MOBIKE without NAT Traversal support will not work if the paths
+   contain NATs, IPv4/IPv6 translation agents, or other nodes that
+   modify the addresses in the IP header.  This feature is mainly
+   intended for IPv6 and site-to-site VPN cases, where the
+   administrators may know beforehand that NATs are not present, and
+   thus any modification to the packet can be considered an attack.
+
+   More specifically, when NAT Traversal is not enabled, all messages
+   that can update the addresses associated with the IKE_SA and/or IPsec
+   SAs (the first IKE_AUTH request and all INFORMATIONAL requests that
+   contain any of the following notifications: UPDATE_SA_ADDRESSES,
+   ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS,
+   NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED
+   notification.  The exchange responder MUST verify that the contents
+   of the NO_NATS_ALLOWED notification match the addresses in the IP
+   header.  If they do not match, a response containing an
+   UNEXPECTED_NAT_DETECTED notification is sent.  The response message
+   is sent to the address and port that the corresponding request came
+   from, not to the address contained in the NO_NATS_ALLOWED
+   notification.
+
+   If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
+   notification in response to its INFORMATIONAL request, it SHOULD
+   retry the operation several times using new INFORMATIONAL requests.
+   Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
+   IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
+   times, starting from a new IKE_SA_INIT request.  This ensures that an
+   attacker who is able to modify only a single packet does not
+   unnecessarily cause a path to remain unused.  The exact number of
+   retries is not specified in this document because it does not affect
+   interoperability.  However, because the IKE message will also be
+   rejected if the attacker modifies the integrity checksum field, a
+   reasonable number here would be the number of retries that is being
+   used for normal retransmissions.
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 19]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
+   responder MUST NOT use the contents of the NO_NATS_ALLOWED
+   notification for any other purpose than possibly logging the
+   information for troubleshooting purposes.
+
+3.10.  Path Testing
+
+   IKEv2 Dead Peer Detection allows the peers to detect if the currently
+   used path has stopped working.  However, if either of the peers has
+   several addresses, Dead Peer Detection alone does not tell which of
+   the other paths might work.
+
+   If required by its address selection policy, the initiator can use
+   normal IKEv2 INFORMATIONAL request/response messages to test whether
+   a certain path works.  Implementations MAY do path testing even if
+   the path currently being used is working to, for example, detect when
+   a better (but previously unavailable) path becomes available.
+
+3.11.  Failure Recovery and Timeouts
+
+   In MOBIKE, the initiator is responsible for detecting and recovering
+   from most failures.
+
+   To give the initiator enough time to detect the error, the responder
+   SHOULD use relatively long timeout intervals when, for instance,
+   retransmitting IKEv2 requests or deciding whether to initiate Dead
+   Peer Detection.  While no specific timeout lengths are required, it
+   is suggested that responders continue retransmitting IKEv2 requests
+   for at least five minutes before giving up.
+
+3.12.  Dead Peer Detection
+
+   MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but
+   as addresses may change, it is not sufficient to just verify that the
+   peer is alive, but also that it is synchronized with the address
+   updates and has not, for instance, ignored an address update due to
+   failure to complete return routability test.  This means that when
+   there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the
+   addresses used in those packets and determine that they correspond to
+   those that should be employed.  If they do not, such packets SHOULD
+   NOT be used as evidence that the peer is able to communicate with
+   this node and or that the peer has received all address updates.
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 20]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+4.  Payload Formats
+
+   This specification defines several new IKEv2 Notify payload types.
+   See [IKEv2], Section 3.10, for a general description of the Notify
+   payload.
+
+4.1.  Notify Messages - Error Types
+
+4.1.1.  UNACCEPTABLE_ADDRESSES Notify Payload
+
+   The responder can include this notification in an INFORMATIONAL
+   exchange response to indicate that the address change in the
+   corresponding request message (which contained an UPDATE_SA_ADDRESSES
+   notification) was not carried out.
+
+   The Notify Message Type for UNACCEPTABLE_ADDRESSES is 40.  The
+   Protocol ID and SPI Size fields are set to zero.  There is no data
+   associated with this Notify type.
+
+4.1.2.  UNEXPECTED_NAT_DETECTED Notify Payload
+
+   See Section 3.9 for a description of this notification.
+
+   The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41.  The
+   Protocol ID and SPI Size fields are set to zero.  There is no data
+   associated with this Notify type.
+
+4.2.  Notify Messages - Status Types
+
+4.2.1.  MOBIKE_SUPPORTED Notify Payload
+
+   The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
+   exchange to indicate that the implementation supports this
+   specification.
+
+   The Notify Message Type for MOBIKE_SUPPORTED is 16396.  The Protocol
+   ID and SPI Size fields are set to zero.  The notification data field
+   MUST be left empty (zero-length) when sending, and its contents (if
+   any) MUST be ignored when this notification is received.  This allows
+   the field to be used by future versions of this protocol.
+
+4.2.2.  ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify
+        Payloads
+
+   Both parties can include ADDITIONAL_IP4_ADDRESS and/or
+   ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and
+   INFORMATIONAL exchange request messages; see Section 3.4 and
+   Section 3.6 for more detailed description.
+
+
+
+Eronen                      Standards Track                    [Page 21]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
+   ADDITIONAL_IP6_ADDRESS are 16397 and 16398, respectively.  The
+   Protocol ID and SPI Size fields are set to zero.  The data associated
+   with these Notify types is either a four-octet IPv4 address or a
+   16-octet IPv6 address.
+
+4.2.3.  NO_ADDITIONAL_ADDRESSES Notify Payload
+
+   The NO_ADDITIONAL_ADDRESSES notification can be included in an
+   INFORMATIONAL exchange request message to indicate that the exchange
+   initiator does not have addresses beyond the one used in the exchange
+   (see Section 3.6 for more detailed description).
+
+   The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399.  The
+   Protocol ID and SPI Size fields are set to zero.  There is no data
+   associated with this Notify type.
+
+4.2.4.  UPDATE_SA_ADDRESSES Notify Payload
+
+   This notification is included in INFORMATIONAL exchange requests sent
+   by the initiator to update addresses of the IKE_SA and IPsec SAs (see
+   Section 3.5).
+
+   The Notify Message Type for UPDATE_SA_ADDRESSES is 16400.  The
+   Protocol ID and SPI Size fields are set to zero.  There is no data
+   associated with this Notify type.
+
+4.2.5.  COOKIE2 Notify Payload
+
+   This notification MAY be included in any INFORMATIONAL request for
+   return routability check purposes (see Section 3.7).  If the
+   INFORMATIONAL request includes COOKIE2, the exchange responder MUST
+   copy the notification to the response message.
+
+   The data associated with this notification MUST be between 8 and 64
+   octets in length (inclusive), and MUST be chosen by the exchange
+   initiator in a way that is unpredictable to the exchange responder.
+   The Notify Message Type for this message is 16401.  The Protocol ID
+   and SPI Size fields are set to zero.
+
+4.2.6.  NO_NATS_ALLOWED Notify Payload
+
+   See Section 3.9 for a description of this notification.
+
+   The Notify Message Type for this message is 16402.  The notification
+   data contains the IP addresses and ports from/to which the packet was
+   sent.  For IPv4, the notification data is 12 octets long and is
+   defined as follows:
+
+
+
+Eronen                      Standards Track                    [Page 22]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+                           1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                      Source IPv4 address                      !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                   Destination IPv4 address                    !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !          Source port          !       Destination port        !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   For IPv6, the notification data is 36 octets long and is defined as
+   follows:
+
+                           1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                                                               !
+      !                      Source IPv6 address                      !
+      !                                                               !
+      !                                                               !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !                                                               !
+      !                   Destination IPv6 address                    !
+      !                                                               !
+      !                                                               !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      !          Source port          !       Destination port        !
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Protocol ID and SPI Size fields are set to zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 23]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+5.  Security Considerations
+
+   The main goals of this specification are to maintain the security
+   offered by usual IKEv2 procedures and to counter mobility-related
+   threats in an appropriate manner.  This section describes new
+   security considerations introduced by MOBIKE.  See [IKEv2] for
+   security considerations for IKEv2 in general.
+
+5.1.  Traffic Redirection and Hijacking
+
+   MOBIKE payloads relating to updating addresses are encrypted,
+   integrity protected, and replay protected using the IKE_SA.  This
+   assures that no one except the participants can, for instance, give a
+   control message to change the addresses.
+
+   However, as with normal IKEv2, the actual IP addresses in the IP
+   header are not covered by the integrity protection.  This means that
+   a NAT between the parties (or an attacker acting as a NAT) can modify
+   the addresses and cause incorrect tunnel header (outer) IP addresses
+   to be used for IPsec SAs.  The scope of this attack is limited mainly
+   to denial of service because all traffic is protected using IPsec.
+
+   This attack can only be launched by on-path attackers that are
+   capable of modifying IKEv2 messages carrying NAT detection payloads
+   (such as Dead Peer Detection messages).  By modifying the IP header
+   of these packets, the attackers can lead the peers to believe a new
+   NAT or a changed NAT binding exists between them.  The attack can
+   continue as long as the attacker is on the path, modifying the IKEv2
+   messages.  If this is no longer the case, IKEv2 and MOBIKE mechanisms
+   designed to detect NAT mapping changes will eventually recognize that
+   the intended traffic is not getting through, and will update the
+   addresses appropriately.
+
+   MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
+   detect modification, by outsiders, of the addresses in the IP header.
+   When this notification is used, communication through NATs and other
+   address translators is impossible, so it is sent only when not doing
+   NAT Traversal.  This feature is mainly intended for IPv6 and site-to-
+   site VPN cases, where the administrators may know beforehand that
+   NATs are not present.
+
+5.2.  IPsec Payload Protection
+
+   The use of IPsec protection on payload traffic protects the
+   participants against disclosure of the contents of the traffic,
+   should the traffic end up in an incorrect destination or be subject
+   to eavesdropping.
+
+
+
+
+Eronen                      Standards Track                    [Page 24]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   However, security associations originally created for the protection
+   of a specific flow between specific addresses may be updated by
+   MOBIKE later on.  This has to be taken into account if the (outer) IP
+   address of the peer was used when deciding what kind of IPsec SAs the
+   peer is allowed to create.
+
+   For instance, the level of required protection might depend on the
+   current location of the VPN client, or access might be allowed only
+   from certain IP addresses.
+
+   It is recommended that security policies, for peers that are allowed
+   to use MOBIKE, are configured in a manner that takes into account
+   that a single security association can be used at different times
+   through paths of varying security properties.
+
+   This is especially critical for traffic selector authorization.  The
+   (logical) Peer Authorization Database (PAD) contains the information
+   used by IKEv2 when determining what kind of IPsec SAs a peer is
+   allowed to create.  This process is described in [IPsecArch], Section
+   4.4.3.  When a peer requests the creation of an IPsec SA with some
+   traffic selectors, the PAD must contain "Child SA Authorization Data"
+   linking the identity authenticated by IKEv2 and the addresses
+   permitted for traffic selectors.  See also [Clarifications] for a
+   more extensive discussion.
+
+   It is important to note that simply sending IKEv2 packets using some
+   particular address does not automatically imply a permission to
+   create IPsec SAs with that address in the traffic selectors.
+   However, some implementations are known to use policies where simply
+   being reachable at some address X implies a temporary permission to
+   create IPsec SAs for address X.  Here "being reachable" usually means
+   the ability to send (or spoof) IP packets with source address X and
+   receive (or eavesdrop) packets sent to X.
+
+   Using this kind of policies or extensions with MOBIKE may need
+   special care to enforce the temporary nature of the permission.  For
+   example, when the peer moves to some other address Y (and is no
+   longer reachable at X), it might be necessary to close IPsec SAs with
+   traffic selectors matching X.  However, these interactions are beyond
+   the scope of this document.
+
+5.3.  Denial-of-Service Attacks against Third Parties
+
+   Traffic redirection may be performed not just to gain access to the
+   traffic or to deny service to the peers, but also to cause a denial-
+   of-service attack on a third party.  For instance, a high-speed TCP
+   session or a multimedia stream may be redirected towards a victim
+   host, causing its communications capabilities to suffer.
+
+
+
+Eronen                      Standards Track                    [Page 25]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   The attackers in this threat can be either outsiders or even one of
+   the IKEv2 peers.  In usual VPN usage scenarios, attacks by the peers
+   can be easily dealt with if the authentication performed in the
+   initial IKEv2 negotiation can be traced to persons who can be held
+   responsible for the attack.  This may not be the case in all
+   scenarios, particularly with opportunistic approaches to security.
+
+   If the attack is launched by an outsider, the traffic flow would
+   normally stop soon due to the lack of responses (such as transport
+   layer acknowledgements).  However, if the original recipient of the
+   flow is malicious, it could maintain the traffic flow for an extended
+   period of time, since it often would be able to send the required
+   acknowledgements (see [Aura02] for more discussion).
+
+   It should also be noted, as shown in [Bombing], that without ingress
+   filtering in the attacker's network, such attacks are already
+   possible simply by sending spoofed packets from the attacker to the
+   victim directly.  Furthermore, if the attacker's network has ingress
+   filtering, this attack is largely prevented for MOBIKE as well.
+   Consequently, it makes little sense to protect against attacks of
+   similar nature in MOBIKE.  However, it still makes sense to limit the
+   amplification capabilities provided to attackers, so that they cannot
+   use stream redirection to send a large number of packets to the
+   victim by sending just a few packets themselves.
+
+   This specification includes return routability tests to limit the
+   duration of any "third party bombing" attacks by off-path (relative
+   to the victim) attackers.  The tests are authenticated messages that
+   the peer has to respond to, and can be performed before the address
+   change takes effect, immediately afterwards, or even periodically
+   during the session.  The tests contain unpredictable data, and only
+   someone who has the keys associated with the IKE SA and has seen the
+   request packet can properly respond to the test.
+
+   The duration of the attack can also be limited if the victim reports
+   the unwanted traffic to the originating IPsec tunnel endpoint using
+   ICMP error messages or INVALID_SPI notifications.  As described in
+   [IKEv2], Section 2.21, this SHOULD trigger a liveness test, which
+   also doubles as a return routability check if the COOKIE2
+   notification is included.
+
+5.4.  Spoofing Network Connectivity Indications
+
+   Attackers may spoof various indications from lower layers and the
+   network in an effort to confuse the peers about which addresses are
+   or are not working.  For example, attackers may spoof link-layer
+   error messages in an effort to cause the parties to move their
+   traffic elsewhere or even to disconnect.  Attackers may also spoof
+
+
+
+Eronen                      Standards Track                    [Page 26]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   information related to network attachments, router discovery, and
+   address assignments in an effort to make the parties believe they
+   have Internet connectivity when, in reality, they do not.
+
+   This may cause use of non-preferred addresses or even denial of
+   service.
+
+   MOBIKE does not provide any protection of its own for indications
+   from other parts of the protocol stack.  These vulnerabilities can be
+   mitigated through the use of techniques specific to the other parts
+   of the stack, such as validation of ICMP errors [ICMPAttacks], link
+   layer security, or the use of [SEND] to protect IPv6 Router and
+   Neighbor Discovery.
+
+   Ultimately, MOBIKE depends on the delivery of IKEv2 messages to
+   determine which paths can be used.  If IKEv2 messages sent using a
+   particular source and destination addresses reach the recipient and a
+   reply is received, MOBIKE will usually consider the path working; if
+   no reply is received even after retransmissions, MOBIKE will suspect
+   the path is broken.  An attacker who can consistently control the
+   delivery or non-delivery of the IKEv2 messages in the network can
+   thus influence which addresses actually get used.
+
+5.5.  Address and Topology Disclosure
+
+   MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/
+   ADDITIONAL_IP6_ADDRESS notifications reveal information about which
+   networks the peers are connected to.
+
+   For example, consider a host A with two network interfaces: a
+   cellular connection and a wired Ethernet connection to a company LAN.
+   If host A now contacts host B using IKEv2 and sends
+   ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B
+   receives additional information it might not otherwise know.  If host
+   A used the cellular connection for the IKEv2 traffic, host B can also
+   see the company LAN address (and perhaps further guess that host A is
+   used by an employee of that company).  If host A used the company LAN
+   to make the connection, host B can see that host A has a subscription
+   from this particular cellular operator.
+
+   These additional addresses can also disclose more accurate location
+   information than just a single address.  Suppose that host A uses its
+   cellular connection for IKEv2 traffic, but also sends an
+   ADDITIONAL_IP4_ADDRESS notification containing an IP address
+   corresponding to, say, a wireless LAN at a particular coffee shop
+   location.  It is likely that host B can now make a much better guess
+   at A's location than would be possible based on the cellular IP
+   address alone.
+
+
+
+Eronen                      Standards Track                    [Page 27]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   Furthermore, as described in Section 3.4, some of the addresses could
+   also be private addresses behind a NAT.
+
+   In many environments, disclosing address information is not a problem
+   (and indeed it cannot be avoided if the hosts wish to use those
+   addresses for IPsec traffic).  For instance, a remote access VPN
+   client could consider the corporate VPN gateway sufficiently
+   trustworthy for this purpose.  Furthermore, the
+   ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are
+   sent encrypted, so the addresses are not visible to eavesdroppers
+   (unless, of course, they are later used for sending IKEv2/IPsec
+   traffic).
+
+   However, if MOBIKE is used in some more opportunistic approach, it
+   can be desirable to limit the information that is sent.  Naturally,
+   the peers do not have to disclose any addresses they do not want to
+   use for IPsec traffic.  Also, as noted in Section 3.6, an initiator
+   whose policy is to always use the locally configured responder
+   address does not have to send any ADDITIONAL_IP4_ADDRESS/
+   ADDITIONAL_IP6_ADDRESS payloads.
+
+6.  IANA Considerations
+
+   This document does not create any new namespaces to be maintained by
+   IANA, but it requires new values in namespaces that have been defined
+   in the IKEv2 base specification [IKEv2].
+
+   This document defines several new IKEv2 notifications whose values
+   have been allocated from the "IKEv2 Notify Message Types" namespace.
+
+      Notify Messages - Error Types     Value
+      -----------------------------     -----
+      UNACCEPTABLE_ADDRESSES            40
+      UNEXPECTED_NAT_DETECTED           41
+
+      Notify Messages - Status Types    Value
+      ------------------------------    -----
+      MOBIKE_SUPPORTED                  16396
+      ADDITIONAL_IP4_ADDRESS            16397
+      ADDITIONAL_IP6_ADDRESS            16398
+      NO_ADDITIONAL_ADDRESSES           16399
+      UPDATE_SA_ADDRESSES               16400
+      COOKIE2                           16401
+      NO_NATS_ALLOWED                   16402
+
+   These notifications are described in Section 4.
+
+
+
+
+
+Eronen                      Standards Track                    [Page 28]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+7.  Acknowledgements
+
+   This document is a collaborative effort of the entire MOBIKE WG.  We
+   would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo
+   Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti,
+   Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann,
+   Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld,
+   Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami
+   Vaarala.  This document also incorporates ideas and text from earlier
+   MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen],
+   [MOPO], and [SMOBIKE], and the MOBIKE design document [Design].
+
+8.  References
+
+8.1.  Normative References
+
+   [IKEv2]           Kaufman, C., "Internet Key Exchange (IKEv2)
+                     Protocol", RFC 4306, December 2005.
+
+   [IPsecArch]       Kent, S. and K. Seo, "Security Architecture for the
+                     Internet Protocol", RFC 4301, December 2005.
+
+   [KEYWORDS]        Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", RFC 2119, March 1997.
+
+8.2.  Informative References
+
+   [AddrMgmt]        Dupont, F., "Address Management for IKE version 2",
+                     Work in Progress, November 2005.
+
+   [Aura02]          Aura, T., Roe, M., and J. Arkko, "Security of
+                     Internet Location Management",  Proc. 18th Annual
+                     Computer Security Applications Conference (ACSAC),
+                     December 2002.
+
+   [Bombing]         Dupont, F., "A note about 3rd party bombing in
+                     Mobile IPv6", Work in Progress, December 2005.
+
+   [Clarifications]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications
+                     and Implementation Guidelines", Work in Progress,
+                     February 2006.
+
+   [DNA4]            Aboba, B., Carlson, J., and S. Cheshire, "Detecting
+                     Network Attachment in IPv4 (DNAv4)", RFC 4436,
+                     March 2006.
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 29]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+   [DNA6]            Narayanan, S., Daley, G., and N. Montavont,
+                     "Detecting Network Attachment in IPv6 - Best
+                     Current Practices for hosts", Work in Progress,
+                     October 2005.
+
+   [Design]          Kivinen, T. and H. Tschofenig, "Design of the
+                     MOBIKE protocol", Work in Progress, January 2006.
+
+   [ICMPAttacks]     Gont, F., "ICMP attacks against TCP", Work in
+                     Progress, October 2005.
+
+   [Kivinen]         Kivinen, T., "MOBIKE protocol", Work in Progress,
+                     February 2004.
+
+   [MIP4]            Perkins, C., "IP Mobility Support for IPv4",
+                     RFC 3344, August 2002.
+
+   [MIP6]            Johnson, D., Perkins, C., and J. Arkko, "Mobility
+                     Support in IPv6", RFC 3775, June 2004.
+
+   [MOPO]            Eronen, P., "Mobility Protocol Options for IKEv2
+                     (MOPO-IKE)", Work in Progress, February 2005.
+
+   [RFC2461]         Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+                     Discovery for IP Version 6 (IPv6)", RFC 2461,
+                     December 1998.
+
+   [SEND]            Arkko, J., Kempf, J., Zill, B., and P. Nikander,
+                     "SEcure Neighbor Discovery (SEND)", RFC 3971,
+                     March 2005.
+
+   [SMOBIKE]         Eronen, P. and H. Tschofenig, "Simple Mobility and
+                     Multihoming Extensions for IKEv2 (SMOBIKE)",
+                     Work in Progress, March 2004.
+
+   [STUN]            Rosenberg, J., Weinberger, J., Huitema, C., and R.
+                     Mahy, "STUN - Simple Traversal of User Datagram
+                     Protocol (UDP) Through Network Address Translators
+                     (NATs)", RFC 3489, March 2003.
+
+   [UNSAF]           Daigle, L., "IAB Considerations for UNilateral
+                     Self-Address Fixing (UNSAF) Across Network Address
+                     Translation", RFC 3424, November 2002.
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 30]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+Appendix A.  Implementation Considerations
+
+A.1.  Links from SPD Cache to Outbound SAD Entries
+
+   [IPsecArch], Section 4.4.2, says that "For outbound processing, each
+   SAD entry is pointed to by entries in the SPD-S part of the SPD
+   cache".  The document does not specify how exactly this "pointing" is
+   done, since this is an implementation detail that does not have to be
+   standardized.
+
+   However, it is clear that the links between the SPD cache and the SAD
+   have to be done correctly to ensure that outbound packets are sent
+   over the right SA.  Some implementations are known to have problems
+   in this area.
+
+   In particular, simply storing the (remote tunnel header IP address,
+   remote SPI) pair in the SPD cache is not sufficient, since the pair
+   does not always uniquely identify a single SAD entry.  For instance,
+   two hosts behind the same NAT can accidentally happen to choose the
+   same SPI value.  The situation can also occur when a host is assigned
+   an IP address previously used by some other host, and the SAs
+   associated with the old host have not yet been deleted by Dead Peer
+   Detection.  This may lead to packets being sent over the wrong SA or,
+   if the key management daemon ensures the pair is unique, denying the
+   creation of otherwise valid SAs.
+
+   Storing the remote tunnel header IP address in the SPD cache may also
+   complicate the implementation of MOBIKE, since the address can change
+   during the lifetime of the SA.  Thus, we recommend implementing the
+   links between the SPD cache and the SAD in a way that does not
+   require modification when the tunnel header IP address is updated by
+   MOBIKE.
+
+A.2.  Creating Outbound SAs
+
+   When an outbound packet requires IPsec processing but no suitable SA
+   exists, a new SA will be created.  In this case, the host has to
+   determine (1) who is the right peer for this SA, (2) whether the host
+   already has an IKE_SA with this peer, and (3) if no IKE_SA exists,
+   the IP address(es) of the peer for contacting it.
+
+   Neither [IPsecArch] nor MOBIKE specifies how exactly these three
+   steps are carried out.  [IPsecArch], Section 4.4.3.4, says:
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 31]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+      For example, assume that IKE A receives an outbound packet
+      destined for IP address X, a host served by a security gateway.
+      RFC 2401 [RFC2401] and this document do not specify how A
+      determines the address of the IKE peer serving X.  However, any
+      peer contacted by A as the presumed representative for X must be
+      registered in the PAD in order to allow the IKE exchange to be
+      authenticated.  Moreover, when the authenticated peer asserts that
+      it represents X in its traffic selector exchange, the PAD will be
+      consulted to determine if the peer in question is authorized to
+      represent X.
+
+   In step 1, there may be more than one possible peer (e.g., several
+   security gateways that are allowed to represent X).  In step 3, the
+   host may need to consult a directory such as DNS to determine the
+   peer IP address(es).
+
+   When performing these steps, implementations may use information
+   contained in the SPD, the PAD, and possibly some other
+   implementation-specific databases.  Regardless of how exactly the
+   steps are implemented, it is important to remember that IP addresses
+   can change, and that an IP address alone does not always uniquely
+   identify a single IKE peer (for the same reasons as why the
+   combination of the remote IP address and SPI does not uniquely
+   identify an outbound IPsec SA; see Appendix A.1).  Thus, in steps 1
+   and 2 it may be easier to identify the "right peer" using its
+   authenticated identity instead of its current IP address.  However,
+   these implementation details are beyond the scope of this
+   specification.
+
+Author's Address
+
+   Pasi Eronen (editor)
+   Nokia Research Center
+   P.O. Box 407
+   FIN-00045 Nokia Group
+   Finland
+
+   EMail: pasi.eronen@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 32]
+
+RFC 4555                    MOBIKE Protocol                    June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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 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 provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Eronen                      Standards Track                    [Page 33]
+