[address-policy-wg] PA/PI unification IPv6 Address Space
- Previous message (by thread): [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs
- Next message (by thread): [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elvis Velea
elvis at velea.eu
Mon Jul 1 13:41:40 CEST 2013
Hi Gert, everyone, I'd like to volunteer and join this editorial team. I used to be an IPRA so I've got first-hand experience with address requests and the whole process. Count on me, I hope we can get this policy proposal written by the next RIPE Meeting. cheers, Elvis On 6/27/13 4:32 PM, Sonderegger Olaf ABRAXAS INFORMATIK AG wrote: > Hi Daniel, Hi Gert, Hi Sander > > I have same experience level as Daniel, but I will support you as much as I can. > > Do you have any collaboration platform to write together this policy? Or how do you normally start? > > Olaf > > > -----Original Message----- > From: Daniel Stolpe [mailto:stolpe at resilans.se] > Sent: Donnerstag, 27. Juni 2013 14:56 > To: Gert Doering > Cc: Sonderegger Olaf ABRAXAS INFORMATIK AG; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] PA/PI unification IPv6 Address Space > > > Hi Gert, > > I have very limited experience of writing RIPE policy documents (but you have to start somewhere, right?) but I think I can check the other boxes. > > Hand up. > > On Thu, 27 Jun 2013, Gert Doering wrote: > >> Hi, >> >> On Wed, Jun 26, 2013 at 02:57:45PM +0200, Daniel Stolpe wrote: >>>> [PA/PI unification proposal] >>> >>>> For IPv6, it's still sitting on my lap, and I need to restart the >>>> process - thanks for the reminder. >>> >>> Just let us know if you need volonteers or cheering. >> >> Since Sander already mentioned it, I now need to write down what I had >> in mind :-) >> >> The original proposal (text appended below) received quite positive >> feedback, so I think we want to go ahead with that. >> >> What is necessary next is to actually write this up in the form of a >> RIPE policy document - and since the secondary effects of this change >> are quite radical, I think it leads to "write a new policy document >> for the new IPv6 address policy in RIPE, after that change, taking >> into account most of the questions that have come up" (like: what are >> the rules for a LIR to receive multiple "blocks of addresses"?). >> >> I can't seem to find enough "undisturbed time" to actually get going >> with this, so my idea was to form a *small* editorial team, maybe 3-5 >> people, who would work together with Sander, me and Emilio to write >> this new policy document (you write, we review :) ), and if we all >> agree that "yes, this is good!" it will be presented as a formal >> policy proposal to the WG, possibly leading to further tweaks of the text. >> >> The group writing this should be people that have had first-hand >> experience with address requests, customer confusion about PA and PI, >> with the RIPE policy process - and who have nerves of steel, to >> actually fight for it in the ensueing arguments on the list... >> >> >> So... volunteers? :-) >> >> 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 >> > > Best Regards, > > Daniel Stolpe > > _________________________________________________________________________________ > Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se > Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ > Box 13 054 556741-1193 > 103 02 Stockholm > >
- Previous message (by thread): [address-policy-wg] Guidance Requested: Reassigning Referenced ASNs
- Next message (by thread): [address-policy-wg] 2013-03 New Draft Document and Impact Analysis Published (No Need - Post-Depletion Reality Adjustment and Clean up)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]