in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4? in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth. so, at first blush, we thought v6 would be about the same as v4. but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits. this does not bode well. randy
and then there are the loons who will locally push /64 or longer, some of which may leak. even if things were sane & nothing longer than a /32 were to be in the table, are we not looking at the functional equivalent of v4 host routes? /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 19February2015Thursday, at 19:07, Randy Bush <randy@psg.com> wrote:
in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4?
in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth.
so, at first blush, we thought v6 would be about the same as v4.
but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits.
this does not bode well.
randy
That might be a little more valid once we move past 2000::/3 -- at the moment, more like IPv4 /29s. Alas, /48 seems to be the generally accepted maximum prefix length, so, yeah, this could be unfortunate. Jima On 2015-02-19 20:16, manning bill wrote:
and then there are the loons who will locally push /64 or longer, some of which may leak.
even if things were sane & nothing longer than a /32 were to be in the table, are we not looking at the functional equivalent of v4 host routes?
/bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102
On 19February2015Thursday, at 19:07, Randy Bush <randy@psg.com> wrote:
in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4?
in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth.
so, at first blush, we thought v6 would be about the same as v4.
but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits.
this does not bode well.
randy
Instead, we may find network equipment vendors might ship with larger/faster TCAM, and faster processing to handle increasing routing table demands. We've been hearing "the end is nigh!" for a decade, and as far as I can tell, we are no closer to the end than when we started. Maybe some equipment refresh cycles will increase, and some providers will have to make a choice to upgrade sooner than later. But, as network engineers and architects, surely we all know that nothing is static, and growth will continue to accelerate. Better be ready, or some of us will be left behind. On Thu, Feb 19, 2015 at 7:29 PM, Jima <nanog@jima.us> wrote:
That might be a little more valid once we move past 2000::/3 -- at the moment, more like IPv4 /29s.
Alas, /48 seems to be the generally accepted maximum prefix length, so, yeah, this could be unfortunate.
Jima
On 2015-02-19 20:16, manning bill wrote:
and then there are the loons who will locally push /64 or longer, some of which may leak.
even if things were sane & nothing longer than a /32 were to be in the table, are we not looking at the functional equivalent of v4 host routes?
/bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102
On 19February2015Thursday, at 19:07, Randy Bush <randy@psg.com> wrote:
in a discussion with some fellow researchers, the subject of ipv6
deaggregation arose; will it be less or more than we see in ipv4?
in http://archive.psg.com/jsac-deagg.pdf it was thought that multi-homing, traffic engineering, and the /24 pollution disease were the drivers. multi-homing seems to be increasing, while the other two were stable as a relative measure to total growth.
so, at first blush, we thought v6 would be about the same as v4.
but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits.
this does not bode well.
randy
-- Brent Jones brent@brentrjones.com
On Thu, Feb 19, 2015 at 10:16 PM, manning bill <bmanning@isi.edu> wrote:
and then there are the loons who will locally push /64 or longer, some of which may leak.
2001:2b8:46:bbbb::/64 ... a fairly extensive list actually....
show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count Count: 297 lines
Some are likely my local network's interfaces (so skip ~50 or so? to be generous) and some might be my provider's customers? (but they shouldn't send me shorter than a /48, right?) -chris (note on another observation point I don't see this sort of thing so perhaps it's just one upstream in a collection... I'll ask them seperately)
On Feb 19, 2015, at 21:25 , Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, Feb 19, 2015 at 10:16 PM, manning bill <bmanning@isi.edu> wrote:
and then there are the loons who will locally push /64 or longer, some of which may leak.
2001:2b8:46:bbbb::/64 ... a fairly extensive list actually....
show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count Count: 297 lines
Some are likely my local network's interfaces (so skip ~50 or so? to be generous) and some might be my provider's customers? (but they shouldn't send me shorter than a /48, right?)
-chris (note on another observation point I don't see this sort of thing so perhaps it's just one upstream in a collection... I'll ask them seperately)
Your regular expression will not only count /49 and longer, it will also count /19 and shorter. In my routing table, there are at least some examples of such routes. Owen
On Tue, Feb 24, 2015 at 12:27 PM, Owen DeLong <owen@delong.com> wrote:
On Feb 19, 2015, at 21:25 , Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, Feb 19, 2015 at 10:16 PM, manning bill <bmanning@isi.edu> wrote:
and then there are the loons who will locally push /64 or longer, some of which may leak.
2001:2b8:46:bbbb::/64 ... a fairly extensive list actually....
show route table inet6.0 | grep ^2 | except /4[876543210] | except /3 | except /2 | count Count: 297 lines
Some are likely my local network's interfaces (so skip ~50 or so? to be generous) and some might be my provider's customers? (but they shouldn't send me shorter than a /48, right?)
-chris (note on another observation point I don't see this sort of thing so perhaps it's just one upstream in a collection... I'll ask them seperately)
Your regular expression will not only count /49 and longer, it will also count /19 and shorter.
In my routing table, there are at least some examples of such routes.
yup, not very many and I think not enough to matter over all, give then actual point was I see many smaller (longer?) than /48 in the table.
On (2015-02-20 12:07 +0900), Randy Bush wrote: Hey,
in a discussion with some fellow researchers, the subject of ipv6 deaggregation arose; will it be less or more than we see in ipv4?
Is deaggregation inherently undesirable? In some RIR LIR will not get new allocation, just because LIR lacks INET connectivity between their datacenter or pop. This wasn't issue in IPv4, because you actually could reasonably fill your IPv4 allocation and were eligible for another allocation for your discontinuous locations. Clearly there are valid routing reasons why >1 network from single company has to appears in DFZ. Having RIR allocate another network or having LIR deaggregate have exact same cost to RIB/FIB, yet they are different. Multiple allocation gives additional scrutiny, network must pass RIR policy to be able to exist. Deagrregation is entirely uncontrolled, we don't know from route object the reason for it, valid reasons and invalid reasons are grouped in same pool. What is the correct solution here? Deaggregate or allocate space you don't need? Or some others solution, should route object creation be limited to LIR and be controlled by specific policy? It would allow inject information about the reason for it. Correct solution is not to use some so called 'strict' ipv6 filters, which break Internet, by not allowing discontinuous pops having connectivity. -- ++ytti
On Fri, 20 Feb 2015, Saku Ytti wrote:
Correct solution is not to use some so called 'strict' ipv6 filters, which break Internet, by not allowing discontinuous pops having connectivity.
From a technical point of view, I have little interest in my router handling the fact that an office at the other side of the planet shut down
Before, the practical level of de-agg was at /24 for IPv4. This meant only larger organisations could do it. With automation in the network space increasing, and with /48 being justifiable to any site, and with /48 being the typical DFZ routing filter, we now have the possibility of a lot more entities seeing IP address based multihoming and "PI" being possible. I don't like where this is headed. There are millions of entities that are justifiable to announce a /48 into DFZ. Do we want this to happen? By allowing it, we're not putting any pressure to invent solutions for graceful address migration with continous services, and instead putting the pressure on the DFZ infrastructure. Is this the correct tradeoff? How many smaller than /32 in the IPv6 DFZ do we allow before we need to start to worry? In these discussions I frequently interact with people who don't want to limit things until they are actually a problem. So when will this become a problem? 100k de-agged routes? 200k? 500k? 1M? their router, and learning this via DFZ. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 20/02/15 12:42, Mikael Abrahamsson wrote:
I don't like where this is headed. There are millions of entities that are justifiable to announce a /48 into DFZ. Do we want this to happen?
rfc6115 have good overview and recommendation. IPv6 clearly need separation of identification of endpoints and routing information to that endpoint. We already have broadband operators who fully deagg their IPv4 space. And just one ISP IPv6 with /32 deagg will take 65536 routes.
On 2/20/2015 4:13 AM, Nikolay Shopik wrote:
rfc6115 have good overview and recommendation. IPv6 clearly need separation of identification of endpoints and routing information to that endpoint.
I'm not overly familiar, but I'm always good for new things if one process is supported. deagg X network to Y provider, ask provider to blackhole XY address in X. Not every provider has a good blackhole system. Sometimes you desire to move a subset of data to a single provider for purposes of discarding data. I believe some of the protocols allow multiple sub-identifiers for load balancing purposes, but I'm unsure how strictly they are adhered to or if they might be ignored. I know BGP blackholing is a coincidental abuse of how BGP works, but it is a commonly used one; especially when some city endusers now have more bandwidth than entire rural ISPs. DDOS/amplification isn't always necessary these days. :( Jack
Subject: Re: v6 deagg Date: Fri, Feb 20, 2015 at 10:42:03AM +0100 Quoting Mikael Abrahamsson (swmike@swm.pp.se):
From a technical point of view, I have little interest in my router handling the fact that an office at the other side of the planet shut down their router, and learning this via DFZ.
I'm working at one of those organisations who have a /48 and am announcing it into DFZ. We have a situation where I might have another site with separate connectivity to the DFZ (but there is internal networking) which would entitle me to another /48 according to RIR rules. I did ask my LIR whether there is any thought given to the possibility of getting the next higher prefix, thus creating a /47. They did understand the "why" perfectly well, of course. However, apparently there is no such process or intention available from the RIR in question (RIPE), short of explicitly asking for that specific prefix. Of course this does not help every case, but supporting aggregation where possible certainly ought to be in-scope for most policy-making bodies in this area. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 I'm wearing PAMPERS!!
Hi Mans,
I'm working at one of those organisations who have a /48 and am announcing it into DFZ. We have a situation where I might have another site with separate connectivity to the DFZ (but there is internal networking) which would entitle me to another /48 according to RIR rules.
Correct.
I did ask my LIR whether there is any thought given to the possibility of getting the next higher prefix, thus creating a /47. They did understand the "why" perfectly well, of course.
However, apparently there is no such process or intention available from the RIR in question (RIPE), short of explicitly asking for that specific prefix.
So you asked to grow the /48 to a /47? Was it accepted? Or did you want the RIR to automatically grow your first assignment when you request a second one without you having to ask?
Of course this does not help every case, but supporting aggregation where possible certainly ought to be in-scope for most policy-making bodies in this area.
Then please take this to the appropriate policy-making body: address-policy-wg@ripe.net :-) Cheers! Sander
Subject: Re: v6 deagg Date: Sat, Feb 21, 2015 at 01:48:48PM +0100 Quoting Sander Steffann (sander@steffann.nl):
However, apparently there is no such process or intention available from the RIR in question (RIPE), short of explicitly asking for that specific prefix.
So you asked to grow the /48 to a /47? Was it accepted? Or did you want the RIR to automatically grow your first assignment when you request a second one without you having to ask?
So far have just discussed it with my LIR, but will reinit this.
Of course this does not help every case, but supporting aggregation where possible certainly ought to be in-scope for most policy-making bodies in this area.
Then please take this to the appropriate policy-making body: address-policy-wg@ripe.net :-)
Considering this as well. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... this must be what it's like to be a COLLEGE GRADUATE!!
On Feb 20, Saku Ytti <saku@ytti.fi> wrote:
Is deaggregation inherently undesirable? In some RIR LIR will not get new No. Excessive deaggregation is undesirable, but we lack a method to teach routers to enforce this subtlety and maybe also a wide agreement on what is excessive.
allocation, just because LIR lacks INET connectivity between their datacenter or pop. This wasn't issue in IPv4, because you actually could reasonably fill your IPv4 allocation and were eligible for another allocation for your discontinuous locations. But at least in the RIPE region this can be easily solved by deaggregating /32s out of your /29.
-- ciao, Marco
Excessive deaggregation is undesirable, but we lack a method to teach routers to enforce this subtlety
you might find http://www.route-aggregation.net/ interesting randy
On Mon, Feb 23, 2015 at 1:33 PM, Randy Bush <randy@psg.com> wrote:
you might find http://www.route-aggregation.net/ interesting
Hi Randy, I found it very interesting. Wish I'd noticed when it was fresh. I don't fully understand the math yet but the algorithm doesn't smell right. As near as I can figure it may only be correct in a static system. If after convergence the disaggregate ceases to be reachable from the aggregate, there doesn't appear to be either enough information in the system or enough triggers traveling between routers for it to reconverge to a correct state. Deriving only from the information available to each router at each step, look at page 58 in the presentation and see if you can figure out what happens to the network in that start state when the link between u7 and u9 drops. Remember that all the slashed half-moons mean that the router in that position does not relay the disaggregate and, in most cases, does not know that the disaggregate exists. I've emailed the authors and asked them to clarify. I hope I'm wrong. I'm tried of being a killjoy on this sort of thing and it would be truly cool if it turns out they've cracked the problem. Regardless, if we could presume (with support from the registries) that disaggregates are always reachable from the aggregate (always TE, never downstream customers or discrete sites) and everybody with an address block was courteous enough to advertise an aggregate then it might be usable to control IPv6 deagg. Actually, as long as we could assume the first part we could probably have routers synthesize aggregates to cover the second. But without the first assumption it looks dysfunctional. I discussed the cutouts problem in my 2010 presentation to ARIN XXVI in Atlanta: https://bill.herrin.us/network/201010-cutouts.pdf Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
Hi Bill,
I don't fully understand the math yet but the algorithm doesn't smell right. As near as I can figure it may only be correct in a static system. If after convergence the disaggregate ceases to be reachable from the aggregate, there doesn't appear to be either enough information in the system or enough triggers traveling between routers for it to reconverge to a correct state.
If a network announces an aggregate when they can't reach all more-specifics then things will already be broken. Don't announce address space that you can't handle traffic for... But true: without Dragon the more specific would still arrive via another path and it would still be reachable. Cheers, Sander
On Tue, Feb 24, 2015 at 1:16 PM, Sander Steffann <sander@steffann.nl> wrote:
Bill Herrin said:
I don't fully understand the math yet but the algorithm doesn't smell right. As near as I can figure it may only be correct in a static system. If after convergence the disaggregate ceases to be reachable from the aggregate, there doesn't appear to be either enough information in the system or enough triggers traveling between routers for it to reconverge to a correct state.
If a network announces an aggregate when they can't reach all more-specifics then things will already be broken. Don't announce address space that you can't handle traffic for...
Howdy, That's... basically the opposite of how customer cutout routes work today. Funny thing about customers... when they go to the trouble of announcing a route to another ISP, they expect it to work even when the link to you fails. Not sure where they came up with such an unreasonable expectation. ;) Anyway, I heard back from DRAGON's authors. Paraphrasing: "An aggregate (e.g. 10.0.0.0/8) must be withdrawn if the aggregate's origin loses its direct route to the filterable disaggregate's origin (e.g. 10.2.3.0/24). The withdrawn aggregate is replaced with a synthesized set of announcements which fully cover the aggregate's address space excluding the unreachable disaggregate (e.g. 10.0.0.0/15, 10.2.0.0/23, 10.2.2.0/24, 10.2.4.0/22, 10.2.8.0/21, 10.2.16.0/20, etc.) When direct connectivity is restored, the aggregate is again announced and the synthetic announcements withdrawn." This overcomes my objection. The aggregate's origin can reasonably be programmed to trigger on the nearby disaggregate's withdrawal. System-wide withdrawal of the aggregate route is a sufficient trigger to cancel filtering on the disaggregate which should then fully propagate. And the overall savings should still be substantial even with transient synthetics in the table. I look forward to seeing how the authors address the many implications of this requirement. I'm not sold just yet but I am suitably impressed. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
On 2/24/2015 6:35 PM, William Herrin wrote:
Anyway, I heard back from DRAGON's authors. Paraphrasing: "An aggregate (e.g. 10.0.0.0/8) must be withdrawn if the aggregate's origin loses its direct route to the filterable disaggregate's origin (e.g. 10.2.3.0/24). The withdrawn aggregate is replaced with a synthesized set of announcements which fully cover the aggregate's address space excluding the unreachable disaggregate (e.g. 10.0.0.0/15, 10.2.0.0/23, 10.2.2.0/24, 10.2.4.0/22, 10.2.8.0/21, 10.2.16.0/20, etc.) When direct connectivity is restored, the aggregate is again announced and the synthetic announcements withdrawn." This overcomes my objection. The aggregate's origin can reasonably be programmed to trigger on the nearby disaggregate's withdrawal. System-wide withdrawal of the aggregate route is a sufficient trigger to cancel filtering on the disaggregate which should then fully propagate. And the overall savings should still be substantial even with transient synthetics in the table. I look forward to seeing how the authors address the many implications of this requirement. I'm not sold just yet but I am suitably impressed. Regards, Bill Herrin
Yipee for huge amounts of automatic updates! I guess convergence latency is better than memory? So, how many /16 networks does a core network have which they hand out to customers that are multi-homed? What is the state of flux? Normally, we'd see the transition states of the more specific routes. Now we'll see multiple updates for each of those transition states (/24 removed so /16 is broken. Another /24 is removed so a /17 is broken, another /24 is removed so a /18 is broken). Provider X lost 50 multihomed customers spread across 20 aggregate networks. Process! Aggregates normally cover unassigned space as well. Do we now have to define to the router which space is supposed to be used and which is not so it knows when to break apart an aggregate? Removing a route "don't come this way!" is roughly the same as breaking the aggregate except for the extra processing time. It is likely that a node choosing between 2 aggregates would also be choosing the same between 2 more specific routes. Until convergence is done, it'd still route the wrong way in either case. One could stipulate that convergence might be slightly longer in this case due to update processing. Routing might be contrary to desire in cases where more specific route is advertised one way only and then an aggregate is used as a fallback. While the node filtering the more specific route may consider the path the same so it filters, the next node is making a choice between aggregates and may choose to send the traffic the other way because it's less AS hops; but don't worry, the 256k line backup will do just fine! Consider this simplistic model: A------B \ / C C is a business or ISP with it's own address space. It normally advertises an aggregate /20 to A and B. A and B local-pref C's routes because that's what transit providers do. C is under a DDOS attack. They issue a covering /24 to B and a /32 to B for blackhole service. B will propagate the /32 through it's entire network because the hop is to a discard (nifty!), however, the /24 will be the same as the /20, so it is filtered out. We can change the local-pref (go communities) of the /24 and that will allow it to propagate to A. A will accept the /24, presumably because the /24 doesn't match the selected /20 chosen (because of local pref). However! A--D---B \ / C D may or may not filter the /24 from B. It depends on their routing policy. A may only see the /20 from D and thus send all it's DDOS traffic on to C due to local-pref. Sorry, C. Next time, please manually change your BGP so you no longer advertise an aggregate. Oh, and it will be simpler for you to change if you just do /24 networks from now on and don't bother with the aggregate headache. SUMMARY: What is the cost if aggregates start being broke apart and not used because people want to insure their traffic does what they want? What is the cost of all these aggregate networks being broken up because their more specific routes aren't there? What is the cost of managing which smaller networks are supposed to be there and which are just unassigned currently to prevent aggregate breakup? Jack P.S. I didn't delve completely into all the documents and so perhaps I misunderstood or missed something important. My concerns may be completely unjustified.
On Thu, Feb 19, 2015 at 10:07 PM, Randy Bush <randy@psg.com> wrote:
but then we considered that v6 allocations seem to be /32s, and the longest propagating route seems to be /48, leaving 16 bits with which the deaggregators can play. while in v4 it was /24s out of a /19 or /20, four or five bits.
this does not bode well.
Howdy, I took a look at what it might take to keep TE-based disaggregation under control back in 2009. This is what I came up with: http://lists.arin.net/pipermail/arin-ppml/2009-June/014351.html Needless to say, the sparse allocation expandable netmask strategy we're using instead doesn't have many levers we can grab for control. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
participants (14)
-
Brent Jones -
Christopher Morrow -
Jack Bates -
Jima -
manning bill -
md＠Linux.IT -
Mikael Abrahamsson -
Måns Nilsson -
Nikolay Shopik -
Owen DeLong -
Randy Bush -
Saku Ytti -
Sander Steffann -
William Herrin