SAVI P. Thubert, Ed. Internet-Draft Cisco Systems Intended status: Standards Track June 4, 2012 Expires: December 6, 2012 Throttling RAs on constrained interfaces draft-thubert-savi-ra-throttler-01 Abstract In a large switched topology with either many routers or routers that transmit a high rate of multicast advertisements per router, as suggested to support mobile nodes, the cost of distributing the many resulting multicast messages to certain classes of devices might be prohibitive. This is the case of a device that runs on batteries, or a device that is reachable over a wireless interface. For this device, it can be beneficial to filter a certain amount of multicast messages such as the Router Advertisement while preserving the functionality expected in the IPv6 Neighbor Discovery Protocol. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 6, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Thubert Expires December 6, 2012 [Page 1] Internet-Draft ra-throttler June 2012 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Routers behavior . . . . . . . . . . . . . . . . . . . . . 5 3.2. Wireless Mobility domain . . . . . . . . . . . . . . . . . 5 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Throttling scope and period . . . . . . . . . . . . . . . 7 4.2. Pending Hosts List . . . . . . . . . . . . . . . . . . . . 7 4.3. Advertising Routers List . . . . . . . . . . . . . . . . . 8 4.4. RA with an Advertisement Interval Option . . . . . . . . . 8 4.5. Final RA . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.6. Throttling Policy . . . . . . . . . . . . . . . . . . . . 10 5. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Thubert Expires December 6, 2012 [Page 2] Internet-Draft ra-throttler June 2012 1. Introduction The protection of the network is not necessarily a security function such as the defense against a specific attack. It might also have to do with other activities that include the control of multicast storms, as provided to some extent by Multicast Listener Discovery (MLD) Snooping [RFC4541], or of the overuse of the network that might degrade the service for all users as provided for instance by Call Admission Control [RFC5865]. In particular, the wireless edge of a large Layer 2 topology will require some special protections to conserve the limited bandwidth that is available over the radio medium, such protections certainly involving the reduction of multicast operations. MLD Snooping helps control the impact of multicast messages but: It does not apply to the all-nodes link-scoped multicast address (FF02::1) as defined in the IP Version 6 Addressing Architecture [RFC4291]. MLD snooping is generally not implemented for link scope multicast messages anyway. If MLD snooping runs in instance as opposed to the Access Point (AP) and if there is at least one listener associated to the AP then the AP will still get the multicast and transmit it to all the devices that are associated to the AP. MLD snooping has the granularity of a group as opposed to a binding table that has the granularity of a target - a host. This document focusses on the protection against an excessive bandwidth consumption by multicast IPv6 Neighbor Discovery (ND) [RFC4861] Protocol (NDP) Router Advertisement (RA) messages over the wireless edge of a switched network. RA messages are link-scoped messages that provide the recipient node with link information such as availability and characteristics of routers that are present on the link and a list of prefixes that are usable for IPv6 NDP Stateless Address Autoconfiguration (SLAAC) [RFC4862]. RA messages coming from different routers may carry different information, including information about the router itself, but also different prefix lists and other information such as the period of transmission [RFC6275]. Thubert Expires December 6, 2012 [Page 3] Internet-Draft ra-throttler June 2012 In a number of cases, the fact that a node misses an RA does not impact the node operation in a notable fashion, either because the information is fully redundant with information that the node already has (e.g. multiple RAs of a same content from a same router in rapid sequence) or because the information is not critical to the node (e.g. yet another router that is not preferable as default gateway). In other cases, the loss of an RA is eventually recovered, but the node will not operate optimally in the meantime and such a loss should be avoided. This document studies situations when an Ethernet Switch, an IEEE 802.11 Access Point, or a Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller (AC) [RFC5415] can, with no notable effect, make the decision not to copy an RA message onto a port or a set of ports, typically one or more ports that connect to an IEEE 802.11 wireless domain, the consequences of doing so and the eventual recovery. In the remainder of this document, the term throttling will refer to the decision not to copy a message over such ports, and the layer 2 device in charge of making that decision will simply be referred to as switch, whether it is a classical Ethernet switch or any one of the sorts of devices listed above. 2. Terminology The draft uses the following terminology: Switch: A layer 2 device that distributes packets over one or more ports. This broad definition includes but is not limited to Ethernet and IEEE802.3 switches, CAPWAP Access Controllers and IEEE 802.11 Access Points. Throttling: The decision not to copy a given multicast message onto a given port or a set of ports after the determination that the RA would be redundant for most hosts across the port(s). A multicast packet that is throttled over a given port might still be copied for unicast delivery to selected hosts on a that port if it is determined that they will benefit from receiving the RA. The packet might still be passed on to other ports such as trunk ports, for further switching along a VLAN for instance. Throttled port: A port on the switch where throttling is active. The port might be an access port that is directly connected to a host, but it might also be a multipoint port, for instance if it is connected to another switch such as an Access Point. Thubert Expires December 6, 2012 [Page 4] Internet-Draft ra-throttler June 2012 3. Problem statement 3.1. Routers behavior Assuming that the solicitor's source address is not the unspecified address, a router may choose to respond to an ND Router solicitation (RS) with a unicast RA message directly to the soliciting host's address. But it is common that the router aggregates multiple requests and sends a single multicast response to the all-nodes group. This RA is received by all the nodes on link, though a host that did not issue an RS is probably not very interested in receiving the solicited RA response message. Yet, in a wireless environment, a host will usually issue an RS each time it reassociates, which can be quite often if the host is as mobile as a smartphone. A traditional (wireline) router will typically not rate limit its RA emissions based on consistent RA messages received from other routers, though such a behavior is required in the Routing Protocol for Low Power and Lossy Networks (RPL) [I-D.ietf-roll-rpl] that is specifically designed for constrained environments such as wireless mesh networks. As a result, the number of RAs on a switched topology increase roughly linearly with the number of deployed routers. As it goes, the whole RA operation denotes an implicit expectation that the cost for a multicast operation is not substantially different from that of a unicast transmission and that the cost is roughly similar on all segments of the link. Sadly, this is not true in the case of a composite network with a switched Ethernet backbone and an IEEE 802.11 Extended Service Set (ESS) wireless edge. The situation is even worse if the edge is a mesh network, e.g. an IEEE 802.11S or a Low Power Lossy Network as described in [I-D.phinney-roll-rpl-industrial-applicability] and [I-D.thubert-lowpan-backbone-router]. In any case, a rate of RAs that might appear acceptable on the backbone can rapidly become excessive on the wireless edge. 3.2. Wireless Mobility domain A number of (layer 3) Network-Based Localized Mobility Management (NetLMM) techniques have been deployed that enable IP mobility transparently to the host, that is without requiring the active participation of the host in any mobility-related signaling. This is achieved by hiding its mobility to the host and more specifically by presenting the host with a consistent link appearance as it roams at layer 3, in particular through tailored RA messages. An example of such NetLMM solutions would be the adaption of Proxy Mobile IPv6 (PMIPv6) [RFC5213] within a proprietary mobility framework. Thubert Expires December 6, 2012 [Page 5] Internet-Draft ra-throttler June 2012 As a result, within a same radio environment (say an IEEE 802.11 Service Set Identification or SSID), some of the associated nodes may be local nodes and some other nodes may be roaming devices that are virtually part of some other link or VLAN in a remote location. If all the associated nodes received a local RA announcing an local IPv6 prefix, roaming devices would detect their movement, form new addresses and defeat the mobility functionality to the point that the entire mobility domain would appear as one flat single IPv6 link. To avoid that problem, a dedicated RA is unicast to each of the associated devices as opposed to sent once as a layer 2 broadcast to all devices in a single shot. A very common method consists in rewriting the link layer multicast address in a frame that carries the layer 3 multicast message onto a layer 2 unicast address. This isolates which L3 multicast packet gets to which host, and more importantly which multicast packet will not get to a given host for whih it is not destined. When a multicast packet is converted into multiple unicast frames by a siwtch such as an Access Point or an Access Controller, a single packet that is sent to the all-nodes group can consume a large amount of bandwidth that is roughly a factor of the number of associated devices, and disrupt sensitive applications such as voice over IEEE 802.11. The NDP assumption that a multicast does not cost more than a unicast is severely broken. It results that the ND Protocol is not really suited for the wireless medium, and that some tailoring is required in instance to reduce the impact of the multicast messages, in particular RA messages. 4. Operation The NDP messages Router Advertisements are scoped to a link. They are sent on a given IPv6 link (e.g. a Virtual Local Area Network) and should be delivered only to IPv6 nodes that reside on that link. An RA message can be transmitted over the medium either as unicast response or as a multicast message that is sent to the link-scoped all-nodes multicast address (FF02::1) as defined in [RFC4291], which all IPv6 nodes on the link listen to. If a Router Advertisement is sent to a unicast destination address, instance MUST forward the packet to the destination device. But as opposed to other ND Protocol operations such as the Duplicate Address Detection (DAD) that occurs only when a node obtains or forms a new address, multicast RAs are sent periodically and might be quite frequent for the duration of the network activity. In that case, instance MAY drop the multicast RA if it is redundant. The question becomes to determine whether a multicast RA is redundant. Thubert Expires December 6, 2012 [Page 6] Internet-Draft ra-throttler June 2012 A switch might connect ports of different natures. Some ports may need throttling of the RA messages, and some node. It is expected that some mechanism is in place to determine which ports require throttling, for instance a configured policy or an automatic discovery. 4.1. Throttling scope and period The scope of a throttling activity is a link (a VLAN). Within that scope, some ports on instance are determined to be throttled, while others are not. A throttling period is associated to that scope. A policy dictates how many and under which conditions multicast RAs are throttled. The policy is based on counters that count RAs per router and counters that aggregate the numbers to the throttling scope (the VLAN). The counters are reset at each throttling period. NDP does not mandate that routers on a link expose the same prefixes. It is possible that a router advertises a prefix that none of the other routers does for instance. Or a router might advertise a better preference for a given destination [RFC4291]. It is this important that the throttling mechanism does not starve any given router. instance SHOULD attempt to distribute fairly the amount of RAs per source router, and to serve at least once any given router on the link (VLAN) within a given period of time. 4.2. Pending Hosts List A multicast RA that is the response to an RS is probably redundant for all nodes that did not solicit the RA in the first place. But it is certainly useful to nodes that issued an RS over a throttled port since the last multicast RA happened. instance needs to keep track of all those hosts as discovered through their RS messages, in an abstract list referred to as the Pending Hosts List (PHL). There is one PHL per link (that is, typically, per VLAN). A host is anchored to a port on instance, a link layer address, and eventually one or more VLAN identifier(s) depending on the deployment. An IPv6 Link Local Address [RFC4291] might be available to qualify the host. A PHL entry SHOULD contain all the anchor parameter and MAY indicate additional information such as the host Link Local Address. instance SHOULD add a host to the PHL when it receives an RS from that host over a throttled port, and upon a layer 2 trigger that indicates that the port has flapped, typically an association or a reassociation event in an Access Point or an Accesss Controller. instance MAY remove a host from the PHL when a RA is forwarded to the host, either as a unicast, a multicast, or a unicast copy of a Thubert Expires December 6, 2012 [Page 7] Internet-Draft ra-throttler June 2012 throttled multicast, and SHOULD remove the entry after a number or RAs are forwarded, depending on the policy that applies to the host. 4.3. Advertising Routers List The primary cause of RA redundancies is a router that sends multiple identical RAs in a short sequence, for instance as stimulated by hosts joining the link. instance identifies such redundancies by keeping track of all the routers as discovered through RA messages, and eventually of the content of those RA messages, in an abstract list referred to as the Advertising Routers List (ARL). There is one ARL per link (VLAN). A router is anchored to a port on instance, a link layer address, and eventually one or more VLAN identifier(s) depending on the deployment. The router Link Local Address is found as the source address of the RA. A ARL entry SHOULD contain all the anchor parameters, the router Link Local Address, and a number of counters that indicate the router activity over the last period and MAY contain additional information from the RA such as a prefix list or the router preferences [RFC4191]. The entry MUST also contain counters that are necessary for the throttling operation, typically the number of multicast RAs that where copied and the number that were throttled during the current throttling period. instance SHOULD add a router to the ARL when it receives an RA from that router on any port that belong to that link (VLAN). instance SHOULD remove the router from the ARL when the throttle period elapses. instance MAY maintain a list of routers that were part of the ARL for the previous period in an alternate list to keep additional history and improve runtime performances. 4.4. RA with an Advertisement Interval Option The Mobility Support in IPv6 (MIPv6) [RFC4191] section 7.3 introduces the Advertisement Interval Option (AIO), used in RA messages to advertise the interval at which the advertising router sends unsolicited multicast Router Advertisements. When this option is present, a switch SHOULD NOT interfere with a routers attempt to live up to its claim that at least one RA message will be posted every advertisement interval. There is more than one way for instance to comply with this requirement, as controlled by a policy that applies to the throttling operation: instance MAY never copy RAs from a given router that carry the AIO over throttled ports. Thubert Expires December 6, 2012 [Page 8] Internet-Draft ra-throttler June 2012 Or instance MAY copy all RAs from a given router that carry the AIO over throttled ports. Alternatively, instance MAY monitor the timing of RA emissions from a given router and refrain from throttling at least one RA per advertisement interval from that router. It might then happen that the router arms its timer on a message that instance throttles later. In that case, the next RA that is not throttled can be separated by substantially more time than one advertisement interval though less than 2 intervals. This should not impact the MIPv6 operation that does not take action until no RA is received within two and a half advertisement intervals. It can be noted that the advertisement interval that is used to support mobility can be very short and load the radio medium quite dramatically, depending on the available bandwidth on that medium. The policy in place SHOULD probably make it so that RAs with too short intervals are not copied on throttled ports unless no other option is available. If mobile devices are expected on the wireless link, then it might be preferred to block all routers advertising AIO but one or two that would preferably use an acceptable interval. 4.5. Final RA Section 6.2.5 of the Neighbor Discovery specification [RFC4861] describe the router operation when it ceases to advertise on a given interface. In particular, the router needs to transmit one or more final (multicast) RA messages on the interface with a Router Lifetime field of zero. This information is critical to any host that utilizes the router either as default gateway or more preferred gateway for a given destination prefix since filtering out a final RA might leave such host without connectivity till the host discovers that the router is gone. A switch SHOULD NOT take actions that would prevent such a host from receiving at least one final RA that indicates that a given router ceases to be a available as a IPv6 gateway on the link (VLAN) where throttling applies. There is more than one way for instance to comply with that requirement, as controlled by a policy that applies to the throttling operation: instance MAY never throttle an RA with a Router Lifetime field set to zero. Alternatively, instance MAY throttle further multicast final RAs arrive immediately after a first final RA from a same router. Thubert Expires December 6, 2012 [Page 9] Internet-Draft ra-throttler June 2012 It can be noted that the advertisement interval that is used to support mobility can be very short and load the system quite dramatically. The policy in place should probably make it so that RAs with short intervals are not copied on throttled ports unless no other option is available. 4.6. Throttling Policy An implementation SHOULD allow to configure a policy whereby the RA throttling operation is based on the history of received RAs during the current throttling period. Suggested policy parameters per link (VLAN) include: throttle-period: This is the duration of the throttling period. A suggestion is to keep this value under the highest MaxRtrAdvInterval used in the network. MaxRtrAdvInterval is defined in [RFC4861] with a default of 600 seconds. The policy that provides that parameter MAY apply to the link (VLAN) or instance. max-through: This is a maximum number of RAs that may pass before for all routers during a throttling period. rAdvInterval is defined in [RFC4861] with a default of 600 seconds. The policy that provides that parameter MAY apply to the link (VLAN) or instance. A suggested default is 1. at-least: This is the minimum guaranteed number of RAs that pass before the first RA is throttled for a given router. The policy that provides that parameter MAY apply to an individual router, a port, the link (VLAN) or instance. A suggested default is 1. This parameter takes precedence over the max-through parameter that is defined at the link (VLAN) level so as not to starve any router. at-most: This is a maximum number of RAs that may pass before for a given router during a throttling period. The policy that provides that parameter MAY apply to the router, the port, the link (VLAN) or instance. A suggested default is 1. interval-option: This parameter indicates the behaviour upon RAs with the IAO as discussed in Section 4.4. The policy that provides that parameter MAY apply to the router, the port, the link (VLAN) or instance. A suggested default is never to copy RAs with IAO on a throttled port. Thubert Expires December 6, 2012 [Page 10] Internet-Draft ra-throttler June 2012 5. Manageability An implementation SHOULD allow the administrator to define one or more throttling policies and to apply them on the relevant targets (routers, ports, links and switch). The implementation should count the number of RAs that passed and RAs that are throttled per target. 6. IANA Considerations This specification does not require IANA action. 7. Security Considerations This specification is not found to introduce new security threat. 8. Acknowledgements The author wishes to thank Eric Levy-Abegnoli for his kind mentorship all along this project. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 9.2. Informative References [I-D.ietf-roll-rpl] Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. Winter, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in Thubert Expires December 6, 2012 [Page 11] Internet-Draft ra-throttler June 2012 progress), March 2011. [I-D.phinney-roll-rpl-industrial-applicability] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability in industrial networks", draft-phinney-roll-rpl-industrial-applicability-00 (work in progress), October 2011. [I-D.thubert-lowpan-backbone-router] Thubert, P., "LoWPAN Backbone Router", draft-thubert-lowpan-backbone-router-00 (work in progress), November 2007. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. Thubert Expires December 6, 2012 [Page 12] Internet-Draft ra-throttler June 2012 Author's Address Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 497 23 26 34 Email: pthubert@cisco.com Thubert Expires December 6, 2012 [Page 13]