[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