[address-policy-wg] PA/PI unification IPv6 Address Space
- Previous message (by thread): [address-policy-wg] PA/PI unification IPv6 Address Space
- Next message (by thread): [address-policy-wg] PA/PI unification IPv6 Address Space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Stolpe
stolpe at resilans.se
Thu Jun 27 14:56:09 CEST 2013
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] PA/PI unification IPv6 Address Space
- Next message (by thread): [address-policy-wg] PA/PI unification IPv6 Address Space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]