Internet DRAFT - draft-van-beijnum-grow-controlled-deagg
draft-van-beijnum-grow-controlled-deagg
Global Routing Operations Working Group I. van Beijnum
Internet-Draft Institute IMDEA Networks
Intended status: Informational October 21, 2014
Expires: April 24, 2015
Controlled IPv6 deaggregation by large organizations
draft-van-beijnum-grow-controlled-deagg-00
Abstract
The use of IPv6 addresses by large organizations doesn't fit the
commonly used PA/PI dichotomy. Such organizations may hold a large
address block which is deaggregated into subprefixes that are
advertised by subunits of the organization. This document proposes a
set of best practices to allow this deaggregation to be controlled
through filtering so that on the one hand, the size of the IPv6
global routing table isn't unduly inflated, while on the other hand
organizations that seek to deaggregate a large IPv6 address block
don't see their reachability limited by remote filters.
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 April 24, 2015.
Copyright Notice
Copyright (c) 2014 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
van Beijnum Expires April 24, 2015 [Page 1]
Internet-Draft Controlled IPv6 deaggregation October 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The aggregate of last resort service . . . . . . . . . . . . 3
3. Geographic communities . . . . . . . . . . . . . . . . . . . 4
4. Encoding of geographic information . . . . . . . . . . . . . 4
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security considerations . . . . . . . . . . . . . . . . . . . 8
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Generally, two classes of global unicast address prefixes are
recognized: provider aggregatable (PA) and provider independent (PI).
PA prefixes are the prefixes advertised into the global routing table
by ISPs, covering the addresses used by multiple customers of that
ISP. PI prefixes are the address blocks used by a single
organization.
However, there is a third class of addresses: the addresses used by
large organizations with subunites that independently connect to the
internet. An example are multinational corporations. Another are
national governments. Such organizations often desire a single IPv6
prefix so the addresses used by subunits are easily recognized as
being part of the larger organization in firewalls and router
filters. As such, many of these organizations become "enterprise
LIRs" (local internet registries) at one or more of the five regional
internet registries (RIRs) that distribute IP addresses. However,
unlike regular LIRs (ISPs), they are not in the business of moving IP
packets between locations, and as such different locations or
subunits advertise deaggregates (subprefixes) of the organization's
LIR PA prefix, often to different ISPs. This advertisement of
deaggregates would be unexpected from regular LIRs, and as such, the
deaggregates may be filtered.
Currently, the IPv6 global routing table is small and in no immediate
danger of growing beyond what today's routers can handle. However,
without some of the limitations that are present in IPv4, the IPv6
routing table could conceivably grow at a high rate for decades to
come, and would then at some point become hard to manage.
van Beijnum Expires April 24, 2015 [Page 2]
Internet-Draft Controlled IPv6 deaggregation October 2014
This document proposes two mechanisms that will allow organizations
that seek to deaggregate an enterprise LIR prefix to enjoy the same
level of connectivity as users of PI and PA space while at the same
time limiting the impact of this practice on the IPv6 global routing
table. The first mechanism is the establishment of an "aggregate of
last resort" (AoLR), the second mechanism is a set of communities
that allow deaggregates to be filtered in some parts of a network
without loss of reachability.
This document is meant to start a discussion. As such, it may be
split into several documents, and/or the venue for discussion and
eventual publication is subject to change.
2. The aggregate of last resort service
The assumption is that an enterprise LIR allocates addresses from a
single block to different organizational subunits, and that these
subunits advertise those smaller blocks to the ISPs they use to
connect to the internet, where different subunits use different ISPs.
For reasons of cost and routing efficiency it's not possible or
desired to use an internal network between the subunits or locations
to transport traffic to/from the internet from one organizational
subunit to another.
One way to run such a network would be for the enterprise to
advertise its aggregate in a small number of locations. The traffic
is then delivered to those locations, and then from there sent back
to an ISP that has a path to the subunit in question. However, this
has the downside that traffic has to pass through one of the
locations advertising the aggregate, using up additional bandwidth
and possibly incurring long detours. For instance, if an
organization advertises its prefix in Europe then a third party in
the US that sends traffic to one of the organization's offices in the
US may see its traffic cross the Atlantic twice.
The solution is to ask one or more ISPs to advertise the aggregate--
preferably ones with a large geographic footprint. By default,
networks hand over traffic to a remote network as soon as possible
("hot potato" routing), so in this case the traffic just has to flow
to the closest location where the ISP in question has a presence. If
that ISP then connects to an ISP serving the organizational subunit
in question, the traffic can be handed over between the two ISPs at
the nearest location where they interconnect.
This way, deaggregates only have to be carried by ISPs providing the
aggregate of last resort service and the ISPs connecting subunits of
the organization. Because the organization has customer - service
van Beijnum Expires April 24, 2015 [Page 3]
Internet-Draft Controlled IPv6 deaggregation October 2014
provider relationships with each, presumably those ISPs will not
filter the deaggregates.
3. Geographic communities
BGP supports a community mechanism that allows a router to tag a
prefix with additional information that may be interpreted by other
routers. This document proposes a set of communities that encode the
geographic origin of a deaggregated prefix. This allows network
operators to filter prefixes that are covered by an aggregate.
Additionally, such filtering may be applied selectively.
For instance, a network that operates in the APNIC region may want to
filter out deaggregates originated in other regions, but allow the
ones originated in the APNIC region. Or a North American network may
want to carry European deaggregates only at the US East Coast, where
it interconnects with European networks, and only carry Asian
deaggregates at the US West Coast, where it interconnects with Asian
networks.
An objection against encoding geographic information in the routing
system is that topology doesn't follow geography. Strictly speaking,
this is of course true. In theory, a user in Tokyo could connect to
the internet in Madrid. In practice, this is is exceedingly rare.
And in the case where this happens and BGP is in the position to make
decisions, having this information available is even more useful than
in in routine situations: when that user in Tokyo connects to the
internet in Madrid and Hong Kong, users outside Europe would do well
to avoid the route through Madrid. A geographic community would
allow them to do exactly that.
4. Encoding of geographic information
There are currently two types of communities defined for BGP: the
original community attribute ([RFC1997]), which encodes 32-bit
values, and extended community attribute ([RFC4360]), which supports
subtypes of various lengths. Regular communities are widely
supported and are typically displayed in the form ddddd:ddddd, where
ddddd are both 16-bit values displayed in decimal, such as 702:120.
Defining a new extended community subtype has the advantage that it
would be possible to specify a new syntax and new semantics tailored
to the needs of the new community, but the disadvantage is that it
would take a lot of time for this to be implemented by router
vendors. As such, geographical information will be encoded into a
set of communities within the numbering space of the existing
[RFC1997] system. Router vendors are encouraged to recognize these
van Beijnum Expires April 24, 2015 [Page 4]
Internet-Draft Controlled IPv6 deaggregation October 2014
communities and handle them appropriately as outlined later in this
document.
There are many ways to encode geographic information, such as the ISO
3166-1 alpha-2 two-letter country code, the ITU E.164 one-to-three-
digit international phone dialing numbers and the ISO 3166-1 three-
digit numeric code. The only one that is well-known in numeric form
are international phone dialing numbers. However, the size
difference in population/area served between the different country
codes (and area codes in the North American Numbering Plan) is very
large, and the numbers don't lend themselves to easily identifying a
geographic region bigger than a metropolitan area but smaller than a
country.
To avoid these issues, this document specifies that geographic
communities encode latitude/longitude information. This encoding
avoids interpretation and contention. By rounding to whole degrees,
a reasonable tradeoff between precision and location privacy is
achieved.
A geographic community consists of two 16-bit values in decimal
notation. In the first value, the least significant bits indicate
north or south and east or west, respectively. In the second value,
the upper two digits indicate the latitude and the lower three digits
indicate the longitude, each rounded to the nearest degree. For
example:
Berlin, DE; 52 deg 31 min N, 13 deg 23 min E:
xxxx1:53013
Chicago, US; 41 deg 50 min N, 87 deg 41 min W:
xxxx0:42088
Mumbai, IN; 18 deg 58 min N, 72 deg 49 min E:
xxxx1:19073
Rio de Janeiro, BR; 22 deg 54 min S, 43 deg 11 min W:
xxxx2:23043
Saint Petersburg, RU; 59 deg 57 min N, 30 deg 18 min E:
xxxx1:60030
Locations further than 64 degrees north or south are encoded
differently: the upper two digits of the second community value
encode the upper two digits of the longitude, the next two digits
encode the latitude, and the last digit encodes the lower digit of
the longitude:
van Beijnum Expires April 24, 2015 [Page 5]
Internet-Draft Controlled IPv6 deaggregation October 2014
Spitsbergen, NO; 78 deg 45 min N, 16 deg 00 min E:
xxxx1:00790
McMurdo Station, Antarctica; 77 deg 51 min S 166 deg 40 min E:
xxxx3:16787
This format is somewhat human-readable. However, router vendors are
encouraged to recognize these communities and display the values as
follows:
xxxx1:53013
53N13E
xxxx0:42088
42N88W
xxxx1:19073
19N73E
xxxx2:23043
23S43W
xxxx1:60030
60N30E
xxxx1:790
79N0E
xxxx3:16787
78S167E
Furthermore, it would be helpful if filters could specify areas in
the form 53N3E-50NE8. (This encompasses the Netherlands in its
entirety, although it also covers parts of the neighboring
countries.)
Although they don't immediately serve the purpose of this draft, two
additional forms of geographic communities are specified. This makes
for three different sets of geographic communities:
Covered:
The presence of a geographic community of this type indicates
that the prefix is covered by an aggregate and can therefore
safely be filtered without loss of reachability. The location
encoded in the community is the location of the ISP side of
circuit that connects the site using the prefix to the internet.
If an indication that the prefix is covered by an aggregate is
van Beijnum Expires April 24, 2015 [Page 6]
Internet-Draft Controlled IPv6 deaggregation October 2014
desired, but not the encoding of a location, then the community
xxxx0:999 may be used.
Uncovered:
The presence of a geographic community of this type DOES NOT
indicate that a covering aggregate is present. The location
encoded in the community is the location of the ISP side of
circuit that connects the site using the prefix to the internet
and may be presented in order to facilitate best path selection.
Seen-at:
The presence of a geographic community of this type DOES NOT
indicate that a covering aggregate is present. The location
encoded in the community is a location where the prefix was seen.
For instance, the location where a network learned the prefix
over EBGP. Multiple instances of this type of geographical
community may be present.
5. IANA considerations
IANA is requested to register the following 16-bit ranges of
community values out of the subset of community value space that maps
to private AS numbers:
Covered origin NW
Covered origin NE
Covered origin SW
Covered origin NE
Uncovered origin NW
Uncovered origin NE
Uncovered origin SW
Uncovered origin NE
Seen-at NW
Seen-at NE
Seen-at SW
Seen-at NE
van Beijnum Expires April 24, 2015 [Page 7]
Internet-Draft Controlled IPv6 deaggregation October 2014
6. Security considerations
It would be possible for any router along the AS path to rewrite a
geographic community and claim a false geographic origin and/or
falsely claim that a prefix is covered by an aggregate.
7. Contributors
None at this time.
8. Acknowledgements
None at this time.
9. References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006.
Author's Address
Iljitsch van Beijnum
Institute IMDEA Networks
Avda. del Mar Mediterraneo, 22
Leganes, Madrid 28918
Spain
Email: iljitsch@muada.com
van Beijnum Expires April 24, 2015 [Page 8]
