diff options
Diffstat (limited to 'doc/rfc/rfc7563.txt')
| -rw-r--r-- | doc/rfc/rfc7563.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7563.txt b/doc/rfc/rfc7563.txt new file mode 100644 index 0000000..748ef5b --- /dev/null +++ b/doc/rfc/rfc7563.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Pazhyannur +Request for Comments: 7563 S. Speicher +Updates: 6757 S. Gundavelli +Category: Standards Track Cisco Systems +ISSN: 2070-1721 J. Korhonen + Broadcom Corporation + J. Kaippallimalil + Huawei + June 2015 + + + Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier + Option + +Abstract + + The Access Network Identifier (ANI) mobility option was introduced in + RFC 6757, "Access Network Identifier (ANI) Option for Proxy Mobile + IPv6". This enables a Mobile Access Gateway (MAG) to convey + identifiers like the network identifier, geolocation, and operator + identifier. This specification extends the Access Network Identifier + mobility option with sub-options to carry the civic location and the + MAG group identifier. This specification also defines an ANI Update- + Timer sub-option that determines when and how often the ANI option + will be updated. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7563. + + + + + + + + + + + + +Pazhyannur, et al. Standards Track [Page 1] + +RFC 7563 Extensions to ANI June 2015 + + +Copyright Notice + + Copyright (c) 2015 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 + 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Protocol Extension . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Civic-Location Sub-Option . . . . . . . . . . . . . . . . 5 + 3.2. MAG-Group-Identifier Sub-Option . . . . . . . . . . . . . 6 + 3.3. ANI Update-Timer Sub-Option . . . . . . . . . . . . . . . 6 + 4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7 + 4.1. MAG Considerations . . . . . . . . . . . . . . . . . . . 7 + 4.2. LMA Considerations . . . . . . . . . . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 7.2. Informative References . . . . . . . . . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + + + + + + + + + + + + + + + + +Pazhyannur, et al. Standards Track [Page 2] + +RFC 7563 Extensions to ANI June 2015 + + +1. Introduction + + "Access Network Identifier (ANI) Option for Proxy Mobile IPv6" + [RFC6757] introduced the ANI mobility option. This enabled a Mobile + Access Gateway (MAG) to provide the Network-Identifier, Geo-Location, + and Operator-Identifier sub-options. When the access network is + WLAN, the Network-Identifier sub-option may contain the Service Set + Identifier (SSID) and the Basic Service Set Identifier (BSSID) of the + Access Point (AP) and the geolocation of the AP, and the Operator- + Identifier may contain the realm of the operator managing the WLAN. + The MAG sends the above information to the Local Mobility Anchor + (LMA). The LMA may use this information to determine access-network- + specific policies (in terms of Quality of Service (QoS), Deep Packet + Inspection (DPI), etc.). Further, the LMA may make this information + available to location-based applications. + + While the above mentioned sub-options provide a rich set of + information, in this document we describe the need for extending the + ANI sub-options that are particularly useful in WLAN deployments. In + WLAN deployments (especially indoor AP deployments), it is difficult + to provide geospatial coordinates of APs. At the same time, for many + location-based applications the civic location is sufficient. This + motivates the need for an ANI Civic-Location sub-option. In many + deployments, operators tend to create groups of APs into "AP-Groups". + These groups have a group identifier. The group identifier is used + as a proxy for coarse location (such as the floor of a building or a + small building). The group identifier may also be used to provide a + common policy (e.g., QoS, charging, DPI) for all APs in that group. + This specification provides a sub-option for the MAG to convey a + group identifier to the LMA. The provisioning of the group + identifier is outside the scope of this specification and is + typically done via a configuration mechanism such as CLI (Command- + line Interface) or via Control and Provisioning of Wireless Access + Points (CAPWAP) [RFC5415] [RFC5416]. + + This document also provides a new sub-option that determines how + often the MAG will update the ANI. In typical deployments, it is + expected that the MAG will update the ANI as soon as it changes. + This is certainly true when the MAG is co-located with the AP. When + a client roams from one AP to another AP, the MAG on the roamed (or + sometimes referred to as the target) AP will provide the new ANI (for + example, the network identifier and geolocation of the new AP). + However, if the MAG is co-located with an Access Controller (also + known as Wireless LAN Controller (WLC)), then a client roaming from + one AP to another AP does not necessarily perform an ANI update. The + WLC handles client mobility between APs and as a result, intra-WLC + mobility is hidden from the LMA. + + + + +Pazhyannur, et al. Standards Track [Page 3] + +RFC 7563 Extensions to ANI June 2015 + + + In such deployments, the information conveyed in the ANI sub-options + (e.g., location) becomes stale and is only refreshed at the time of + lifetime expiry. The MAG could deal with this by sending a Proxy + Binding Update (PBU) whenever a client moves between APs just for the + purpose of updating the ANI sub-option. Alternately, this document + allows the LMA to determine how often it wants to know about the + changes in the ANI sub-option; for example, in some cases the LMA may + not care about the ANI sub-option except at the time of initial + binding, or in some cases it may care about every AP transition. The + sub-option allows the LMA to tell the MAG the desired update + frequency. As always, mobility events or re-registration events will + update the ANI sub-options. The LMA can use the ANI Update-Timer + option to set the maximum frequency at which it wants to receive ANI + updates. This is particularly useful in environments where a MAG + covers a large number of Wi-Fi APs and there is high client mobility + between the APs; for example, in a stadium Wi-Fi deployment, if a LMA + does not want ANI updates any more often than 100 seconds, then it + can propose 100 seconds as the value for ANI Update-Timer. + + [RFC6757] provides ANI sub-options to carry geolocation information. + In this document, we provide additional sub-options to carry the + civic location and group identifier. This document also defines an + ANI sub-option to enable a MAG to communicate how often the MAG will + update the ANI information. + +2. Conventions and Terminology + +2.1. Conventions + + 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 [RFC2119]. + +2.2. Terminology + + All of the mobility-related terms used in this document are to be + interpreted as defined in [RFC5213] and [RFC5844]. In this document, + Civic Location is defined as follows. + + Civic Location: There are two common ways to identify the location + of an object, either through geospatial coordinates or by so- + called civic addresses. Geospatial coordinates indicate + longitude, latitude, and altitude, while civic addresses indicate + a street address or sometimes the location within a building (such + as a room number). Civic location refers to the civic address. + + + + + + +Pazhyannur, et al. Standards Track [Page 4] + +RFC 7563 Extensions to ANI June 2015 + + +3. Protocol Extension + +3.1. Civic-Location Sub-Option + + The Civic-Location is a mobility sub-option carried in the Access + Network Identifier option defined in [RFC6757]. This sub-option + carries the civic location information of the mobile node as known to + the MAG. The format of this option is defined below. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |ANI Type=4 | ANI Length | Format | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | civic location ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Civic-Location Sub-Option + + ANI Type: 4 + + ANI Length: Total length of this sub-option in octets, excluding the + ANI Type and ANI Length fields. + + Format: This specifies the encoding format of the civic location. + The value 0 is defined in this specification as described below. + The remaining values (1 through 255) are reserved. + + 0: This value denotes Binary Encoding. The location format + is based on the encoding format defined in Section 3.1 of + [RFC4776], whereby the first 3 octets are not put into the + civic location field (i.e., the code for the DHCP option, + the length of the DHCP option, and the 'what' element are + not included). What is included is the two-octet country + code field, followed by one or more civic address elements. + The country-code is a two-letter ISO 3166 country code in + capital ASCII letters, e.g., US. The structure of the civic + address elements that follow the country code field is as + defined in Section 3.3 of [RFC4776]. + + Reserved: This MUST be set to zero when sending and ignored when + received. + + civic location: This field will contain the civic location. The + format (encoding) type is specified in the format field of this + sub-option. Note that the length SHALL NOT exceed 253 bytes. + + + + + +Pazhyannur, et al. Standards Track [Page 5] + +RFC 7563 Extensions to ANI June 2015 + + +3.2. MAG-Group-Identifier Sub-Option + + The MAG group identifier is a mobility sub-option carried in the + Access Network Identifier option defined in [RFC6757]. The MAG group + identifier identifies the group affiliation of the MAG within that + Proxy Mobile IPv6 domain. The group identifier is not assumed to be + globally unique across different network operators. However, the + group identifier should be unique within an operator network. In + domains spanning multiple operators, it is recommended that the + Operator-Identifier sub-option (defined in [RFC6757]) be used in + addition to the MAG-Group-Identifier sub-option to ensure uniqueness. + When the MAG is configured with a group identifier, the MAG should + send its group identifier in the PBU. Note that the configuration of + this identifier is outside the scope of this specification; the usage + of the identifier by the LMA is left to implementation. The format + of this sub-option is defined below. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |ANI Type=5 | ANI Length | group identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: MAG-Group-Identifier Sub-Option + + ANI Type: 5 + + ANI Length: Total length of this sub-option in octets, excluding the + ANI Type and ANI Length fields. The value is always 2. + + group identifier: This is a 3-octet unsigned integer value assigned + to a group of MAGs. + +3.3. ANI Update-Timer Sub-Option + + The ANI Update-Timer is a mobility sub-option carried in the ANI + option defined in [RFC6757]. Section 4 describes how the MAG and LMA + use this sub-option. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |ANI Type=6 | ANI Length | Update-Timer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: ANI Update-Timer Sub-Option + + + + + +Pazhyannur, et al. Standards Track [Page 6] + +RFC 7563 Extensions to ANI June 2015 + + + ANI Type: 6 + + ANI Length: Total length of this sub-option in octets, excluding the + ANI Type and ANI Length fields. The value is always 2. + + Update-Timer: Update-Timer is a 16-bit unsigned integer. The unit + of time is 4 seconds (time unit of 4 seconds ensures consistency + with the time units for the binding lifetime). A value of 0 + indicates that the MAG will send an updated ANI mobility option as + soon as it discovers a change in ANI values. A non-zero value + indicates that the MAG may not send ANI values immediately after + they have changed but rather send ANI updates when the + Update-Timer expires. + +4. Protocol Considerations + + The following considerations apply to the LMA and the MAG. + +4.1. MAG Considerations + + o The conceptual Binding Update List entry data structure maintained + by the mobile access gateway, described in Section 6.1 of + [RFC5213], is extended to store the access-network-related + information elements associated with the current session. + Specifically, the following parameters are defined: + + * civic location + + * MAG group identifier + + * ANI Update-Timer + + o If the mobile access gateway is configured to support the Access + Network Information sub-options defined in this specification, it + includes this option with the specific sub-options in all PBU + messages (including PBUs for lifetime extension and for + deregistration) that it sends to the LMA. The Access Network + Information option is constructed as specified in Section 3. + + o ANI Update-Timer Considerations: The MAG sets the Update-Timer + based on an exchange of timer values with the LMA. When the ANI + Update-Timer sub-option is carried in a PBU, it is considered as a + proposed value for the Update-Timer. The LMA may change the value + of the Update-Timer received in the PBU. When the LMA-provided + value for the Update-Timer is different than what is sent by the + MAG, the MAG should use the LMA-provided value. If the MAG does + not receive an ANI Update-Timer sub-option in the Proxy Binding + Acknowledgement (PBA) (in response to sending the sub-option in + + + +Pazhyannur, et al. Standards Track [Page 7] + +RFC 7563 Extensions to ANI June 2015 + + + the PBU), then MAG behavior is in accordance to [RFC6757]. When + ANI parameters of a mobility session change, the MAG checks + whether the Update-Timer has expired. If the Update-Timer has + expired, the MAG sends a PBU with the ANI option. The ANI option + reflects the updated access network parameters for that mobility + session. If the Update-Timer has not expired, the MAG does not + send a PBU. When the Update-Timer for a mobility session expires, + the MAG checks whether the ANI parameters have changed. If the + parameters have changed from the last reported values, the MAG + sends a PBU with an ANI option. If the parameters have not + changed, the MAG does not send a PBU (and the Update-Timer remains + expired). Note that the MAG may send a PBU even before the + Update-Timer expires. This could be, for example, to initiate a + QoS service request to the LMA (see [RFC7222]). In such cases, + the MAG must reset the Update-Timer when it sends a PBU. + + o If the mobile access gateway had any of the Access Network + Information mobility options included in the PBU sent to an LMA, + then the PBA received from the LMA should contain the Access + Network Information mobility option with the specific sub-options. + If the mobile access gateway receives a PBA with a successful + Status Value but without an Access Network Information mobility + option, then the mobile access gateway may log the event and, + based on its local policy, even proceed to terminate the mobility + session. In this case, the mobile access gateway knows the LMA + does not understand the Access Network Information mobility + option. + +4.2. LMA Considerations + + o The conceptual Binding Cache entry data structure maintained by + the LMA, described in Section 5.1 of [RFC5213], is extended to + store the access-network-related information elements associated + with the current session. Specifically, the following parameters + are defined: + + * civic location + + * MAG group identifier + + * ANI Update-Timer + + o On receiving a PBU message from a MAG with the ANI option, the LMA + must process the option and update the corresponding fields in the + Binding Cache entry. If the option is not understood by that LMA + implementation, it will skip the option and process the PBU + without these options. + + + + +Pazhyannur, et al. Standards Track [Page 8] + +RFC 7563 Extensions to ANI June 2015 + + + o If the received PBU message does not include the Access Network + Information option, then the mobility session associated with that + PBU is updated to remove any access network information elements. + + o If the LMA understands/supports the Access Network Identifier + mobility sub-options defined in this specification, then the LMA + echoes the Access Network Identifier mobility option with the + specific sub-option(s) that it accepted back to the mobile access + gateway in a PBA. The Civic-Location and MAG-Group-Identifier + sub-options defined in this specification should not be altered by + the LMA. The LMA may change the value of the ANI Update-Timer + sub-option. It may choose to either echo the same value or + increase or decrease the timer value. For example, if the LMA + does not want to receive frequent updates (as implied by the timer + value), it may choose to increase the value. Similarly, if the + LMA needs to receive ANI updates as soon as possible, then it may + set the value to zero (0) in the PBA. + +5. IANA Considerations + + IANA has registered the values described below. + + o This specification defines a new Access Network Identifier sub- + option called the Civic-Location sub-option. This mobility sub- + option is described in Section 3.1 and this sub-option can be + carried in the Access Network Identifier mobility option. The + type value <4> has been allocated from the registry "Access + Network Information (ANI) Sub-Option Type Values". + + o This specification defines a new Access Network Identifier sub- + option called the MAG-Group-Identifier sub-option. This mobility + sub-option is described in Section 3.2 and this sub-option can be + carried in Access Network Identifier mobility option. The type + value <5> has been allocated from the registry "Access Network + Information (ANI) Sub-Option Type Values". + + o This specification defines a new Access Network Identifier sub- + option called the ANI Update-Timer sub-option. This sub-option is + described in Section 3.3 and this sub-option can be carried in the + Access Network Identifier mobility option. The type value <6> has + been allocated from the registry "Access Network Information (ANI) + Sub-Option Type Values". + + + + + + + + + +Pazhyannur, et al. Standards Track [Page 9] + +RFC 7563 Extensions to ANI June 2015 + + +6. Security Considerations + + The Civic-Location sub-option defined in this specification is + carried in the Access Network Identifier option defined in [RFC6757]. + This sub-option is carried in PBU and PBA messages. This sub-option + is carried like any other Access Network Identifier sub-option as + defined in [RFC6757]. Therefore, it inherits its security guidelines + from [RFC5213] and [RFC6757] and does not require any additional + security considerations. + + The Civic-Location sub-option exposes the civic location of the + network to which the mobile node is attached. This information is + considered to be very sensitive, so care must be taken to secure the + Proxy Mobile IPv6 signaling messages when carrying this sub-option. + The base Proxy Mobile IPv6 specification [RFC5213] specifies the use + of IPsec for securing the signaling messages, and those mechanisms + can be enabled for protecting this information. Operators can + potentially apply IPsec Encapsulating Security Payload (ESP) with + confidentiality and integrity protection for protecting the location + information. The other way to protect the sensitive location + information of network users is of course to not send it in the first + place. Users of the Civic-Location sub-option should provision + location values with the highest possible level of granularity, e.g., + to the province or city level rather than provisioning specific + addresses. + + Access-network-specific information elements that the mobile access + gateway sends may have been dynamically learned over DHCP or using + other protocols. If proper security mechanisms are not in place, the + exchanged information between the MAG and LMA may be compromised. + This situation may result in incorrect service policy enforcement at + the LMA and impact other services that depend on this access network + information. This threat can be mitigated by ensuring the + communication path between the mobile access gateway and the access + points is properly secured by the use of IPsec, Transport Layer + Security (TLS), or other security protocols. + + + + + + + + + + + + + + + +Pazhyannur, et al. Standards Track [Page 10] + +RFC 7563 Extensions to ANI June 2015 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol + (DHCPv4 and DHCPv6) Option for Civic Addresses + Configuration Information", RFC 4776, + DOI 10.17487/RFC4776, November 2006, + <http://www.rfc-editor.org/info/rfc4776>. + + [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., + Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", + RFC 5213, DOI 10.17487/RFC5213, August 2008, + <http://www.rfc-editor.org/info/rfc5213>. + + [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy + Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, + <http://www.rfc-editor.org/info/rfc5844>. + + [RFC6757] Gundavelli, S., Ed., Korhonen, J., Ed., Grayson, M., + Leung, K., and R. Pazhyannur, "Access Network Identifier + (ANI) Option for Proxy Mobile IPv6", RFC 6757, + DOI 10.17487/RFC6757, October 2012, + <http://www.rfc-editor.org/info/rfc6757>. + + [RFC7222] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. + Gundavelli, "Quality-of-Service Option for Proxy Mobile + IPv6", RFC 7222, DOI 10.17487/RFC7222, May 2014, + <http://www.rfc-editor.org/info/rfc7222>. + +7.2. Informative References + + [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, + Ed., "Control And Provisioning of Wireless Access Points + (CAPWAP) Protocol Specification", RFC 5415, + DOI 10.17487/RFC5415, March 2009, + <http://www.rfc-editor.org/info/rfc5415>. + + [RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, + Ed., "Control and Provisioning of Wireless Access Points + (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, + DOI 10.17487/RFC5416, March 2009, + <http://www.rfc-editor.org/info/rfc5416>. + + + +Pazhyannur, et al. Standards Track [Page 11] + +RFC 7563 Extensions to ANI June 2015 + + +Acknowledgements + + This document benefited considerably from the numerous improvements + proposed by Kent Leung. + +Authors' Addresses + + Rajesh S. Pazhyannur + Cisco Systems + 170 West Tasman Drive + San Jose, California 95134 + United States + EMail: rpazhyan@cisco.com + + + Sebastian Speicher + Cisco Systems + Richtistrasse 7 + Wallisellen, Zurich 8304 + Switzerland + EMail: sespeich@cisco.com + + + Sri Gundavelli + Cisco Systems + 170 West Tasman Drive + San Jose, California 95134 + United States + EMail: sgundave@cisco.com + + + Jouni Korhonen + Broadcom Corporation + 3151 Zanker Road + San Jose, California 95134 + United States + EMail: jouni.nospam@gmail.com + + + John Kaippallimalil + Huawei + 5340 Legacy Drive, Suite 175 + Plano, Texas 75024 + United States + EMail: john.kaippallimalil@huawei.com + + + + + + +Pazhyannur, et al. Standards Track [Page 12] + |