Internet DRAFT - draft-so-ikev2-fmciwk-ipv4encap

draft-so-ikev2-fmciwk-ipv4encap



IPSECME                                                           T. So
Internet Draft                                                  ZTE USA
Intended status: standard                                      Z. Qiang
Expires: June 2012                                             Ericsson
                                                      December 12, 2011



           Problem Statement of IPv4 Private Addressing Support
             for Fixed Mobile Convergence over IPSec Tunneling
                  draft-so-ikev2-fmciwk-ipv4encap-00.txt


Abstract

   IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many
   standardized network solutions to provide the secure transport
   between network elements over third party's infrastructure.  For
   example, the emerging Fixed Mobile Convergence (FMC) network solution
   that involves Femtocell deployment requires the mobile operator's
   Femtocell AP to leverage the IPSec IKEv2 to support mutual
   authentication and remote IP address configuration as well as other
   auto configuration support over the broadband fixed network (BBF) of
   which the mobile and fixed networks may be operated by two different
   operators.

   Most of today broadband fixed networks are still relying on the IPv4
   private addressing plan to support its attached devices including the
   mobile operator's Femtocell AP.  Hence, the private IPv4 addressing
   and Network Address and Port Translation (NA(P)T) support mostly
   likely stays for many years to come.

   In FMC interworking scenario, there is a need for the mobile network
   to pass on it mobile subscribers' policies to the broadband fixed
   network (BBF) to maintain the service level agreement (SLA) and to
   support remote network management. In addition, a broadband fixed
   network (BBF) may partnership with more than one mobile operator.
   Therefore it is important for the BBF and the mobile network to be
   able to overcome the limitation of the private IPv4 addressing and to
   be able to identify the user's subscription as well as to determine
   the location of the Femtocell AP that serves its mobile user over the
   BBF network.

   This document presents the problems for the IPSec tunneling support
   with private IPv4 addressing for FMC interworking and proposes a
   simple extension to the IKEv2 to resolve the issues.





So                      Expires June 12, 2012                  [Page 1]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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 June 12, 2009.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.



So                      Expires June 12, 2012                  [Page 2]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011






Table of Contents

   1. Introduction...................................................4
      1.1. Requirement for FAP location verification.................5
      1.2. Requirement for FAP's identification for the attached mobile
      UE.............................................................6
   2. Problem statements.............................................8
      2.1. Considerations of STUN support for FMC interworking with FAP
      ...............................................................9
   3. Proposed Solution - Extension to IKEv2 Configuration Payload..10
      3.1. Details of proposed changes to RFC 5996 for IKEv2 CP.....12
   4. Security Considerations.......................................14
   5. IANA Considerations...........................................14
   6. Conclusions...................................................15
   7. References....................................................15
      7.1. Normative References.....................................15
      7.2. Informative References...................................15
   8. Acknowledgments...............................................15



Table of Figures

   Figure 1: Femto-AP (FAP) E2E Configuration ...................... 5

   Figure 2: Example of the typical IP Addressing used across the BBF
   and Mobile Network for Femto-cell deployment with IPSec Tunneling 7

   Figure 3: Example of the IKEv2 Configuration Payload solution to
   carry the public IPv4 address and port number of the UDP header for
   the encapsulated IPSec tunnel....................................12














So                      Expires June 12, 2012                  [Page 3]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


1. Introduction

   Today many network solutions leverage the IPSec IKEv2 to provide the
   secure transport as well as some form remote configuration support
   for their network elements over third party infrastructure (e.g.
   ADSL, Cable etc.).

   The standardized Femtocell architecture from Femto Forum as well as
   from many mobile standards (e.g. 3GPP, 3GPP2 and WiMAX) are good
   examples that all have common architecture to leverage the IPSec
   IKEv2 to interconnect the Femtocell AP (FAP) with the Security
   Gateway (SeGW) over the broadband fixed (BBF) network (e.g. ADSL,
   Cable networks etc.).  Both the Femtocell AP (FAP) and the SeGW are
   managed by the mobile operator which may be a different operator for
   the BBF network.

   Most BBF networks today operate on the private IPv4 addressing plan
   within their networks and rely NA(P)T for external communication.
   For the FMC scenario, a given BBF network may require to be able to
   interwork with more than one mobile network which may also deploy its
   own private IPv4 addressing plan.

   Given each operator manages their own private IPv4 addressing plan
   within their network domains and they need to support inter-operators
   subscribers policy exchange, this introduces a major challenge on how
   to coordinate the private and public addressing across the operators'
   domains so that the mobile network can locate the serving BBF access
   network that its mobile user entity (UE) is attached to and the
   mobile user's identity, so that the BBF network can provide the
   appropriate FMC interworking policy and bearer control on its UE, and
   also to enable the remote network management, when required.

   The following presents an example of typical Femtocell network
   configuration.















So                      Expires June 12, 2012                  [Page 4]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


   /---------------------------\
   | +----+ +--------+  +----+ |   B-----------B  M-------------------M
   | | UE | | Stand- |<=|====|=|===|===========|==|=>o--o o--o        |
   | +----+ | alone  |  | RG | |   |           |  |  |  | |  | Mobile |
   |        |  FAP   |  +----+ |   |           |  |  |S | |F | Network|
   |        +--------+  (NAPT) |   | Broadband |  |  |e | |A |        |
   \---------------------------/   |   Fixed   |  |  |G |-|P | c-----c|
                                   |  Network  |  |  |W | |G |-| Core||
   /---------------------------\   |   (BBF)   |  |  |  | |W | | Ntwk||
   | +----+ +------------+     |   |           |  |  |  | |  | c-----c|
   | | UE | | Integrated |<====|===|===========|==|=>o--o o--o  /  \  |
   | +----+ | FAP (NAPT) |     |   B-----------B  M-------------------M
   |        +------------+     |                               /    \
   \---------------------------/                      I-------I  p----p
                                                      |Inter- |  |PSTN|
    Legends:                                          | net   |  p----p
    <=====>   - IPSec Tunnel                          I-------I
    CoreNtwk  - Core Network
    FAPGW     - FAP Gateway
    NAPT      - Network Address & Port Translation
    RG        - Routing Gateway
    SeGW      - Security Gateway
    UE        - User Entity


            Figure 1 : Typical Femto-AP (FAP) E2E Configuration



1.1. Requirement for FAP location verification

   FAP is designed to support plug and play, however, given it is
   operating on the license band frequency spectrum to support the
   mobile devices, the FAP is required to support location verification
   to ensure its legitimacy to operate on the license spectrum for a
   given mobile operator prior to the FAP be ready to serve its mobile
   devices.

   There are several recommendations from today mobile standards that
   provide possible solutions, but all with limitations:

      1. GPS

         o Limitation: may not be feasible due to poor indoor signal

      2. Overlay Macro cell



So                      Expires June 12, 2012                  [Page 5]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


         o Limitation: not always feasible, especially in rural area

      3. Femto-AP's IP address

         o Limitation: private IPv4 addressing and NA(P)T

      4. Etc.

   Option 1. and 2. above are very much limited by the physical
   environment where the FAP is installed which may be beyond the
   control of the mobile operator; whereas, Option 3. could be resolved
   by operators' deployment strategy and network solution on the private
   IPv4 addressing and the NAPT issue.  Hence, Option 3. is considered
   as the more desirable option to address this FAP location
   verification requirement.

   Once the location of the FAP is identified (e.g. based on IP
   address), the corresponding BBF access network which assigns the
   public IPv4 address to the given FAP can also be known to the mobile
   network, and hence, the location of the FAP could be verified.



1.2. Requirement for FAP's identification for the attached mobile UE

   As part of the FMC interworking, the policy associated with the
   mobile UE is required to be provided by the policy function of the
   mobile network, that serves the UE, to the policy function of the BBF
   network that serves the same UE.  In the case of the private IPv4
   addressing plan is employed at the BBF network, the identity of its
   mobile UE and the corresponding mapping between the private IPv4
   address and the public IPv4 address of the FAP with the port number
   (in the case of the NAPT) are needed to be known by the policy
   function of the mobile network so that it can inform the appropriate
   policy function of the BBF network based on the BBF local
   identification of the FAP that the mobile UE is attached.  As a
   result, the BBF network can provide the policy enforcement to apply
   the QoS policy on the FAP's traffic originated by and targeted to the
   UE.

   The following figure describes the scenario of the mobile UE's IPv4
   address-mapping relationship in typical Femtocell deployment over the
   BBF and mobile networks with IPSec tunneling.






So                      Expires June 12, 2012                  [Page 6]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011




          (Mobile Network   +--------+    +-----------------------+
              Assigned)     | /----\ |    | /----\  /----------\  |
               Inner        | |BPCF|--------|PCRF|--| MME/SGW  |- |
                IP@         | \----/ |    | \----/  \----------/| |
                 |          |   |    |    |    |--------------| | |
                 |          | /----\ |    | /----\   /------\ | | |
         +---+   |   +--+   | |BNG | |    | |SeGW|   |FAP-GW| | | |
   +--+  |   <===v===|==|===|=|====|=|====|=>    |---|      | | | |
   |UE|..|FAP|.......|RG|...|.|....|.|....|.|....|...|..... | | | |
   +--+  |   <=======|==|===|=|====|=|====|=>    |   |    . | | | |
         +---+       +--+^  | \----/ |    | \----/   \------/ | | |
              ^          |  |        |    |            |  .   | | |
              |          |  |  BBF   |    |          /------\ | | |
        Private          |  | Network|    | Mobile   |PGW . |-- | |
           IP@       Public +--------+    | Network  \------/---| |
          (BBF      IP@+Port#             |               .       |
       Assigned)     (NAPT)               +-----------------------+
                  (BBF Assigned)                          .
                                                     *--------*
    Legends:                                         |Internet|
    BPCF       - Broadband Policy Control Function   *--------*
    BNG        - Broadband Network Gateway
    PCRF       - Policy Charging Rule Function
    PGW        - PDN Gateway
    <===>      - IPSec Tunnel
    <===>

   Figure 2 : Example of the typical IP Addressing used across the BBF
   and Mobile Network for Femto-cell deployment with IPSec Tunneling



   As shown in the Figure 2 above, the mobile network identifies the UE
   based on the inner-IPv4 address that it assigned to the UE.  When the
   UE attaches to the FAP, all UE's traffic is encapsulated into FAP's
   IPSec tunnel.  The outer-IPv4 address of the FAP's IPSec tunnel is
   assigned by the BBF network and the IPSec tunnel is terminated at the
   FAP and at the SeGW.

   If NA(P)T is deployed at the RG, the IPSec tunnel will be
   encapsulated by the UDP header in the case of the Tunnel-Mode as
   specified in RFC 5996 [RFC5996] operation is applied, the private
   outer-IPv4 address of the FAP's UDP encapsulated IPSec tunnel will be
   replaced by a public outer-IPv4 address with a possible new port
   number which are assigned by BBF's NA(P)T.


So                      Expires June 12, 2012                  [Page 7]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


   The BPCF/BNG will be based on the public outer-IPv4 address and the
   port number of the UDP encapsulated IPSec tunnel, to perform the
   admission control and policy enforcement on the FAP's traffic which
   is also the UEs' traffic.



2. Problem statements

   Based on the discussions in the previous section, for the FMC
   interworking deployment with FAP that involves two different
   operators (i.e. fixed and mobile operators), using private IPv4
   addressing with NA(P)T enabled in BBF network, one can recognize the
   important requirement for the BBF and the mobile networks to
   determine the IPv4 address mapping as described in the followings:

      - Determine the UE attached FAP's public IPv4 address together
        with the translated port number of the UDP header of the
        encapsulated IPSec tunnel between the FAP and the SeGW which
        are assigned by the BBF.  The FAP's public IPv4 address is:

           o used for identifying the location of the FAP

           o used for identifying the UE's traffic at the BBF network

      - Determine the corresponding FAP's public IPv4 address's
        association with the UE's inner-IPv4 address which is assigned
        by the mobile network.  The association is:

           o used for identifying the mobile UE that is attached to the
             FAP in order to allow the PCRF to retrieve the UE's policy
             to be passed onto the BPCF at the BBF network

   Based on the typical FAP architecture as described in Figure 1 above,
   the only network element that would have the full knowledge of such
   mapping is the SeGW.

   Unfortunately, in today generic FAP architecture, SeGW has no direct
   or indirect interface to the mobile network's policy function or
   management function in order to pass on its knowledge of the mapping.
   One of the main reasons is because SeGW is not specific designed for
   FAP deployment and hence, there is no justification to define
   specific interface to the mobile network's policy function or
   management function. Never-the-less, it is outside the scope of this
   document to discuss the motivation behind such architecture decision.




So                      Expires June 12, 2012                  [Page 8]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


   Besides, given the existing deployment for FAP for mobile operator,
   it is too late to change the existing architecture which will
   introduce backward incompatibility.

   Another solution consideration which is based on existing RFC 5389
   [RFC5389] - Session Traversal Utilities for NAT (STUN) was examined
   to resolve the issue.  Unfortunately, it is determined that STUN is
   not a good fit given the consideration of the FMC interworking
   deployment scenario with FAP.  The issues for using STUN for the FMC
   interworking deployment with FAP are discussed in the following
   section.



2.1. Considerations of STUN support for FMC interworking with FAP

   RFC 5389 [RFC5389] STUN client/server solution is not suitable for
   FMC interworking deployment with FAP because of the following
   reasons.

   Assuming the STUN client is implemented at the FAP, there are two
   options for the STUN server to be deployed and implemented:

   Option-1: STUN server is deployed by the BBF operator at the egress
   of the BNG towards the SeGW based on the generic FAP architecture.

     There are two main technical challenges with this option:

       - Since FAP is a plug and play device, and FAP is not managed by
          the BBF operator, an additional solution is required to the
          existing RFCs to determine how to support inter-operator STUN
          client server discovery.

       - The security authentication between the STUN client and server
          according to RFC 5389 [RFC5389] is based on either long-term
          credential or short-term credential mechanisms.  The mechanism
          requires either a prior pre-configuration or out-of-band
          signaling which would be extremely difficult to implement when
          the two network elements are managed by different operators.

     The conclusion of this option imposes more technical issues than to
     solve the original problem itself.  Hence, Option-1 is not
     acceptable.

   Option-2: STUN server is deployed by the mobile operator

     There are two further sub-options considered by this Option-2.


So                      Expires June 12, 2012                  [Page 9]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


       a) Integrate the STUN server into the SeGW - this option requires
          the STUN server to share the same data path and socket within
          the IPSec and IKE processing which is a significant change to
          many existing SeGW implementation, backward compatibility is a
          major issue.

       b) Deploy STUN server as the standalone element at the ingress of
          the SeGW - this option requires architecture and procedure
          changes to the existing FAP related specification which is
          also another major backward incompatibility issue to the
          existing architecture.



3. Proposed Solution - Extension to IKEv2 Configuration Payload

   After examining many different design options, one particular
   solution stands out. The solution requires only minimum changes to
   the existing RFC 5996 [RFC5996] - Internet Key Exchange Protocol
   Version 2 (IKEv2), and it does not introduce any backward
   incompatibility issue to the existing RFC, the existing
   specification, the existing architecture and the existing
   implementation.

   The proposed solution is to leverage the existing IKE Configuration
   Payload (CP) that has been supported by many FAP deployments to allow
   the IKE-responder (i.e. SeGW) to insert the UDP encapsulated source-
   IPv4 address and the optional UDP port number of the UDP encapsulated
   IPSec tunnel into the CP, if the IKE-initiator (i.e. FAP) and the
   IKE-responder (i.e. SeGW) detect the presence of NA(P)T between them,
   and after they are successfully mutually authenticated.

   The major advantages of this proposal are as follows:

     - Simple extension to the existing IKEv2 RFC 5996 [RFC5996]

          o only a new code point is required to be defined for the CP
            to indicate the carriage of the source IPv4 address and
            port number in the UDP header of the IPSec tunnel.

     - Fully compatibility to the existing architecture and procedures

           o FAP (i.e. IKE-initiator) has signaling path with the
             policy function, the management function as well as with
             the network gateway of the mobile network (e.g. PDN
             Gateway)



So                      Expires June 12, 2012                 [Page 10]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


           o CP is part of the IKEv2 parameters which is generally
             supported by existing FAP-SeGW IPSec/IKEv2 authentication
             procedures

           o Each CP is designed to be standalone and orthogonal to
             each other, and hence, no concern for backward
             incompatibility to the existing IKEv2 procedures that are
             supported by the FAP

       -  Built-in dynamic update with the existing FAP authentication
          procedure to adapt to the changes of the IPv4 address

           o Each IPv4 address, even for the network translated IPv4
             address will have limited life-span.  When the life-span
             expires for the given IPv4 address, the IPSec/IKEv2
             authentication will be renewed and the same procedures are
             executed to enable the IKEv2 peers to obtain the newly
             renewed and translated IPv4 address.

       -  No impact to the existing security mechanisms for the end-to-
          end system and the existing protocols

           o the new added code point has no impact to the IKEv2
             Configuration Payload to continue the use of the existing
             IKEv2 security mechanism.

   The following Figure 3 describes the high-level control flows on how
   the IKEv2 CP is used to carry the public IPv4 address of the UDP
   header for encapsulated the IPSec Tunnel.




















So                      Expires June 12, 2012                 [Page 11]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


        +-------+          +------+              +----------+
         | IKE-  |          |NA(P)T|              |  IKE-    |
         |Client |          +------+              | Gateway  |
         +-------+                                +----------+
       IKE-Initiator                              IKE-Responder
         (e.g FAP)                                 (e.g SeGW)

   IKEv2 Message 1  --------------------------->
   (HDR, SAi1, Kei, Ni)

                    <--------------------------- IKEv2 Message 2
                                      (HDR, SAr1, KEr, Nr, [CERTREQ])

   IKEv2 Message 3  --------------------------->
   (HDR, SK{IDi, [CERT],
   [CERTREQ][IDr]CP(CFG_REQUEST),
   SAi2, TSi, TSr})        :
                           :...> CFG_REQUEST: If NA(P)T is detected,
                              => EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info

                    <--------------------------- IKEv2 Message 4
                                    (HDR, SK{IDr, [CERT], Auth,
                                     CP(CFG_REPLY), SAr2, TSi, TSr})
                                              :
   CFG_REPLY: If successful authentication <..:
      EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4_Info <=

   NOTE: EXTERNAL_IKE-INITIATOR_UDP_Encap_Source_IPv4 Info includes
         Both source IPv4 address and port number that have been
         translated by the NA(P)T.


   Figure 3 : Example of the IKEv2 Configuration Payload solution to
   carry the public IPv4 address and port number of the UDP header for
   the encapsulated IPSec tunnel



   The details of the proposed changes are described in the following
   section.

3.1. Details of proposed changes to RFC 5996 [RFC5996] for IKEv2 CP

   New code point and the corresponding descriptions to be added to RFC
   5996 [RFC5996], section 3.15, are shown as follows:

   NOTE: The new code point is highlighted in a different color.


So                      Expires June 12, 2012                 [Page 12]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


   Attribute Type          Value   Multi-Valued        Length

   -------------------------------------------------------------------

   INTERNAL_IP4_ADDRESS    1       YES              0 or 4 octets

   INTERNAL_IP4_NETMASK    2       NO                0 or 4 octets

   INTERNAL_IP4_DNS       3       YES              0 or 4 octets

   INTERNAL_IP4_NBNS       4       YES              0 or 4 octets

   INTERNAL_IP4_DHCP       6       YES              0 or 4 octets

   APPLICATION_VERSION     7       NO                0 or more

   INTERNAL_IP6_ADDRESS    8       YES*              0 or 17 octets

   INTERNAL_IP6_DNS       10       YES              0 or 16 octets

   INTERNAL_IP6_DHCP       12       YES              0 or 16 octets

   INTERNAL_IP4_SUBNET    13       YES              0 or 8 octets

   SUPPORTED_ATTRIBUTES    14       NO                Multiple of 2

   INTERNAL_IP6_SUBNET    15       YES              17 octets

   EXTERNAL Source_IPv4_NAT_Info

                           16       NO            0 or 6 octets

   * These attributes may be multi-valued on return only if multiple
   values were requested.

   :

   :

   EXTERNAL_Source_IPv4_NAT_Info - The translated external source IPv4
   address and the optional port number of the UDP encapsulated packet
   sent by the initiator is requested by initiator in CFG_REQUEST once
   the IKE peers detect the presence of NA(P)T in between.  If both the
   initiator and responder are mutually authenticated, the initiator's
   source IP address and the optional UDP port number of the UDP
   encapsulated packet will be retrieved by responder and to be included
   in CFG_REPLY. This attribute is made up of two fields: the first


So                      Expires June 12, 2012                 [Page 13]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


   being an IPv4 address and optionally, the second being an IPv4 UDP
   port number. The responder MAY respond with zero or one attribute to
   initiator. This is discussed in more detail in Section 3.15.4.

   :

   :

   3.15.4 Configuration Payloads for EXTERNAL_Source_IPv4_NAT_Info

   The Configuration payloads is used by the IKE initiator to request
   its corresponding IKE responder via the CFG_REQUEST to return its
   source IPv4 NAT information, which is composed of the IPv4 address
   and the optional IPv4 UDP port number, via the CFG_REPLY.

   The IKE initiator will request such information from its
   corresponding IKE responder if the presence of NA(P)T is detected via
   the NAT traversal procedures in between itself and its corresponding
   responder.

   If the initiator and the responder are mutually authenticated, the
   responder will respond to initiator for the translated initiator's
   source IPv4 address and the optional translated source UDP port
   number information.

   A minimal exchange might look like this:

   CP(CFG_REQUEST) = EXTERNAL_Source_IPv4_NAT_Info()

   CP(CFG_REPLY) = EXTERNAL Source_IPv4_NAT_Info(198.51.100.234, 233)



4. Security Considerations

   The proposed solution is to add a new code point to the already
   defined IKEv2 Configuration Payload with no change to the existing
   IKEv2 security mechanism that has been used to protect the CP.



5. IANA Considerations

   A new code point for IKEv2 Configuration Payload that indicates the
   new contents containing the source IPv4 address and source port
   number of the IKE-initiator which is assigned by the NA(P)T  is
   required to be registered with IANA.


So                      Expires June 12, 2012                 [Page 14]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011




6. Conclusions

   This document explains the issues of the lack of the support in the
   FMC architecture to retrieve the mapping of the FAP's public IPv4
   address and port number with the inner IP address of the mobile UE
   that is attached to the FAP in order to support the FMC interworking
   deployment with FAP.

   This document discusses the requirements and the solution
   considerations to resolve the issue as described above.  One solution
   is eventually selected as the final proposal which only requires
   simple extension to the IKEv2 Configuration Payload as defined in RFC
   5996 [RFC5996] to carry the mapping information inserted by the SeGW
   (i.e. IKE-responder) and to be passed onto the FAP (i.e. IKE-
   initiator).  In addition, the solution is backward compatible to the
   existing FAP system architecture and signaling procedures.



7. References

7.1. Normative References

   [RFC 5996]  Internet Key Exchange Version 2, C. Kaulman et al
               http://www.rfc-editor.org/rfc/rfc5996.txt


   [RFC 5389]  Session Traversal Utility for NAT, J. Rosenberg et al,
               http://www.rfc-editor.org/rfc/rfc5389.txt



7.2. Informative References



8. Acknowledgments

   TBD








So                      Expires June 12, 2012                 [Page 15]

Internet-Draft     draft-so-ikev2-fmciwk-ipv4encap        December 2011


Authors' Addresses

   Tricci So
   ZTE USA
   9920 Pacific Heights Blvd., STE 400, San Diego, CA, 92121

   Email: tso@zteusa.com










































So                      Expires June 12, 2012                 [Page 16]