Internet Engineering Task Force Subir Das
Internet-Draft Telcordia Technologies
Intended status: Proposed Standard Gabor Bajko
Expires: August 21, 2010 Nokia
February 22, 2010
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
Access Network Discovery and Selection Function(ANDSF) Discovery
draft-das-mipshop-andsf-dhcp-options-03
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), 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2010.
Copyright and License Notice
Copyright (c) 2010 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.
S Das & G. Bajko Expires 08/21/10 [Page 1]
ANDSF DHCP Options February 2010
Abstract
This document defines new Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) options to enable a mobile node to discover
Access Network Discovery and Selection Function (ANDSF) entities
in an IP network. ANDSF is being developed in 3GPP and provides
inter-system mobility policies and access network specific
information to the mobile nodes(MNs). ANDSF is specified in
[3GPPTS23.402].
Table of Contents
1. Introduction .................................................2
2. ANDSF IPv4 address option for DHCPv4..........................3
3. ANDSF Domain Name List option for DHCPv4......................4
4. ANDSF IPv6 address option for DHCPv6..........................5
5. ANDSF Domain Name List option for DHCPv6......................6
6. Option Usage..................................................7
6.1 Usage of ANDSF Options for DHCPv4.......................7
6.2 Usage of ANDSF Options for DHCPv6.......................7
7. Security Considerations ......................................8
8. IANA Considerations ..........................................8
9. Acknowledgements .............................................9
10. References ..................................................9
10.1 Normative References ...................................9
10.2 Informative References ................................10
Author's Addresses .............................................10
(1) Conventions used in this document
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.
(2) Terminology and abbreviations used in this document
ANDSF (Access Network Discovery and Selection Function): An entity
that provides network discovery and selection assistance data to the
user entity (UE) as per operator policy [3GPP TS 23.402].
Access Network: A network that is accessed by the user entity(UE)
3GPP Network : A radio access network specified by Third Generation
Partnership Project
Non-3GPP Network: A radio access network specified outside 3GPP by
Other Projects or Standards Organizations.
S. Das & G. Bajko Expires 08/21/10 [Page 2]
ANDSF DHCP Options February 2010
1. Introduction
Access Network Discovery and Selection Function (ANDSF) is being
defined in 3GPP (Release-8) to provide necessary network discovery
and selection assistance data to the mobile nodes for multi-access
network scenarios where 3GPP access-network level solutions are not
sufficient for the mobile nodes to perform network discovery and
selection of non-3GPP networks[3GPPTS23.402].
The information provided by ANDSF contains inter-system mobility
policies and access network specific data to assist the mobile
node with performing the inter-system handover. This set of
information can either be provisioned in the mobile node by the
home operator, or provided to the mobile node (MN) dynamically by
the ANDSF over the S14 reference point as defined in [3GPPTS23.402].
In 3GPP, the ANDSF is located either in the subscriber's home
operator or visited network and needs to be known to the MN or
discovered by the MN. According to [3GPPTS23.402] the ANDSF is
discovered through interaction with the Domain Name Service function
or the DHCP Server function.
This document defines new DHCPv4 and DHCPv6 options called the ANDSF
IP Address Option and ANDSF Domain List Option, which allow the MN to
locate an ANDSF Server.
2. ANDSF IPv4 Address Option for DHCPv4
This section describes the ANDSF IPv4 Address Option for DHCPv4.
The Option begins with an option code followed by a length and one
or more IP addresses. The option layout is depicted below:
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 Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv4_Address-ANDSF(To Be Assigned) - 1 byte
S. Das & G. Bajko Expires 08/21/10 [Page 3]
ANDSF DHCP Options February 2010
Length
An 8-bit field indicating the length of the option
excluding the 'Option Code' and the 'Length' fields
IP Address
IPv4 address(es) of ANDSF Server(s)
If the length is followed by a list of IPv4 addresses indicating
appropriate ANDSF servers available to the MN, servers MUST be
listed in order of preference and the client should process them
in decreasing order of preference. In case there is no ANDSF server
available, the length is set to 0, otherwise it is a multiple of 4.
The Option has the following format:
Code Len IPv4 Address 1 IPv4 Address 2
+-----+----+----+----+----+----+----+----+----
| XX | n |a1 | a2 | a3 | a4 | a1 | ...
+-----+----+----+----+----+----+----+----+----
3. ANDSF Domain Name List Option for DHCPv4
This section describes the ANDSF Domain Name List Option for DHCPv4.
The format of this option is depicted below:
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 Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name List |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv4_FQDN-ANDSF (To Be Assigned) - 1 byte
Length
An 8-bit field indicating the length of the option
excluding the 'Option Code' and the 'Length' fields
Domain Name List
FQDN(s) of ANDSF Server
S. Das & G. Bajko Expires 08/21/10 [Page 4]
ANDSF DHCP Options February 2010
When the total length of an ANDSF Domain Name List Option exceeds
254 octets, the procedure outlined in [RFC3396] MUST be employed
to split the option into multiple, smaller options.
The encoding for this option has the following format:
Code Len DNS name of ANDSF server
+-----+----+----+----+----+----+----+----
| XX | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+----+----+----+----+----+----+----
The Option begins with a code followed by a length and a sequence
of labels that are encoded according to Section 8 of [RFC3315].
When the MN discovers one or more FQDNs, it SHALL resolve those
according to the procedures as specified in [RFC1035]. The list of
domains MAY contain the domain name of the ANDSF servers of the
network provider and its partner networks that also offer ANDSF
capabilities.
As an example, consider the case where the server wants to offer
two ANDSF servers, "example.com" and "example.net". These would
be encoded as follows:
+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| XX |26 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
4. ANDSF IPv6 Address option for DHCPv6
This section describes the ANDSF IPv6 Address Option for DHCPv6.
The Option begins with an option code followed by a length
and one or more IP addresses. The value of the length octet does
not include itself or the option code. The option layout is
depicted below:
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 Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S. Das & G. Bajko Expires 08/21/10 [Page 5]
ANDSF DHCP Options February 2010
Option Code
OPTION-IPv6_Address-ANDSF (To Be Assigned) - 2 bytes
Length
A 16-bit field indicating the length of the option
excluding the 'Option Code' and the 'Length' fields.
IP Address
IPv6 address(es) of ANDSF Server(s)
The Option follows the same format (except the Option Code and
Length value) as described in Section 2. The value of the Option
Code and Length are 2-octets and the Length does not include
itself or the Option Code field.
If the length is followed by a list of IPv6 addresses indicating
appropriate ANDSF servers available to the MN, servers MUST be
listed in order of preference and the client should process them in
decreasing order of preference. In case there is no ANDSF server
available, the length is set to 0, otherwise it is a multiple of 16.
5. ANDSF Domain Name List option for DHCPv6
This section describes the ANDSF Domain List Option for DHCPv6. The
general format of this option is depicted below:
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 Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain Name List |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv6_FQDN-ANDSF(To Be Assigned) - 2 bytes
Length
A 16-bit field indicating the length of the option
excluding the 'Option Code' and the 'Length' fields.
S. Das & G. Bajko Expires 08/21/10 [Page 6]
ANDSF DHCP Options February 2010
Domain Name List
FQDN(s) of ANDSF Server
The Option follows the same format (except the Option Code and
Length value) as described in Section 3. The value of the Option
Code and Length are 2-octets and the Length does not include
itself or the Option Code field.
The semantics and content of the DHCPv6 encoding of this option are
exactly the same as the encoding described in Section 3, except the
Option Code and Length value.
6. Option Usage
6.1 Usage of ANDSF Options for DHCPv4
The requesting and sending of the proposed DHCPv4 options follow the
rules for DHCP options in [RFC2131].
6.1.1 Mobile Node behavior
The mobile node performs ANDSF discovery procedure either during
initial association with a network or when the policy and access
network information is required from ANDSF. It may also try to
perform the ANDSF discovery when the network information is outdated
or mobile does not have any ANDSF information. MN SHOULD always query
for the IP address, unless the operator policy requires to discover
the FQDN, in which case the MN will need to request for the domain
name.
In order to request an address or domain name of a ANDSF Server, the
mobile node(DHCP client) MUST include either an ANDSF IPv4 Address
Option or ANDSF Domain Name List Option in the Parameter Request List
(PRL)in the respective DHCP messages as defined in [RFC2131].
6.1.2 DHCP Server behavior
When the DHCP server receives either an ANDSF IPv4 Address Option or
ANDSF Domain Name List Option in the PRL, the DHCP server MUST
Include the option in its response messages (as defined in [RFC2131])
that may contain a list of one or more IP addresses or a list of one
or more FQDNs of the ANDSF server hosting the service.
S. Das & G. Bajko Expires 08/21/10 [Page 7]
ANDSF DHCP Options February 2010
In case that the server cannot find any ANDSF Server satisfying
the requested Option Code, the server MUST return the ANDSF Option
by setting the Option Code to the requested Option Code and the
length of the Option to 0.
.
6.2 Usage of ANDSF Options for DHCPv6
The requesting and sending of the proposed DHCPv6 options follow
the rules for DHCP options in [RFC3315].
6.2.1 Mobile node behavior
The mobile node performs ANDSF discovery according to the procedures
described in Section 6.1.1.
In order to discover the address or domain name of an ANDSF Server,
the mobile node(DHCP client) MUST include either an ANDSF IPv6
Address Option or ANDSF Domain Name List Option in the Option Request
Option (ORO) in the respective DHCP messages as defined in [RFC3315].
6.2.2 DHCP Server behavior
When the DHCP Server receives either an ANDSF IPv6 Address Option
or ANDSF Domain Name List Option in the ORO, the DHCP server MUST
include the option in its response (as defined in [RFC3315])that
may contain a list of one or more IP addresses or a list of one or
more FQDNs of the ANDSF server hosting the service.
In case that the server cannot find any ANDSF Server satisfying
the requested Option Code, the server MUST return the ANDSF Option
by setting the Option Code to the requested Option Code and the
length of the Option to 0.
7. Security Considerations
The security considerations in [RFC2131] apply. If an adversary
manages to modify the response from a DHCP server or insert its own
response, an MN could be led to contact a rogue ANDSF Server.
It is recommended to use DHCP authentication option described in
[RFC3118] where available. This will also protect the denial of
service attacks to DHCP servers. [RFC3118] provides mechanisms for
both entity authentication and message authentication.
S. Das & G. Bajko Expires 08/21/10 [Page 8]
ANDSF DHCP Options February 2010
In deployments where DHCP authentication is not available, 3GPP
specific lower layer security services may be sufficient to protect
DHCP messages.
Regarding domain name resolution, it is recommended to consider the
usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational
Practices [RFC4641].
8. IANA Considerations
This document defines two new DHCPv4 options as described in Sections
2 and 3.
ANDSF IPv4 Address Option for DHCPv4(OPTION-IPv4_Address-ANDSF) TBA
ANDSF Domain Name List option for DHCPv4(OPTION-IPv4_FQDN-ANDSF) TBA
This document also defines two DHCPv6 options as described in
Sections
4 and 5.
ANDSF IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-ANDSF) TBA
ANDSF Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-ANDSF) TBA
9. Acknowledgements
Authors would like to acknowledge the following individuals for
their valuable comments.
Patrick Stuper, Vijay Devarapalli, Jouni Korhonen, and Jari Arkko,
10. References
10.1 Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6),
Droms et al, July 2003
S. Das & G. Bajko Expires 08/21/10 [Page 9]
ANDSF DHCP Options February 2010
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC3118] Authentication for DHCP Messages, Droms et al, June 2001
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long DHCP Options",
RFC3396, November 2002.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC 4033,
March 2005.
10.2 Informative References
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006.
[3GPP TS23.402] www.3gpp.org/ftp/Specs/html-info/23402.htm
3GPP TS 23.402 V8.8.0 (2009-12): Architecture
enhancements for non-3GPP accesses (Release 8)
[3GPP Ts 24.302] www.3gpp.org/ftp/Specs/html-info/24302.htm
3GPP TS 24.302 V8.4.1 (2009-12): Access to the 3GPP
Evolved Packet Core (EPC) via non-3GPP access
networks; Stage 3;(Release 8)
Authors' Addresses
Subir Das
Telcordia Technologies Inc.
e-mail: subir(at)research(dot)Telcordia(dot)com
Gabor Bajko
Nokia
e-mail: gabor(dot)bajko(at)nokia(dot)com
S. Das & G. Bajko Expires 08/21/10 [Page 10]