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/[email protected]/
[address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
- Previous message (by thread): [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
- Next message (by thread): [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Remco van Mook
remco.vanmook at gmail.com
Tue May 17 14:08:01 CEST 2016
Thank you Marco. Dear colleagues, Yes, this is another policy proposal about IPv4. It's even about the current allocation policy (confusingly known as 'last /8'). I'm sorry it's come to this. The proposal doesn't aim to change a lot about the *intended* goals of the last /8 policy - instead, it tries to clarify the current policy and lock it down against creative interpretations. We're in the IPv4 afterlife, and have been for about 3.5 years. The last scrap of IPv4 space that any LIR can get is meant for a specific purpose - to facilitate migration to IPv6. The age of the 32 bit integers is over. The other purpose of the 'last /8' policy is to be able to hand out IPv4 space to new entrants for as long as feasible. These specific purposes are currently not reflected anywhere once a block has been allocated, and this proposal means to change that. To summarise the proposed changes: - All allocations handed out under the 'last /8 policy' will be (re-)registered as 'ALLOCATED FINAL'; - Allocations marked as 'ALLOCATED FINAL' can not be transferred or sub-allocated; - Any LIR can hold up to a /22 of 'ALLOCATED FINAL' address space, regardless of how they got it; - Any excess space will have to be returned to the RIEP NCC within 180 days (however I don't intend that this is applied retroactively); - DNS reverse delegation will be limited to the LIR itself, and is limited to a total of a /22 in space. And, outside of policy but enforceable as business rules following from this policy proposal: - No RPKI for any 'ALLOCATED FINAL' blocks over a single /22 - No routing registry entries for any 'ALLOCATED FINAL' blocks over a single /22 Basically, every LIR gets 1 allocation, and if you no longer need it or you end up having more, you have to return the excess. All the extra limitations should be workable if you're using the space the way it was intended, but make it unattractive to collect allocations for other purposes. Let's hear your thoughts. I'll be at the RIPE meeting next week where I'll be talking about this proposal during the first APWG session. Kind regards, Remco van Mook (no hats) > On 17 May 2016, at 14:05 , Marco Schmidt <mschmidt at ripe.net> wrote: > > Dear colleagues, > > A new RIPE Policy proposal 2016-03, "Locking Down the Final /8 Policy" > is now available for discussion. > > The goal of this proposal is to limit IPv4 from the remaining address pool > to one /22 per LIR (regardless of how it was received). > These “final /22” allocations will receive a separate status with several restrictions: > > - These allocation are not transferrable > - LIRs may only retain one final /22 following a merger or acquisition > - Sub-allocations are not possible > - Reverse delegation authority can not delegated to another party > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2016-03 > > We encourage you to review this proposal and send your comments to > <address-policy-wg at ripe.net> before 15 June 2016. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/1aedf671/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: </ripe/mail/archives/address-policy-wg/attachments/20160517/1aedf671/attachment.sig>
- Previous message (by thread): [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
- Next message (by thread): [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]