[Apwg-ipv6-papi] hello

[Daniel Stolpe]

On Wed, 3 Jul 2013, Gert Doering wrote:

>> My goal is to have a policy proposal which is simple, clear and easy to
>> follow by both the LIRs and the RIPE NCC.
>
> Full ACK.

ACK.

>> @Gert or Emilio: will you create/share the google document or should we
>> create one and start working on it?
>> The google account that I will use for this document is elvis at velea.eu
>> so you can share it with me if you will create the document.
>
> I'm gdoering at gmail.com, feel free to create and share.

As I wrote someehere else, I just created pdg.stolpe at gmail.com
If you Elvis starts and invites the others in that should be fine.

>> 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 don't think the community would have any problems but what about the 
NCC? Anyone remebering the famous "This is our position" by Axel? We have 
hade the suspicion for some time that the NCC wants to protect its own 
economy and with the new charging scheme, membership fees (and sign-up 
for new members) is the main income. That seems to be the main reason for 
the position that everybody should become an LIR.

So event though this task is about address policy we have to keep the 
economic aspects in mind.

>> - 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)
> RIPE NCC -> LIR sponsor -> customer /48 (B)
>
> and I think we need to keep that in place - so it needs to be very well
> documented that the "model A" is

In many (but not all) cases this works fine.

> - 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)
>
> 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.
>
>
> So I don't want so much to change the possible options but to change the
> "special rules" surrounding "blue" and "green" IPv6 addresses.
>
>
>> 2. Currently, if you want to start using IPv6 you have a few options:
>>
>> a. if you are an LIR - it's simple, request your /32 - /29 from the RIPE
>> NCC and start using it
>
> ACK.
>
>> b. if you are not an LIR, you have a few options:
>> i. request the /48 PI via a Sponsoring LIR and you only qualify for more
>> than a /48 if you have more than one end-site/network OR if you can
>> justify the usage of more than 65K subnets
>> ii. request a sub-allocation from an LIR (ALLOCATED-BY-LIR) from which
>> you can assign address space to your network or to your customers
>> iii. if a /48 is enough for your business and you want to offer any kind
>> of services to your end-users, you have to lie to the RIPE NCC, receive
>> the /48 and start assigning from it, thus making sub-assignments and
>> violating the policy.
>
> ACK, and "iii" is actually what I want to kick out at this time, as this
> is not really useful ("encourage lying or use of a /32").

Yes. That is sadly the case today.

> One of the problems with the current policy documents for IPv*4* is that
> it intermixes "RIPE NCC -> LIR" and "LIR -> end users" address space
> delegation.
>
> Maybe there should be clearly distributed sections or even documents:
>
> - *policy*: how to get space from the RIPE NCC (who, why, how)
> - *policy*: what is the reciever of a block from the RIPE NCC permitted
>             to do with it (= assignment of /48.../64 without questions,
>             get approval for bigger.  Also, do sub-allocations if needed)
> - *guidance*: "if I need address space for <x>, what options do I have?"
>    (<x> being "for my ISP business", "for my SME company with BGP routing",
>     "for my home network", add a few more typical cases)

That would be good. And before the policy is finished we should have a 
good look at these typical cases, as well as the more un-typical ones.

>> 3. the current major problems of the policy, as I see them are:
>>
>> - I don't think we have a workable definition of an end-site, the
>> current definition is a start but I think we could make it clearer, simpler.
>
> "end-site" comes from the IETF, which also doesn't give useful guidance...
>
> But yes, the questions "under which conditions is *this* 1-end-site or
> 2-end-sites?  what can I assign?" is coming up quite often...

ACK.

>> - currently, an organisation which offers services to it's customers has
>> to become an LIR if they want to make assignments - otherwise, if they
>> want to be independent from the LIR they can request a /48 IPv6 PI (if a
>> /48 is large enough for them and their customers) and hope they will
>> never get caught violating the policy.
>
> Out with this :-)

ACK! :-)

>> - 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...

Yes.

>> - 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"
>
>> - as far as I know, current practice on route filtering is being done at
>> the /48 level. What if ISPs will start following the RIPE Routing
>> recommendations and filter based on the allocation size? In that case,
>> the customers of the LIR that will want to multihome or move to an other
>> LIR will find their prefixes filtered out from the routing table and/or
>> will have to renumber.
>
> "Model B" :-) - and yes, that's to be expected.  Either it's your space,
> or it's your ISP's space, and then you can't expect it to have full BGP
> visibility (but it won't do much harm as the aggregate should still be
> visible).
>
>> - most of the organisations in the RIPE NCC service region still think
>> conservatively when they want to assign address space to
>> infrastructure/customers. I've seen engineers thinking that a /64 is
>> already too large for a customer. The end-user of an ISP or hosting
>> provider in some of the current setups receives a /64 because the
>> engineers do not see the need for multiple subnets for someone's home
>> connection or hosted device.
>
> Guidance document, and policy document "how do give addresses to end users".

ACK.

>> We should ask the LIRs (and their customers) in this policy to:
>> - use a /64 only where a single network/subnet is anticipated for the
>> end-site (already part of the current policy) - ie: only to connect the
>> end-site/customer/equipment to the LIR's network/internet
>> - use at least a /60 - /56 (?) or larger where the end-site is a
>> customer or would need to use more than one subnet
>> - keep the /56 efficiency measurement unit, when an LIR needs to assign
>> more than a /56 to an end-site, it should collect internally some kind
>> of data that justifies the usage of more than a /56
>
> ACK

ACK.

>> - introduce the AW - the LIR should be able to assign up to a /48 with
>> no questions asked (offcourse, the LIR should receive a justification
>> why a /48 is needed for the end-site).
>
> No.  A /48 per end-site can be given out without justification if the
> LIR thinks it is a good idea.  This is what we have today, and we should
> not make the new policy more restrictive, like by requiring justification.
>
> Larger-than-/48 is rare enough, still, that I don't think we should
> reintroduce the complexities of AW management - how many requests have
> you seen at the NCC asking for end user assignments bigger than a /48?

So what if the LIR wants to assign a /47? Or 2 x /48? just to be clear.

>> - 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?

One could argue that if the LIR has the space, give them guidance and let 
them use it.

>> 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.
>
> 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...

Yes. As I wrote before we do a lot of "sponsoring LIR stuff". Yes, we do 
some registry work for our own network but the major part is for externa 
customers that are very happy to let the "experts" handle this strange 
business.

I think it would be a good idea to allow this solution to contiue, and as 
I wrote above it is probably most an economic concern for the NCC. What if 
one singel LIR serves what could have been 10 LIR:s? Or 100 LIR:s? There 
would indeed have to be some additional fees for "blocks of numbers".

>> The end-user, in this case, should be able to use an allocation and be
>> able to make assignments to it's end-sites/customers.
>> The Sponsoring LIR should be responsible for making sure that it's
>> customers register the assignments correctly and follow the policy.
>
> ACK.

ACK.

>> In this case we would have several flavors of statuses in the RIPE Database:
>> - ALLOCATED-BY-RIR (allocation made by the RIPE NCC)
>> - ALLOCATED-BY-LIR (allocation made by the LIR)
>> - ALLOCATED-VIA-LIR (allocation made by the RIPE NCC to customer of LIR)
>> - AGGREGATED (by the LIR or customer)
>> - ASSIGNED (by the LIR or customer)
>> - ASSIGNED-BY-RIR (by the RIPE NCC)
>
> What would be ASSIGNED-BY-RIR?  But besides that, yes.  The status: values
> actually are an interesting can of worms :-)

Indeed. If we allow for "portable" address blocks we will have to think 
about LIR portability as well as ISP portability. The IPv4 legacy space we 
handle is assigned as PI which means it is ISP portable but it it still 
part of our allocations which means our customers cannot move address 
space to another LIR, which is sometimes confusing.

One problem with the current policy that I don't think we have mentioned 
yet is unnessecary de-aggregation.

Yes, sometimes an end-user might want several differant /48:s (or whatever 
size) because they hade a lot of different end-sites behind other ISP:s. 
Aggregation is not possible.

But what if a growing end-user gets a /48 and then othother one and then a 
couple more etc.

We do have customers with like 97 different PI chunks of IPv4. Those are 
the kind of people now coming to us saying: we don't want to make the same 
mistake again. Give us a huge slab now, to keep for a long time. And they 
have don't want to become an LIR.


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