[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 6153

Internet Engineering Task Force                                Subir Das
Internet-Draft                                    Telcordia Technologies
Intended status: Proposed Standard                           Gabor Bajko
Expires: February 02, 2011                                         Nokia
                                                           July 02, 2010


Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for
Access Network Discovery and Selection Function(ANDSF) Discovery
                    draft-das-mipshop-andsf-dhcp-options-04

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 February 02, 2011.

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 02/02/11                   [Page 1]

ANDSF DHCP Options                                         July 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).



Table of Contents

   1. Introduction .................................................2
   2. ANDSF IPv4 address option for DHCPv4..........................3
   3. ANDSF IPv6 address option for DHCPv6..........................4
   4. Option Usage..................................................5
        4.1 Usage of ANDSF Options for DHCPv4.......................5
        4.2 Usage of ANDSF Options for DHCPv6.......................6
   5. Security Considerations ......................................6
   6. IANA Considerations ..........................................6
   7. Acknowledgements .............................................7
   8. References ...................................................7
       8.1 Normative References ....................................7
       8.2 Informative References ..................................7
   Author's Addresses ..............................................8



(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 02/02/10                  [Page 2]

ANDSF DHCP Options                                        July 2010


1. Introduction

   Access Network Discovery and Selection Function (ANDSF) is being
   defined in 3GPP [3GPPTS23.402] 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.

   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 02/02/11                 [Page 3]

ANDSF DHCP Options                                        July 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.  The Option has the following
   format:

           Code Len    IPv4 Address 1    IPv4 Address 2
         +-----+----+----+----+----+----+----+----+----
         | XX  | n  |a1 | a2  | a3 | a4 | a1 | ...
         +-----+----+----+----+----+----+----+----+----


3. 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                                |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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.


  S. Das & G. Bajko          Expires 02/02/11                 [Page 4]

ANDSF DHCP Options                                          July 2010


 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.



4. Option Usage

4.1 Usage of ANDSF Options for DHCPv4

   The requesting and sending of the proposed DHCPv4 options follow the
   rules for DHCP options in [RFC2131].

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

   In order to request an address of a ANDSF Server, the mobile node
   (DHCP client) MUST include an ANDSF IPv4 Address Option in the
   Parameter Request List(PRL)in the respective DHCP messages as
   defined in [RFC2131] and [RFC2132].

   If the mobile node receives no address, it may either try another
   server or may continue to retransmit the PRL message. However, it
   MUST limit the rate at which it retransmits the message and limit
   the duration of the time during which it retransmits the message.

  4.1.2 DHCP Server behavior

   When the DHCP server receives an ANDSF IPv4 Address Option in the
   PRL, the DHCP server MUST include the option in its response
   messages (as defined in [RFC2131]and [RFC2132])that may contain a




S. Das & G. Bajko          Expires 02/02/11                   [Page 5]

ANDSF DHCP Options                                       February 2010

   list of one or more IP addresses of the ANDSF server hosting the
   service.


4.2 Usage of ANDSF Options for DHCPv6

   The requesting and sending of the proposed DHCPv6 options follow the
   rules for DHCP options in [RFC3315].

  4.2.1 Mobile node behavior

   The mobile node performs ANDSF discovery according to the procedures
   described in Section 4.1.1.

   In order to discover the address of an ANDSF Server, the mobile
   node(DHCP client) MUST include an ANDSF IPv6 Address Option in the
   Option Request Option (ORO) in the respective DHCP messages as
   defined in [RFC3315].

   If the mobile node receives no address, it may either try another
   server or may continue to retransmit the ORO message. However, it
   MUST limit the rate at which it retransmits the message and limit
   the duration of the time during which it retransmits the message.


  4.2.2 DHCP Server behavior

   When the DHCP Server receives an ANDSF IPv6 Address 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 of the ANDSF server hosting the service.


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

   In deployments where DHCP authentication is not available, 3GPP
   specific lower layer security services may be sufficient to protect
   DHCP messages. 3GPP ANDSF framework also provides additional



S. Das & G. Bajko          Expires 02/02/11                    [Page 6]

ANDSF DHCP Options                                          July 2010


   mechanisms that protect message exchanges between ANDSF client and
   server at the higher layer.


6. IANA Considerations

   This document defines two new DHCP options as described in Sections
   2 and 3.

   ANDSF IPv4 Address Option for DHCPv4(OPTION-IPv4_Address-ANDSF) TBA

   ANDSF IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-ANDSF) TBA


7. Acknowledgements

   Authors would like to acknowledge the following individuals for
   their valuable comments.

   Patrick Stuper, Vijay Devarapalli, Jouni Korhonen, and Jari Arkko,


 8. References

    8.1 Normative References

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

   [RFC2132] S. Alexander, Droms, R. ?DHCP Options and BOOTP Vendor
      Extensions?, RFC 2132, March 1997

   [RFC3315] Droms, R.,  et al,  ?Dynamic Host Configuration Protocol
      for IPv6 (DHCPv6), RFC 3315, July 2003

   [RFC3118] Authentication for DHCP Messages, Droms et al, June 2001


   8.2 Informative References


   [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)






 S. Das & G. Bajko          Expires 02/02/11                   [Page 7]

 ANDSF DHCP Options                                          July 2010


   [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 02/02/10                [Page 8]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/