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

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