IPv6 Operations I. van Beijnum Internet-Draft September 27, 2006 Intended status: Informational Expires: March, 2007 BGP Community for PA Multihoming draft-van-beijnum-v6ops-pa-mhome-community-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 24, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract When an organization wants to connect to the internet using two or more Internet Service Providers (multihoming), this is usually done by setting up BGP routing between the organization in question and each of its ISPs. For this, the multihomed organization needs a block of address space. This can either be a provider independent (PI) address block that belongs to the organization, or a block out of the provider aggregatable (PA) address space of one its ISPs. With IPv4, an address block of at least /24 will generally be suitable for multihoming, whether its origin is PI or PA. However, until now, ISPs were encouraged to only accept /32 and shorter prefixes from IPv6 PA space, while end-users generally receive a /48. This makes Van Beijnum Expires March 27, 2007 [Page 1] Internet-Draft BGP Community for PA Multihoming September 2006 multihoming with PA address space in IPv6 very difficult. This memo describes a new well-known BGP community attribute for tagging prefixes used for multihoming with PA space in order to facilitate filtering, rather than filter based on prefix length alone. 1 Introduction Since the introduction of Classless Inter-Domain Routing (CIDR) in BGP-4 it has been possible to advertise prefixes of arbitrary length into the "global routing table". However, in IPv4 the practice of filtering out prefixes longer than a /24 is widely adopted by network operators. A smaller number of operators only accepts prefix sizes that match allocations and assignments by the Regional Internet Registries that handle day-to-day address distribution. The RIRs publish lists of which prefix size they give out from certain parts of the address space. With IPv6, the 6Bone Backbone Routing Guidelines [RFC2772] only allowed advertisement of the prefix size that was delegated, which was either /24 or /32. When the RIRs started giving out address space, they included as part of their collective policies a minimum delegation size of /32 to accommodate prefix length filtering. Later, they also started giving out /48 prefixes for certain purposes. The result is that many operators consider it best practice to allow /48 prefixes from the address blocks set aside for these assignments, and /32 or shorter from the remaining IPv6 global unicast address space (currently 2000::/3). The result of these filtering practices is that with IPv6, multihoming using address space from a provider's PA block is as good as impossible. Worse, when a longer prefix from PA space, generally a /48, shows up, this is often over a much longer path because the prefix is filtered over shorter paths, in which case the longest match first rule [RFC1519] makes traffic flow towards the longer prefix over the longer path. A case can be made for relaxing these filters to allow multihoming using PA space, but not having filters that reject /48 (and longer) prefixes from PA space removes a line of defense against accidental deaggregation. This is what happens when an AS leaks internal routing information. Worst case, an ISP that has a /32 block could leak as many as 65,536 /48s. This document offers an alternative by defining a BGP community that can be used to tag prefixes used for multihoming so it's possible to make the distinction between prefixes in PA space that are longer than /32 which are advertised on purpose, and those that are apparently leaked by accident. Van Beijnum Expires March 27, 2007 [Page 2] Internet-Draft BGP Community for PA Multihoming September 2006 2 MULTIHOME community The name of the new community is MULTIHOME. Its value is to be decided by the Internet Assigned Numbers Authority. Because a multihomed prefix is no longer recognizable as such when the MULTIHOME community is stripped off, BGP implementations are encouraged to propagate the MULTIHOME community by default, even if they don't propagate other communities by default. Some implementations don't propagate communities by default, but since it's almost impossible for a network operator to know for sure that all of its (external) BGP sessions are toward such implementations, it seems unlikely that propagating the MULTIHOME community by default would cause operational problems. Operators should tag prefixes from PA space used for multihoming with the MULTIHOME community and propagate this community along with the advertisement of these prefixes. It is not incompatible with the intent of this memo to tag prefixes used for multihoming that aren't drawn from PA space. So a PI prefix could have the MULTIHOME community, and subsequently be allowed through by both the filters that recognize PI prefixes and by filters that allow the MULTIHOME community. The MULTIHOME community isn't meant to be used on more specific prefixes that are advertised for traffic engineering purposes. Doing this may lessen the effectiveness of the community as people may start ignoring the MULTIHOME community and filter out prefixes longer than /32 in PA space if the number of routes advertised for traffic engineering purposes grows too large and many of them carry the MULTIHOME community. 3 Suggested filtering practices Policies about which routes to filter and which to allow are a local matter. As such, the following suggestions on filtering don't constitute a mandate from the IETF, the Regional Internet Registries or any other organization, but merely reflect examples of filtering policies that are expected to make technical sense in the absence of other considerations. Until recently, the assumption was that most end-users, and especially the ones considering multihoming, would receive a /48 allocation. It is unclear whether this assumption holds today, and whether it will hold in the future. For the purpose of this document the assumption will be made that multihomers will use a prefix of at least /56. The pseudo code consists of numbered if/then clauses that are executed in order until a clause matches, at which point an ACCEPT will accept the prefix in the BGP RIB, while a REJECT will reject the prefix and the Van Beijnum Expires March 27, 2007 [Page 3] Internet-Draft BGP Community for PA Multihoming September 2006 evaluation of further clauses stops. At the end, there is a specific REJECT clause that rejects all prefixes that aren't allowed by any of the previous clauses. The logic of the filtering rules is that all prefixes are passed through the filter rules one by one, with "pfx" being the prefix under consideration at any particular time. At this time, APNIC, LACNIC and the RIPE NCC publish a list of address blocks from which longer prefixes than /32 are assigned ([ALLOCSIZE-APNIC], [ALLOCSIZE-LACNIC] and [ALLOCSIZE-RIPE]) and ARIN maintains a list of micro allocations[ARIN-MICRO]. 3.1 Don't allow MULTIHOME prefixes This policy allows /48 and shorter prefixes from the address ranges set aside for direct allocations and /32 and shorter prefixes from the IPv6 global unicast space. The presence of the MULTIHOME community isn't considered. This policy is provided as an example of a currently used filter policy for the purpose of illuminating the difference between the current situation and filtering based on the MULTIHOME community. 10 IF (pfx falls-in list-of-direct-allocation-blocks AND length(pfx) less-or-equal /48) THEN ACCEPT 20 IF (pfx falls-in ipv6-global-unicast-space AND length(pfx) less-or-equal /32) THEN ACCEPT 30 REJECT Note that there is no minimum prefix length. Some large ISPs have received very large blocks in the past and there is no way to know how large these blocks may become in the future. The minimum prefix length visible in the global routing table as of this writing is the 6to4 prefix, 2002::/16. 3.2 Allow MULTIHOME prefixes This policy allows /48 and shorter prefixes from the address ranges set aside for direct allocations, /56 and shorter prefixes from the IPv6 global unicast space if the MULTIHOME community is present and /32 or shorter otherwise. This policy would be suitable for peering sessions, where more specific routing information makes it possible to send more traffic over the Van Beijnum Expires March 27, 2007 [Page 4] Internet-Draft BGP Community for PA Multihoming September 2006 peering link, but also for transit sessions if the size of the routing table isn't a concern. 10 IF (pfx falls-in list-of-direct-allocation-blocks AND length(pfx) less-or-equal /48) THEN ACCEPT 20 IF (pfx falls-in ipv6-global-unicast-space AND length(pfx) less-or-equal /32) THEN ACCEPT 30 IF (pfx falls-in ipv6-global-unicast-space AND pfx has-community MULTIHOME AND length(pfx) less-or-equal /56) THEN ACCEPT 40 REJECT 3.3 Allow MULTIHOME prefixes with short AS path This policy allows /48 and shorter prefixes from the address ranges set aside for direct allocations, /56 and shorter prefixes from the IPv6 global unicast space if the MULTIHOME community is present and the AS path contains no more than four ASes, and /32 or shorter otherwise. This policy assumes that having more specific routing information for destinations that are many hops away has little added value and may even be harmful because it allows for long detours when the more specific route is filtered on more direct paths. 10 IF (pfx falls-in list-of-direct-allocation-blocks AND length(pfx) less-or-equal /48) THEN ACCEPT 20 IF (pfx falls-in ipv6-global-unicast-space AND length(pfx) less-or-equal /32) THEN ACCEPT 30 IF (ASpath(pfx) regular-expression-matches ".+_.+_.+_.+_.+") THEN REJECT Van Beijnum Expires March 27, 2007 [Page 5] Internet-Draft BGP Community for PA Multihoming September 2006 40 IF (pfx falls-in ipv6-global-unicast-space AND pfx has-community MULTIHOME AND length(pfx) less-or-equal /56) THEN ACCEPT 50 REJECT The regular expression in clause 30 matches if there are at least five sequences of one or more characters separated by the underscore character present. A period followed by a plus sign means "one or more characters" in regular expression matching, and matches an AS number here. The underscore character matches the space between AS numbers. This is a roundabout way of matching any AS path with five or more AS numbers in it, as most BGP implementations lack the capability to filter directly on the length of the AS path. 4 Alternatives The new MULTIHOME community is meant to support multihoming using a longer prefix taken from an ISP's provider aggregatable block of address space. It has been suggested that multihoming using provider independent address space is easier as, presumably, the RIRs will publish from which blocks they'll make PI assignments and what prefix length those assignments will have, so that network operators will allow those prefixes. However, some organizations prefer the PA approach, which has the added benefit that it's more compatible with the work going on in the IETF shim6 working group. Assuming multihoming with PA address space, it would be possible to filter based on a different property than a BGP community, most notably the prefix length. This requires that prefixes used for multihoming can be recognized by their prefix length. For instance, when an organization decides to multihome, it could be assigned a /47 prefix, the next shorter length after /48. Network operators could then allow /47 prefixes, which are advertised by multihomers, while filtering out /48 and longer prefixes in PA space, which are used by non-multihomed customers of ISPs. 5 IANA Considerations The IANA is asked to register the new MULTIHOME well-known community attribute in the "Well-known Communities" registry that references [RFC1997]. 6 Security Considerations Filtering based on the MULTIHOME community without any form of authentication of the relationship between a prefix and the advertising Van Beijnum Expires March 27, 2007 [Page 6] Internet-Draft BGP Community for PA Multihoming September 2006 AS allows for the situation where an attacker announces reachability to a certain address block with the MULTIHOME community present. If this prefix is accepted, the longest match first rule will make traffic flow towards the attacker announcing the longer prefix, rather than to the ISP announcing the entire PA block in BGP. 7 References [RFC1519] V. Fuller, T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993. [RFC1997] R. Chandrasekeran, Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. [RFC2772] R. Rockell, R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000. [RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [ALLOCSIZE-APNIC] APNIC, "Allocation sizes within APNIC IPv4 address ranges", http://www.apnic.net/db/min-alloc.html [ALLOCSIZE-LACNIC] LACNIC, "LACNIC - Registration Services", http://lacnic.net/en/registro/index.html [ALLOCSIZE-RIPE] L. Vegoda, "RIPE-380 Address Space Managed by the RIPE NCC", June 2006, https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html [ARIN-MICRO] ARIN, "ARIN Micro-allocations", http://www.arin.net/reference/micro_allocations.html 8 Document and Author Information This document expires March, 2007. The latest version will always be available at http://www.muada.com/drafts/. Please direct questions and comments to the v6ops mailinglist or directly to the author: Iljitsch van Beijnum Email: iljitsch@muada.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in Van Beijnum Expires March 27, 2007 [Page 7] Internet-Draft BGP Community for PA Multihoming September 2006 this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Van Beijnum Expires March 27, 2007 [Page 8]