[Apwg-ipv6-papi] hello

[Daniel Stolpe]

On Wed, 3 Jul 2013, Elvis Velea wrote:

> Hi again,
>
> On 7/3/13 4:41 PM, Gert Doering wrote:
>>  Hi,
>>
>>  just a few words (thanks, btw, for the introductions :-) - I'm impressed!)
>>
>>  On Tue, Jul 02, 2013 at 07:26:02PM +0200, Elvis Velea wrote:
>> >  I would say that I have quite some experience with the limitations of
>> >  the current IPv6 policy and have a few ideas on how we can make this
>> >  policy proposal work. I have almost 0 experience with the practical
>> >  usage of IPv6 and how it is actually implemented in networks, I hope to
>> >  learn a bit more from you guys in the process of writing this policy
>> >  proposal.
>> > 
>> >  The goal here is, as far as I understand, to unify the IPv6 flavors and
>> >  have one single policy for all the IPv6 space.
>>
>>  Yes.  The initial reasoning was discussions with end users "what sort of
>>  space should I ask for?" and they fully don't understand the difference
>>  between PA and PI, which are quite logical for "us at the RIPE NCC level".
>>
>>  So my initial goal was:
>>
>>     - unify PA and PI into "address blocks"
>>
>>  it's not as simple, though, as the existing differences (that have a
>>  reason :) ) will come back as "special clauses".  Like, for example,
>>  anycast IPv6 address blocks - they are "just addresses" but come from a
>>  specific address range earmarked as "anycast", so people can look at
>>  the prefix and see "ah, I should pay more close attention to these in
>>  my routing" (for example).  And "PI" comes from yet another block, so
>>  people know "this is the only range where /48s are given out from the
>>  NCC"...
>>
>>  So for all the caveats, take a look at the concept paper :-)
>
>
> I agree that we should stick with the 'special blocks' and also believe that 
> there are multiple types of businesses that need portable addresses.
>
> Having different assignment types complicates the RIPE Database, I believe. 
> That is why I would see one single status for anything that the RIPE NCC 
> would assign, either for an anycast setup, for an IXP or for an organisation 
> that only needs an assignment and does not plan to further assign and that 
> status would be ASSIGNED-BY-RIR. I've got nothing against having different 
> statuses in the RIPE Database but I don't see the advantage.
>
> Organisations could request an assignment of a /48 no matter what setup they 
> have just as they have PI now. If the /48 would be for anycast it would come 
> from a block, if it's for IXP it would come from an other block, if it's for 
> some kind of critical infrastructure business we haven't yet invented, it 
> will come at that point from a specific block.
>
> We could also agree to having special cases where one type of setup may need 
> more than a /48.. for example anycast, or an IXP with different peering 
> networks and other types of services, or ...

I agree. As long as the information is easy to find, it might not be 
necessary to have different db-status for different types. Having 
ASSIGNED-FOR-SPECAIL-USE-147 does not look very tempting.


>> >  A few things that come from my experience and I think we should address 
>> >  are:
>> > 
>> >  1. do you think that the community will agree with the concept of the
>> >  RIPE NCC allocating blocks of address space to end-users via the LIR?
>> >  (allocations via the sponsoring LIR concept)
>>
>>  This is what we have today, and what seems to work out quite well - my
>>  original idea was to keep that, to make the whole thing low-effort
>>  (relatively).
>
> I agree, my question was more directed to whether if when the LIR maks a 
> sub-allocation to a customer, could this become portable in the event of the 
> customer moving away from that LIR?
> To be more clear, would we agree (or even want to have this situation in the 
> policy) with the RIPE NCC splicing an allocation into pieces at the request 
> of the LIR and with the agreement of the end-user? And if yes, would we apply 
> any restrictions on the size?
>
> Over time I have seen many cases where an LIR would start making assignments 
> to it's customers and at some points those customers become LIRs. They want 
> to transfer the administration of that block to their newly created LIR but 
> the policies do not specifically allow or disallow it.
> Many organisations (especially the big ones) re-organize their businesses and 
> may need to shuffle (parts of) allocations between their registries. This is 
> extremely difficult right now from an administrative point of view.

Absolutely. As you saw I was into this matter in the other e-mail. We have 
the two cases:

1) The LIR has a /29 .. /32 and customers (or the LIR itself for some 
reason) announce fractions from several AS numbers. We could recommend 
aggregation but it does not seem possible to forbid this behaviour.

That is split routing. De-aggregation.

2) As you said, the LIR has a block and wants to move some or the whole of 
it to another LIR.

That is split/merged administration. And maybe the combination of the two.

We have to think thoroughly about this.

>> >  - do we still want to have the Sponsoring LIR concept in the new policy
>> >  or should we keep it simple: RIPE NCC allocates to LIR, LIR assigns or
>> >  sub-allocates to it's customers? in the latter case, if the customer
>> >  moves to an other LIR, can the assignment/allocation move to the new LIR
>> >  (and thus have a possible problem with de-aggregation)?
>>
>>  This is one of the tricky bits - there's two ways a customer of a LIR
>>  can get space ("as of today")
>>
>>    RIPE NCC -> LIR /32     -> customer /48 (A)
>
> this is possible today, indeed
>
>>    RIPE NCC -> LIR sponsor -> customer /48 (B)
>
> correct, currently we have: RIPE NCC assigns to customer (via LIR)
>
> what we are missing is:
>
> - RIPE NCC allocates to customer which then assigns to customer.
>
> As most of the organisations that use the portable addresses are small 
> organisations that do not or can not become LIRs, these organisations can not 
> offer IPv6 services right now because they can only use them for their 
> infrastructure.

Right!

> Once we allow the small ISPs and hosting companies to get IPv6 and assign to 
> their customers, I think we will also start seeing an IPv6 uptake.

Yes. Now we are talking! :-)

Current policies are effectively blocking IPv6 usage today. If a small 
company offering ISP:ish services applies for a /48 PI today, the NCC will 
say no. And then of course an LIR with a /29.../32 can share some of 
theirs but as far as I know there are no policies for or against it.

>>  and I think we need to keep that in place - so it needs to be very well
>>  documented that the "model A" is
>>
>>    - an entity planning to assign prefixes to end users gets a /29.../32
>>      from the RIPE NCC, and uses that to distribute /48.../64 to end users.
>>      Adresses given to end users from the aggregate prefix are not portable
>>      outside the aggregate, unless special agreements with the aggregate
>>      holder are made.  (We can't really "forbid" it, as that would not
>>      match
>>      reality, but having a default-deny in here should be good enough)
>
> ok
>
>>
>>  and "model B" is:
>>
>>    - an entity needing fully portable address space without the wish to
>>      distribute /48.../64 to third parties can get an independent /48
>>      for each "end site" (we could define this or leave it as it is - that
>>      term is coming from the IETF side).  They will receive a dedicated
>>      block
>>      of addresses which is not technically tied to the LIR that facilitated
>>      the request, just contractually, and can be moved both network-wise
>>      and
>>      contract-wise to other point-of-contacts.
>
> ok
>
>> 
>>
>>  So I don't want so much to change the possible options but to change the
>>  "special rules" surrounding "blue" and "green" IPv6 addresses.
>> 
>
> What about the "model C"
>
> - an entity that has a business where they need to connect or offer services 
> to customers (thus needs to make assignments) but can/will not become an LIR?

Yes. What about it?


>> >  - LIRs do not really like sub-allocating parts of their allocations if
>> >  they have plans to grow their business. In IPv4 quite a few LIRs have
>> >  made a business out of IP address assignment policies. In IPv6 I do not
>> >  see this business model taking off yet. The LIRs will be limited by the
>> >  HD-ratio when they will need to request an additional allocation. It's
>> >  difficult for an LIR to demonstrate the usage higher than the HD-ratio
>> >  when some(most) of the space is sub-allocated to customers
>>
>>  It might still make sense to give them the option.  Like, "we know we're
>>  never going to use up our /29, but we have 6 different business units
>>  which all will never fill up a /32, so we sub-allocate /32s to all of
>>  them, and never have to think about it again".  Those who expect growth
>>  will not use it, but there are cases where it makes sense...
>
> I agree, however I was also aiming at a question: should this policy 
> encourage de-aggregation of allocations?
>
> Look at many LIRs today in IPv4, they receive an allocation and start making 
> assignments to themselves or customers, sometimes the customer grows bigger 
> than the LIR. They customer needs to ensure multihoming and stability for 
> their network. Once they have started using the IPs from the LIR's allocation 
> for themselves or their customers they have two options:
> - become an LIR
> - convince the LIR to allow more specifics
>
> I think we need the third option:
>
> - be able to request (via a Sponsoring LIR) a portable allocation

Yes. Something like that.


>> >  - the efficiency measurement unit is a /56 while the LIRs are allowed to
>> >  assign up to a /48 with no questions asked
>>
>>  Yeah.  This is confusing, but actually it's well-defined "if a /48 is
>>  assigned it counts as 256 /56s" (was discussed at one of the RIPE meetings
>>  and on the mailing list).  But let's see whether we can come up with
>>  different criteria to decide
>>
>>    - I need a larger initial block than a /29
>>    - "my block is full"
>
> I must have missed that discussion or forgot about it, I'm getting old may be 
> a weak excuse :-)
>
> I do have an example in my mind where things get a bit messy.
> Let's say an ISP decides to make an aggregation, and they register it in the 
> RIPE Database like:
>
> inet6num: 2001:db8::/40
> status: AGGREGATED-BY-LIR
> assignment-size:64
>
> How can we calculate the HD-ratio for an aggregation that has /64s in it when 
> our efficiency measurement unit is a /56? How many /64s would have to be in 
> use to consider the usage efficient?
>
> They may be using one /64 out of each /56 and the efficiency may be 
> acceptable,however, they may be also using all of the /64s in the first 2 
> bits of the /40, will it still be efficient used?
>
> What if they do use one /64 from each /56, would we still consider the usage 
> of the /56 efficiently and count it in the hd-ratio?

It seems somewhat artificial. The measuremant I mean.


>> >  - limiting the size of the sub-allocation should also be an idea, an LIR
>> >  could sub-allocate from their allocation up to a /40 (?) without having
>> >  to send a request to the RIPE NCC. Anything above the /40 (?) could be
>> >  approved by the RIPE NCC's IPRAs after an evaluation.
>>
>>  What do we gain by adding restrictions?
>
> I was again thinking ahead at model 3. If a customer A of the LIR has a 
> business where he may need to make assignments to it's own customers B, we 
> could have a minimum /40 allocated by the (LIR or) RIPE NCC to that customer 
> A.
>
> It would make things simple to say, you are a organisation that needs to make 
> assignments, ok, here is a /32 portable, no need to become an LIR. However, 
> that would discourage organisations in becoming an LIR in the future.
>
> And as you said, the GM is the only place where the fees can be changed. I 
> think that if we allow a minimum /32 allocation portable, we could recommend 
> the GM to have two different fees on the portable blocks. A fee for the 
> assignments (like the 50E today for PI) and a fee for the allocations (more 
> like a few hundreds ?)

I guess we come back to the Dutch tax rules. I am very much in favour of 
the idea that you can get address space without being forced into RIPE 
membership or starting a LIR. Of course you would have to pay someone, 
somehow but it should not be impossible to find a solution.


>>  [..]
>> >  To sum up, I see two possible models:
>>  [..]
>> >  2. the RIPE NCC allocates&assigns address space to both the LIR and the
>> >  end-user (via the sponsoring LIR scheme).
>>
>>  This is what I had in mind, as explained above.  Don't change too many
>>  things at the same time, and this general setup seems to work sufficiently
>>  well.
>
> correct.. but in the current setup the allocation to customer is missing.

Yes.

>>  If you look at the concept paper again, this brings up new possibilities,
>>  namely "multiple ISPs requesting a /32 through a sponsoring LIR", which
>>  we can't really prevent if we really want to remove the PA/PI distinction
>>  - if it's just addresses, we need to be ready to give out multiple
>>  "large blocks" and "small blocks" *via* the same LIR...  one of the
>>  receivers could then be "the LIR itself", but in theory, a LIR could
>>  exist that only does "sponsoring LIR stuff", handling /32s for the
>>  ISPs in the neighbourhood...
>
> do we want to give anyone who has plans to make assignments a /32 portable 
> allocation? I was the one thinking conservatively here and thinking that a 
> /40 with no justification may be enough for the small-middle sized 
> businesses. I may be wrong.

You mean that the LIR holding the /32 can assign /40 with no 
justification?

Well, it could be a tool preventing too excessive use.

> I've just shared an empty document. I'll probably start working on it after 
> dinner :p

Good to hear it should be empty. I was a bit worried I was missing 
something. ;-)

Cheers,

Daniel

_________________________________________________________________________________
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