idnits 2.17.1 draft-ietf-netext-ani-location-09.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6757, but the abstract doesn't seem to directly say this. It does mention RFC6757 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 22, 2015) is 3316 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG R. Pazhyannur 3 Internet-Draft S. Speicher 4 Updates: 6757 (if approved) S. Gundavelli 5 Intended status: Standards Track Cisco Systems 6 Expires: September 23, 2015 J. Korhonen 7 Broadcom 8 J. Kaippallimalil 9 Huawei 10 March 22, 2015 12 Extensions to the PMIPv6 Access Network Identifier Option 13 draft-ietf-netext-ani-location-09.txt 15 Abstract 17 Access Network Identifier (ANI) Mobility option was introduced in 18 Access Network Identifier Option for Proxy Mobile IPv6 (RFC 6757). 19 This enables a Mobility Access Gateway (MAG) to convey identifiers 20 like network identifier, geolocation, and operator identifier. This 21 specification extends the Access Network Identifier mobility option 22 with sub options to carry civic location and MAG group Identifier. 23 This specification also defines an ANI Update-Timer sub option that 24 determines when and how often the ANI option will be updated. 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 September 23, 2015. 43 Copyright Notice 45 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 62 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Civic Location Sub-Option . . . . . . . . . . . . . . . . 4 66 3.2. MAG Group identifier Sub-Option . . . . . . . . . . . . . 5 67 3.3. ANI Update-Timer Sub-Option . . . . . . . . . . . . . . . 6 68 4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 6 69 4.1. MAG Considerations . . . . . . . . . . . . . . . . . . . 6 70 4.2. LMA Considerations . . . . . . . . . . . . . . . . . . . 8 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 Access Network Identifier (ANI) Option for Proxy Mobile IPv6 82 [RFC6757] introduced the Access Network Identifier (ANI) mobility 83 Option. This enabled a Mobility Access Gateway (MAG) to provide the 84 Network Identifier, geolocation, and Operator-Identifier sub options. 85 When the access network is WLAN, the Network Identifier sub option 86 may contain Service Set Identifier (SSID) and Basic Service Set 87 Identifier (BSSID) of the Access Point (AP), the geolocation of the 88 AP, and the Operator-Identifier may contain the realm of the operator 89 managing the WLAN. The MAG sends the above information to the Local 90 Mobility Anchor (LMA). The LMA may use this information to determine 91 access network specific policies (in terms of Quality of Service 92 (QoS), Deep Packet Inspection (DPI), etc.). Further, the LMA may 93 make this information available to location based applications. 95 While the above mentioned sub options provide a rich set of 96 information, in this document we describe the need for extending the 97 ANI sub options, particularly useful in WLAN deployments. In WLAN 98 deployments (especially indoor AP deployments), it is difficult to 99 provide Geo-spatial coordinates of APs. At the same time, for many 100 location based applications the civic location is sufficient. This 101 motivates the need for a ANI civic location sub option. In many 102 deployments, operators tend to create groups of APs into "AP-Groups". 103 These groups have a group identifier. The group identifier is used 104 proxy for coarse location (such as floor of a building, or a small 105 building). The group identifier may also be used to provide a common 106 policy (e.g., QoS, charging, DPI) for all APs in that group. This 107 specification provides a sub option for the MAG to convey a group 108 identifier to the LMA. The provisioning of the group identifier is 109 outside the scope of this specification and is typically done via a 110 configuration mechanism such as CLI (Command line Interface), or via 111 CAPWAP ([RFC5415], [RFC5416]), etc. 113 This document also provides a new sub option that determines how 114 often the MAG will update the ANI. In typical deployments, it is 115 expected that the MAG will update the ANI as soon as it changes. 116 This is certainly true when the MAG is co-located with the AP. When 117 a client roams from one AP to another AP, the MAG on the roamed (or 118 sometimes referred to as the target) AP will provide the new ANI (for 119 example the network identifier and geolocation of the new AP). 120 However, if the MAG is co-located with an Access Controller (also 121 known as Wireless LAN Controller (WLC)), then a client roaming from 122 one AP to another AP does not necessarily perform an ANI update. The 123 WLC handles client mobility between APs and as a result, intra-WLC 124 mobility is hidden from the LMA. In such deployments, the 125 information conveyed in the ANI sub-options (e.g. location) becomes 126 stale and is only refreshed at the time of lifetime expiry. The MAG 127 could deal with this by sending a Proxy Binding Update (PBU) whenever 128 a client moves between APs just for the purpose of updating ANI sub 129 option. Alternately, this draft allows the LMA to determine how 130 often it wants to know about the changes in the ANI sub option. For 131 example, in some cases the LMA may not care about ANI sub option 132 except at the time of initial binding or in some cases it may care 133 about every AP transitions. The sub option allows LMA to tell the 134 MAG the desired update frequency. As always, mobility events or re- 135 registration events will update ANI sub options.The LMA can use ANI 136 Update-Timer option to set the maximum frequency at which it wants to 137 receive ANI updates. This is particularly useful in environments 138 where a MAG covers a large number of Wi-Fi APs and there is high 139 client mobility between the APs for example in a stadium Wi-Fi 140 deployment. For example, if a LMA does not want ANI updates any more 141 often than 100 seconds, then it can propose 100 seconds as the value 142 for ANI Update-Timer. 144 [RFC6757] provides ANI sub options to carry geolocation information. 145 In this document we provide additional sub options to carry civic 146 location, and group identifier. This document also defines an ANI 147 sub option to enable a MAG to communicate how often the MAG will 148 update the ANI information. 150 2. Conventions and Terminology 152 2.1. Conventions 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 2.2. Terminology 160 All the mobility related terms used in this document are to be 161 interpreted as defined in [RFC5213] and [RFC5844]. 163 Civic Location: There are two common ways to identify the location of 164 an object, either through geospatial coordinates or by so-called 165 civic addresses. Geospatial coordinates indicate longitude, 166 latitude, and altitude, while civic addresses indicate a street 167 address or sometimes the location within a building (such as a room 168 number). Civic location refers to the civic address. 170 3. Protocol Extension 172 3.1. Civic Location Sub-Option 174 The civic location is a mobility sub option carried in the Access 175 Network Identifier option defined in [RFC6757]. This sub option 176 carries the civic location information of the mobile node as known to 177 the MAG. The format of this option is defined below. 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |ANI Type=IANA-1| ANI Length | Format | Reserved | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | civic location ~ 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1: Network-Identifier Sub-option 189 ANI Type: 191 ANI Length: Total length of this sub option in octets, excluding the 192 ANI Type and ANI length fields. 194 Format: This specifies the encoding format of the civic location. 195 The value 0 is defined in this specification as described below. 196 The remaining values (1 through 255) are reserved. 198 0: This value denotes Binary Encoding. The location format is 199 based on the encoding format defined in Section 3.1 of 200 [RFC4776], whereby the first 3 octets are not put into the 201 civic location field (i.e., the code for the DHCP option, the 202 length of the DHCP option, and the 'what' element are not 203 included). 205 civic location: This field will contain the civic location. The 206 format (encoding) type is specified in the format field of this 207 sub option. Note that the length SHALL NOT exceed 253 bytes./>. 209 3.2. MAG Group identifier Sub-Option 211 The MAG group identifier is a mobility sub option carried in the 212 Access Network Identifier option defined in [RFC6757]. The MAG group 213 identifier identifies the group affiliation of the MAG within that 214 Proxy Mobile IPv6 domain. The group identifier is not assumed to be 215 globally unique, across different network operators. However, group 216 identifier should be unique within an operator network. In domains 217 spanning multiple operators it is recommended that the operator 218 identifier sub option (defined in [RFC6757]) be used in addition to 219 group identifier sub option to ensure uniqueness. When the MAG is 220 configured with a group identifier, the MAG should send its group 221 identifier in the PBU. (The configuration of this identifier is 222 outside the scope of this specification. The usage of the identifier 223 by the LMA is left to implementation.) The format of this sub option 224 is defined below. 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 |ANI Type=IANA-2| ANI Length | group identifier | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 2: MAG group identifier Sub-option 234 ANI Type: 236 ANI Length: Total length of this sub option in octets, excluding the 237 ANI Type and ANI length fields. The value is always 2. 239 group identifier: This is a 2 octet unsigned integer value assigned 240 to a group of MAGs. 242 3.3. ANI Update-Timer Sub-Option 244 The ANI Update-Timer is a mobility sub option carried in the ANI 245 option defined in [RFC6757]. Section 4 describes how the MAG and LMA 246 use this sub option. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |ANI Type=IANA-3| ANI Length | Update-Timer | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 3: Network-Identifier Sub-option 256 ANI Type: 258 ANI Length: Total length of this sub option in octets, excluding the 259 ANI Type and ANI length fields is always 2. 261 Update-Timer: Update-Timer is a 16 bit unsigned integer. The unit 262 of time is seconds. A value of 0 indicates that the MAG will send 263 an updated ANI mobility option as soon as it discovers a change in 264 ANI values. A non-zero value indicates that the MAG may not send 265 ANI values immediately after they have changed but rather send ANI 266 updates when the Update-Timer expires. 268 4. Protocol Considerations 270 The following considerations apply to the LMA and the MAG. 272 4.1. MAG Considerations 274 o The conceptual Binding Update List entry data structure maintained 275 by the mobile access gateway, described in Section 6.1 of 276 [RFC5213], is extended to store the access-network-related 277 information elements associated with the current session. 278 Specifically, the following parameters are defined: 280 * civic location 282 * MAG group identifier 284 * ANI Update-Timer 286 o If the mobile access gateway is configured to support the Access 287 Network Information sub options defined in this specification, it 288 includes this option with the specific sub options in all PBU 289 messages (including PBUs for lifetime extension and for 290 deregistration) that it sends to the LMA. The Access Network 291 Information option is constructed as specified in Section 3. 293 o ANI Update-Timer Considerations: The MAG sets the Update-Timer 294 based on an exchange of timer values with the LMA. When the 295 Update-Timer Sub option is carried in a PBU, it is considered as a 296 proposed value for the Update-Timer. The LMA may change the value 297 of the Update-Timer received in the PBU. When the LMA provided 298 value for the Update-Timer is different than what is sent by the 299 MAG, the MAG should use the LMA provided value. If the MAG does 300 not receive an Update-Timer sub option in PBA (in response to 301 sending the sub option in the PBU), then MAG behavior is in 302 accordance to [RFC6757]. When ANI parameters of a mobility 303 session change, the MAG checks whether the Update-Timer has 304 expired. If the Update-Timer has expired, the MAG sends a PBU 305 with the ANI option. The ANI option reflects the updated access 306 network parameters for that mobility session. If the Update-Timer 307 has not expired, the MAG does not send a PBU. When the Update- 308 Timer for a mobility session expires, the MAG checks whether the 309 ANI parameters have changed. If the parameters have changed from 310 the last reported values, the MAG sends a PBU with ANI option. If 311 the parameters have not changed, the MAG does not send a PBU (and 312 the Update-Timer remains expired). Note that the MAG may send a 313 PBU even before the Update-Timer expires. This could be, for 314 example, to initiate a QoS service request to the LMA (see 315 [RFC7222]). In such cases, the MAG must reset the Update-Timer 316 when it sends a PBU. 318 o If the mobile access gateway had any of the Access Network 319 Information mobility options included the PBU sent to a LMA, then 320 the PBA received from the LMA should contain the Access Network 321 Information mobility option with the specific sub options. If the 322 mobile access gateway receives a PBA with a successful Status 323 Value but without an Access Network Information mobility option, 324 then the mobile access gateway may log the event and, based on its 325 local policy, even proceed to terminate the mobility session. In 326 this case, the mobile access gateway knows the LMA does not 327 understand the Access Network Information mobility option. 329 4.2. LMA Considerations 331 o The conceptual Binding Cache entry data structure maintained by 332 the LMA, described in Section 5.1 of [RFC5213], is extended to 333 store the access-network-related information elements associated 334 with the current session. Specifically, the following parameters 335 are defined: 337 * civic location 339 * MAG group identifier 341 * ANI Update-Timer 343 o On receiving a PBU message from a MAG with the ANI option, the LMA 344 must process the option and update the corresponding fields in the 345 Binding Cache entry. If the option is not understood by that LMA 346 implementation, it will skip the option and process the PBU 347 without these options. 349 o If the received PBU message does not include the Access Network 350 Information option, then the mobility session associated with that 351 PBU is updated to remove any access network information elements. 353 o If the LMA understands/supports the Access Network Identifier 354 mobility sub options defined in this specification, then the LMA 355 echoes the Access Network Identifier mobility option with the 356 specific sub option(s) that it accepted back to the mobile access 357 gateway in a PBA. The civic location and group identifier sub 358 options defined in this specification should not be altered by the 359 LMA. The LMA may change the value of the Update-Timer sub option. 360 It may choose to either echo the same value, or increase or 361 decrease the timer value. For example, if the LMA does not want 362 to receive frequent updates (as implied by the timer value) it may 363 choose to increase the value. Similarly, if the LMA needs to 364 receive ANI updates as soon as possible then it may set the value 365 to zero (0) in the PBA. 367 5. IANA Considerations 369 This document requires the following IANA action. 371 o Action-1: This specification defines a new Access Network 372 Identifier sub option called civic location Sub-option. This 373 mobility sub option is described in Section 3.1 and this sub 374 option can be carried in Access Network Identifier mobility 375 option. The type value for this sub option needs to be 376 allocated from the registry "Access Network Information (ANI) Sub- 377 Option Type Values". RFC Editor: Please replace in 378 Section 3.1 with the assigned value, and update this section 379 accordingly. 381 o Action-2: This specification defines a new Access Network 382 Identifier sub option called MAG group identifier Sub-option. 383 This mobility sub option is described in Section 3.2 and this sub 384 option can be carried in Access Network Identifier mobility 385 option. The type value for this sub option needs to be 386 allocated from the registry "Access Network Information (ANI) Sub- 387 Option Type Values". RFC Editor: Please replace in 388 Section 3.2 with the assigned value, and update this section 389 accordingly. 391 o Action-3: This specification defines a new Access Network 392 Identifier sub option called ANI Update-Timer Sub-option. This 393 sub option is described in Section 3.3 and this sub option can be 394 carried in Access Network Identifier mobility option. The type 395 value for this sub option needs to be allocated from the 396 registry "Access Network Information (ANI) Sub-Option Type 397 Values". RFC Editor: Please replace in Section 3.3 with 398 the assigned value, and update this section accordingly. 400 6. Security Considerations 402 The civic location sub option defined in this specification is 403 carried in the Access Network Identifier option defined in [RFC6757]. 404 This sub option is carried in PBU and PBA messages. This sub option 405 is carried like any other Access Network Identifier sub option as 406 defined in [RFC6757]. Therefore, it inherits from [RFC5213] and 407 [RFC6757], its security guidelines and does not require any 408 additional security considerations. 410 The civic location sub option carried in the Access Network 411 Information option exposes the civic location of the network to which 412 the mobile node is attached. This information is considered to be 413 very sensitive, so care must be taken to secure the Proxy Mobile IPv6 414 signaling messages when carrying this sub option. The base Proxy 415 Mobile IPv6 specification [RFC5213] specifies the use of IPSec for 416 securing the signaling messages, and those mechanisms can be enabled 417 for protecting this information. Operators can potentially apply 418 IPSec Encapsulating Security Payload (ESP) with confidentiality and 419 integrity protection for protecting the location information. The 420 other way to protect the sensitive location information of network 421 users is of course to not send it in the first place. Users of the 422 civic location sub option should provision location values with the 423 highest possible level of granularity, e.g., to the province or city 424 level, rather than provisioning specific addresses. 426 Access-network-specific information elements that the mobile access 427 gateway sends may have been dynamically learned over DHCP or using 428 other protocols. If proper security mechanisms are not in place, the 429 exchanged information between the MAG and LMA may be compromised. 430 This situation may result in incorrect service policy enforcement at 431 the LMA and impact to other services that depend on this access 432 network information. This threat can be mitigated by ensuring the 433 communication path between the mobile access gateway and the access 434 points is properly secured by the use of IPSec, Transport Layer 435 Security (TLS), or other security protocols. 437 7. Acknowledgements 439 This document benefited considerably from the numerous improvements 440 proposed by Kent Leung. 442 8. References 444 8.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", BCP 14, RFC 2119, March 1997. 449 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 450 (DHCPv4 and DHCPv6) Option for Civic Addresses 451 Configuration Information", RFC 4776, November 2006. 453 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 454 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 456 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 457 Mobile IPv6", RFC 5844, May 2010. 459 [RFC6757] Gundavelli, S., Korhonen, J., Grayson, M., Leung, K., and 460 R. Pazhyannur, "Access Network Identifier (ANI) Option for 461 Proxy Mobile IPv6", RFC 6757, October 2012. 463 [RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. 464 Gundavelli, "Quality-of-Service Option for Proxy Mobile 465 IPv6", RFC 7222, May 2014. 467 8.2. Informative References 469 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 470 Provisioning of Wireless Access Points (CAPWAP) Protocol 471 Specification", RFC 5415, March 2009. 473 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 474 Provisioning of Wireless Access Points (CAPWAP) Protocol 475 Binding for IEEE 802.11", RFC 5416, March 2009. 477 Authors' Addresses 479 Rajesh S. Pazhyannur 480 Cisco Systems 481 170 West Tasman Drive 482 San Jose, CA 95134 483 USA 485 Email: rpazhyan@cisco.com 487 Sebastian Speicher 488 Cisco Systems 489 Richtistrasse 7 490 Wallisellen, Zurich 8304 491 Switzerland 493 Email: sespeich@cisco.com 495 Sri Gundavelli 496 Cisco Systems 497 170 West Tasman Drive 498 San Jose, CA 95134 499 USA 501 Email: sgundave@cisco.com 503 Jouni Korhonen 504 Broadcom 505 Porkkalankatu 24 506 Helsinki FIN-00180 507 Finland 509 Email: jouni.nospam@gmail.com 510 John Kaippallimalil 511 Huawei 512 5340 Legacy Drive, Suite 175 513 Plano, Texas 75024 514 USA 516 Email: john.kaippallimalil@huawei.com