[address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20170922/52787735/attachment.sig>