[address-policy-wg] concept document: IPv6 PA/PI unification

Hi AP WG,

next week at the RIPE meeting (and by remote participation, of course) 
I want to continue discussing an idea that came up before, and that I
brought up at RIPE 62 already - doing away with the distinction between
IPv6 PA and IPv6 PI space, going for a "unified number distribution
policy" (to give credits, it's not exactly my original idea, but has
been brought up a couple of times by members of the community in the 
last years).

Feedback from RIPE 62 was mostly positive, with "we need to think about
many details", so Sander and I sat down and tried to write a concept
document that has some answers about the details - which needs to be
discussed, refined, and eventually formed into a full-featured policy
proposal to go through the PDP.

So far, this is to start the thought process, and to get your ideas
about it - especially ideas of the sort "this is not going to work 
*because* <detail we've overlooked>".  But I'm taking "we want to keep
the difference between PA and PI!" as well - but if you say so, please
explain where you see the benefit of "more complicated rules".


The discussion will take place on Thursday morning, in the 09:00-10:30
time slot.

thanks for helping shape policy,

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