Network Working Group F. Xia
Internet-Draft B. Sarikaya
Expires: October 31, 2009 Huawei USA
April 29, 2009
Local Mobile Anchor Discovery Using DHCP
draft-xia-netlmm-lma-discovery-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 October 31, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Xia & Sarikaya Expires October 31, 2009 [Page 1]
Internet-Draft LMA Discovery April 2009
Abstract
This draft defines a DHCP-based scheme to enable dynamic discovery of
a Local Mobility Anchor (LMA) in Proxy Mobile IPv6. Existing Dynamic
Host Configuration Protocol (DHCP) options are used allowing a Mobile
Access Gateway (MAG) to request the LMA's IP address, Fully Qualified
Domain Name (FQDN), or home network prefix via the DHCP response.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Message Sequence . . . . . . . . . . . . . . . . . . . . . . . 4
4. DHCPv6 Relay Agent . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Relay agent configuration . . . . . . . . . . . . . . . . . 5
4.2. Transmission of DHCPv6 messages . . . . . . . . . . . . . . 5
4.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative references . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Xia & Sarikaya Expires October 31, 2009 [Page 2]
Internet-Draft LMA Discovery April 2009
1. Introduction
[I-D.giaretta-netlmm-mip-interactions] describes possible scenarios
which require an interaction between PMIPv6 and MIPv6. In a similar
scenario depicted in Figure 1 , some mobile nodes use Mobile IPv6 to
manage their movements while others rely on a network-based mobility
solution provided by the network. There is a common mobility anchor
that acts as Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA,
depending on the type of the node.
+---------+ +--------+
|LMA1/HA1 | |LMA2/HA2|
+---------+ +--------+
//\\ \\
+----//--\\-------------\\------+
( // \\ \\ )
( // \\ \\ )
+-//--------\\-------------\\---+
// \\ \\
// \\ \\
// \\ \\
+----+ +----+ +--------+
|MAG1| |AR2 | |MAG3/AR3|
+----+ +----+ +--------+
| | |
[MN1] [MN2] [MN3]
Figure 1: Hybrid deployment with MIPv6 and PMIPv6
Before a MAG or a MN can engage in mobility management signaling with
the mobility anchor (LMA or HA), it SHOULD either know the IP address
of the mobility anchor via pre-configuration, or dynamically discover
it.
[I-D.ietf-mip6-hiopt] defines DHCPv6 options which are used for
acquiring the mobile anchor(HA) information from a DHCPv6 server in
MIPv6, while this document describes a procedure that the MAG
retrieves the information from the same server using the DHCP options
in Proxy MIPv6.
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 [RFC2119].
Xia & Sarikaya Expires October 31, 2009 [Page 3]
Internet-Draft LMA Discovery April 2009
The terminology in this document is based on the definitions in
[RFC5213].
3. Message Sequence
Figure 2 shows the message sequence for dynamic LMA discovery using
DHCPv6. The following details apply.
+-----+ +------+ +------+ +------+
| | |NAS/ | | | | |
| MN/ | |MAG/ | | DHCP | | AAA |
|User | |DHCP | |Server| |Server|
| | |client| | | | |
+-----+ +------+ +------+ +------+
| | | |
| 1 | 1 | |
|<------------>|<---------------------->| Access Authentication
| | | |
| | 2 | |
| |------------>| | Information Request
| | | |
| | 3 | |
| |<------------| | Information Reply
| | | |
Figure 2: Dynamic LMA Using DHCP
1. The mobile node executes the network access authentication
procedure (e.g., IEEE802.1X or IKEv2 SA establishment followed by
EAP authentication) and it interacts with the NAS/MAG. The NAS/
MAG interacts with the AAA server to authenticate the mobile
node. In the process of authorizing the mobile node, the AAA
server verifies in the AAA profile that the mobile node is
allowed to use the Proxy Mobile IPv6 service. The AAA server
possibly assigns a LMA and returns this information to the NAS
through Diameter [I-D.korhonen-dime-pmip6] or RADIUS
[I-D.xia-netlmm-radius], thus, it is not necessary to continue
with step 2 and 3. Otherwise, the NAS/MAG continues the
following DHCP exchanges to inquire the home network information.
2. The NAS/MAG as a DHCP client sends a DHCPv6 Information Request
message [RFC3315] to the All_DHCP_Relay_Agents_and_Servers
multicast address. In this message, the NAS/MAG SHALL include
Home Network Identifier Option [I-D.ietf-mip6-hiopt] in the
OPTION_ORO, and a Home Network Identifier Option with id-type set
Xia & Sarikaya Expires October 31, 2009 [Page 4]
Internet-Draft LMA Discovery April 2009
to 0. When the Sub-opt-code of the sub-option is set to 1 in the
request, the Home Network Parameter field MUST contain an
identifier to specify the home network requested by the mobile
node. This field MUST be set in the form of a FQDN [RFC1035],
encoded as specified in Section 8 of [RFC3315]. If the mobile
node has a NAI, the FQDN can be constructed by concatenating a
fixed string with the realm part of the NAI. This sub-option in
the request SHOULD be copied into the Home Network Information
option returned in the reply. The NAS/MAG SHALL also include the
OPTION_CLIENTID to identify itself to the DHCP server. The DHCP
Unique Identifier(DUID) can be generated based on the mobile
node's link layer address or other information. How to create
DUID is beyond the scope of this document.
3. The DHCP server identifies the client by looking at the DUID for
the client in the OPTION_CLIENTID. The DHCP server also
determines that the MAG is requesting home network information by
looking at the Home Network Identifier Option (id-type 0). The
DHCP server retrieves the allocated LMA, FQDN, and home network
prefix, and includes them in the Home Network Information Option
[I-D.ietf-mip6-hiopt] in the Information Reply Message that it
sends to the DHCP client.
4. DHCPv6 Relay Agent
A DHPCv6 relay agent function [RFC3315] SHOULD be used when NAS/MAG
and the DHCP server are not connected directly. In this
configuration, the relay agent function is co-located in the NAS/MAG
with the DHCPv6 client function. Rather than using multicast to send
DHCPv6 messages to the DHCPv6 server, the DHCPv6 client in the NAS/
MAG hands any outbound DHCPv6 messages to the co- located relay
agent. Responses from the DHCPv6 server are delivered to the relay
agent function in the NAS/MAG, which extracts the encapsulated
message and delivers it to the DHCPv6 client in the NAS/MAG.
4.1. Relay agent configuration
The use of the relay agent function in the NAS/MAG allows the NAS/MAG
to unicast DHCPv6 messages to the DHCPv6 server. The relay agent
must be configured with the address of the DHCPv6 server or another
DHCPv6 relay agent that will forward message on to a DHCPv6 server.
4.2. Transmission of DHCPv6 messages
In this configuration, when the DHCPv6 client in the NAS/MAG sends a
message, it hands the message to the DHCPv6 relay agent in the NAS/
MAG. The relay agent encapsulates the message from the client in a
Relay-forward message and sends the resulting DHCPv6 message to the
Xia & Sarikaya Expires October 31, 2009 [Page 5]
Internet-Draft LMA Discovery April 2009
DHCP server. The relay agent sets the fields in the Relay-forward
message as follows:
msg-type RELAY-FORW
hop-count 1
link-address A non-link-local address from the upstream or loopback
interface.
peer-address A non-link-local address from the upstream or loopback
interface.
options MUST include a "Relay Message option" in which OPTION_ORO
is included.
4.3. Receipt of DHCPv6 messages
In this configuration, messages from the DHCPv6 server will be
returned to the DHCPv6 relay agent, with the message for the DHCPv6
client encapsulated in the Relay Message option [RFC3315] in a Relay-
reply message. The relay agent function extracts the message for the
client from the Relay Message option and hands the message to the
DHCPv6 client in the NAS/MAG.
5. Security Considerations
This document describes the use of DHCPv6 for LMA discovery in Proxy
Mobile IPv6 networks. It does not introduce any additional security
concerns beyond those described in the "Security Considerations"
section of the DHCPv6 base specification [RFC3315].
6. IANA considerations
None.
7. Acknowledgements
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Xia & Sarikaya Expires October 31, 2009 [Page 6]
Internet-Draft LMA Discovery April 2009
[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.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
8.2. Informative references
[I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008.
[I-D.ietf-mip6-hiopt]
Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
Options for Home Information Discovery in MIPv6",
draft-ietf-mip6-hiopt-17 (work in progress), May 2008.
[I-D.xia-netlmm-radius]
Xia, F., Sarikaya, B., Korhonen, J., Gundavelli, S., and
D. Damic, "RADIUS Support for Proxy Mobile IPv6",
draft-xia-netlmm-radius-04 (work in progress), April 2009.
[I-D.korhonen-dime-pmip6]
Korhonen, J., Bournelle, J., Muhanna, A., Chowdhury, K.,
and U. Meyer, "Diameter Proxy Mobile IPv6: Support For
Mobile Access Gateway and Local Mobility Anchor to
Diameter Server Interaction", draft-korhonen-dime-pmip6-04
(work in progress), September 2008.
[I-D.giaretta-netlmm-mip-interactions]
Giaretta, G., "Interactions between PMIPv6 and MIPv6:
scenarios and related issues",
draft-giaretta-netlmm-mip-interactions-02 (work in
progress), November 2007.
Xia & Sarikaya Expires October 31, 2009 [Page 7]
Internet-Draft LMA Discovery April 2009
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires October 31, 2009 [Page 8]