[ppml] Fwd: Keeping in reserve
[Originally to ppml, CC to address-policy at ripe, prune as necessary]
On 5-okt-2006, at 18:17, David Conrad wrote:
> Is there any reason PI /48s shouldn't be allocated with the
> bisection method, thus removing the need to reserve space?
The goal of filtering in BGP is either to keep out accidentally
injected prefixes, or keep out both accidentially and maliciously
This means that a reasonable filter, i.e., one that can be configured
on a router with a relatively limited number of filter rules, must
allow through all prefixes that match legitimate allocations, and
reject as much of everything else as possible.
This means that ideally, from a certain block of address space,
prefixes of one size are allocated sequentially with no unused space
between them. For instance:
192.0.0.0/24 -> /28s:
In this example, only blocks above 22.214.171.124/28 can be successfully
used to get around the filter, either for the purpose of hijacking
unused address space for purposes like spamming, or to overload
routers by injecting large numbers of bogus prefixes.
If we now reserve a /26 for every user of a /28, we'd have:
So a filter would have to allow 192.0.0.0/22 -> /26 - /28. This gives
an attacker the opportunity to inject three malicious /28 prefixes
between any two legitimate /28s. Worse, when someone grows out of a /
28 and gets a /27, such as 126.96.36.199/27, an attacker can inject
188.8.131.52/28 + 184.108.40.206/28, which cover the same address space but
the longest match first rule makes packets flow toward the attacker
rather than the real holder of the addresses.
For this reason and because of temporary instability when moving from
a smaller to a larger prefix, or maybe because of simple laziness or
cluelessness, the real holder of the address space may choose to
inject both 220.127.116.11/28 and 18.104.22.168/28 and maybe also
22.214.171.124/27. This negates the purpose of keeping some extra space
in reserve between allocations. In IPv4 we have to be careful not to
give too much space away, but in IPv6 there is absolutely no reason
to skimp when people come back for seconds. So if a /48 isn't enough,
don't grow to a /47 or even a /44, just give a /40 and then a /32.
The number of extra prefixes in the routing table that this results
in is minimal because even a /48 is more than enough for the majority
of organizations, and it allows for much stricter filters. And it
avoids fragmenting the address space.
With the bisection method, you'd have to use even more liberal
filters and allow between /25 and /28 in this example.
All in all, it would be best if for every block of address space,
only a fixed size allocations are given out.