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.
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.
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)
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.
Correct solution is not to use some so called 'strict' ipv6 filters, which break Internet, by not allowing discontinuous pops having connectivity.
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?
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 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.
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.
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
> 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
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.
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 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.
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.
