This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
- Previous message (by thread): [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
- Next message (by thread): [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Anna Wilson
anna.wilson at heanet.ie
Fri Sep 22 16:50:20 CEST 2017
Hi Tom, > On 22 Sep 2017, at 15:37, Tom Hill <tom.hill at bytemark.co.uk> wrote: > > 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. The proposal doesn't have a goal of changing anyone's behaviour or incentivising anyone. The goal is to quadruple the number of remaining IPv4 applications that RIPE NCC can fulfil. So the gain is to those three quarters of applications that would otherwise be unsuccessful. >> 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. It's a fair concern; I suggest filters specific to the last /8 boundary as a way to contain the risk. >> 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. I hear you. I think it even supports your point in this case- if deaggregation could spread when the stakes were lower, we may be very sure that it'll spread when the stakes are higher. I hope I was able to address that point in the surrounding paragraphs. Best regards, Anna -- Anna Wilson Service Desk Manager HEAnet CLG, Ireland’s National Education and Research Network 1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland +353 (0)1 6609040 anna.wilson at heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20170922/576434cf/attachment.html>
- Previous message (by thread): [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
- Next message (by thread): [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]