Internet DRAFT - draft-liu-dhc-ho
draft-liu-dhc-ho
dhc G. Liu
Internet-Draft Y. Tu
Intended status: Standards Track C. Zhu
Expires: August 20, 2013 ZTE Corporation
February 16, 2013
HO from 3GPP to a trusted non-3GPP access
draft-liu-dhc-ho-03.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 August 20, 2013.
Copyright Notice
Copyright (c) 2013 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 August 20, 2013 [Page 1]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 2]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 3]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 4]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 5]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
+---------+ +------------------+ +--------+ +------------+
| 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 August 20, 2013 [Page 6]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 7]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 8]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 9]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 10]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 11]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
6. Security Considerations
Security considerations in DHCPv4 are described in [RFC3118].
Security considerations in DHCPv6 are described in [RFC3315].
Liu, et al. Expires August 20, 2013 [Page 12]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 13]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 14]
Internet-Draft HO from 3GPP to trusted non-3GPP access February 2013
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 August 20, 2013 [Page 15]
