idnits 2.17.1 draft-bhandari-dhc-access-network-identifier-04.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 16, 2013) is 4026 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) == Missing Reference: 'RFC1035' is mentioned on line 476, but not defined == Unused Reference: 'RFC2434' is defined on line 595, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ANI' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMI' -- Possible downref: Non-RFC (?) normative reference: ref. 'TS23003' -- Possible downref: Non-RFC (?) normative reference: ref. 'TS23203' -- Possible downref: Non-RFC (?) normative reference: ref. 'TS23402' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bhandari 3 Internet-Draft S. Gundavelli 4 Intended status: Standards Track Cisco Systems 5 Expires: October 18, 2013 J. Korhonen 6 Renesas Mobile 7 M. Grayson 8 Cisco Systems 9 April 16, 2013 11 Access-Network-Identifier Option in DHCP 12 draft-bhandari-dhc-access-network-identifier-04 14 Abstract 16 This document specifies the format and mechanism that is to be used 17 for encoding access network identifiers in DHCPv4 and DHCPv6 messages 18 by defining new access network identifier options and sub-options. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 18, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. DHCPv4 Access-Network-Identifier Option . . . . . . . . . . . 5 64 4.1. DHCPv4 Access-Network-Identifier Sub-options . . . . . . . 5 65 5. DHCPv6 Access-Network-Identifier options . . . . . . . . . . . 6 66 6. DHCPv4 and DHCPv6 Access-Network-Identifier Options . . . . . 6 67 6.1. Access-Network-Type option . . . . . . . . . . . . . . . . 6 68 6.2. Network-Identifier options . . . . . . . . . . . . . . . . 8 69 6.3. Operator identifier options . . . . . . . . . . . . . . . 11 70 7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 71 8. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . . 13 72 9. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 76 13. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 14. Normative References . . . . . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 Access network identification of a network device has a range of 83 application. For e.g. The local mobility anchor in a Proxy Mobile 84 IPv6 domain is able to provide access network and access operator 85 specific handling or policing of the mobile node traffic using 86 information about the access network to which the mobile node is 87 attached. 89 This document specifies Dynamic Host Configuration Protocol v4 90 (DHCPv4) [RFC2131] and Dynamic Host Configuration Protocol v6 91 (DHCPv6) [RFC3315] options for access network identification that is 92 added by Client or Relay agent in the DHCPv4 or DHCPv6 messages 93 towards the Server. 95 Dynamic Host Configuration Protocol (DHCP) client or DHCP relay agent 96 aware of the access network and access operator add this information 97 in the DHCP messages. This information can be used to provide 98 differentiated services and policing of traffic based on the access 99 network to which a client is attached. Examples of how this 100 information can be used in mobile networks can be found in [RFC6757] 102 2. Motivation 104 Proxy mobile IPv6 [RFC5213] can be used for supporting network-based 105 mobility management in various type of network deployments. The 106 network architectures, such as Service provider Wi-Fi access 107 aggregation or, WLAN integrated mobile packet core are examples where 108 Proxy Mobile IPv6 is a component of the overall architecture. Some 109 of these architectures require the ability of the local mobility 110 anchor (LMA) [RFC5213] to provide differentiated services and 111 policing of traffic to the mobile nodes based on the access network 112 to which they are attached. Policy systems in mobility architectures 113 such as PCC [TS23203] and ANDSF [TS23402] in 3GPP system allow 114 configuration of policy rules with conditions based on the access 115 network information. For example, the service treatment for the 116 mobile node's traffic may be different when they are attached to a 117 access network owned by the home operator than when owned by a 118 roaming partner. The service treatment can also be different based 119 on the configured Service Set Identifiers (SSID) in case of IEEE 120 802.11 based access networks. Other examples of services include the 121 operator's ability to apply tariff based on the location. 123 The PMIPv6 extension as specified in [RFC6757] defines PMIPv6 options 124 to carry access network identifiers in PMIPv6 signaling from Mobile 125 Access Gateway (MAG) to LMA. MAG can learn this information from 126 DHCP options as inserted by DHCP client or Relay agent before MAG. 128 If MAG relays DHCP messages to LMA as specified in [RFC5844] this 129 information can be inserted by MAG towards LMA in the forwarded DHCP 130 messages. 132 Figure 1 illustrates an example Proxy Mobile IPv6 deployment where 133 Access Points (AP) inserts access network identifiers in DHCP 134 messages. The mobile access gateway learns this information over 135 DHCP and delivers the information elements related to the access 136 network to the local mobility anchor over Proxy Mobile IPv6 signaling 137 messages. In this example, the additional information could comprise 138 the SSID of the used IEEE 802.11 network and the identities of the 139 operators running the IEEE 802.11 access network infrastructure. 141 SSID: IETF-1 142 Operator-Id: provider1.example.com 143 +--+ DHCP 144 |AP|-------. {Access Specific Policies) 145 +--+ | _-----_ | 146 +-----+ _( )_ +-----+ 147 | MAG |-=====( PMIPv6 )======-| LMA |- 148 +-----+ (_ Tunnel_) +-----+ 149 +--+ DHCP | '-----' 150 |AP|-------' 151 +--+ 152 SSID: IETF-2 153 Operator-Id: provider2.example.com 155 Access Networks attached to MAG 157 3. Terminology 159 All the DHCP related terms used in this document to be interpreted as 160 defined in the Dynamic Host Configuration Protocol v4 (DHCPv4) 161 [RFC2131] and Dynamic Host Configuration Protocol v6 (DHCPv6) 162 [RFC3315] specifications. DHCP refers to both DHCPv4 and DHCPv6 163 messages and entities throughout this document. 165 All the mobility related terms used in this document are to be 166 interpreted as defined in the Proxy Mobile IPv6 specifications 167 [RFC5213] and [RFC5844]. Additionally, this document uses the 168 following abbreviations: 170 Service Set Identifier Service Set Identifier (SSID) identifies the 171 name of the IEEE 802.11 network. SSID differentiates from one 172 network to the other. 174 Vendor ID The Vendor ID is the SMI Network Management Private 175 Enterprise Code of the IANA-maintained Private Enterprise Numbers 176 registry [SMI]. 178 4. DHCPv4 Access-Network-Identifier Option 180 Access network identifier option carries information to identify the 181 access network to which the client is attached to. This information 182 includes access technology type, network identifier and access 183 network operator identifiers. 185 The format of the DHCPv4 Access-Network-Identifier option is shown 186 below. 188 Code Len ANI Sub-options 189 +------+------+------+------+------+-- --+-----+ 190 | code | len | s1 | s2 | s2 | ... | sn | 191 +------+------+------+------+------+-- --+-----+ 193 code: 8-bit code carrying Access Network Identifier sub-options, 194 If added by relay agent: Relay Agent Information Option (82) 195 If added by client: OPTION_ACCESS_NETWORK_ID (TBD1) 197 len: 8 bit indicating total length of the included suboptions. 199 ANI Sub-options: The ANI Sub-options consists of a 200 sequence of SubOpt/Length/Value tuples for each sub-option, encoded 201 in the following manner: 203 SubOpt Len Sub-option Value 204 +------+------+------+------+------+------+--...-+------+ 205 | code | N | s1 | s2 | s3 | s4 | | sN | 206 +------+------+------+------+------+------+--...-+------+ 208 ANI Sub-options are defined in following sections. 210 4.1. DHCPv4 Access-Network-Identifier Sub-options 212 Access network identifier information will be defined in multiple 213 sub-options. The initial assignment of DHCP access network 214 identifier Sub-options is as follows: 216 Sub-option Code Sub-Option Description 217 --------------- ---------------------- 218 TBD7 Access-Network-Type Sub-option 219 TBD8 Network-Name Sub-option 220 TBD9 AP-Name Sub-option 221 TBD10 Operator-Identifier Sub-option 222 TBD11 Operator-Realm Sub-option 224 5. DHCPv6 Access-Network-Identifier options 226 The Access Network Identifier option defined here will be added by 227 DHCPv6 client in upstream DHCPv6 messages or by the Relay in Relay- 228 forward messages. 230 Option Code Descrption 231 --------------- ---------------------- 232 TBD2 OPTION_ANI_ATT 233 TBD3 OPTION_ANI_NETWORK_NAME 234 TBD4 OPTION_ANI_AP_NAME 235 TBD5 OPTION_ANI_OPERATOR_ID 236 TBD6 OPTION_ANI_OPERATOR_REALM 238 6. DHCPv4 and DHCPv6 Access-Network-Identifier Options 240 This section defines DHCPv4 suboption and DHCPv6 options for access 241 network identification. 243 6.1. Access-Network-Type option 245 This option is used for exchanging the type of the access technology 246 the client is attached to the network. There can only be a single 247 instance of this specific option in any DHCPv6 message or single 248 instance of this specific sub-option in DHCPv4 249 OPTION_ACCESS_NETWORK_ID or Relay Agent information option. Its 250 format is as follows: 252 DHCPv4: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | suboption-code| Length | ATT | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 suboption-code: 8-bit code, it should be set to value of (TBD7), 260 indicating that its a Access-Network-Type sub-option 262 Length: 8-bit unsigned integer indicating the length of this suboption 263 in octets, excluding the suboption-code and length fields. 264 This field MUST be set to 2. 266 DHCPv6: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Option Code (TBD2) | OptLen | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | ATT + 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 option-code: 16-bit code OPTION_ANI_ATT (TBD2) 276 option-length: 16-bit unsigned integer indicating length 277 in octets of this option 279 Common format applicable to DHCPv4 and DHCPv6: 280 Access Technology Type (ATT) 282 An 16-bit field that specifies the access technology through 283 which the client is connected to the access link. 285 The values is as populated from the IANA name space 286 Access Technology Type Option type values as requested in [RFC5213] 288 0: Reserved ("Reserved") 289 1: Virtual ("Logical Network Interface") 290 2: PPP ("Point-to-Point Protocol") 291 3: IEEE 802.3 ("Ethernet") 292 4: IEEE 802.11a/b/g ("Wireless LAN") 293 5: IEEE 802.16e ("WIMAX") 295 6.2. Network-Identifier options 297 These options can be used for carrying the name of the access network 298 (e.g., a SSID in case of IEEE 802.11 Access Network, or PLMN 299 Identifier [TS23003] in case of 3GPP access ) and Access Point name, 300 to which the client is attached. There can only be a single instance 301 of each of these options in any DHCPv6 message or single instance of 302 each of these sub-options in DHCPv4 OPTION_ACCESS_NETWORK_ID or Relay 303 Agent information option. The format of these options is defined 304 below. 306 DHCPv4: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |suboption code | Length | ~ 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Network Name (e.g., SSID or PLMNID) ~ 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 suboption code: 8-bit code, it should be set to value of (TBD8), 317 indicating that its a Network-Name sub-option 319 Length: 8-bit indicating Total length of this sub option, 320 excluding the suboption code and length fields. 321 The value can be in the range of 2 to 32 octets. 323 DHCPv6: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Option Code (TBD3) | OptLen | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Network Name (e.g., SSID or PLMNID) ~ 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 option-code: 16-bit code OPTION_ANI_NETWORK_NAME (TBD3) 333 option-length: 16-bit unsigned integer indicating length 334 in octets of this option.The value can be in the 335 range of 2 to 32 octets. 337 Common format applicable to DHCPv4 and DHCPv6: 339 Network Name: The name of the access network to which the mobile 340 node is attached. The type of the Network Name is dependent on 341 the access technology to which the mobile node is attached. If it 342 is 802.11 access, the Network Name MUST be the SSID of the 343 network. If the access network is 3GPP access, the Network Name 344 is the PLMN Identifier of the network. If the access network is 345 3GPP2 access, the Network Name is the 346 Access Network Identifier [ANI]. 348 When encoding the PLMN Identifier, both the Mobile Network Code 349 (MNC) [TS23003] and Mobile Country Code (MCC) [TS23003] MUST be 3 350 digits. If the MNC in use only has 2 digits, then it MUST be 351 preceded with a '0'. Encoding MUST be UTF-8. 353 DHCPv4: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 |suboption code | Length | ~ 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Access-Point Name ~ 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 suboption code: 8-bit code, it should be set to value of (TBD9), 364 indicating that its a Network-AP-Name sub-option 366 Length: 8-bit indicating Total length of this sub option, 367 excluding the suboption code and length fields. 368 The value can be in the range of 2 to 32 octets. 370 DHCPv6: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Option Code (TBD3) | OptLen | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Access-Point Name ~ 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 option-code: 16-bit code OPTION_ANI_AP_NAME (TBD4) 381 option-length: 16-bit unsigned integer indicating length 382 in octets of this option.The value can be in the 383 range of 2 to 32 octets. 385 Common format applicable to DHCPv4 and DHCPv6: 387 Access-Point Name: The name of the access point (physical device 388 name) to which the mobile node is attached. This is the 389 identifier that uniquely identifies the access point. While 390 Network Name (e.g., SSID) identifies the operator's access 391 network, Access-Point Name identifies a specific network device in 392 the network to which the mobile node is attached. In some 393 deployments, the Access-Point Name can be set to the Media Access 394 Control (MAC) address of the device or some unique identifier that 395 can be used by the policy systems in the operator network to 396 unambiguously identify the device. The string is carried in UTF-8 397 representation. 399 6.3. Operator identifier options 401 The Operator identifier options can be used for carrying the operator 402 identifier of the access network to which the client is 403 attached.There can only be a single instance of each of these options 404 in any DHCPv6 message or single instance of each of these sub-options 405 in DHCPv4 OPTION_ACCESS_NETWORK_ID or Relay Agent information option. 406 The format of these options is defined below. 408 DHCPv4: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | suboptioncode | Length | ~ 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 ~ Operator Enterprise ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 suboption code: 8 bit code, It should be set to value of (TBD10), 419 indicating that it is Operator-Identifier sub-option 421 Length: Total length of this sub option, excluding the suboption code 422 and length fields. 424 DHCPv6: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Option Code (TBD4) | OptLen | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Operator Enterprise ID | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 option-code: 16-bit code OPTION_ANI_OPERATOR_ID (TBD5) 434 option-length: 16-bit unsigned integer indicating length 435 in octets of this option. 437 Common format applicable to DHCPv4 and DHCPv6: 439 Operator Enterprise ID: Vendor ID as a four octet 440 Private Enterprise Number [SMI]. 442 DHCPv4: 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | suboptioncode | Length | ~ 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 ~ Operator Realm ~ 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 suboption code: 8 bit code, It should be set to value of (TBD11), 453 indicating that it is Operator-Realm sub-option 455 Length: Total length of this sub option, excluding the suboption 456 code and length fields. 458 DHCPv6: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Option Code (TBD4) | OptLen | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 ~ Operator Realm ~ 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 option-code: 16-bit code OPTION_ANI_OPERATOR_REALM (TBD6) 468 option-length: 16-bit unsigned integer indicating length 469 in octets of this option. 471 Common format applicable to DHCPv4 and DHCPv6: 473 Operator Realm: Realm of the operator. Realm names are required to be 474 unique, and are piggybacked on the administration of the DNS 475 namespace. Realms are encoded using a domain name encoding 476 defined in [RFC1035].Up to 253 octets of the operator realm. 478 7. Client Behavior 480 All hosts or clients MAY include access network identifier options in 481 all the upstream DHCP messages to inform the receiver about the 482 access network it is attached to. 484 8. Relay Agent Behavior 486 DHCP Relay Agents MAY include these options before forwarding the 487 DHCP message to provide information about the access network over 488 which DHCP messages from the client is received. 490 9. Server Behavior 492 If DHCP Server is unable to understand this option it MUST be 493 ignored. There is no requirement that a server return this option 494 and its data in a downstream DHCP message. If DHCP Server is able to 495 process these options it MAY use it for address pool selection policy 496 decisions if configured. It MAY store this information along with 497 the lease for logging and audit purpose. 499 10. IANA Considerations 501 This document defines DHCPv4 Access Network Identifier option which 502 requires assignment of DHCPv4 option code TBD1 assigned from "Bootp 503 and DHCP options" registry (http://www.iana.org/assignments/ 504 bootp-dhcp-parameters/bootp-dhcp-parameters.xml), as specified in 505 [RFC2939]. 507 IANA is requested to assign Sub-option codes for the following DHCPv4 508 Sub-options from the "DHCP Relay Agent Sub-Option Codes" 510 Sub-option Code Sub-Option Description 511 --------------- ---------------------- 512 TBD7 Access-Network-Type Sub-option 513 TBD8 Network-Name Sub-option 514 TBD9 AP-Name Sub-option 515 TBD10 Operator-Identifier Sub-option 516 TBD11 Operator-Realm Sub-option 518 IANA is requested to assign option codes for the following DHCPv6 519 options from the "DHCPv6 and DHCPv6 options" registry (http:// 520 www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml). 522 Option Code Descrption 523 --------------- ---------------------- 524 TBD2 OPTION_ANI_ATT 525 TBD3 OPTION_ANI_NETWORK_NAME 526 TBD4 OPTION_ANI_AP_NAME 527 TBD5 OPTION_ANI_OPERATOR_ID 528 TBD6 OPTION_ANI_OPERATOR_REALM 530 11. Security Considerations 532 Since there is no privacy protection for DHCP messages, an 533 eavesdropper who can monitor the link between the DHCP server, relay 534 agent and client can discover access network information. 536 To minimize the unintended exposure of this information, this option 537 SHOULD be included by DHCP entities only when it is configured. 538 Where critical decisions might be based on the value of this option, 539 DHCP authentication as defined in "Authentication for DHCP Messages" 540 [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" 541 [RFC3315] SHOULD be used to protect the integrity of the DHCP 542 options. Link-layer confidentiality and integrity protection may 543 also be employed to reduce the risk of disclosure and tampering. 545 Security issues related DHCPv6 are described in section 23 of 546 [RFC3315]. 548 12. Acknowledgements 550 The authors would like to thank Kim Kinnear, Ted Lemon, Gaurav 551 Halwasia, Bernie Volz for their valuable inputs. 553 13. Change log 555 Changes from 00 - 01 557 o Modified v4 top level option to be either option 82 if added by 558 relay or a new top level option if added by client 560 o Removed DHCPv6 container option 562 o Reorganized the options to converge v4 and v6 option descriptions 564 Changes from 01-02 565 o Modified v4 DHCP option format to align with the 1 byte code, len 567 o Corrected typos 569 Changes from 02-03 571 o No change 573 Changes from 03-04 575 o split network name and ap name into separate options, removed E 576 bit allowing different encoding 578 o corrected the option code, type alignment to match the boundary 580 o split operater id into enterprise id and realm as separate options 582 14. Normative References 584 [ANI] "Interoperability Specification (IOS) for High Rate Packet 585 Data (HRPD) Radio Access Network Interfaces with Session 586 Control in the Access Network, A.S0008-A v3.0", 587 October 2008. 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 593 RFC 2131, March 1997. 595 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 596 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 597 October 1998. 599 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 600 of New DHCP Options and Message Types", BCP 43, RFC 2939, 601 September 2000. 603 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 604 Messages", RFC 3118, June 2001. 606 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 607 and M. Carney, "Dynamic Host Configuration Protocol for 608 IPv6 (DHCPv6)", RFC 3315, July 2003. 610 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 611 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 613 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 614 Mobile IPv6", RFC 5844, May 2010. 616 [RFC6757] Gundavelli, S., Korhonen, J., Grayson, M., Leung, K., and 617 R. Pazhyannur, "Access Network Identifier (ANI) Option for 618 Proxy Mobile IPv6", RFC 6757, October 2012. 620 [SMI] "PRIVATE ENTERPRISE NUMBERS, SMI Network Management 621 Private Enterprise Codes", February 2011. 623 [TS23003] "Numbering, addressing and identification", 2011. 625 [TS23203] "Policy and Charging Control Architecture", 2012. 627 [TS23402] "Architecture enhancements for non-3GPP accesses", 2012. 629 Authors' Addresses 631 Shwetha Bhandari 632 Cisco Systems 633 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 634 Bangalore, KARNATAKA 560 087 635 India 637 Phone: +91 80 4426 0474 638 Email: shwethab@cisco.com 640 Sri Gundavelli 641 Cisco Systems 642 170 West Tasman Drive 643 San Jose, CA 95134 644 USA 646 Email: sgundave@cisco.com 648 Jouni Korhonen 649 Renesas Mobile 650 Linnoitustie 6 651 FIN-02600 Espoo, 652 Finland 654 Phone: 655 Email: jouni.nospam@gmail.com 656 Mark Grayson 657 Cisco Systems 658 11 New Square Park 659 Bedfont Lakes, FELTHAM TW14 8HA 660 ENGLAND 662 Email: mgrayson@cisco.com