[ppml] Principles for IPv6 PI allocations to end sites

[Thomas Narten]

Here are some thoughts I have w.r.t. this topic. Generally, I'm in
favor of coming up with a policy for granting PI space to large end
sites. However, I am also very concerned that we do not open the
floodgates and create a situation a few years down the road that we
wish we weren't in.

Some principles I keep in my mind as I evaluate various proposals.

IPv6 space is a public resource, and we need to avoid having a policy
adopted today turn into an "early adopter bonus program". That is, if
5-10 years from now we have two classes of entities:

 - early adopters with PI assignments, and

 - those who wish they had a PI assignment, and believe they have just
   as much right to one as those that have them, but can't get them
   because the policy had to be changed and PI space has become much
   harder to get

then I think we've done the community a huge disservice.
   
Corallary: I don't buy the argument that "we can always change the
policy later, if it proves to be problematic". The reality is that
doing so will lead to the previous situation, and that makes it rather
hard to change the policy. We won't be able to get consensus to do so.
Thus, I think we need to be conservative now, at least at the
outset. We can always loosen the policy later if that proves
appropriate. 
    
Multihoming: we don't have a "magic bullet" multihoming solution on
the table today, and I'm not willing to count on some solution
appearing that bales us out of a mess we create under the assumption
that one will come along. Thus, any policy we adopt to facilitiate
multihoming needs to have sufficient incentives/checks to prevent the
size of the table from exploding, not just this year or next, but in
5-10 years and beyond.

And who wants multihoming? My guess is that as time goes on, many if
not most businesses will. Thus, we are potentially talking 100K to
millions of distinct PI assignments. I do not believe we can give
_all_ of them PI space (due to scaling concerns). Thus, I worry that
just saying "need to multihome" is insufficient justification. We
can't afford to go there long term.

I've come to believe that (at some level) we should let pretty much
all of the "big sites" with PI space in v4 get it in v6. I don't think
we should _require_ having v4 space as a prerequisite, but it's a
reasonable assumption that those those that operate big sites today,
and that multihome, will (eventually) do the same in IPv6, and
therefore we should let them.

Another way of looking at it:

  - giving space to those (IPv4 users) that don't plan on deploying
    IPv6 in the short term doesn't matter if v6 doesn't take
    off. 
    
  - But if IPv6 does take off, those that are slow to deploy, will
    still eventually deploy (and we don't want to make IPv6 PI
    assignments just for early adopters). So it is fairly safe to
    give prefixes to existing large IPv4 users


One question that arises is fairness. Since we can't give PI space to
all end sites, who can we say yes to, and who will we have to say no
to? And will we be able to defend the policies we come up with 5-10
years down the road? (I sure hope so...)

One possible metric for fairness is that since PI allocations each
have a cost associated with them (in terms of route slots in the DFZ),
we should attempt to maximimize the benefit of each such slot. Thus,
one reason I favor PI space for "large end sites" is that large can be
an indication of the numbers of networks/devices/users covered by a
prefix. The more users/machines/networks covered by a prefix, the
greater the "benefit" to the community in terms of carrying that
prefix in the DFZ. Hence, I tend to lean towards giving PI space only
to the largest end sites, i.e., those that will provide benefit to the
largest communities. 

There may be other metrics that we should consider; in any case, I do
think its useful to think about what metric we are actually using, and
what community is going to benefit from a PI assignments, since there
will certainly be other communities that might also benefit, but to
whom we will be forced to say no to. 

I believe we need to allocate PI space out of specific prefix, so that
it is clearly identifiable in case filters are needed. Hopefully, we
will never have to impose filters, but it is better to have the
capability to impose filters based on explicit knowledge (e.g., by
knowing that anything within a specific prefix is PI to end sites)
than having to approximate by just assuming that all prefixes of some
fixed length are PI.

Given that one of the goals of IPv6 address allocation is to minimize
fragmentation of address blocks, we should try hard to ensure that if
an end site ever gets a PI block, it will never need (or get) a second
one from a separate block. That is, I think we should (just like with
LIR assigments) have the RIRs use sparse allocation (or equivalent) to
allow future expansion. IPv6 has sufficient address space to do
this. Fixing the assignment at a fixed value (and stating up front
that no larger prefix will ever be given) is just asking for trouble
(i.e. runs risk of future fragementation)

Thomas