concept document: IPv6 PA/PI unification
Hi AP WG, next week at the RIPE meeting (and by remote participation, of course) I want to continue discussing an idea that came up before, and that I brought up at RIPE 62 already - doing away with the distinction between IPv6 PA and IPv6 PI space, going for a "unified number distribution policy" (to give credits, it's not exactly my original idea, but has been brought up a couple of times by members of the community in the last years). Feedback from RIPE 62 was mostly positive, with "we need to think about many details", so Sander and I sat down and tried to write a concept document that has some answers about the details - which needs to be discussed, refined, and eventually formed into a full-featured policy proposal to go through the PDP. So far, this is to start the thought process, and to get your ideas about it - especially ideas of the sort "this is not going to work *because* <detail we've overlooked>". But I'm taking "we want to keep the difference between PA and PI!" as well - but if you say so, please explain where you see the benefit of "more complicated rules". The discussion will take place on Thursday morning, in the 09:00-10:30 time slot. thanks for helping shape policy, Gert Doering -- APWG chair --------------------------------------------------------------- Motivation: why? ---------------- - PA and PI are just different labels for "IPv6 addresses" ... but with different strings attached: - PI must not be used for 3rd party assignments (problem for hosting providers) - only single PA allocation for LIRs possible, even if multiple independent networks exist - network structure and operation is very different these days than at the time where the PA/PI distinction was made. The boundaries between networks, different operators and different services are not as clear as they used to be... - the classic distinction "PA is for ISPs and their access customers" "PI is for enterprises that do not do ISP-like business" has been overcome by reality, and there are no longer clear borders between "ISP", "enterprise" and "end-customer" networks - Network addresses are for *numbering network devices*. Limiting what someone is allowed to do with certain addresses creates confusion. Constantly having to tweak policy to work around this is the wrong solution. Goals and Caveats ----------------- - encourage IPv6 deployment - be flexible enough to accommodate both typical and non-typical network- and business models - do not encourage assignment of /64 or single addresses to end users - do not encourage excessive routing table growth - encourage proper documentation and discourage lying to the RIPE NCC to wiggle around policy restrictions The Proposal ------------ - abandon distinction between PA (allocation) and PI (assignment) - everything is just "numbers" - RIPE NCC hands out "block(s) of numbers" to "users of numbers" - see below for answers on the fine print... Who get's address space? ------------------------ - existing model is kept: LIRs as distribution point for address space - either to "the LIR organization" - classic model: "LIR is part of the Internet Provider business" - or via the LIR to "the entity that wants to use the space and take responsibility for it" (sponsoring LIR), keeping the contractual requirements of 2007-01 - "Direct Assignment Users" members could still be possible, but "every NCC member is an LIR" would simplify things further (see "Costs" section) Amount of space per "block of numbers"? --------------------------------------- - /48 (or larger with justification) by default - /32.../29 (or larger with justification) allowed when planning to assign to 3rd parties - multiple "blocks of numbers" to or via a single LIR allowed and expected to be a frequently seen usage case Allocation from well-known ranges for anything that people might want to treat specially in their routing policy (former "special case" and PI policies): - IXP - Root DNS - Anycast DNS - /33.../48 blocks Cost? ----- - determined by AGM, but we can discuss models here and provide recommendations to AGM and NCC board, e.g.: * base cost per year per LIR * yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks" Multiple blocks per LIR? ------------------------ - since there would no longer be any difference between PA and PI, "more than one block going to a single LIR" would be a typical case - so it needs to be permitted - "get any number of blocks that people are asking for" is not likely to get consensus due to pressure on the routing system - proposal for compromise: ``one "block of numbers" per "network"'' - needs workable definition for "network": - interconnected network - operated by the same entity - operated as a layer 3 network - be flexible in allowing multiple blocks, but don't *require* anyone to actually ask for multiple number blocks if they are happy with using the same address block for multiple networks/sites/... - problem cases to keep in mind, leading to this definition - ISPs providing L3 services on top of other ISPs' Layer 2 infrastructure - single LIRs providing addresses to two independent Layer 3 networks that are not directly connected - e.g. due to political (commercial/NREN), legal or geographical reasons - "classical PI" type connections - end users with independent numbers - Multiple L3 providers providing address space to a single user must be allowed (multi-homing, special-purpose networks, etc.) -- 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 (89) 32356-444 USt-IdNr.: DE813185279
Hi Geert, thanks for taking the time, you and Sander, to get this discussion started. I will dive into just one of them with some feedback. :) On Fri, 2011-10-28 at 19:16 +0200, Gert Doering wrote:
* yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks"
This was an interesting suggestion. Going straight for the details of one point, I wonder, what's the most fair way to reflect the handling cost of an address space request? A /24 telco request for a larger national / european / pan-european access network takes (on average) a much higher toll on IPRAs) than say, a (good) /48 single site allocation. Similarily, I'm not convinced that a /24 with a couple thousand more-specific objects of various kind in the database, should (or should not) have a higher "RIPE database maintenance cost share" than a single /48 with one of each. That's only the database maintenance however. So I guess I disagree with your conclusion from the arguments you iterated over. Out-of-the-box counter-proposal: IPRA interacting work (including address space requests) == [IPRA hour fee] * [IPRA-time spent on application], Infrastructure cost sharing (yearly recurring cost) == [RIPE NCC specific registry / IPRA related costs] ----------------------------------------- number of LIRs at billing year end (*) registry / IPRA related costs, for example: * DB upkeep, org. * overhead for strictly registry-related org functions, *) number of LIRs at billing year end. (LIRs paying quarterly could pay Y1Q1, Y1Q2, Y1Q3, Y1Q4 by end-Y1 projections done quarterly, for a final adjustment of Y1 Y2Q1. mmmm details) This obviously does not take into account how to share RIPE NCC's costs of all its non-IP registry related undertakings. This is on purpose. Cheers, Martin
Hi, On Sat, Oct 29, 2011 at 04:56:40PM +0200, Martin Millnert wrote:
On Fri, 2011-10-28 at 19:16 +0200, Gert Doering wrote:
* yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks"
This was an interesting suggestion.
Going straight for the details of one point, I wonder, what's the most fair way to reflect the handling cost of an address space request?
I see your point, and I'm buy no way insisting on "every block costs the same". The reason why I proposed to do it this way is to discourage large-scale ISPs from going for "we give all our customers a single /128 each, so we can run the whole country-wide network on a /48 and save lots of money!". We *want* them to give /56s (or such) to customers, and if there's a monetary penalty for doing so - is this the right message to send? (OTOH, depending on the final numbers, the per-block-per-year price might be low enough to make this all uninteresting - if it's "50 EUR per /48, 100 EUR per /32, 200 EUR for /28 or bigger", the financial incentive is not that strong).
So I guess I disagree with your conclusion from the arguments you iterated over.
What about the "encourage ISPs to give end-users a reasonably-sized network" argument?
Out-of-the-box counter-proposal: IPRA interacting work (including address space requests) == [IPRA hour fee] * [IPRA-time spent on application], Infrastructure cost sharing (yearly recurring cost) == [RIPE NCC specific registry / IPRA related costs] ----------------------------------------- number of LIRs at billing year end (*)
I'm not sure I get that formula - are you dividing everything by number of LIRs, so everybody pays the same price? (Now that would be simple :) ). Gert Doering -- APWG chair -- 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 (89) 32356-444 USt-IdNr.: DE813185279
Hi Gert, On Sat, Oct 29, 2011 at 10:51 PM, Gert Doering <gert@space.net> wrote:
Hi,
On Sat, Oct 29, 2011 at 04:56:40PM +0200, Martin Millnert wrote:
On Fri, 2011-10-28 at 19:16 +0200, Gert Doering wrote:
* yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks"
This was an interesting suggestion.
Going straight for the details of one point, I wonder, what's the most fair way to reflect the handling cost of an address space request?
I see your point, and I'm buy no way insisting on "every block costs the same".
Check. It looked like that (and I decided to bite).
The reason why I proposed to do it this way is to discourage large-scale ISPs from going for "we give all our customers a single /128 each, so we can run the whole country-wide network on a /48 and save lots of money!". We *want* them to give /56s (or such) to customers, and if there's a monetary penalty for doing so - is this the right message to send?
I'm not suggesting charge per block size either. :)
(OTOH, depending on the final numbers, the per-block-per-year price might be low enough to make this all uninteresting - if it's "50 EUR per /48, 100 EUR per /32, 200 EUR for /28 or bigger", the financial incentive is not that strong).
Agreed.
So I guess I disagree with your conclusion from the arguments you iterated over.
What about the "encourage ISPs to give end-users a reasonably-sized network" argument?
Good question.. Handle applications where users/customers are shown to be given /56s or larger, faster? (Ie. cheaper, according to below)
Out-of-the-box counter-proposal:
IPRA interacting work (including address space requests) == [IPRA hour fee] * [IPRA-time spent on application],
Pay per direct load on the hostmasters. This could encourage people having more clue interacting with the RIPE NCC and so on.
Infrastructure cost sharing (yearly recurring cost) == [RIPE NCC specific registry / IPRA related costs] ----------------------------------------- number of LIRs at billing year end (*)
I'm not sure I get that formula - are you dividing everything by number of LIRs, so everybody pays the same price? (Now that would be simple :) ).
Share *overhead* costs equally, yes. *shrug* :) Best, Martin
Hi, On Mon, Oct 31, 2011 at 04:22:50PM +0100, Martin Millnert wrote:
Out-of-the-box counter-proposal:
IPRA interacting work (including address space requests) == [IPRA hour fee] * [IPRA-time spent on application],
Pay per direct load on the hostmasters. This could encourage people having more clue interacting with the RIPE NCC and so on.
... but backfires if you have a particularily fast or slow IPRA... since these are humans with differing background, your request might hit one IPRA that has very much or very little experience on the way *you* want to roll out your network... or extra curiosity adding more e-mail rounds... so I'm not sure this can be done in a way that would be considered "fair". Just throwing concerns around.
Infrastructure cost sharing (yearly recurring cost) == [RIPE NCC specific registry / IPRA related costs] ----------------------------------------- number of LIRs at billing year end (*)
I'm not sure I get that formula - are you dividing everything by number of LIRs, so everybody pays the same price? (Now that would be simple :) ).
Share *overhead* costs equally, yes. *shrug* :)
Ah, understood. So the yearly cost would be identically for everybody, and the initial request is billed for "the real cost caused by it". Right? Gert Doering -- APWG chair -- 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 (89) 32356-444 USt-IdNr.: DE813185279
Gert, On Mon, Oct 31, 2011 at 4:34 PM, Gert Doering <gert@space.net> wrote:
Hi,
On Mon, Oct 31, 2011 at 04:22:50PM +0100, Martin Millnert wrote:
Out-of-the-box counter-proposal:
IPRA interacting work (including address space requests) == [IPRA hour fee] * [IPRA-time spent on application],
Pay per direct load on the hostmasters. This could encourage people having more clue interacting with the RIPE NCC and so on.
... but backfires if you have a particularily fast or slow IPRA... since these are humans with differing background, your request might hit one IPRA that has very much or very little experience on the way *you* want to roll out your network... or extra curiosity adding more e-mail rounds... so I'm not sure this can be done in a way that would be considered "fair".
Just throwing concerns around.
They're fair concerns and does point to a perhaps greater issue: that variance of IPRA's can be that high that it makes a big difference. The system is right now not optimized towards per-hour billing for applications, etc, however, so it's hard to conclude what the variance would be in that situation.
Infrastructure cost sharing (yearly recurring cost) == [RIPE NCC specific registry / IPRA related costs] ----------------------------------------- number of LIRs at billing year end (*)
I'm not sure I get that formula - are you dividing everything by number of LIRs, so everybody pays the same price? (Now that would be simple :) ).
Share *overhead* costs equally, yes. *shrug* :)
Ah, understood. So the yearly cost would be identically for everybody, and the initial request is billed for "the real cost caused by it". Right?
Well, identical for everybody using the IP registry services - yes. :) Cheers, Martin
A /24 telco request for a larger national / european / pan-european access network takes (on average) a much higher toll on IPRAs) than say, a (good) /48 single site allocation.
it _could_ be the opposity o oh, dtag wants another /2, yep they eat them regularly, and we just do not have the depth to look deeply into their net design. fine o this weenie that wants a /48, who the heck are they and have they any net design randy
On Sun, Oct 30, 2011 at 12:08 PM, Randy Bush <randy@psg.com> wrote:
o oh, dtag wants another /2, yep they eat them regularly, and we just do not have the depth to look deeply into their net design. fine
o this weenie that wants a /48, who the heck are they and have they any net design
That's how I felt like it is now, so it cannot get worse. The most important point for me is, that larger blocks will be more expensive than the small (/48) ones. If the costs are shared equally, the "weenies" pay the org overhead for LIRs. Gerts 50/100/200 EUR plan is the way to go. just my 2 cents. regards, danrl -- regards. danrl -- Dan Luedtke http://www.danrl.de
participants (4)
-
Dan Luedtke -
Gert Doering -
Martin Millnert -
Randy Bush