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 14:56:13 CEST 2017
Hi Ray, > On 22 Sep 2017, at 12:04, Jetten Raymond <raymond.jetten at elisa.fi> wrote: > > Hi Anna, > > I saw some calculations that with the current policy it would be 4-5 years, to run completely out, last /8 and returned space. > > Now I don’t know if these calculations are correct, but even if they are, or not, then I would like to know how long it should last ? 10 years, 20 , 50? > > I can see and understand your points, the original /8 proposal was not meant to delay v6, fully agree, but by spreading it now it will be expected to be spread out again in say 2-4 years (?) . > > I seriously think that the more time we get, or give the illusion that we can then rearrange it again, the more time people will ignore the fact that it will run out, regardless if we change the policy or not. I believe you are correct that people will ignore runout, regardless of whether we change the policy or not. My concern is that the problems of ignoring runout fall disproportionately not on existing holders who do the ignoring (who have a good chance of being able to rustle up a small amount of their existing space somewhere to run their IPv6 transition equipment) but on future new entrants (who would have no existing space to shuffle.) That's an externalised cost, and it is the very same externalised cost that I believe the original last /8 policy was intended to address. This proposal is the best way I can think to reduce that burden on new entrants. So to answer your first question: how long should it last? My only answer to that can be "for as long as new entrants need some IPv4 in order to use IPv6; or as long as possible if we can't get that far." We land on /24 because we think it's practical today. > Therefore I still think the current policy is sufficient. Forgive me if I misunderstand your thinking; I believe it's this: that full runout is the remaining tool we have to get existing IPv4 holders to deploy IPv6, so we should not take further actions to delay it. It's not an unreasonable effect to hope for. But the current /8 policy is already quite restrictive. I would be surprised if full runout would have a much greater effect on existing IPv4 holders. And even if that effect is something above negligible, the burden of it falls disproportionately on post-runout new entrants. So I think that's who we need to help, and why a policy change is needed. 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/04fa7979/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 ]