Skip to main content

HO from 3GPP to a trusted non-3GPP access
draft-liu-dhc-ho-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Guoyan Liu , Yangwei Tu , Chunhui Zhu
Last updated 2012-08-27
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-dhc-ho-02
dhc                                                               G. Liu
Internet-Draft                                                     Y. Tu
Intended status: Standards Track                                  C. Zhu
Expires: February 28, 2013                               ZTE Corporation
                                                         August 27, 2012

               HO from 3GPP to a trusted non-3GPP access
                        draft-liu-dhc-ho-02.txt

Abstract

   This document adds DHCP client and server behavior description in a
   scenario for handover from 3GPP to a trusted non-3GPP access.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on February 28, 2013.

Copyright Notice

   Copyright (c) 2012 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Liu, et al.             Expires February 28, 2013               [Page 1]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Convention & Terminology . . . . . . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  DHCPv4 Requirement . . . . . . . . . . . . . . . . . . . .  7
     3.2.  DHCPv6 Requirement . . . . . . . . . . . . . . . . . . . .  8
   4.  DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  DHCPv4 Protocol  . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  DHCPv6 Protocol  . . . . . . . . . . . . . . . . . . . . . 10
   5.  DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  DHCPv4 Protocol  . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  DHCPv6 Protocol  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Liu, et al.             Expires February 28, 2013               [Page 2]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

1.  Introduction

   In 3GPP TS 23.402, 3GPP EPS supports the use of non-3GPP IP access
   networks to access the EPC, and also supports handover between 3GPP
   and non-3GPP access.

   This document describes DHCP client and server behavior in a scenario
   for handover from 3GPP to a trusted non-3GPP access.

Liu, et al.             Expires February 28, 2013               [Page 3]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

2.  Convention & 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 [RFC 2119].

   The terminology in this document is based on the definitions in
   [RFC2131,RFC3315], in addition to the ones specified in this section

   3GPP 3rd Generation Partnership Project

   TS Technical Specification

   EPC Evolved Packet Core

   EPS Evolved Packet System

   APN Access Point Name

   PDN Packet Data Network

   GTP GPRS Tunnelling Protocol

   PMIP Proxy Mobile IP

   PDN GW PDN Gateway

Liu, et al.             Expires February 28, 2013               [Page 4]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

3.  Problem Statement

   During handover from 3GPP to a non-3GPP access, UE IP address
   allocated by 3GPP network needs be reused after handover to non-3GPP
   access in order to keep UE service continuous.  For non-3GPP access,
   it needs to know UE capability for the IP address preservation, and
   in 3GPP TS 23.402, the information can be gotten from IKEv2
   authentication procedure for untrusted non-3GPP access, however, a
   method how the trusted non-3GPP access get UE capability for the IP
   address preservation isn't described explicitly shown as follows.

Liu, et al.             Expires February 28, 2013               [Page 5]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

    +---------+       +------------------+       +--------+   +------------+
    |   UE    |       |  Trusted Non-3GPP|       | PDN GW |   | HSS/AAA    |
    |         |       |    IP Access     |       +--------+   +------------+
    +---------+       +------------------+           |              |
         |                    |                      |              |
         |        1. 3GPP Access Procedure           |              |
         |/--------------------------------------------------------\|
         |\--------------------------------------------------------/|
      ---------------------    |                     |              |
      | 2. UE discovers   |    |                     |              |
      |  Trusted Non-3GPP |    |                     |              |
      |  Access and       |    |                     |              |
      |  initiates HO     |    |                     |              |
      ---------------------    |                     |              |
         |3.Access Authentication   3.Authentication&Authorization  |
         |/-------------------\|/--------------------|-------------\|
         |\-------------------/|\--------------------|-------------/|
         |                     |                     |              |
      ---------------------------                    |              |
      |  4.L3 Attach Trigger    |                    |              |
      |                         |                    |              |
      ---------------------------                    |              |
         |                     |5.PBU/Create Session Request        |
         |                     |-------------------->| 6. Update PDN GW Address
         |                     |                     |<------------>|
         |                     |7.PBA/Create Session Response       |
         |                     |<--------------------|              |
         |                     |                     |              |
      ---------------------------                    |              |
      |  8.L3 Attach Completion |                    |              |
      |                         |                    |              |
      ---------------------------                    |              |
         |                     |                     |              |
         |        9. UE-initiated additional PDN Connection         |
         |/--------------------------------------------------------\|
         |\--------------------------------------------------------/|
         |        10. 3GPP EPS Bearer Release        |              |
         |/-----------------------------------------\|              |
         |\-----------------------------------------/|              |

             Figure 1: Handover from 3GPP to a non-3GPP access

   From above figure, the step 4 is involved for the problem, the
   description is as follows.Step 4: After successful authentication and
   authorization, the L3 attach procedure is triggered.  At the latest,
   in this step, the UE should indicate its capability for the IP
   address preservation.  How this information is signalled from the UE

Liu, et al.             Expires February 28, 2013               [Page 6]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

   to the access network is outside of the scope of 3GPP.

   From step 4 description, it is considered that the capability for the
   IP address preservation must be transferred to Trusted Non-3GPP IP
   Access in step 4, if this information hasn!_t been transferred before
   step 4.  For the capability for the IP address preservation, it
   indicates UE need to reuse the previously assigned address.

   Currently, DHCP message, especially for IPv4 type, is considered of
   preferred method for triggering Trusted Non-3GPP IP Access to access
   3GPP EPC, and UE is integrated with DHCP client and trusted non-3GPP
   access is integrated with DHCP server.  And then, DHCP messages need
   to support to transfer UE capability for the IP address preservation
   from UE to Trusted Non-3GPP IP Access.

3.1.  DHCPv4 Requirement

   In RFC2131 section 3.2, there are procedures for Client-server
   interaction - reusing a previously allocated network address, in the
   procedures shown as follow figure, DHCP client in INIT-REBOOT state
   sends DHCPREQUEST message to DHCP server, where 'requested IP
   address' option must be filled in with client's notion of its
   previously assigned address, 'ciaddr' MUST be zero and 'server
   identifier' MUST NOT be filled in, and the server will return DHCP
   ACK message to the client.

Liu, et al.             Expires February 28, 2013               [Page 7]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

                   Server          Client          Server

                     v                v               v
                     |                |               |
                     |              Begins            |
                     |          initialization        |
                     |                |               |
                     |                /|\             |
                     |   _________ __/ | \__________  |
                     | /DHCPREQU EST  |  DHCPREQUEST\ |
                     |/               |              \|
                     |                |               |
                  Locates             |            Locates
               configuration          |         configuration
                     |                |               |
                     |\               |              /|
                     | \              |  ___________/ |
                     |  \             | /  DHCPACK    |
                     |   \ _______    |/              |
                     |     DHCPACK\   |               |
                     |          Initialization        |
                     |             complete           |
                     |               \|               |
                     |                |               |
                     |           (Subsequent          |
                     |             DHCPACKS           |
                     |             ignored)           |
                     |                |               |
                     |                |               |
                     v                v               v

      Figure 2: procedures for reusing a previously allocated network
                                  address

   If above procedure is applied for the scenario of handover from 3GPP
   to a trusted non-3GPP access, DHCP server can implicitly get the
   capability for the IP address preservation by detecting the
   parameters in received DHCPREQUEST message.  But the requirement for
   DHCP client and DHCP server behavior in this specific scenario isn!_t
   included in RFC2131 and needs to be described in more detailed than
   one of RFC2131.

3.2.  DHCPv6 Requirement

   In RFC3315, there is following description associated with handover
   scenario, for example, in any situation when a client may have moved
   to a new link, the client must initiate a Confirm/Reply message

Liu, et al.             Expires February 28, 2013               [Page 8]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

   exchange.  The client includes any IAs assigned to the interface that
   may have moved to a new link, along with the addresses associated
   with those IAs, in its Confirm message. in its Any responding servers
   will indicate whether those addresses are appropriate for the link to
   which the client is attached with the status in the Reply message it
   returns to the client.  If confirm message is applied for the
   scenario of handover from 3GPP to a trusted non-3GPP access, DHCP
   server can implicitly get the capability for the IP address
   preservation if receiving confirm message and get previously
   allocated IP address from confirm message.  But the requirement for
   DHCP client and DHCP server behavior in this specific scenario isn!_t
   included in RFC3315 and needs to be described in more detailed than
   one of RFC3315.  This document is intended to describe DHCP client
   and server behavior in specific scenario for handover from 3GPP to a
   trusted non-3GPP access.

Liu, et al.             Expires February 28, 2013               [Page 9]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

4.  DHCP Client Behavior

4.1.  DHCPv4 Protocol

   When UE decides to handover from 3GPP to a non-3GPP access, UE will
   notify DHCP client move to INIT-REBOOT state, and DHCP client sends
   DHCPREQUEST message to DHCP Server, and the included parameters refer
   to the description for 'DHCPREQUEST generated during INIT-REBOOT
   state' in RFC2131 section 4.3.2.

   Subsequently, the client receives the DHCPACK message with
   configuration parameters.  The client performs a final check on the
   parameters and notes the duration of the lease specified in the
   DHCPACK message, more detailed description refer to 'DHCPREQUEST
   generated during INIT-REBOOT state' in RFC2131.

4.2.  DHCPv6 Protocol

   When UE decides to handover from 3GPP to a non-3GPP access, UE will
   notify DHCP client to send confirm message to DHCP Server, and the
   included parameters refer to the description for 'Creation and
   Transmission of Confirm Messages' in RFC3315 section18.1.2.

   Subsequently, the client receives the Reply message with
   configuration parameters.  The client SHOULD perform duplicate
   address detection on each of the addresses in any IAs it receives in
   the Reply message before using that address for traffic, more
   detailed description refer to 'Receipt of Reply Messages' in RFC3315
   section 18.1.8.

Liu, et al.             Expires February 28, 2013              [Page 10]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

5.  DHCP Server Behavior

5.1.  DHCPv4 Protocol

   WDHCP server receives DHCPREQUEST message from DHCP client and deal
   with the message, if the 'server identifier' isn!_t be filled in,
   'requested IP address' option is filled in with client's notion of
   its previously assigned address. 'ciaddr' is zero, which corresponds
   to the requirements of 'DHCPREQUEST generated during INIT-REBOOT
   state' in RFC2131, then DHCP server will notify trusted non-3GPP
   access to send PMIP or GTP message to 3GPP PDN GW, which includes
   handover indication for reusing a previously allocated network
   address.

   Subsequently, when trusted non-3GPP access receives the response
   message from PDN GW, it will notify DHCP server to respond with a
   DHCPACK message to the client, whose format and requirement refer to
   the description for 'Table 3: Fields and options used by DHCP
   servers' in RFC2131.

5.2.  DHCPv6 Protocol

   DHCP server receives confirm message from DHCP client and deal with
   the message, if the parameters match the requirements of 'Receipt of
   Confirm Messages' in RFC3315 section 18.2.2, then DHCP server will
   notify trusted non-3GPP access to send PMIP or GTP message to 3GPP
   PDN GW, which includes handover indication for reusing a previously
   allocated network address.

   Subsequently, when trusted non-3GPP access receives the response
   message from PDN GW, it will notify DHCP server to respond with a
   Reply message to the client, whose format and requirement refer to
   the description for 'Transmission of Reply Messages' in RFC3315
   section18.2.8.

Liu, et al.             Expires February 28, 2013              [Page 11]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

6.  Security Considerations

   Security considerations in DHCPv4 are described in [RFC3118].

   Security considerations in DHCPv6 are described in [RFC3315].

Liu, et al.             Expires February 28, 2013              [Page 12]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

7.  IANA Considerations

   This document does not introduce any new namespaces for the IANA to
   manage and does not request any new code point assignments.

Liu, et al.             Expires February 28, 2013              [Page 13]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

8.  Normative References

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [TS23402]  3GPP, "Architecture enhancements for non-3GPP accesses",
              2011.

Liu, et al.             Expires February 28, 2013              [Page 14]
Internet-Draft   HO from 3GPP to trusted non-3GPP access     August 2012

Authors' Addresses

   Guoyan Liu
   ZTE Corporation
   No.68 Zijinghua Avenue, Yuhuatai District
   Nanjing
   China

   Phone: +86-25-5287-1362
   Email: liu.guoyan@zte.com.cn

   Yangwei Tu
   ZTE Corporation
   No.68 Zijinghua Avenue, Yuhuatai District
   Nanjing
   China

   Phone: +86-25-5287-1362
   Email: tu.yangwei@zte.com.cn

   Chunhui Zhu
   ZTE Corporation
   No.68 Zijinghua Avenue, Yuhuatai District
   Nanjing
   China

   Phone: +86-25-5287-4634
   Email: zhu.chunhui@zte.com.cn

Liu, et al.             Expires February 28, 2013              [Page 15]