[address-policy-wg] PA/PI unification IPv6 Address Space

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
>
>