Hi Anna, On 22/09/17 15:05, Anna Wilson wrote: > - that new entrants are most likely to support IPv6 (because very little > IPv4 can be got); > - that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work; > - reaching IPv4 runout while this is still the case will hurt those new > entrants disproportionately;
The assertion that reducing the amount of IPv4 given will encourage those entrants to support IPv6 is tentative at best. The LIR entrance is a means to an end, and either it provides enough IPv4 for the task at hand, or it does not (ergo you seek another option). A stunning number of LIR applications are - as far as I can tell from this corner - from those that would have otherwise applied for IPv4 PI space. Any sane 'new entrant' (e.g. startup ISP/host) relying on the LIR application solely isn't going to succeed. Whether you give them 1024 or 256 addresses, it's just a per-address cost. It doesn't make IPv6 any more fit for the same purpose, or worth the engineering time at a point where your sole concentration is on not going bust. Because I don't see a way in which this policy will change anyone's behaviour, or incentivise them differently over the current policy, I don't believe it needs to be changed. If you would like, we can take IPv6 adoption out of the argument completely, and I can still be solely against it for the reason of changing the status quo on acceptable prefix sizes for no perceivable gain to anyone. > So the problem we face with the DFZ I think is not specifically > "smallest prefix in the table" but "growth of number of entries over > time." Entries over time keeps going up, and RIR policies have very > successfully kept that growth contained. "I've deaggregated our /19 to /24s to prevent hijacks." is the problem. Legitimate traffic engineering is not the issue here, it's the blatant disregard for the cost of TCAM across the DFZ versus the selfish/misguided security requirements of certain network operators. The concern is that those persons will, very quickly, deaggregate to the minimum possible prefix size. > If you then fear that this deaggregation would spread to the rest of the > DFZ: yes, I share this fear. In fact I think we can be very sure that > this is coming, one way or another; Randy explained how based on history > earlier in the thread. Yes, and I pointed out to Randy in response that the stakes are hell of a lot higher than they were in 1995. Like, "we're not the butt of all jokes" higher. -- Tom
signature.asc
Description: OpenPGP digital signature
