DHC Working Group Hee Jin Jang
Internet-Draft Alper Yegin
Expires: August 31, 2006 JinHyeock Choi
SAMSUNG AIT
February 27, 2006
DHCP Option for Home Agent Discovery in MIPv6
draft-jang-dhc-haopt-02.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of 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 August 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This draft defines a DHCP-based scheme to enable dynamic discovery of
Mobile IPv6 home agent address and home subnet. New DHCP options are
defined to carry the information from a DHCP server to the DHCP
client running on the mobile node.
Jang, et al. Expires August 31, 2006 [Page 1]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DHCP options for HA Dynamic Discovery . . . . . . . . . . . . 5
3.1. Home Network Identifier Option . . . . . . . . . . . . . . 5
3.2. Home Network Information Option . . . . . . . . . . . . . 6
4. Option Usage . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. DHCP Server - Home Agent Relation . . . . . . . . . . . . 8
4.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 8
4.3. DHCP Server Considerations . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Jang, et al. Expires August 31, 2006 [Page 2]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
1. Introduction
Before a mobile node can engage in Mobile IPv6 signaling with a home
agent, it should either know the IP address of the home agent via
preconfiguration, or dynamically discover it. Mobile IPv6
specification [2] describes how home agents can be dynamically
discovered by mobile nodes that know the home subnet prefix. This
scheme does not work when prefix information is not already available
to the mobile node. This problem can be solved by delivering one or
more home subnet prefix information to the mobile node by means of
DHCP. Subsequently, the mobile node can engage dynamic home agent
discovery using the prefix information. In addition to delivering
the prefix information, DHCP can also be used to directly provide the
IP addresses or FQDNs of the home agents that are available to the
mobile node.
The solution involves defining new DHCP options to carry home subnet
prefix, home agent IP address and FQDN information. A similar
solution has already been defined for Mobile IPv4 home agents [3].
As part of configuring the initial TCP/IP parameters, a mobile node
can obtain home network information for the subnet it is directly
attached to, other subnets in the visited domain, or a subnet from
its home domain. Mobile node can convey the target home subnet's
identity in order to receive corresponding information. For example
the mobile node can provide realm portion of its user NAI and expect
that a home agent information from its home domain is returned. The
availability of the requested information depends on the DHCP server
having prior knowledge or dynamically discovering it. While the
specific details are outside the scope of this document, use of
static tables and AAA-assisted discovery are possible options [8].
The mobile node may or may not be connected to the "home" subnet when
it attempts to learn Mobile IPv6 home network information. This
allows operators to centrally deploy home agents while being able to
bootstrap mobile nodes that are already roaming. This scenario
occurs when HMIP [7] is used, where the mobile node is required to
discover the MAP (a special home agent) that is located multiple hops
away from the mobile node's attachment point.
Jang, et al. Expires August 31, 2006 [Page 3]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
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 [1].
Most of terms used in this draft are defined in Mobile IPv6 [2] and
RFC3315 [4].
Jang, et al. Expires August 31, 2006 [Page 4]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
3. DHCP options for HA Dynamic Discovery
This section introduces two DHCP options used for dynamic home agent
discovery in Mobile IPv6.
3.1. Home Network Identifier Option
This option is used to carry the identifier of the target home
network. This identification allows mobile node to request
information for a home subnet within the visited domain, or from a
specific domain. It is assumed that the DHCP server has some
mechanism to know or retrieve the requested Mobile IPv6 information.
The specifics of these mechanisms are outside the scope of this
draft.
The mobile node MUST include this option along with its Option
Request option in its request.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_HNId | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| id-type | |
+-+-+-+-+-+-+-+-+ +
| |
. .
. Home Network Identifier .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code
OPTION_HNId (TBD)
option-len
Total length of the option
id-type
The type of Home Network Identifier:
0 Local (visited) domain
Jang, et al. Expires August 31, 2006 [Page 5]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
1 Network realm
Id-type 0 indicates the mobile node is interested in learning the
home network information that pertains to the immediately connected
(visited) network. In that case, Home Network Identifier field is
not used. This type can be used to discover local home agents in a
visited network.
Id-type 1 indicates the format of Home Network Identifier field is a
network realm as defined in [5]. In this case, the mobile node is
interested in learning home network information that pertains to the
given realm. This type can be used to discover home agents that are
hosted by a user's home domain (as indicated by his/her NAI-based
username -- user@HomeRealm).
3.2. Home Network Information Option
This option is used to carry home network information in the form of
one or more of home subnet prefix(es), home agent address(es), and
FQDN(s) to a mobile node.
The server MUST provide all of the matching home subnet prefix(es),
home agent address(es) and FQDN(s) in a Home Network Information
option. If the server has no information to provide, it MUST set the
option-len field to zero in this option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_HNInf | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hainfo-type | hainfo-len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Home Network Information .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jang, et al. Expires August 31, 2006 [Page 6]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
option-code
OPTION_HNInf (TBD)
option-len
Total length of the option
hainfo-type
The type of following Home Network Information field.
Possible values are:
0 Home subnet prefix
1 Complete IPv6 address of the home agent
2 FQDN of the home agent
hainfo-len
8-bit unsigned integer. Length of the home agent
information field plus 1.
Home Network Information
A home subnet prefix, home agent IP address or FQDN.
When hninfo-type is set to 0, the data field MUST
contain 8-bit prefix length information followed
by a 128-bit IPv6 address.
When hninfo-type is set to 1, the data field MUST
contain a 128-bit IPv6 address.
When hninfo-type is set to 2, the data field MUST
contain a FQDN as described in RFC1035 [6].
Single option can carry multiple information preceded by hninfo-type
and hninfo-len fields. The length fields help identify the
information boundaries.
Jang, et al. Expires August 31, 2006 [Page 7]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
4. Option Usage
The requesting and sending of this option follows the rules for DHCP
options in [4].
4.1. DHCP Server - Home Agent Relation
The DHCP server does not have to be co-located with a home agent, or
even be on the home subnet of the mobile node. Its location with
respect to home network does not matter as long as it possesses the
requested information.
4.2. Mobile Node Considerations
When a Mobile IPv6 Mobile Node finds itself with neither a home
subnet prefix nor a home agent address, it may request the needed
information with Option Request option. For instance, a mobile node
connecting to a network for the first time may acquire a DHCP address
and solicit for home network information at the same time.
A mobile node MUST identify the desired information with Home Network
Identifier option. For example, a DHCP server may have information
about home agents from several domains (and subnets). It relies on
the mobile node to select the domain for determining which ones it
should provide in response to the client's request.
When the mobile node gets more than one home agent address, it MUST
have a selection mechanism to determine which one to use for
establishing a Mobile IPv6 session. In case it retrieves only home
subnet prefix(es), it needs to perform dynamic home agent discovery
to learn the IP addresses of the home agents. Similarly, if FQDN of
a home agent is retrieved, the mobile node can use DNS to resolve it
to IPv6 address(es).
4.3. DHCP Server Considerations
It is assumed that the DHCP server has access to home network
information for its clients for this option to be useful. The DHCP
server can rely on pre-configuration, or some dynamic discovery
mechanisms for obtaining this information. In case it does not have
any information, or it cannot locate matching information based on
Home Network Identifier, it returns a Home Network Information option
with 0-length data.
Jang, et al. Expires August 31, 2006 [Page 8]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
5. Security Considerations
Secure delivery of home agent and home link information from a DHCP
server to the mobile node (DHCP client) relies on the overall DHCP
security. The particular option defined in this draft does not have
additional impact on the DHCP security.
Aside from the DHCP client to server interaction, an operator must
also ensure secure delivery of mobile IP information to the DHCP
server. This is outside the scope of DHCP and the newly defined
option.
Jang, et al. Expires August 31, 2006 [Page 9]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
6. IANA Consideration
This document introduces two new DHCPv6 options, Home Agent Request
option and Home Agent Reply option. The type numbers for new DHCP
options are currently TBD. An appropriate request will be made to
IANA if this Internet draft gets accepted as an RFC.
7. 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] Levkowetz, H., "DHCP Option for Mobile IP Mobility Agents",
draft-ietf-dhc-mipadvert-opt-02 (work in progress),
February 2004.
[4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[5] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[6] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[7] Soliman, H., Castelluccia, C., Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004.
[8] Chowdhury, K. and A. Lior, "RADIUS Attributes for Mobile IPv6
bootstrapping", draft-chowdhury-mip6-bootstrap-radius-01 (work
in progress), November 2004.
Jang, et al. Expires August 31, 2006 [Page 10]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
Authors' Addresses
Hee Jin Jang
Samsung Advanced Institute of Technology
P.O. Box 111
Suwon 440-600
Korea
Email: heejin.jang@samsung.com
Alper E. Yegin
Samsung Advanced Institute of Technology
Istanbul
Turkey
Email: alper01.yegin@partner.samsung.com
JinHyeok Choi
Samsung Advanced Institute of Technology
P.O. Box 111
Suwon 440-600
Korea
Email: athene@sait.samsung.co.kr
Jang, et al. Expires August 31, 2006 [Page 11]
Internet-Draft DHCP Option for HA Discovery in MIPv6 February 2006
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 (2006). 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.
Jang, et al. Expires August 31, 2006 [Page 12]