[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4877

MIP6 Working Group                                        V. Devarapalli
Internet-Draft                                                     Nokia
Expires: April 18, 2005                                 October 18, 2004


  Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
                   draft-ietf-mip6-ikev2-ipsec-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 April 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes Mobile IPv6 operation with the revised IPsec
   architecture and IKEv2.









Devarapalli              Expires April 18, 2005                 [Page 1]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  What is applicavble from RFC 3776? . . . . . . . . . . . . . .  5
     3.1   Packet Formats . . . . . . . . . . . . . . . . . . . . . .  5
     3.2   Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1   Home Agent Requirements  . . . . . . . . . . . . . . .  5
       3.2.2   Mobile Node Requirements . . . . . . . . . . . . . . .  6
   4.  Manual Configuration . . . . . . . . . . . . . . . . . . . . .  7
     4.1   Binding Update and Acknowledgements  . . . . . . . . . . .  7
     4.2   Return Routabililty Messages . . . . . . . . . . . . . . .  8
     4.3   Mobile Prefix Discovery Messages . . . . . . . . . . . . .  8
     4.4   Payload Packets  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Dynamic Configuration  . . . . . . . . . . . . . . . . . . . . 10
     5.1   Security Policy Database Entries . . . . . . . . . . . . . 10
       5.1.1   Binding Updates and Acknowledgements . . . . . . . . . 10
       5.1.2   Return Routability Messages  . . . . . . . . . . . . . 11
       5.1.3   Mobile Prefix Discovery Messages . . . . . . . . . . . 11
       5.1.4   Payload Packets  . . . . . . . . . . . . . . . . . . . 12
     5.2   Security Association negotiation using IKEv2 . . . . . . . 12
   6.  The use of EAP authentication  . . . . . . . . . . . . . . . . 14
   7.  Dynamic Home Address Configuration . . . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 19
   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 19
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 19
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 21




















Devarapalli              Expires April 18, 2005                 [Page 2]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


1.  Introduction

   RFC 3776 describes how IPsec [7] is used with Mobile IPv6 [2] to
   protect the signaling messages.  It also illustrates the Security
   Policy Database and Security Association Database entries required to
   protect Mobile IPv6 signaling messages.

   The IPsec architecture has been revised [5].  Among the many changes,
   the list of selectors has been expanded to included the Mobility
   Header message type.  This has an impact on how security policies and
   security associations are configured for protecting mobility header
   messages.  It becomes easier to differentiate between the various
   Mobility Header messages based on the type value instead of checking
   if a particular mobility header message is being sent on a tunnel
   interface between the MN and the HA, as it was in RFC 3776.  The
   revised IPsec architecture specification also includes ICMP message
   type and code as selectors.  This makes it possible to protect Mobile
   Prefix Discovery messages without applying the same security
   associations to all ICMPv6 messages.

   This document discusses new requirements for the Home Agent and the
   Mobile Node to use the revised IPsec architecture and IKEv2.  Section
   3.2 lists the requirements.  Section 3 describes the differences with
   RFC 3776.  Section 4 describes the required Security Policy Database
   (SPD) and Security Association Database (SAD) entries.

   The Internet Key Exchange (IKE) has also been substantially revised
   and simplified [4].  This document describes how IKEv2 can be used to
   setup security associations for Mobile IPv6.

   The use of EAP within IKEv2 is allowed to authenticate the Mobile
   Node to the Home Agent.  This is described in Section 6.  A method
   for dynamically configuring a Home Address from the Home Agent using
   the Configuration Payload in IKEv2 is described in Section 7.

















Devarapalli              Expires April 18, 2005                 [Page 3]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


2.  Terminology

   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 [1].














































Devarapalli              Expires April 18, 2005                 [Page 4]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


3.  What is applicavble from RFC 3776?

3.1  Packet Formats

   The Mobile Node and the Home Agent MUST support the packet formats as
   defined in Seciton 3 of RFC 3776.

3.2  Requirements

   The Mobile Node and the Home Agent MUST support the requirements
   listed in Section 4 of RFC 3776 with the following exceptions.

   o  It is not required to configure security policies per interface in
      order to protect return routability signaling messages.  Since the
      Mobility Header message type is a selector, it is easy to
      differentiate HoTi and HoT messages from other Mobility Header
      messages.

   o  It is necessary to avoid a condition where a mobile ndoe could use
      its security association to send a Binding Update on behalf of
      another Mobile Node.  With manual IPsec configuration, the Home
      Agent MUST be able to verify that a security association was
      created for a particular Home Address.  With dynamic keying, it
      should be possible for the Home Agent to verify that the identity
      presented in the IKE_AUTH exchange is allowed to create security
      associations for a particular home address.

   o  The Mobile Node should use its Care-of Address as source address
      in protocol exchanges, when using dynamic keying.  However, the
      security associations MUST be created for the Home Address of the
      Mobile Node.

   o  The Mobile Node and the Home Agent MUST create security
      associations based on the Home Address, so that the security
      associations survive change in Care-of Address.  When using IKEv2
      as the key exchange protocol, the TSi payload during the
      CREATE_CHILD_SA exchange [4] MUST carry the Home Address of the
      Mobile Node.


3.2.1  Home Agent Requirements

   This section describes some new and additional requirements on the
   Home Agent.

   o  The Home Agent MUST support Mobility Header message type as an
      IPsec selector.




Devarapalli              Expires April 18, 2005                 [Page 5]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


   o  The Home Agent MUST support ICMPv6 message type as an IPsec
      selector.

   o  The Home Agent MUST be able to distinguish between HoTi messages
      sent to itself, when it is acting as a Correspondent Node) from
      those sent to Correspondent Nodes when it is acting as a Home
      Agent, based on the destination address of the packet.

   o  The Home Agent MUST have an entry for each Mobile Node in its Peer
      Authorization Database (PAD), [5].  The PAD entry for a Mobile
      Node contains either a shared key or a trust anchor to verify the
      Mobile Node's certificate.

   o  The Home Agent MUST support remote configuration of Home Address
      as descrined in Section 7.  When the Home Agent receives a
      configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDR, it
      must reply with a valid Home Address for the Mobile Node.  The
      Home Agent could pick a Home Address from a local database or from
      a DHCPv6 server on the home link.

   o  The Home Agent MAY support authentication using EAP in IKEv2 as
      described in Section 2.16 of [4].


3.2.2  Mobile Node Requirements

   This section describes new additional requirements on the Mobile
   Node.

   o  The Mobile Node MUST support Mobility Header message type as an
      IPsec selector.

   o  The Mobile Node MUST supprt ICMPv6 message type as an IPsec
      selector.

   o  The Mobile Node MAY support EAP as an authentication mechanism
      when using IKEv2 to setup security associations for protecting
      Mobile IPv6 signaling messages.

   o  The Mobile Node MAY support the mechanism described in Section 7
      to dynamically configure a Home Address.










Devarapalli              Expires April 18, 2005                 [Page 6]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


4.  Manual Configuration

   This section describes the SPD and SAD entries necessary to protect
   the Mobile IPv6 signaling messages.  The format used to describe the
   SPD and SAD entries is the same as described in RFC 3776.

   For the examples described in this document, a Mobile Node with home
   address, "home_address_1", a Home Agent with addres, "home_agent_1"
   and a user of the Mobile Node with identity "user_1" are assumed.

4.1  Binding Update and Acknowledgements

        mobile node SPD-S:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = MH & mh_type = BU
            THEN USE SA SA1

        mobile node SPD-I:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = MH & mh_type = BAck
            THEN USE SA SA2

        mobile node SAD:
          - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1 &
            proto = MH & mh_type = BU
          - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1 &
            proto = MH & mh_type = BAck

        home agent SPD-S:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = MH & mh_type = BAck
            THEN USE SA SA2

        home agent SPD-I:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = MH & mh_type = BU
            THEN USE SA SA1

        home agent SAD:
          - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1 &
            proto = MH & mh_type = BAck
          - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1 &
            proto = MH & mh_type = BU




Devarapalli              Expires April 18, 2005                 [Page 7]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


4.2  Return Routabililty Messages

        mobile node SPD-S:
          - IF source = home_address_1 & destination = any &
            proto = MH & mh_type = HoTi
            THEN USE SA SA3

        mobile node SPD-I:
          - IF destination = home_address_1 & source = any &
            proto = MH & mh_type = HoT
            THEN USE SA SA4

        mobile node SAD:
          - SA3(OUT, spi_c, home_agent_1, ESP, TUNNEL):
            source = home_address_1 & destination = any & proto = MH &
            mh_type = HoTi
          - SA4(IN, spi_d, care_of_address_1, ESP, TUNNEL):
            source = any & destination = home_address_1 & proto = MH &
            mh_type = HoT

        home agent SPD-S:
          - IF destination = home_address_1 & source = any &
            proto = MH & mh_type = HoT
            THEN USE SA SA4

        home agent SPD-I:
          - IF source = home_address_1 & destination = any &
            proto = MH & mh_type = HoTi
            THEN USE SA SA3

        home agent SAD:
          - SA4(OUT, spi_d, care_of_address_1, ESP, TUNNEL):
            source = any & destination = home_address_1 & proto = MH &
            mh_type = HoT
          - SA3(IN, spi_c, home_agent_1, ESP, TUNNEL):
            source = home_address_1 & destination = any & proto = MH &
            mh_type = HoTi


4.3  Mobile Prefix Discovery Messages











Devarapalli              Expires April 18, 2005                 [Page 8]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


        mobile node SPD-S:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = ICMPv6 & icmp6_type = MPS
            THEN USE SA SA5.

        mobile node SPD-I:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = ICMPv6 & icmp6_type = MPA
            THEN USE SA SA6

        mobile node SAD:
          - SA5(OUT, spi_e, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1 &
            proto = ICMPv6 & icmp6_type = MPS
          - SA6(IN, spi_f, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1 &
            proto = ICMPv6 & icmp6_type = MPA

        home agent SPD-S:
          - IF source = home_agent_1 & destination = home_address_1 &
               proto = ICMPv6 & icmp6_type = MPA
            THEN USE SA SA6

        home agent SPD-I:
          - IF source = home_address_1 & destination = home_agent_1 &
               proto = ICMPv6 & icmp6_type = MPS
            THEN USE SA SA5

        home agent SAD:
          - SA6(OUT, spi_f, home_address_1, ESP, TRANSPORT):
            source = home_agent_1 & destination = home_address_1 &
            proto = ICMPv6 & icmp6_type = MPA
          - SA5(IN, spi_e, home_agent_1, ESP, TRANSPORT):
            source = home_address_1 & destination = home_agent_1 &
            proto = ICMPv6 & icmp6_type = MPS


4.4  Payload Packets

   Payload traffic tunneled through the Home Agent can be protected by
   IPsec, if required.  The Mobile Node and the Home Agent use ESP in
   tunnel mode to protect the tunneled traffic.  The SPD and SAD entries
   shown in Section 5.2.4 of [3] are applicable here.








Devarapalli              Expires April 18, 2005                 [Page 9]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


5.  Dynamic Configuration

   This section describes the use of IKEv2 to setup the required
   security associatiosn.

5.1  Security Policy Database Entries

5.1.1  Binding Updates and Acknowledgements

        mobile node SPD-S:
          - IF destination = home_agent_1 & proto = MH & mh_type = BU
            THEN USE SA ESP TRANSPORT: local identity = user_1

        mobile node SPD-I:
          - IF source = home_agent_1 & proto = MH & mh_type = BAck
            THEN USE SA ESP TRANSPORT: local identity = user_1

        home agent SPD-S:
          - IF source = home_agent_1 & proto = MH & mh_type = BAck
            THEN USE SA ESP TRANSPORT: peer identity = user_1

        home agent SPD-I:
          - IF destination = home_agent_1 & proto = MH & mh_type = BU
            THEN USE SA ESP TRANSPORT: peer identity = user_1



























Devarapalli              Expires April 18, 2005                [Page 10]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


5.1.2  Return Routability Messages

        mobile node SPD-S:
          - IF proto = MH & mh_type = HoTi
            THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
                                    local identity = user_1 &
                                    inner source address =home_address_1

        mobile node SPD-I:
          - IF source = any & destination = home_address_1 &
               proto = MH & mh_type = HoT
            THEN USE SA ESP TUNNEL: outer destination = home_agent_1 &
                                    local identity = user_1

        home agent SPD-S:
          - IF source = any & destination = home_address_1 &
               proto = MH & mh_type = HoT
            THEN USE SA ESP TUNNEL: inner destination = home_address_1
                                    & peer identity = user_1

        home agent SPD-I:
          - IF source = home_address_1 & destination = any &
               proto = MH & mh_type = HoTi
            THEN USE SA ESP TUNNEL: inner destination = home_address_1
                                    & peer identity = user_1


5.1.3  Mobile Prefix Discovery Messages

        mobile node SPD-S:
          - IF destination = home_agent_1 & proto = ICMPv6 &
               icmp6_type = MPS
            THEN USE SA ESP TRANSPORT: local identity = user_1

        mobile node SPD-I:
          - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA
            THEN USE SA ESP TRANSPORT: local identity = user_1

        home agent SPD-S:
          - IF source = home_agent_1 & proto = ICMPv6 & icmp6_type = MPA
            THEN USE SA ESP TRANSPORT: peer identity = user_1

        home agent SPD-I:
          - IF destination = home_agent_1 & proto = ICMPv6 &
               icmp6_type = MPS
            THEN USE SA ESP TRANSPORT: peer identity = user_1





Devarapalli              Expires April 18, 2005                [Page 11]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


5.1.4  Payload Packets

   The SPD and SAD entries shown in Section 5.3.4 of [3] are applicable
   here.  This document does not update the SPD and SAD entries
   described in RFC3776 for protecting payload packets.

5.2  Security Association negotiation using IKEv2

   Mobile IPv6 signaling messages are always first initiated by the
   Mobile Node.  The Mobile Node sends a Binding Update to the Home
   Agent whenever it moves and acquires a new Care-of Address.

   The Mobile Node initiates an IKEv2 protocol exchange if the required
   security associations are not present.  For authenticating the Home
   Agent, public key based mechanisms MUST be used.  The Mobile Node
   includes a Certificate Request payload in the first message sent in
   the IKE_AUTH exchange.  If the Mobile Node is using a shared key for
   authentication, it uses the shared key to generate the AUTH payload
   in the IKE_AUTH exchange.  If the Mobile Node is using a public key
   based mechanism, then it uses its private key to generate the AUTH
   payload in the IKE_AUTH exchange.  The Mobile Node MUST always
   includes its identity in the IDi payload in the IKE_AUTH exchange.
   The Mobile Node could use a FQDN or RFC 822 [13] identifier as
   identities.  In case the Mobile Node uses FQDN, it sets the IDi type
   to ID_FQDN.  In case, the Mobile Nodes uses a RFC 822 kind of
   identifier, it sets the IDi type to ID_RFC822_ADDR.

        Mobile Node                      Home Agent
        -----------                      ----------
        HDR, SAi1, KEi, Ni      -->

                                <--      HDR, SAr1, KEr, Nr, [CERTREQ]

        HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                 AUTH, SAi2, TSi, TSr}
                                -->

                                <--      HDR, SK {IDr, [CERT,] AUTH,
                                                  SAr2, TSi, TSr}

   After the IKE_AUTH exchange completes, the Mobile Node and the Home
   Agent initiate CREATE_CHILD_SA exchanges to negotiate security
   associations for protecting Binding Update/Binding Ack messages,
   Return Routability signaling, Mobile Prefix Discovery messages and
   optionally payload traffic.  The CREATE_CHILD_SA exchanges are
   protected by the security association created during the IKE_AUTH
   exchange.




Devarapalli              Expires April 18, 2005                [Page 12]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


   It is important that the security associations are created based on
   the Home Address of the Mobile Node, so that the security
   associations survive Care-of Address change.  The Mobile Node MUST
   set the TSi (Traffic Selector-initiator) payload to its Home Address
   in the CREATE_CHILD_SA exchange in order to create the security
   associations for the Home Address.

        Mobile Node                      Home Agent
        -----------                      ----------
        HDR, SK {[N], SA, Ni, [KEi],
                 [TSi, TSr]}    -->

                                <--      HDR, SK {SA, Nr, [KEr],
                                                  [TSi, TSr]}





































Devarapalli              Expires April 18, 2005                [Page 13]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


6.  The use of EAP authentication

   In addition to using public key signatures and shared secrets, EAP
   [14] can be used with IKEv2 for authenticating the Mobile Node to the
   Home Agent.

   The Mobile Node indicates that it wants to use EAP by including the
   IDi payload but leaving out the AUTH payload in the first message
   during the IKE_AUTH exchange.  The Home Agent includes an EAP payload
   if it is willing to use an extensible authentication method.
   Security associations are not created until the subsequent IKE_AUTH
   exchange after successful EAP authentication.

        Mobile Node                     Home Agent
        ------------                    ----------
        HDR, SAi1, KEi, Ni      -->

                                <--     HDR, SAr1, KEr, Nr, [CERTREQ]

        HDR, SK {IDi, [CERTREQ,] [IDr,]
                 SAi2, TSi, TSr}-->

                                <--     HDR, SK {IDr, [CERT,] AUTH,
                                                 EAP }

        HDR, SK {EAP}           -->

                                <--     HDR, SK {EAP (success)}

        HDR, SK {AUTH}          -->

                                <--     HDR, SK {AUTH, SAr2, TSi,
                                                 TSr}


















Devarapalli              Expires April 18, 2005                [Page 14]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


7.  Dynamic Home Address Configuration

   The Mobile Node can dynamically configure a Home Address by including
   a Configuration Payload with a request for an address from the home
   link.  The Mobile Node MUST include an INTERNAL_IP6_ADDRESS and
   INTERNAL_IP6_SUBNET attributes in the Configuration Payload.  The
   Mobile Node MAY also include an INTERNAL_IP6_DNS attribute.

   When the Home Agent receives a configuration payload with a
   CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid Home
   Address for the Mobile Node.  The Home Agent could use a local
   database or contact a DHCPv6 server on the home link to allocate a
   Home Address.  The Home Agent MUST also include an
   INTERNAL_ADDRESS_EXPIRY attribute to indicate to the Mobile Node, the
   duration for which the dynamically allocated Home Address is valid.

   In case the Home Agent is unable to allocate a Home Address for the
   Mobile Node during the IKE_AUTH exhcange, it MUST send a Notify
   Payload with an INTERNAL_ADDRESS_FAILURE message.

        Mobile Node                        Home Agent
        -----------                        ----------
        HDR, SK {IDi, [CERT,] [CERTREQ,]
                 [IDr,] AUTH, CP(CFG_REQUEST),
                 SAi2, TSi, TSr}
                                 -->

                                 <--   HDR, SK {IDr, [CERT,] AUTH,
                                                CP(CFG_REPLY), SAr2,
                                                TSi, TSr}





















Devarapalli              Expires April 18, 2005                [Page 15]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


8.  Security Considerations

   This document describes how IPsec can be used to secure Mobile IPv6
   signaling messages.  Please refer to RFC 3775 and RFC 3776 for
   security considerations related to the use of IPsec with Mobile IPv6.














































Devarapalli              Expires April 18, 2005                [Page 16]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


9.  IANA Considerations

   This document requires no action from IANA.
















































Devarapalli              Expires April 18, 2005                [Page 17]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


10.  Acknowledgements

   TBD
















































Devarapalli              Expires April 18, 2005                [Page 18]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


11.  References

11.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.

   [3]  Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
        Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
        Agents", RFC 3776, June 2004.

   [4]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
        draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.

   [5]  Kent, S. and K. Seo, "Security Architecture for the Internet
        Protocol", draft-ietf-ipsec-rfc2401bis-03 (work in progress),
        September 2004.

   [6]  Kent, S., "IP Encapsulating Security Payload (ESP)",
        draft-ietf-ipsec-esp-v3-09 (work in progress), October 2004.

11.2  Informative References

   [7]   Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [8]   Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.

   [9]   Giaretta, G., Guardini, I., Demaria, E., Bournelle, J. and M.
         Laurent-Maknavicius, "MIPv6 Authorization and Configuration
         based on EAP", draft-giaretta-mip6-authorization-eap (work in
         progress), October 2004.

   [10]  Giaretta, G., "Goals for AAA-HA interface",
         draft-giaretta-mip6-aaa-ha-goals-00 (work in progress),
         September 2004.

   [11]  Yegin, A., "AAA Mobile IPv6 Application Framework",
         draft-yegin-mip6-aaa-fwk-00 (work in progress), September 2004.

   [12]  Patel, A., "Problem Statement for bootstrapping Mobile IPv6",
         draft-ietf-mip6-bootstrap-ps-01 (work in progress), October
         2004.




Devarapalli              Expires April 18, 2005                [Page 19]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


   [13]  Crocker, D., "Standard for the format of ARPA Internet text
         messages", STD 11, RFC 822, August 1982.

   [14]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
         Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
         3748, June 2004.


Author's Address

   Vijay Devarapalli
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA  94043
   USA

   EMail: vijay.devarapalli@nokia.com


































Devarapalli              Expires April 18, 2005                [Page 20]

Internet-Draft    Mobile IPv6 with IKEv2 and revised IPsec  October 2004


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Devarapalli              Expires April 18, 2005                [Page 21]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/