2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)
Dear colleagues, The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. Some of the differences from version 1.0 include: - Introduction of new assessment criteria used to evaluate IPv6 allocations larger than a /29 - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-03 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 7 August 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC
* Marco Schmidt
You can find the full proposal and the impact analysis at:
I'm generally positive to this proposal, but the impact analysis made me realise that it only applies to *initial* allocations. That causes the new allocation criteria to only benefit any late adopters who do not currently hold an IPv6 allocation. They will get an unfair advantage that the early adopters who are currently holding a [presumably too small] allocation, as the early adopters cannot re-apply for a appropriately sized block under the new allocation criteria. I'll note that both authors' LIRs (uk.mod and de.kaufland) already hold an IPv6 /29 allocation each...so assuming the proposal was intended to help scratch an itch of their own, so to speak, perhaps this is simply an omission? Tore
Hi Tore,
-----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Tore Anderson
I'll note that both authors' LIRs (uk.mod and de.kaufland) already hold an IPv6 /29 allocation each...so assuming the proposal was intended to help scratch an itch of their own, so to speak, perhaps this is simply an omission?
It was our (uk.mod's) expectation/assumption that it would be possible to return an existing allocation (in an 'unused/as-new' state) and apply for another under the new criteria. Regards, Mathew
Hi Mathew,
I'll note that both authors' LIRs (uk.mod and de.kaufland) already hold an IPv6 /29 allocation each...so assuming the proposal was intended to help scratch an itch of their own, so to speak, perhaps this is simply an omission?
It was our (uk.mod's) expectation/assumption that it would be possible to return an existing allocation (in an 'unused/as-new' state) and apply for another under the new criteria.
That is correct. If you return your allocation you can then do a new first-allocation request. With the current text it won't be possible to grow an existing allocation though, as that would use the rules for additional allocations. Cheers, Sander
* Mathew Newton
It was our (uk.mod's) expectation/assumption that it would be possible to return an existing allocation (in an 'unused/as-new' state) and apply for another under the new criteria.
Hi Matthew, If your /29 remains unused I suppose I was wrong to consider you an early adopter of IPv6... ;-) I'm thinking more of an organisation that, e.g., received an /29 (as that was what the policy permitted at the time) and actually started using it as best they could. After the passage of 2015-03 they'd like to get a /28-or-larger under the new allocation criteria, but un-deploying what they currently have in production in order to do so might not be operationally feasible. Their situation is then very similar to the one that 2015-02 «Keep IPv6 PI When Requesting IPv6 Allocation» sought to fix. Just to be clear, I'm not objecting to the proposal as it currently stands; I just thought the case was worth while mentioning. If you'd rather let whomever ends up in that situation to also be the one to fix it (through a 2015-02-ish proposal), then that's fair enough as far as I'm concerned. Tore
Hi, as far as I am informed each V6- allocation made by RIPE had always a "reserved" space after the actual allocation which allows "extending" upto /27 ... so returning seems not to be necassary ... at least not as long as /27 is sufficient. BR Jens Am 10. Juli 2015 19:02:43 MESZ, schrieb Tore Anderson <tore@fud.no>:
* Mathew Newton
It was our (uk.mod's) expectation/assumption that it would be possible to return an existing allocation (in an 'unused/as-new' state) and apply for another under the new criteria.
Hi Matthew,
If your /29 remains unused I suppose I was wrong to consider you an early adopter of IPv6... ;-)
I'm thinking more of an organisation that, e.g., received an /29 (as that was what the policy permitted at the time) and actually started using it as best they could. After the passage of 2015-03 they'd like to get a /28-or-larger under the new allocation criteria, but un-deploying what they currently have in production in order to do so might not be operationally feasible. Their situation is then very similar to the one that 2015-02 «Keep IPv6 PI When Requesting IPv6 Allocation» sought to fix.
Just to be clear, I'm not objecting to the proposal as it currently stands; I just thought the case was worth while mentioning. If you'd rather let whomever ends up in that situation to also be the one to fix it (through a 2015-02-ish proposal), then that's fair enough as far as I'm concerned.
Tore
!DSPAM:637,559ffad4149491050911710!
Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
Hi Jens, * Opteamax GmbH
as far as I am informed each V6- allocation made by RIPE had always a "reserved" space after the actual allocation which allows "extending" upto /27 ... so returning seems not to be necassary ... at least not as long as /27 is sufficient.
Actually, the reservation is for a /29. That's precisely the reason why the 6RD proposal allowed for extension up to that exact size: «Legacy /32 allocations were allocated with a /29 of “reserved for future expansion” space in mind and can very easily be expanded within that /29. As such, a move from /32 to /29 does not impact negatively RIPE NCC, nor will it lead to discrimination among existing allocations. As the reserved space is already present and would not be allocated to anyone else other than the holder of the /32 already allocated, it seems reasonable to go ahead and let LIRs use the full /29 of space if they need it.» -- https://www.ripe.net/participate/policies/proposals/2011-04 In hindsight, it is a bit of a shame they didn't reserve a /28 instead. That way, 2011-04 could have moved the boundary with a full nibble. Oh well. Tore
Hi Tore, On 12.07.2015 08:54, Tore Anderson wrote:
Hi Jens,
* Opteamax GmbH
as far as I am informed each V6- allocation made by RIPE had always a "reserved" space after the actual allocation which allows "extending" upto /27 ... so returning seems not to be necassary ... at least not as long as /27 is sufficient.
Actually, the reservation is for a /29. That's precisely the reason why the 6RD proposal allowed for extension up to that exact size:
for a customer, I had a request for a /28 opened recently and were offered to start with a /29 and maybe resize it to /28 depending on outcome of 2015-03. I asked back if "resize" means new allocation so renumbering and received the following reply for RIPE-Staff:
We actually reserve 3 bits for each allocation so in future if needed your user would have access up to a /26.
I just downloaded ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz and grep'ed for /29 $ grep "/29" ripe.db.inet6num | sort I did not validate each and every line, but paged thru the output and it actually seems that the allocations made are all with a following reserved space that they can be grown upto /26: inet6num: 2a06:d00::/29 inet6num: 2a06:d40::/29 inet6num: 2a06:d80::/29 inet6num: 2a06:dc0::/29 inet6num: 2a06:e00::/29 inet6num: 2a06:e40::/29 inet6num: 2a06:e80::/29 inet6num: 2a06:ec0::/29 inet6num: 2a06:f00::/29 inet6num: 2a06:f40::/29 inet6num: 2a06:f80::/29 inet6num: 2a06:fc0::/29 Sorry in my last mail I remembered wrongly that it was /27 instead of /26 BR Jens -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
Hi Jens, * Opteamax GmbH
for a customer, I had a request for a /28 opened recently and were offered to start with a /29 and maybe resize it to /28 depending on outcome of 2015-03. I asked back if "resize" means new allocation so renumbering and received the following reply for RIPE-Staff:
We actually reserve 3 bits for each allocation so in future if needed your user would have access up to a /26.
You should ask that IPRA should re-read 2015-03. If your customer is allocated a /29, the new allocation criteria currently proposed in 2015-03 can simply *not* be used to "resize" it to a /28. This is, as I've mentioned earlier, due to the fact that 2015-03 only changes the *initial* allocation criteria. If already allocated a /29, your customer would need to request a *subsequent* allocation in order to obtain a /28, but as the subsequent allocation criteria is not changed by 2015-03, it won't be of any help as far as your customer's concerned. The Impact Analysis says: «It is important to note that the suggested policy change could also have impact on the evaluation of subsequent IPv6 allocation requests. LIRs that request an initial allocation under the proposed new assessment criteria might find it difficult to reach a sufficient HD-ratio in the future, as a significant amount of address space will be reserved for network structuring and future growth. Meeting the specified HD-ratio is required to qualify for a subsequent IPv6 allocation.» If your customer would qualify for a /28 under the 2015-03 criteria, I'd advise patience - have your customer wait until 2015-03 is implemented, at which point you can submit an *initial* allocation request for a /28.
I just downloaded ftp://ftp.ripe.net/ripe/dbase/split/ripe.db.inet6num.gz and grep'ed for /29
$ grep "/29" ripe.db.inet6num | sort
I did not validate each and every line, but paged thru the output and it actually seems that the allocations made are all with a following reserved space that they can be grown upto /26:
That is only the case if the allocation was a /29 to begin with. If it started out as a /32, and was extended to a /29 (most likely under the 6RD policy), then it can be expanded no further. Matthew's allocation, 2001:40c8::/29, is an example of this - the covering /28 contains other unrelated allocations: $ whois -h whois.ripe.net -- -m 2001:40c8::/28 | egrep '^(inet6num|netname):' inet6num: 2001:40c0::/32 netname: CH-SAFEHOST-20040726 inet6num: 2001:40c8::/29 netname: UK-MOD-20070802 Tore
Tore,
You should ask that IPRA should re-read 2015-03. If your customer is allocated a /29, the new allocation criteria currently proposed in 2015-03 can simply *not* be used to "resize" it to a /28. This is, as I've mentioned earlier, due to the fact that 2015-03 only changes the *initial* allocation criteria. If already allocated a /29, your customer would need to request a *subsequent* allocation in order to obtain a /28, but as the subsequent allocation criteria is not changed by 2015-03, it won't be of any help as far as your customer's concerned.
The 2015-03 proposal might still help/apply if you view the situation as being that the customer has not *outgrown* their /29 allocation (and hence needs consideration under the subsequent allocation policy) but rather that they have effectively *ordered the wrong size* in which case they could return the /29 and get a /28 in return under the new initial allocation criteria. If the /28 is able to encompass the first then this obviously carries the benefit of not requiring any renumbering. This is just speculation though and so, for clarity of understanding, it would be good to hear how RIPE NCC would see things operating in such a scenario... Mathew
Hi Mathew, Thanks for your question. As previously mentioned on the mailing list, LIRs can return unused previously-allocated IPv6 blocks if they believe their initial deployment plans require more than a /29. If a bigger allocation size is justified, the RIPE NCC will allocate a new range with the according reservation to allow for future aggregation. If an LIR has already started to deploy IPv6 from their current allocation and would like additional IPv6 space, the subsequent allocation policy applies: https://www.ripe.net/publications/docs/ripe-641#subsequent_allocation Where possible, the allocation will be made from an adjacent address block. I hope this answers your question. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC On 13/07/15 12:31, Mathew Newton wrote:
Tore,
You should ask that IPRA should re-read 2015-03. If your customer is allocated a /29, the new allocation criteria currently proposed in 2015-03 can simply *not* be used to "resize" it to a /28. This is, as I've mentioned earlier, due to the fact that 2015-03 only changes the *initial* allocation criteria. If already allocated a /29, your customer would need to request a *subsequent* allocation in order to obtain a /28, but as the subsequent allocation criteria is not changed by 2015-03, it won't be of any help as far as your customer's concerned. The 2015-03 proposal might still help/apply if you view the situation as being that the customer has not *outgrown* their /29 allocation (and hence needs consideration under the subsequent allocation policy) but rather that they have effectively *ordered the wrong size* in which case they could return the /29 and get a /28 in return under the new initial allocation criteria. If the /28 is able to encompass the first then this obviously carries the benefit of not requiring any renumbering.
This is just speculation though and so, for clarity of understanding, it would be good to hear how RIPE NCC would see things operating in such a scenario...
Mathew
Hi Tore,
If your /29 remains unused I suppose I was wrong to consider you an early adopter of IPv6... ;-)
'Early adopter' is a loose term so I won't go there but by 'unused' I was more meaning in an 'able-to-be-reissued' sense i.e. not being present in the Internet routing table, on blacklists etc. :-)
I'm thinking more of an organisation that, e.g., received an /29 (as that was what the policy permitted at the time) and actually started using it as best they could. After the passage of 2015-03 they'd like to get a /28-or-larger under the new allocation criteria, but un-deploying what they currently have in production in order to do so might not be operationally feasible.
Understood. This policy proposal is indeed not intended to cater for those situations and is focussed only on initial allocations. It might sound selfish however consideration was given to covering subsequent allocations also but it was decided that broadening the scope too much and potentially having to debate HD-ratios etc might be like trying to boil the ocean.
Just to be clear, I'm not objecting to the proposal as it currently stands; I just thought the case was worth while mentioning. If you'd rather let whomever ends up in that situation to also be the one to fix it (through a 2015-02-ish proposal), then that's fair enough as far as I'm concerned.
I'd rather leave subsequent allocations to a separate policy proposal if at all possible, but would certainly support its development (indeed making the proposal if there was no candidate sponsor). I think it stands to reason that any accepted change in criteria for initial allocation sizes ought to be also reflected in consideration of subsequent allocation requests also. Of course, there may be no easy way around the problem of some organisations having 'landlocked' allocations but even then renumbering might be the least-worst option (the alternative being slowly strangled by too small an allocation). Regards, Mathew
* Mathew Newton
This policy proposal is indeed not intended to cater for those situations and is focussed only on initial allocations. It might sound selfish [...]
Not at all. We all scratch our own itches. Been there, done that. :-) In any case, I don't see much of a downside with this proposal. The only thing one could conceivably be concerned about is excessive consumption of IPv6 due to LIRs grabbing larger allocations than they have a need for, but considering that a /29 is way more than enough for almost everyone and that the IA states that «LIRs would need to provide comprehensive documentation» in order to make use of this policy I don't see why anyone would bother trying to abusing it. On the other hand I would love to see more IPv6 happening in the governments in the region, so if this policy can help make that happen, I'm all for it. So without further ado: +1 Tore
Hi, On Fri, Jul 10, 2015 at 10:11:11PM +0200, Tore Anderson wrote:
So without further ado: +1
Haha, clear and easy for the chairs to understand :-) (But a useful discussion about additional allocations. I've been listening, and indeed it might be a useful excercise to come back there after we agree on what the initial criteria should be...) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On 09.07.2015 14:19, Marco Schmidt wrote:
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 7 August 2015.
tl;dr: I support the proposal in the current state. I do not really think this will help the routing table growth as outlined in section B of the impact analysis though. The organisations that are likely to request address space under the proposed rules will probably announce the received address space with some sort of de-aggregation. But I do think this proposal can remove constraints some organisation currently have when deploying (or trying to deploy) IPv6. g André
Hi André,
On 09.07.2015 14:19, Marco Schmidt wrote:
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 7 August 2015.
tl;dr: I support the proposal in the current state.
I do not really think this will help the routing table growth as outlined in section B of the impact analysis though. The organisations that are likely to request address space under the proposed rules will probably announce the received address space with some sort of de-aggregation.
But I do think this proposal can remove constraints some organisation currently have when deploying (or trying to deploy) IPv6.
I have already been thinking about the de-aggregation, and especially for national networks I think there are ways to keep that under control. But that's not really address policy related. I'll take it to our Routing WG. Cheers, Sander
Marco Schmidt wrote on 9.7.2015:
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 7 August 2015.
we support the proposal, therefore +1 from us. The interpretation of the NCC in their impact analysis strikes a good balance between too much liberalness, which might lead to undue waste of address space, and the constraints of the current policy. We are hopeful that the NCC has found a measureable and impartial way to identify the justifiable size of large allocations. The new policy would allow new address plan structuring arguments to be considered by the NCC - and this is important. Regards, John Collins LIR ch.swissgov
Dear AP WG, On Thu, Jul 09, 2015 at 02:19:35PM +0200, Marco Schmidt wrote: [..]
The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 7 August 2015.
the review phase for 2015-03 has ended (actually, quite a while ago, but it's vacation time... apologies). There was a bit of discussion and thoughtful contemplations about this proposal (and I have to say, very friendly and very constructive discussion, which I appreciate :-) ). If a clear opinion was voiced regarding the proposal itself, it was always supportive. So, I declare we have consensus, and move 2015-03 to Last Call. Marco will send the formal announcement for that in the next days. For reference, a list of people that voiced support or opposition (or something else) in the previous review phase is appended below. This is what I have based my decision on. If you disagree with my interpretation of what has been said and the conclusion I have drawn from it, please let us know. Gert Doering, Address Policy WG Chair Review Phase for V2.0, starting Jul 09, 2015 Support: Shahin Gharghi Carsten Brueckner Tore Anderson (notes that subsequent allocations are not covered) Andre Keller (notes disagreement with the assumptions in the impact analysis regarding routing table growth, but supports proposal) Annette Suedmeyer (plans to submit a follow-up proposal covering subsequent allocations) Silvia Hagen (some thoughts about "we should not be looking at IPv6 with mostly conservation in our minds", and questions about interpretation) John Collins Comments, Clarification: Mathew Newton / Marco Schmidt (side clarification about the evaluation to be done by the NCC) Tore Anderson / Mathew Newton / Sander Steffann / Jens 'Opteamax' (side discussion about subsequent allocations, returning of the initial /29 and asking for a larger *initial* allocation) Jens 'Opteamax' / Tore Anderson (side discussion about size of the reservation done enclosing the initial allocation) Silvia Hagen / Gert Doering / Sascha Luck / Mathew Newton / Marco Schmidt (side discussion about conservation, maths, and finding the right balance between "too liberal" and "too conservative") Opposing voices: - -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi Gert,
-----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Gert Doering Sent: 30 August 2015 14:10
So, I declare we have consensus, and move 2015-03 to Last Call.
That's great news; thanks Gert. Indeed a big thank you to everyone involved in getting us to this stage. Regards, Mathew
Dear AP WG, The last call period for proposal 2015-03 (Assessment Criteria for IPv6 Initial Allocation Size) has ended. In this phase no new feedback has been sent to the working group and the working group chairs have therefore concluded that the consensus as previously announced (see below) still stands. We ask the RIPE NCC to go ahead and implement this policy. Cheers, Your working group chairs Gert & Sander On Sun, Aug 30, 2015 at 03:10:25PM +0200, Gert Doering wrote:
Dear AP WG,
On Thu, Jul 09, 2015 at 02:19:35PM +0200, Marco Schmidt wrote: [..]
The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 7 August 2015.
the review phase for 2015-03 has ended (actually, quite a while ago, but it's vacation time... apologies).
There was a bit of discussion and thoughtful contemplations about this proposal (and I have to say, very friendly and very constructive discussion, which I appreciate :-) ). If a clear opinion was voiced regarding the proposal itself, it was always supportive.
So, I declare we have consensus, and move 2015-03 to Last Call. Marco will send the formal announcement for that in the next days.
For reference, a list of people that voiced support or opposition (or something else) in the previous review phase is appended below. This is what I have based my decision on.
If you disagree with my interpretation of what has been said and the conclusion I have drawn from it, please let us know.
Gert Doering, Address Policy WG Chair
Review Phase for V2.0, starting Jul 09, 2015
Support:
Shahin Gharghi Carsten Brueckner Tore Anderson (notes that subsequent allocations are not covered) Andre Keller (notes disagreement with the assumptions in the impact analysis regarding routing table growth, but supports proposal) Annette Suedmeyer (plans to submit a follow-up proposal covering subsequent allocations) Silvia Hagen (some thoughts about "we should not be looking at IPv6 with mostly conservation in our minds", and questions about interpretation) John Collins
Comments, Clarification:
Mathew Newton / Marco Schmidt (side clarification about the evaluation to be done by the NCC)
Tore Anderson / Mathew Newton / Sander Steffann / Jens 'Opteamax' (side discussion about subsequent allocations, returning of the initial /29 and asking for a larger *initial* allocation)
Jens 'Opteamax' / Tore Anderson (side discussion about size of the reservation done enclosing the initial allocation)
Silvia Hagen / Gert Doering / Sascha Luck / Mathew Newton / Marco Schmidt (side discussion about conservation, maths, and finding the right balance between "too liberal" and "too conservative")
Opposing voices:
- -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (9)
-
Andre Keller -
Gert Doering -
Ingrid Wijte -
John.Collins＠BIT.admin.ch -
Marco Schmidt -
Mathew Newton -
Opteamax GmbH -
Sander Steffann -
Tore Anderson