Deaggregation by large organizations
Hi all, FYI, I just sent this to the IETF v6ops and grow lists: We are all familiar with PA (provider aggregatable) and PI (provider independent) address space. But it turns out a new type of IPv6 address space is starting to show up, which I'll call organization deaggregatable (OD) address space (until someone suggests a better name). How it works is like this: a large organization obtains a large block of IPv6 address space, either as a very large PI block or by becoming a local internet registry (LIR) and getting a regular LIR assignment directly from one of the five regional registries. However, rather than advertising that block in BGP as a single prefix, or perhaps a handful of prefixes, like an ISP would, they subdivide this block within the organization and then many subunits advertise subprefixes though different ISPs. The aggregate may or may not be advertised. The advantage to the organization is that they have provider independent address space that they'll never have to renumber out of, as well as having a single prefix that identifies all of the organization, which makes filtering easy. There seem to be two types of organizations that do this: geographically dispersed ones that advertise subprefixes in different locations, such as multinationals, and organizations with very independent subunits but with more limited geographical scope, such as national governments. This practice, especially if/when it becomes more common, presents two challenges: 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipality prefixes into the global IPv6 routing table. 2. Filtering. If people want to avoid large numbers of deaggregates in their routing tables, they may employ some kind of filtering, especially if the deaggregates are very long prefixes. This means that packets are no longer reliably delivered to the place announcing a more specific prefix. Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the consequences of different kinds of behavior and thus avoid unpleasant surprises. These are some of the things that could go into such best practices: - A well-understood maximum prefix length for IPv6, similar to /24 for IPv4. - An understanding of how the service providers that provide connectivity to multiple subunits of a large organization can work together in order to maximize availability and minimize costs for the organization, the service providers and other network operators. - A way to provide a point of last resort where traffic for the aggregate can be sent to if more specifics are filtered. - A set of communities that indicate whether a prefix is a more specific that is covered by an aggregate and/or is safe to filter without loss of connectivity. - A set of communities that indicate geographical origin of prefixes so remote more specific prefixes can be filtered while local prefixes are kept. - Guidelines for reserving address space in address plans. Is it better to have free space reserved so existing prefixes can grow, or keep reserved space together so tight prefix length filters are possible and reserved space isn't broken up into small pieces? Please note that I'm crosspositing this to v6ops and grow initially. If the chairs have any guidance on which working group is more appropriate for this discussion, please let us know and we can drop the other one. Also note that I haven't been following discussions in both wgs recently, so if this has been discussed previously, my apologies. Last but not least, this treads on RIR policy. But in my opinion, this is foremost a technical matter with global implications and as such is best discussed within the IETF rather than in the five respective policy development forums.
On 15/10/14 16:00, Iljitsch van Beijnum wrote:
Hi all,
FYI, I just sent this to the IETF v6ops and grow lists:
We are all familiar with PA (provider aggregatable) and PI (provider independent) address space. But it turns out a new type of IPv6 address space is starting to show up, which I'll call organization deaggregatable (OD) address space (until someone suggests a better name).
Dear Iljitsch, My *personal* feeling is that RIRs (and NOGs) would be much more suitable place for this discussion, as IETF in principle and historically was not meant to deal with routing policy and/or routing table handling. Being said that, if you can join us on Monday, 3rd November at 18:00 in London for RIPE BCOP TF meeting, I think we can have appropriate discussion about this topic and also ask operators in the room if they would be interested to join and work cooperatively with you on this document. Dear BCOP community - Benno and myself would really appreciate some feedback on this topic before the meeting, so we can shape the message and discussion properly. Goal of the BCOP TF is to get operators together to document Best Current Operational Practice and I think this could be very well one of most needed ones. Cheers and thnx, Jan Zorz
Guys, thank you very much, Iljitsch, for starting this - as I think - long needed discussion. Given I have some background as for the reasoning and perspective of "those organizations wishing to deaggregate" I will happily join the discussion in London. Please allow to point interested parties to this blogpost on the topic: http://www.insinuator.net/2014/10/deaggregation-by-large-organizations/, and to the slides referenced therein which might serve as a contribution to the discussion beforehand. cheers Enno On Wed, Oct 15, 2014 at 07:42:43PM +0200, Jan Zorz @ go6.si wrote:
On 15/10/14 16:00, Iljitsch van Beijnum wrote:
Hi all,
FYI, I just sent this to the IETF v6ops and grow lists:
We are all familiar with PA (provider aggregatable) and PI (provider independent) address space. But it turns out a new type of IPv6 address space is starting to show up, which I'll call organization deaggregatable (OD) address space (until someone suggests a better name).
Dear Iljitsch,
My *personal* feeling is that RIRs (and NOGs) would be much more suitable place for this discussion, as IETF in principle and historically was not meant to deal with routing policy and/or routing table handling.
Being said that, if you can join us on Monday, 3rd November at 18:00 in London for RIPE BCOP TF meeting, I think we can have appropriate discussion about this topic and also ask operators in the room if they would be interested to join and work cooperatively with you on this document.
Dear BCOP community - Benno and myself would really appreciate some feedback on this topic before the meeting, so we can shape the message and discussion properly. Goal of the BCOP TF is to get operators together to document Best Current Operational Practice and I think this could be very well one of most needed ones.
Cheers and thnx, Jan Zorz
-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
participants (3)
-
Enno Rey
-
Iljitsch van Beijnum
-
Jan Zorz @ go6.si