idnits 2.17.1 draft-das-mipshop-andsf-dhcp-options-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Subir Das 3 Internet-Draft Telcordia Technologies 4 Intended status: Proposed Standard Gabor Bajko 5 Expires: April 21, 2011 Nokia 6 October 19, 2010 8 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 9 Access Network Discovery and Selection Function(ANDSF) Discovery 10 draft-das-mipshop-andsf-dhcp-options-07 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 21, 2011. 35 Copyright and License Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 ANDSF DHCP Options October 2010 52 Abstract 54 This document defines new Dynamic Host Configuration Protocol 55 (DHCPv4 and DHCPv6) options to enable a mobile node to discover 56 Access Network Discovery and Selection Function (ANDSF) entities 57 in an IP network. ANDSF is being developed in 3GPP and provides 58 inter-system mobility policies and access network specific 59 information to the mobile nodes(MNs). 61 Table of Contents 63 1. Introduction .................................................2 64 2. ANDSF IPv4 address option for DHCPv4..........................3 65 3. ANDSF IPv6 address option for DHCPv6..........................4 66 4. Option Usage..................................................5 67 4.1 Usage of ANDSF Options for DHCPv4.......................5 68 4.2 Usage of ANDSF Options for DHCPv6.......................6 69 5. Security Considerations ......................................6 70 6. IANA Considerations ..........................................6 71 7. Acknowledgements .............................................7 72 8. References ...................................................7 73 8.1 Normative References ....................................7 74 8.2 Informative References ..................................7 75 Author's Addresses ..............................................7 77 (1) Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 81 this document are to be interpreted as described in [RFC2119]. 83 (2) Terminology and abbreviations used in this document 85 ANDSF (Access Network Discovery and Selection Function): An entity 86 that provides network discovery and selection assistance data to the 87 user entity (UE) as per operator policy [3GPP TS 23.402]. 89 Access Network: A network that is accessed by the user entity(UE) 91 3GPP Network: A radio access network specified by Third Generation 92 Partnership Project 94 Non-3GPP Network: A radio access network specified outside 3GPP by 95 Other Projects or Standards Organizations. 97 ANDSF DHCP Options October 2010 99 1. Introduction 101 Access Network Discovery and Selection Function (ANDSF) is being 102 defined in 3GPP [3GPPTS23.402] to provide necessary network 103 discovery and selection assistance data to the mobile nodes for 104 multi-access network scenarios where 3GPP access-network level 105 solutions are not sufficient for the mobile nodes to perform 106 network discovery and selection of non-3GPP networks. 108 The information provided by ANDSF contains inter-system mobility 109 policies and access network specific data to assist the mobile 110 node with performing the inter-system handover. This set of 111 information can either be provisioned in the mobile node by the 112 home operator, or provided to the mobile node (MN) dynamically by 113 the ANDSF over the S14 reference point as defined in [3GPPTS23.402]. 115 In 3GPP, the ANDSF is located either in the subscriber's home 116 operator or visited network and needs to be known to the MN or 117 discovered by the MN. According to [3GPPTS23.402] the ANDSF is 118 discovered through interaction with the Domain Name Service function 119 or the DHCP Server function. 121 This document defines new DHCPv4 and DHCPv6 options called the ANDSF 122 IP Address Options, which allow the MN to locate an ANDSF Server. 124 2. ANDSF IPv4 Address Option for DHCPv4 126 This section describes the ANDSF IPv4 Address Option for DHCPv4. 127 The option layout is depicted below: 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Option Code | Length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | IP Address | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 . . 136 +---------------------------------------------------------------+ 138 Option Code 140 OPTION-IPv4_Address-ANDSF (To Be Assigned) 142 ANDSF DHCP Options October 2010 144 Length 146 Length (in bytes) of the option excluding the 'Option 147 Code' and the 'Length' fields; Length field is set to 148 4N, where N is the number of IPv4 addresses carried in 149 the option 151 IP Address 153 IPv4 address(es) of ANDSF Server(s) 155 ANDSF servers MUST be listed in order of preference and the client 156 SHOULD process them in decreasing order of preference. 158 3. ANDSF IPv6 Address option for DHCPv6 160 This section describes the ANDSF IPv6 Address Option for DHCPv6. 161 All values in the option are represented in network byte order. 162 The option layout is depicted below: 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Option Code | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | IP Address | 169 . . 170 +---------------------------------------------------------------+ 172 Option Code 174 OPTION-IPv6_Address-ANDSF (To Be Assigned) 176 Length 177 Length (in bytes) of the option excluding the 'Option 178 Code' and the 'Length' fields; Length field is set to 179 16N, where N is the number of IPv6 addresses carried 180 in the option 182 ANDSF DHCP Options October 2010 184 IP Address 186 IPv6 address(es) of ANDSF Server(s) 188 ANDSF servers MUST be listed in order of preference and the client 189 SHOULD process them in decreasing order of preference. 191 4. Option Usage 193 4.1 Usage of ANDSF Options for DHCPv4 195 The requesting and sending of the proposed DHCPv4 options follow 196 the rules for DHCP options in [RFC2131]. 198 4.1.1 Mobile Node behavior 200 The mobile node MAY request the IP address of an ANDSF server 201 either during initial association with a network or when the 202 policy and access network information is required from ANDSF. It 203 MAY also request the IP address of an ANDSF server when the network 204 information is outdated or mobile does not have any ANDSF 205 information. 207 In order to request an address of a ANDSF Server, the mobile node 208 (DHCP client) MUST include an ANDSF IPv4 Address Option in the 209 Parameter Request List(PRL)in the respective DHCP messages as 210 defined in [RFC2131] and [RFC2132]. The DHCP Client MAY initiate a 211 new DHCP exchange or piggyback on other DHCP message exchanges. DHCP 212 client handling PRL options is specified in RFC2131, Section 4.4. 214 4.2 Usage of ANDSF Options for DHCPv6 216 The requesting and sending of the proposed DHCPv6 options follow 217 the rules for DHCP options in [RFC3315]. 219 4.2.1 Mobile node behavior 221 The mobile node MAY request the IP address of an ANDSF server 222 according to the scenarios described in Section 4.1.1. 224 ANDSF DHCP Options October 2010 226 In order to discover the address of an ANDSF Server, the mobile 227 node(DHCP client) MUST include an ANDSF IPv6 Address Option in the 228 Option Request Option (ORO) in the respective DHCP messages as 229 defined in [RFC3315]. The DHCP client MAY initiate a new DHCP 230 exchange or piggyback on other DHCP message exchanges. DHCP 231 client handling ORO options is specified in RFC3315, Sections 17.1 232 and 18.1. 234 5. Security Considerations 236 If an adversary manages to modify the response from a DHCP server 237 or insert its own response, an MN could be led to contact a rogue 238 ANDSF Server. A modified response could also be used to mount an 239 amplification attack. 241 DHCP authentication option described in [RFC3118] and [RFC3315] MAY 242 be used to mitigate the above attacks. In deployments where DHCP 243 authentication is not available, 3GPP specific lower layer security 244 services can be used to protect DHCP messages[3GPPTS33.402]. 3GPP 245 ANDSF framework also provides additional mechanisms that can also be 246 used to mitigate above attacks and to protect message exchanges 247 between ANDSF client and server at the higher layer [3GPPTS33.402]. 249 6. IANA Considerations 251 This document defines two new DHCP options as described in Sections 252 2 and 3. 254 ANDSF IPv4 Address Option for DHCPv4(OPTION-IPv4_Address-ANDSF) TBA 256 ANDSF IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-ANDSF) TBA 258 7. Acknowledgements 260 Authors would like to acknowledge the following individuals for 261 their valuable comments. 263 Patrick Stuper, Vijay Devarapalli, Jouni Korhonen, Jari Arkko, 264 Ted Lemon and Ralph Droms 266 ANDSF DHCP Options October 2010 268 8. References 270 8.1 Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", RFC 2119, March 1997. 275 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 276 2131, March 1997. 278 [RFC2132] S. Alexander, Droms, R. "DHCP Options and BOOTP Vendor 279 Extensions", RFC 2132, March 1997 281 [RFC3315] Droms, R., et al, "Dynamic Host Configuration Protocol 282 for IPv6 (DHCPv6)", RFC 3315, July 2003 284 [RFC3118] Droms, et al, "Authentication for DHCP Messages", June 285 2001 287 8.2 Informative References 289 [3GPPTS23.402] www.3gpp.org/ftp/Specs/html-info/23402.htm 290 3GPP TS 23.402 V8.8.0 (2009-12): Architecture 291 enhancements for non-3GPP accesses 293 [3GPPTS24.302] www.3gpp.org/ftp/Specs/html-info/24302.htm 294 3GPP TS 24.302 V8.4.1 (2009-12): Access to the 3GPP 295 Evolved Packet Core (EPC) via non-3GPP access 296 Networks 298 [3GPPTS33.402]:www.3gpp.org/ftp/Specs/html-info/33402.htm 299 3GPP TS 33.402 v8.6.0 (2009-120) System 300 Architecture Evolution: Security aspects of 301 non-3GPP accesses 303 Authors' Addresses 305 Subir Das 306 Telcordia Technologies Inc. 307 e-mail: subir(at)research(dot)Telcordia(dot)com 309 Gabor Bajko 310 Nokia 311 e-mail: gabor(dot)bajko(at)nokia(dot)com