[Originally to ppml, CC to address-policy@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 injected prefixes. 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: 192.0.0.0/28 192.0.0.16/28 ... 192.0.0.192/28 192.0.0.208/28 In this example, only blocks above 192.0.0.208/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: 192.0.0.0/28 192.0.0.64/28 ... 192.0.2.0/28 192.0.2.64/28 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 192.0.0.64/27, an attacker can inject 192.0.0.64/28 + 192.0.0.80/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 192.0.0.64/28 and 192.0.0.80/28 and maybe also 192.0.0.64/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.