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]