Hi Nick, On 9/26/13 10:48 PM, Nick Hilliard wrote:

On 26/09/2013 18:11, Gert Doering wrote:

...

This is "the big IPv6 revolution thing" I promised you somewhat over two years ago :-) - unification of PA and PI into "just numbers, no colours".

a cursory look over the changes is giving me a warm fuzzy feeling. I need more time to look over it, but right now there's nothing I can see which stands out as obviously harmful.

it's a big change and we will all need to carefully read every word of the new policy text. I am glad that you do not find anything harmful at first glance ;)

I'm mildly concerned that you're defining previously undefinable terms like "End User", "End Site" and that sort of thing - if anything, these terms belong in a separate document.

the term End Site was already defined and it was completely mixed up with the term End User. We have tried to redefine these two terms as best as we could. If you think the definitions could look better, do share with us your idea. I do think that these terms do need to be defined, and the policy text was the best place for the definitions (in my opinion). Where else would you see them? cheers, elvis

On Thu, Sep 26, 2013 at 11:46 PM, Richard Hartmann < richih.mailinglist@gmail.com> wrote:

On Thu, Sep 26, 2013 at 11:12 PM, Elvis Velea <elvis@velea.eu> wrote:

...

I do think that these terms do need to be defined, and the policy text was the best place for the definitions (in my opinion). Where else would you see them?

Personally, I would like to see a single, canonical, authorative document defining _all_ special terms.

In a perfect world, those special terms would then be Always Capitalized When Used Within Documents or MAYBE EVEN ALL UPPER CASE.

If there's any interest, I would be willing to spear-head and/or collaborate on this effort.

As a reasonably fresh novice in this WG and the LIR game, I think that kind of document is an absolute necessity. -- Jan

On Fri, Sep 27, 2013 at 9:13 AM, Tore Anderson <tore@fud.no> wrote:

However, as I've already pointed out, the new "Sponsored LIR" class of End Users introduced by this proposal doesn't really fit the original definition. (RFC 7020 uses the terms "child LIRs" / "sub-LIRs" instead.)

Sponsored/Sponsoring LIR is easy to confuse. Child LIR does not easily expand (Grandchild LIR?). A Sub-LIR can, if need be, have a Sub-Sub-LIR. -- Richard

Hi, On 9/27/13 10:20 AM, Jan Ingvoldstad wrote:

Yikes, I re-read my messages, and they're a bit more negative than intended.

I'd like to say that I support the cleanup work on a general basis; merging the three documents and clearing up the address space allocation policy is a Good Thing.

thanks, I was getting worried a bit :-) cheers, elvis

Hi, On 9/27/13 9:13 AM, Tore Anderson wrote:

* Jan Ingvoldstad

...

As a reasonably fresh novice in this WG and the LIR game, I think that kind of document is an absolute necessity.

FWIW, "End User" is defined here:

http://www.ripe.net/ripe/internet-coordination/internet-governance/internet-...

I had no idea that this page existed :-)

However, as I've already pointed out, the new "Sponsored LIR" class of End Users introduced by this proposal doesn't really fit the original definition. (RFC 7020 uses the terms "child LIRs" / "sub-LIRs" instead.)

looking at the page above, you are right :-) I'll have a look at RFC7020 and discuss with the co-authors to see how we may change the deffinitions/terms in the next version of this proposal. cheers, elvis

On Mon, Sep 30, 2013 at 3:20 PM, Elvis Velea <elvis@velea.eu> wrote:

I agree with you, however, such document should be created for all the special terms used within the RIPE Community and should not be specific to this policy.

Of course. That was the intention.

Therefore, I would say that if anyone is interested in creating such a document (and I will join that team if one is formed), an other policy proposal should be made independent of 2013-06.

There's already some initial work going on off-list. If anyone wants to join in, please contact me. Richard

* Nick Hilliard

a cursory look over the changes is giving me a warm fuzzy feeling. I need more time to look over it, but right now there's nothing I can see which stands out as obviously harmful.

+1 Some comments from the top of my head (probably not exhaustive since I need some more time to digest the totality of the proposal): - I find the new graphics slightly confusing. There is drawn a link between the Sponsoring LIR to between the RIPE NCC and the End User, as expected, but also between the Sponsoring LIR and the 1st and 2nd level End Users (i.e. between the End User holding the allocation and its downstream End Users). Why is that? I don't see that the Sponsoring LIR has any responsibilities on this level? Also, is there some significance to be read into the fact that the line between the 2nd level End User and its End Site is dotted, while between the 1st level End User and its End Site it is solid? - The proposal should update ripe-592 section 5.6.2, bullet 2. This makes a reference to the IPv6 IXP document which this proposal retires, as I understand it. So in order to avoid this reference not pointing anywhere useful, the the original definition into ripe-592 (I believe this would be the PDO's preference), or to update the reference to point to the proposed unified IPv6 document. - I find the precise definition of the term "End User" to be hollowed out to some extent. In the proposed model, the 1st level End User is for all practical purposes operating as an LIR - the only significant difference seems to be related to which organisation it needs to pay for the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the implied meaning of "End User" is the "final" recipient, i.e., someone who is actually *using* the addresses, while a 1st level End User certainly meets the definition of IR in section 2.1. I would therefore consider instead calling this role a "Sponsored LIR" or something along those lines. - In a similar vein, the LIRs have some NCC-provided tools at their disposal, such as for example the LIR Portal, which is the only place where at least some information can be updated. RPKI is another. Has it been thought whether the "Sponsored LIRs" will be given direct access to these tools, or if their resources will appear in the interface of the Sponsoring LIR, who will have the responsibility to maintain this information on their behalf (which would be an increased responsibility compared to sponsored PI), or something else such as LIR Portal access being one of the incentives for becoming a "proper" LIR? - When it comes to the counterpoint regarding taking away the incentive to become "proper" LIRs. Well - it's been possible to run consumer-based ISPs on IPv4 PI for quite a while, yet the NCC is failing to turn a deficit even though it allegedly is trying, so I'm not terribly concerned. :-) More seriously though, I don't think this is likely to be much of a problem before the same "Sponsored LIR" concept is backported to IPv4, and not necessarily then either. Tore

Hi again Jan, :-) On 9/27/13 9:08 AM, Jan Ingvoldstad wrote:

On Fri, Sep 27, 2013 at 8:49 AM, Tore Anderson <tore@fud.no <mailto:tore@fud.no>> wrote:

- I find the new graphics slightly confusing. There is drawn a link between the Sponsoring LIR to between the RIPE NCC and the End User, as expected, but also between the Sponsoring LIR and the 1st and 2nd level End Users (i.e. between the End User holding the allocation and its downstream End Users). Why is that? I don't see that the Sponsoring LIR has any responsibilities on this level? Also, is there some significance to be read into the fact that the line between the 2nd level End User and its End Site is dotted, while between the 1st level End User and its End Site it is solid?

+1 to that.

Although this is a bit like bike shedding, I think there should be a descriptive explanation right next to the graph, which would be helpful to n00bs (like me, really).

I've already responded to Tore's e-mail. If you still think it's confusing, please let me know.

- I find the precise definition of the term "End User" to be hollowed out to some extent. In the proposed model, the 1st level End User is for all practical purposes operating as an LIR - the only significant difference seems to be related to which organisation it needs to pay for the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the implied meaning of "End User" is the "final" recipient, i.e., someone who is actually *using* the addresses, while a 1st level End User certainly meets the definition of IR in section 2.1. I would therefore consider instead calling this role a "Sponsored LIR" or something along those lines.

I agree. This is made even more difficult by apparently changing the scope of the policy from the leftmost 64 bits to all 128 bits, and by restricting suballocations to the smallest atoms to a /64, appears to reduce the IPv6 address space from 128 bits to 64 bits.

The scope of the policy has not been changed. In the current policy assignments lower than a /64 are not permitted. Therefore, nothing is changed.

Section 1, 1.1 Overview has this current sentence that is removed in the proposal:

"All bits to the left of /64 are in scope."

In one of the previous posts, making things easier for e.g. using separate IP addresses for SSL is an argument for this proposal, but as I read it right now, I would have to sub-allocate a /64 for each SSL certificate, rather than say a /128.

I feel reasonably sure that this is not the intention of the authors.

You are right, it was not our intention to remove that line from section 1.1. However, even with the old policy, my understanding was that you should have assigned a /64 for the SSL certificate and not a /128. I am not sure that removing that line makes any difference, let's see what the others think and we could add it back if it really changes the policy scope. cheers, elvis

Hi Jan, On 10/1/13 9:35 AM, Jan Ingvoldstad wrote: [...]

You are right, it was not our intention to remove that line from section 1.1. However, even with the old policy, my understanding was that you should have assigned a /64 for the SSL certificate and not a /128.

Uhm, no, that would be – and sorry for the strong word use here – insane.

What you're essentially saying is that for any case where one would create a reverse pointer, there would have to be a /64.

I'm not talking about how much you would use on your router or reverse dns. I'm talking about how much to 'reserve' as minimum for a point-to-point link or for a service.

This does not scale at all.

In terms of routing, it currently makes sense to ensure that address space smaller than a /64 is not announced globally via BGP.

But preventing actual _use_ of smaller address space is a very bad idea.

It's not preventing use of a smaller prefix, it's preventing assigning/sub-allocating less than a /64 for anything.

One of the HUGE gains of IPv6 is that you can easily encode more information in the IP address itself than you could with IPv4. There is an enormous amount of flexibility thanks to the 128-bit size of the address space.

Also, if the rightmost /64 cannot ever be used, then IPv6 should've been a 64-bit address space, and I don't think policing this here is relevant.

Well, I used to work as an IPRA at the RIPE NCC and my understanding of the policy then (and now) was that assignments and/or sub-allocations of anything below a /64 is out of scope and even if one IPv6 address is used within a /64, the whole subnet is considered to be used.

I am not sure that removing that line makes any difference, let's see what the others think and we could add it back if it really changes the policy scope.

...

From a n00b's point of view, the old policy reads something like this, in brief:

"This policy does not apply to address space smaller than /64"

And the old policy reads:

"This policy applies to address space regardless of its size"

I see, you may be right, this will be a second slide on the presentation made in Athens and we'll discuss it there.

To me, this is the difference between letting me use e.g. 2a01:5b40::80:88:dead:beef:cafe as the IPv6 address for www.oyet.no <http://www.oyet.no>, and having to use e.g. 2a01:5b40:88:cafe::1/64.

I don't actually see it like that. You can still use the whole IPv6 address to number a device, it's just that you can not split a /64 for different services. For example, you can use a /64 to number, let's say, 100 devices that are in the same vlan doing the same thing and providing the same service but you can not number 100 different customers within a /64. cheers, elvis

Hi Jan, thank you for your reply and sorry for the top posting. I got your point and I will ask the RIPE NCC hostmaster to add back the sentence that we removed by mistake. For the next version we also need to decide whether: - we should be strict and restrict what you can do within a /64 - we should not care what happens within the /64, it's the decision of the address space user. This is an other point for a slide at the RIPE Meeting :-) cheers, elvis On 10/1/13 11:44 AM, Jan Ingvoldstad wrote:

On Tue, Oct 1, 2013 at 11:11 AM, Elvis Velea <elvis@velea.eu <mailto:elvis@velea.eu>> wrote:

Hi Jan,

Hello again, Elvis. :)

I'm not talking about how much you would use on your router or reverse dns.

I'm talking about how much to 'reserve' as minimum for a point-to-point link or for a service.

…

It's not preventing use of a smaller prefix, it's preventing assigning/sub-allocating less than a /64 for anything.

…

Well, I used to work as an IPRA at the RIPE NCC and my understanding of the policy then (and now) was that assignments and/or sub-allocations of anything below a /64 is out of scope and even if one IPv6 address is used within a /64, the whole subnet is considered to be used.

While this particular paragraph is fine, the others are less than, uhm, clear.

To me, this is the difference between letting me use e.g. 2a01:5b40::80:88:dead:beef:__cafe as the IPv6 address for www.oyet.no <http://www.oyet.no> <http://www.oyet.no>, and having to use e.g. 2a01:5b40:88:cafe::1/64.

I don't actually see it like that. You can still use the whole IPv6 address to number a device, it's just that you can not split a /64 for different services.

For example, you can use a /64 to number, let's say, 100 devices that are in the same vlan doing the same thing and providing the same service but you can not number 100 different customers within a /64.

… because of this.

This doesn't make sense.

Why can I not number 100 (or indeed, hundreds of thousands of) addresses for different websites within a /64?

I think, perhaps, that the words "customer", "service" etc. are poorly defined and lead to significant misunderstanding, and that I have not made myself clear.

Whatever a hosting provider chooses to do with their IPv6 space to perform comparatively fine-grained routing and other network organization, should be pretty much irrelevant, as long as what's exposed to peers is sane.

The example I came with is not randomly chosen, I know there has been similar issues with the understanding of semantics in IPv4 policy, which according to some NCC members seemed to imply that it would be impossible to use a separate IPv4 address per SSL site without comparatively major bureaucracy, since (the argument went) these addresses should be assigned and registered.

Now you seem to be telling me that I cannot have a single webserver serving two different websites with two different IPv6 addresses, if they are both within the same /64.

If this is really the case, IPv6 is, within RIPE, a 64-bit address space, not a 128-bit address space, and depletion is guaranteed to become a problem with the proposed policy, as well as the current policy, considering that every hosting provider would need _many_ /32 allocations, as I understand the policy and the argument you make.

If, however, we consider IPv6 an 128-bit address space, and the rightmost /64 as simply not governed by RIPE policy, then a /48 is a _humongous_ address space, providing a LIR with 65k networks which may be redelegated to lower-level customers, such as e.g. web hosting providers, as long as these are routed as a /64 block.

-- Jan

On Fri, Oct 4, 2013 at 3:19 PM, Gert Doering <gert@space.net> wrote:

Hi,

On Tue, Oct 01, 2013 at 11:11:05AM +0200, Elvis Velea wrote:

...

For example, you can use a /64 to number, let's say, 100 devices that are in the same vlan doing the same thing and providing the same service but you can not number 100 different customers within a /64.

But do we want to state that? In web hosting environments, it's not uncommon to have 100 different customers on the very same hardware, each of them using a different IP(v6) address - and with vserver/jail type setups, each of them is typically only using a single address (unlike VM style setups where you might want to use "more").

Do we mandate (or even "encourage") using 100 different /64s for that purpose? I'd say "no" :-) - let the ISP do that if they *want*, but do not *mandate* it.

I think that was a nice way of rephrasing part of my point, thanks Gert! Another point is that these kinds of "customers" are far more ephemeral than what I believe RIPE policy is meant to regulate. The relationship between web site (or web virtualhost, if you like) and IP address is a many-to-many relationship: www.oyet.no has one IPv4 and one IPv6 address, but could've had several. www.ipv6.oyet.no could have a different IPv6 address, but still be the same "customer". But the IPv6 address used by www.ipv6.oyet.no could also be serving www.ipv6.onepocket.no, a different "customer". And in either case, the IPv6 address used for this purpose may not really be _assigned_ as such, but rather used temporarily, until the website(s) in question is moved to a different server or virtual server with different routing, or merely different address space segmentation. I imagine that e.g. Amazon or similar large-scale operations would be unhappy having to segment their space in the manner I understood the proposal at first. If the horse ain't dead yet, I'm happy to flog it a bit more by going into practical, human-readable IPv6 address segmentation for keeping address manageable. ;) -- Jan

Hi Dan, thank you for the great feedback. Please see some of my comments inline. On 10/6/13 1:17 PM, Dan Luedtke wrote:

Hi APWG,

...

5.1.2 Initial Allocation Size Allocations made by the RIPE NCC to the LIR have a minimum allocation size of a /32 and may be up to a /29 with no additional documentation required. Allocations made by the RIPE NCC to the End User have a minimum allocation size of a /32. RIPE NCC reserves a /29 for every /32 allocation, right? So even End Users would "occupy" a /29 even if many of them would forever be satisfied with a /48? This is god news for the routing table as only prefixes size are going to change if End Users grow their networks. (Unlike in IPv4, were grows often implied new routes popping up).

Well, the RIPE NCC reserves two or three extra bits. So, if you get a /48, they will reserve a /45, if you get a /32, they reserve a /29, if you get a /29, they will reserve a /26. And indeed, the growth of the routing table will be kept low if every time someone will need an additional allocation, the RIPE NCC will just extend the current one with 1-3 bits. Additionally, if someone will specifically ask for a /48, the RIPE NCC will continue making the small allocation and the 2-3 bits reservation, it's not like.. whenever you ask for a /48 the RIPE NCC will reserve a /32 or /29.

Elvis Velea wrote:

...

Creating different levels/limits will complicate the policy again and our aim was to make it as simple as possible. I like the proposals simplicity and I support the proposal from what I have read so far.

I am glad, I see that the general feeling is that everyone likes it for being simple and there are just a few comments, mostly on the same topics. We have worked through a few iterations to get this proposal to be this simple. Some things may still be fixed for the second version of this proposal which I think will be published after we compile all the feedback from this list and the RIPE Meeting.

...

Then you would have only one path and no confusion: RIR[RIPE NCC] -> LIR -> End User I would support this if there is a way to eliminate the distinction of PI/PA in IPv4 too. In fact, with the initial proposal End Users are becoming IR in the moment they hand out their first address to a customer. The question is: How can we back off from those who *love*

Tore Anderson wrote: their Sponsoring LIR for doing all the "international RIPE stuff" and those who are eager to share some of their address space with friends/neighbors/customers? There should not arise any new requirement from a change like this for those who just want their network numbered without having to deal with international contracts but there should be new options for those who like to do IR things. RPKI, for example, is something the more tech-savy End Users are missing today.

It would be difficult, some End users still want to be independent from a particular LIR, by having only one path, and after looking at my crystal ball, I would see the following problems: a. RIPE NCC would allocate only to the LIR and the LIR could keep the end user captive - stay in a contract with me or renumber your network b. LIRs may start to de-aggregate their allocations up to a level that the global routing table may explode and we will really have nothing to do against it c. we may see anti-competitive laws or such, because only LIRs will be able to get addresses from the RIPE NCC and therefore, LIRs will be able to make their own rules on who gets what. You may be forced to become an LIR if you need addresses.

Nick Hilliard wrote:

...

So how could you convince the existing ipv6 PI holders that the cost increase from €50/year to LIR membership fees would be worth it? Speaking for me, not possible. Other small enterprises probably think the same. I think we should provide some strong incentive to become a LIR eventually. If the price jumps from 50EUR/yr to 1800EUR/yr business will ask what it gets for the extra money.

Forcing everyone to become an LIR is going to be difficult. We have received some numbers from Andrea (thanks A.) and will propose some different discussion points during the RIPE Meeting.

BTW, I suggest renaming End User to SIR (Sponsored Internet Registry). A SIR could re-allocate its address space and/or just number their enterprise network with it.

During one of the iterations of this policy proposal I had the idea of PIR (Portable Internet Registry). However, the idea was not very well received by the co-authors. It's definition was supposed to be: "A Portable Internet Registry is an IR which can request (via a Sponsoring LIR) an allocation from the RIR. The PIR sub-allocates address space to the users of the network services that it provides. " Considering the current feedback, I think we do need to define the additional layer we add to the chain. The PIR or SIR may not be good enough. If we do define the SIR/PIR, what do we do with the entity receiving a sub-allocation from an LIR, this entity will also be allowed to sub-allocate based on the proposed policy. What would we call that entity then? cheers, elvis

Hi Andrea, On 10/7/13 12:21 PM, Andrea Cima wrote: [...]

The RIPE NCC reserves three bits for each allocation. This is due to historical reasons as, according to policy, the RIPE NCC had to reserve a /29 for each LIR. /32s (and their reservations) are made using the sparse allocation method. [...]

We currently reserve two bits for IPv6 assignments, which is done on the basis of availability. According to the policy: "When possible, these further assignments will be made from an adjacent address block."

http://www.ripe.net/ripe/docs/ripe-589#IPv6_PI_Assignments

Thanks for clarifying these procedures.

Best regards, Andrea Cima RIPE NCC

Regards, Elvis

Hi, On Mon, Oct 07, 2013 at 01:18:15AM +0200, Sander Steffann wrote:

However: the current policy for IPv6 PI assignments specifies "Assignments will be made from a separate 'designated block' to facilitate filtering practices.". Is that worth keeping?

I find it useful. If only to help my scripts in building my routing table pictures (http://www.space.net/~gert/RIPE/weekly/) to find "outliers" - I tag address space blocks as "PI" or "IXP" or "DNS root", and then I normally do not need to do anything for new prefixes showing up, as opposed to "oh, a new /48, let's go to the RIPE DB and see what flavour it is". (Now, the "PI" category would not be named as such anymore, but it would still be "the small type of prefix" and as such worth to keep track on a separate line) Gert Doering -- speaking as IPv6 statistics geek -- 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 (0)89/32356-444 USt-IdNr.: DE813185279

* Elvis Velea

On 10/7/13 1:18 AM, Sander Steffann wrote:

...

Hi,

...

RIPE NCC reserves a /29 for every /32 allocation, right?

No, they don't. It used to be like that a long time ago, but these days it is just sparse allocation. The change was announced at RIPE-61 (http://ripe61.ripe.net/presentations/331-Update_RIPE_NCC_R61.pdf) which was in November 2010.

I think they still reserve 3 bits, even with the sparse allocation algorithm.

This is easy to find out, since delegations are public data. AFAICT: - Allocations (at least up to and including /29s): reserve a /26 (for some reason the allocated /32 isn't the first one in the /26) - Assignments (at least /48s): reserve a /46 $ grep 'ipv6.*201310' delegated-ripencc-extended-latest ripencc|AT|ipv6|2a00:f020::|32|20131001|allocated ripencc|SE|ipv6|2a00:f060::|32|20131001|allocated ripencc|NO|ipv6|2a00:f0a0::|32|20131001|allocated ripencc|QA|ipv6|2a00:f0e0::|32|20131001|allocated ripencc|AT|ipv6|2a00:f120::|32|20131002|allocated ripencc|RU|ipv6|2a00:f160::|32|20131002|allocated ripencc|BE|ipv6|2a00:f1a0::|32|20131002|allocated ripencc|SE|ipv6|2a00:f1e0::|32|20131002|allocated ripencc|ME|ipv6|2a00:f220::|32|20131002|allocated ripencc|AZ|ipv6|2a00:f260::|32|20131003|allocated ripencc|RU|ipv6|2a00:f2a0::|32|20131003|allocated ripencc|GE|ipv6|2a00:f2e0::|32|20131003|allocated ripencc|NL|ipv6|2a00:f320::|32|20131003|allocated ripencc|NL|ipv6|2a00:f360::|32|20131003|allocated ripencc|IT|ipv6|2a00:f3a0::|32|20131004|allocated ripencc|RU|ipv6|2a00:f3e0::|32|20131004|allocated ripencc|DE|ipv6|2a00:f420::|32|20131004|allocated ripencc|RU|ipv6|2a00:f460::|32|20131004|allocated ripencc|GG|ipv6|2a04:6b40::|29|20131001|allocated ripencc|NO|ipv6|2a04:6b80::|29|20131001|allocated ripencc|NL|ipv6|2a04:6bc0::|29|20131002|allocated ripencc|ES|ipv6|2a04:6c00::|29|20131002|allocated ripencc|BE|ipv6|2a04:6c40::|29|20131003|allocated ripencc|RO|ipv6|2a04:6c80::|29|20131003|allocated ripencc|SE|ipv6|2a04:6cc0::|29|20131003|allocated ripencc|SE|ipv6|2a04:6d00::|29|20131003|allocated ripencc|CH|ipv6|2a04:6d40::|29|20131004|allocated ripencc|PT|ipv6|2a04:6d80::|29|20131004|allocated ripencc|NL|ipv6|2a04:6dc0::|29|20131004|allocated ripencc|RU|ipv6|2001:67c:2be0::|48|20131001|assigned ripencc|PL|ipv6|2001:67c:2be4::|48|20131003|assigned ripencc|NL|ipv6|2001:67c:2be8::|48|20131004|assigned ripencc|PL|ipv6|2001:67c:2bec::|48|20131004|assigned Tore

Hi Tero, On 9/27/13 10:28 AM, Tero Toikkanen wrote:

...

- I find the new graphics slightly confusing. There is drawn a link between the Sponsoring LIR to between the RIPE NCC and the End User, as expected, but also between the Sponsoring LIR and the 1st and 2nd level End Users (i.e. between the End User holding the allocation and its downstream End Users). Why is that? I don't see that the Sponsoring LIR has any responsibilities on this level? Also, is there some significance to be read into the fact that the line between the 2nd level End User and its End Site is dotted, while between the 1st level End User and its End Site it is solid?

It might be clearer to illustrate all three paths individually (from RIPE NCC to LIR, Sponsoring LIR and End User). I also agree with what Tore Anderson and Richard Hartmann said about somehow clarifying the division between Sponsoring LIR and a possible Sponsored/child/sub-LIR under it. Sponsored/Sponsoring LIR is certainly easily confused, so Sub-LIR might be the way to go.

There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC to End user (we may decide to change the name) via the Sponsoring LIR. cheers, elvis

On 30/09/2013 17:41, Tore Anderson wrote:

Then you would have only one path and no confusion:

RIR[RIPE NCC] -> LIR -> End User

you would have confusion about who the address space holder was and what the end user's rights and obligations were to the ripe ncc. If you're going to suggest this, talk to the RIPE NCC legal eagles because it's a difficult area. Nick

On 30/09/2013 18:00, Tore Anderson wrote:

All existing PI holders would become simultaneously both the LIR *and* the End User in the above chain, so I'm not sure where this confusion would come from?

So how could you convince the existing ipv6 PI holders that the cost increase from €50/year to LIR membership fees would be worth it? IOW, there are two problems here: an addressing flavour issue, which relates to the RIPE community, and a billing issue which is the responsibility of the RIPE NCC. For sure, you couldn't do this to just the ipv6 PI assignments - it would have to be to all address space, but then you get into the thorny issue of billing. Let me pull out a paper napkin for a moment and hand-wave the possibility that all PI holders became LIRs and all LIRs paid the same fees. The 2014 budget is €21.7m (practical). All LIRs pay the same (ncc member policy). There are about 9500 members and 33000 assigned pi resources (reality), probably with lots of overlap (reasonable speculation). Let's pluck a figure out of thin air and say that there are 35000 distinct end users + lirs (wild speculation), who need to pay an equal share of a budget of €21.7 million. This means you have maybe 25000-30000 organisations around the ripe ncc service region who are going to see their fees increase from (wholesale) €50 to €650 per annum. This won't fly. We need to be practical about a workable policy proposal here. Whether we like it or not, there is a strong history of cost differentiation in terms of how ip addresess are handled, and I don't see a practical way of levelling the field within the constraints of what's workable and what we'd ultimately like. Nick

Hi Tore, On 9/30/13 11:21 PM, Tore Anderson wrote: [...]

Q: They wouldn't want to pay the full membership price for being LIRs! A: We don't have to make them. It could be possible to be a RIPE region LIR even though you're not a direct/full member of the RIPE NCC. RIPE NCC members could be seen as "sponsors of LIR status" instead of "sponsors for PI blocks". It could even cost the same €50 as before.

This proposal, the way I see it, creates a new class of End Users who are for all practical purposes LIRs. Quoting the definition from the policy document:

2.1 Internet Registry (IR)

An Internet Registry is an organisation that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above.

[...]

2.3 Local Internet Registry (LIR)

A Local Internet Registry (LIR) is an IR that primarily sub-allocates address space to the users of the network services that it provides.

If you look at the figure in section 2.0, the "End User" box on the right adjacent to the "Sponsoring LIR" one ... that End User is an LIR. It exactly matches the definition, at least - the only difference appears to be in the name. If it walks like an LIR, talks like an LIR...

So let's try replacing the "End User" label on that box with "LIR". Now the two trees below the RIPE NCC are identical, except for the presence of the "Sponsoring LIR" box on the right. But that's a contractual/billing-related mechanism that doesn't really have anything to do with the internet registry system per se. So I think we can just as well remove it from the address policy¹, and we are left with two completely identical hierarchies.

[1] Not saying it should be removed as a contractual/billing-related mechanism as currently used, but I don't think it is necessary to specify it in the policy document just like we don't specify the RIPE NCC fees in there either.

LIR is already a well defined term and making everyone an LIR (while they are not an actual LIR) would confuse more than fix things. I agree that we may want to rename the End User to something else as it is some sort of IR, but making it an LIR (with less service and power) is a bad idea. Would you also give everyone the right to vote at the AGM? Let's not go there. We have LIRs and we all know what these are. Let's find a better name/definition of the entity currently called End User.

...

This won't fly. We need to be practical about a workable policy proposal here. Whether we like it or not, there is a strong history of cost differentiation in terms of how ip addresess are handled, and I don't see a practical way of levelling the field within the constraints of what's workable and what we'd ultimately like.

I'm not saying we should start charging the traditional PI holders more than we do today. Just that if we're going to grant them "LIR powers", which this proposal does (and I don't disagree with that), we might as well start calling them "LIRs" as well. A spade is a spade.

No, I do not agree to call them LIR, the LIR is well defined. You are right, we maybe should not call them End Users either, let's work on redefining the End User to something else. Regarding the payment fees, we can not decide anything in this WG anyway, I'd like to ask everyone to either hold on to this discussion for the GM in Athens or open the discussion on the members-discuss@ripe.net mailing list. thanks, elvis

Hi Tore, On 10/1/13 9:08 AM, Tore Anderson wrote:

* Elvis Velea

...

No, I do not agree to call them LIR, the LIR is well defined. You are right, we maybe should not call them End Users either, let's work on redefining the End User to something else.

The terms LIR (and IR) is indeed well defined, and that's indeed my point - these new "super End Users" actually fit that definition. :-)

Okay, got the point and somehow agree with it.

(I'm only talking about the role of the LIR in the Internet Registry System here, so to be clear I'm *not* equating "LIR" to "direct member of the RIPE NCC who pays the full membership fee and has voting rights at the AGM", nor am I saying that everyone who holds PI space should be forced become such direct members of the RIPE NCC.)

Well, since the assignments will be removed, anyone receiving a sub-allocation from the friendly provider can further sub-allocate (as long as they receive more than a /64) and become some sort of IR. But, would you consider yourself an IR if you receive a sub-allocation from your ISP and sub-allocate a /64 to your brother for his web server?

Anyway, I think I've made my point, so I'll leave it at that and let this be my last message on the subject. Like I've said before, this is not intended to be a "my way or the highway" statement of opposition, just a (hopefully) constructive piece of feedback you and your co-authors may do with as you wish.

One of the slides at the RIPE Meeting (and I hope you will be in Athens) will be related to this subject and I hope we can have a constructive discussion and reach a good decision. thanks for all the feedback, please continue to bring it on ;) cheers, elvis

Hi Gert, On 10/1/13 10:19 AM, Gert Doering wrote:

Hi,

On Tue, Oct 01, 2013 at 01:32:22AM +0200, Elvis Velea wrote:

...

Regarding the payment fees, we can not decide anything in this WG anyway, I'd like to ask everyone to either hold on to this discussion for the GM in Athens or open the discussion on the members-discuss@ripe.net mailing list.

Well. APWG can not *decide* on the charging scheme, but we can make reasonable proposals to the AGM - and if the addressing community agrees that something makes sense, the NCC board usually listens closely and works that into the next proposed charging scheme.

right :)

We did that with 2007-01, and while it wasn't easy, it got done in the end. Now all sides have a bit more experience in listening to each other, so it might be easier this time :-)

I hope that it won't take us two years to get consensus to this proposal (as it happened with 2007-01) :)

Anyway - what we need to be careful about is

- do not make the price for "what used to be called PI holders" dramatically higher - technically, we might do this ("we vote, they pay"), but the signal this sends to the world is "we're a cartel and we've just decided that we all pay less and everyone else pays more", which is very likely to get us into deep shit with regulators, tax authorities, etc.

I see, well.. I think it's time we ask the RIPE NCC for some statistics [1] before we can actually see how this could be modeled.

- have the right incenctives here (e.g.: "a /32 costs 10000 EUR/year, a /48 costs 50 EUR/year" would send the message to ISPs "if you can number your network with a /48, you can save serious money!" and that will lead to "assigning customers a /64 or even less", which we don't want)

correct, I would not want to see ISPs/hosting companies sub-allocating a /96 or a /112 to fit everything within a /48.

So I think something like

- every LIR pays a base fee ("one size fits all") which includes their initial /29.../32 ("as today")

I agree.

- every extra "small allocation" (smaller than /32) costs 50 EUR/year (+ 50 EUR/year per IPv4 PI)

I don't really agree with this bit, but it may be one way to go.

- every extra "big allocation" (/32 or shorter) costs 500 EUR/year

Here is why I do not agree with the 50€ for the /48 and 500€ for the /32 or more.. If we recommend the AGM to do it this way and they actually agree and vote next year to have this charging scheme, I am afraid that ISPs and hosting companies will immediately say: - wait a second, so if I number everything within a /48 I can save 450€/year? - what would cost me to use a /112 to connect a customer? nothing. - What are the technical disadvantages? None. - Why would I use a /64 or more and be forced to pay 500€?

would get us somewhere, without causing extra turmoil - for today's address holders, nothing much would change, and for future allocations, the financial incentives to go one way or other ("do not become LIR, get your /32 from a sponsoring LIR" and "run your whole ISP on a /48") are not significant enough to outweigh other reasons.

Your idea may work but we may also see that everyone will request a /48 and try to fit all their operations within that /48.

Elvis, I think this is something which deserves it's own slide and 10 minutes of discussion at the APWG meeting :-) (and possibly other models for charging scheme and incentives), so we can then have input to the AGM for consideration...

I agree.

Gert Doering -- APWG chair

[1] to the RIPE NCC: Can you please give us some aggregate data regarding the following numbers: (We do not need exact numbers, as these will change 5 minutes later once you make a new registry change - assignment/allocation/etc) 1. Is my number correct ? There are approximately 28355 PI assignments 2. How many organisations are using these 28355 PIs? 3. Is my number correct? There are approximately 1538 IPv6 PI assignments 4. How many organisations are using these 1538 IPv6 PIs? 5. How many LIRs have an IPv6 allocation but not an IPv4 one? thank you, elvis

Hi Andrea, thank you for the numbers :-) On 10/4/13 3:12 PM, Andrea Cima wrote:

Hi Elvis,

Please find the numbers below.

On 10/1/13 11:46 AM, Elvis Velea wrote:

...

[1] to the RIPE NCC: Can you please give us some aggregate data regarding the following numbers: (We do not need exact numbers, as these will change 5 minutes later once you make a new registry change - assignment/allocation/etc)

1. Is my number correct ? There are approximately 28355 PI assignments

There are approximately 25.000 IPv4 PI assignments issued by the RIPE NCC.

...

2. How many organisations are using these 28355 PIs?

Approximately 20.500 organisations.

[...] So, we have about ~20.000 Non-LIRs and ~10.000 LIRs (round numbers) I'll ignore for now the rest of the numbers as these are too low to make a difference. I asked for these numbers to make a few estimations on how could the budget look like in the next years. What I was thinking to propose is the following: Let's consider, for the ease of calculation, that the RIPE NCC budget for 2015 will be ~€22M and we will have 10.000 LIRs and 20.000 non-LIRs using PIv4 or IPv6 allocations. The exact numbers could be provided by the RIPE NCC, however.. again, for the sake of conversation, let's consider the following scenarios based on rough numbers: 1. The simple way - the RIPE NCC budget could be divided in two parts, 50% paid by LIRs; 50% paid by Non-LIRs. €11M would be paid by 10.000 LIRs and €11M would be paid by the rest of 20.000 non-LIRs That means that the LIRs would see a decrease of 700€ in their fees, they would pay 1100€/year. It also means that they users of PIv4 or IPv6 'direct' allocations would see an increase from 50€ to 550€. I think this would be the easiest way, however, the RIPE NCC board may not agree to risk the budget. In that case, we could come up with the next calculus: 2. The complicated way - the RIPE NCC budget would be paid using the scheme 80/20% This means LIRs would pay 80% of the budget and would only see a decrease of 40€ in the anual fee (from 1800€ to 1760€) and the non-LIR would have to pay 220€ (no matter how many resources they would use). This simple mathematical exercise has been made only considering that the whole budget would be constructed only from the fees. Additionally, current price / assignment is 50€. Considering that ~20.500 organisations are using ~25.000 assignments, some organisations already pay more than 50€, some even up to €500 (if they use - for example - 10 assignments). 3. The fair way With 30.000 organisations and a 22M€ budget, if we were to divide the price equally, every organisation would need to pay around 700€/year, no matter how many resources they use. That means a decrease of 1100€ for each LIR and an increase of 650€ (or less for the organisations using more than one assignment). I expect to see that organisations currently using IPv4 PI to start using IPv6 as well. That means that the increase would actually be from min 100€ (50€ for v4 and 50€ for v6) to 700€. 4. Would you think of any other option? cheers, elvis

On 30/09/2013 23:58, Elvis Velea wrote:

the billing issue is the responsibility of the RIPE NCC _members_ :-)

you can't sweep this under the carpet. Billing is the only thing that matters to the vast majority of resource holders. Nick

Hi, On Tue, Oct 01, 2013 at 11:54:31AM +0200, Elvis Velea wrote:

I also think that the discussion about billing related to this policy proposal to take place in the members-discuss, the only place where suggestions can be made and discussed by the ones that will vote.

I actually disagree - it's an inseparable part of the proposal to work out how the effects on membership and charging scheme can look like, and what to propose. When the address policy community agrees on a) the proposal, and b) how a new charging scheme that takes this into account, we pass the ball to members-discuss / the AGM to take our input and decide on the final charging scheme - but without solid agreement from here, the end result will be "disconnection". So the discussion needs to stay here, until this community is in agreement. (Of course we give a HEADS UP to the members and the NCC board - for example by giving a short summary in the NCC services working group, at the RIPE meeting...) Gert Doering -- APWG chair -- 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 (0)89/32356-444 USt-IdNr.: DE813185279

On 01/10/2013 11:04, Gert Doering wrote:

So the discussion needs to stay here, until this community is in agreement. +1 (Of course we give a HEADS UP to the members and the NCC board - for example by giving a short summary in the NCC services working group, at the RIPE meeting...)

At least one board member watches the discussions here ;-) Nigel

On 10/7/13 8:53 PM, Dmitry Burkov wrote:

On Oct 7, 2013, at 8:25 PM, Nigel Titley wrote:

...

On 01/10/2013 11:04, Gert Doering wrote:

...

So the discussion needs to stay here, until this community is in agreement. +1 (Of course we give a HEADS UP to the members and the NCC board - for example by giving a short summary in the NCC services working group, at the RIPE meeting...)

At least one board member watches the discussions here ;-) You are not alone :)

Dmitry

...

Nigel

glad to know that you both are watching this with interest :-) regards, elvis -- V4Escrow, LLC

From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Nigel Titley Sent: 08 October 2013 14:38 To: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) On 07/10/2013 21:16, Elvis Daniel Velea wrote: On 10/7/13 8:53 PM, Dmitry Burkov wrote: On Oct 7, 2013, at 8:25 PM, Nigel Titley wrote: At least one board member watches the discussions here ;-) You are not alone :) Dmitry Nigel glad to know that you both are watching this with interest :-) Big Brother is indeed watching you... Nigel I'd never noticed the family resemblance before... Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. EE Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW

Hi, On 9/30/13 7:00 PM, Tore Anderson wrote:

* Nick Hilliard

...

On 30/09/2013 17:41, Tore Anderson wrote:

...

Then you would have only one path and no confusion:

RIR[RIPE NCC] -> LIR -> End User

you would have confusion about who the address space holder was and what the end user's rights and obligations were to the ripe ncc. If you're going to suggest this, talk to the RIPE NCC legal eagles because it's a difficult area.

All existing PI holders would become simultaneously both the LIR *and* the End User in the above chain, so I'm not sure where this confusion would come from?

sorry, what? I'm confused :-)

It would essential be the same as if a current LIR assigns its entire allocation to itself (its own infrastructure) and has no external End Users. I have a feeling this already happens a quite a bit in IPv4 these days...

Note that assignments will no longer exist under the proposed policy. Additionally, I don't really understand the comparison in the context of the question. Just having one path means that only the LIR will receive address space from the RIPE NCC and they can do whatever they want (provided they follow the policy) with that address space. It removes the independence of the current PI holder status. Anyway, I do not think this is the right way to go forward and this proposal would dramatically change the whole policy which is not what we really aim for. Enough drama with the removal of PI and assignments :-) my 2 cents elvis

Hi, (no hats) On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote:

Q: How would that work? A: We could end up with two levels of RIPE NCC membership, e.g. "full" like we have today, and "associate". Both would be fully-blown LIRs, but to keep the operational overhead in NCC billing/finance low, the membership fee for these "associate" members would be charged by the NCC to the full members who are sponsoring them (just like with PI).

I'm not exactly sure what the difference between an "associate member" and today's "consumer of resources provided by a sponsoring LIR" would then be, except for the title on the contract. On the contrary, some enterprises just don't want to deal with the RIPE NCC if they can make a contract with their friendly neighbouring LIR instead... So I'm not sure it's worth abandoning the established concept of sponsoring LIR right away (especially since doing away with it would affect IPv4 PI as well...). It wouldn't make a difference anyway :-) - if we want to give people the option to take a /48 because it's big enough for them, we'd then still have "two standard sizes"... So, yes, another avenue could be "abandon /48 assignments/allocations", but *that* brings up another can of worms (what about an enterprise that has 5 locations that all have local ISP upstreams and want to do BGP multihoming? 5x /48 suits them well today, 1x /32 with someone blocking more-specifics from that because no site is announcing the /32 aggregate would not be that good). I'm repeating the "no hats" bit, just contributing to the discussion as someone who has fought IPv6 policy for a while now :-) - and this is discussion phase, so take this all as "brain dump", not as "advice from the chair". gert -- 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 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, without actually wanting to drive the direction anywhere, just adding something that you might have missed :-) On Mon, Sep 30, 2013 at 09:02:21PM +0200, Tore Anderson wrote:

PI holders currently cannot assign address space to their customers, and that's what I understand this proposal to be all about changing, but it does it in a way that defines a new "breed" of End User who a) does not at all fit the original definition of an End User, while b) does completely fit the definition of an Internet Registry. Put it another way, the new (1st level) type of End User created by the proposal appears to me to be an LIR in all but name.

Well, there are still "just plain" end users of "PI space" out there, that do not do "LIR things", but just run a (multihomed) network - we have a couple of these under our sponsoring LIR, and they are quite happy not having to deal with the RIPE NCC (because they are smaller german enterprises, not willing to deal with international contracts, etc.). The whole thing that started this PA/PI unification project is that the distinction between "ISP" (=LIR, PA) and "end user" (=not LIR, PI) has become less and less clear over time, and as such, it became mostly confusing to "people out there" not regularily dealing in RIPE policy. So - based on "some people will want to operate more like an ISP" and "other people will be happy to number primarily their own network, and maybe a server of their neighbour next door", it seemed to make sense to keep the distinction of "full LIR" and "address space flowing via a sponsoring LIR to folks not really doing LIR things" - and those might not be interested at all in having to deal more with the RIPE NCC. OTOH, I really should stay out of this discussion now, as it's not my role to push this any specific way - while I *did* get this started, now Elvis is the one driving it, and the community has to decide what they (you!) want, while I focus on the chairing thing - guiding the discussion and such. Gert Doering -- some hats -- 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 (0)89/32356-444 USt-IdNr.: DE813185279

Hi Tore, On 9/30/13 10:55 PM, Tore Anderson wrote:

* Gert Doering

...

On Mon, Sep 30, 2013 at 09:02:21PM +0200, Tore Anderson wrote:

...

PI holders currently cannot assign address space to their customers, and that's what I understand this proposal to be all about changing, but it does it in a way that defines a new "breed" of End User who a) does not at all fit the original definition of an End User, while b) does completely fit the definition of an Internet Registry. Put it another way, the new (1st level) type of End User created by the proposal appears to me to be an LIR in all but name.

Well, there are still "just plain" end users of "PI space" out there, that do not do "LIR things", but just run a (multihomed) network - we have a couple of these under our sponsoring LIR, and they are quite happy not having to deal with the RIPE NCC (because they are smaller german enterprises, not willing to deal with international contracts, etc.).

I didn't miss these, but maybe I wasn't clear enough. Perhaps I should have called them "non-member LIRs" rather than "associate members". So the process would be that your LIR (which is a member of the RIPE NCC) would sponsor your customers to also become LIRs. Contracts are between you and them, no direct RIPE NCC dealings there, while the NCC charges you a fee for each LIR you sponsor in such a way. Just like with PI today. Address blocks would be delegated straight from the RIPE NCC to your customers, also just like with PI today.

there is no big difference between our proposal and what you are talking about. It's just that you want to call everyone an LIR - I don't think this will fly. Either we force everyone to become a member or we keep the Sponsoring LIR concept, I'm for the latter.

Assuming these customers of yours only wants to run a multihomed network, they'd just make an assignment to themselves (or you'd help them with that, or the NCC could do it based on their request forms when registering the delegation), and that's that.

You can still do that, it's just that we need to define the name of these customers, LIRs will not work, End Users clearly doesn't work as these would have some of the attributions of an IR.

...

The whole thing that started this PA/PI unification project is that the distinction between "ISP" (=LIR, PA) and "end user" (=not LIR, PI) has become less and less clear over time, and as such, it became mostly confusing to "people out there" not regularily dealing in RIPE policy.

So - based on "some people will want to operate more like an ISP" and "other people will be happy to number primarily their own network, and maybe a server of their neighbour next door", it seemed to make sense to keep the distinction of "full LIR" and "address space flowing via a sponsoring LIR to folks not really doing LIR things" - and those might not be interested at all in having to deal more with the RIPE NCC.

But...the address space isn't flowing via a sponsoring LIR with PI. The role of the sponsoring LIR is merely a contractual one. AIUI, PI is direct assignments from the RIPE NCC to the End Users, just like PA is direct allocations from the RIPE NCC to the LIRs.

I disagree, the Sponsoring LIR should make sure that the resources are maintained and not just pass contracts between the RIPE NCC and the customer. The contract model on the RIPE website is called "Independent Assignment Request and _Maintenance_ Agreement". Additionally, you may want to see article 4 of the model agreement [1] cheers, elvis [1] https://www.ripe.net/lir-services/resource-management/independent-resources/...

Hi Tore, On 9/30/13 9:02 PM, Tore Anderson wrote:

* Gert Doering

...

On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote:

...

Q: How would that work? A: We could end up with two levels of RIPE NCC membership, e.g. "full" like we have today, and "associate". Both would be fully-blown LIRs, but to keep the operational overhead in NCC billing/finance low, the membership fee for these "associate" members would be charged by the NCC to the full members who are sponsoring them (just like with PI).

I'm not exactly sure what the difference between an "associate member" and today's "consumer of resources provided by a sponsoring LIR" would then be, except for the title on the contract. On the contrary, some enterprises just don't want to deal with the RIPE NCC if they can make a contract with their friendly neighbouring LIR instead...

The difference would be that an "associate member" (which is just an idea, and outside the scope of APWG anyway) would be an LIR, and would therefore be able to assign address space to its customer in turn.

again, assignments are removed from the proposed text. they will be able to sub-allocate. I agree that we may need to give this 'sort of IR' a name, associate member doesn't sound right though. Keep firing suggestions ;)

PI holders currently cannot assign address space to their customers, and that's what I understand this proposal to be all about changing, but it does it in a way that defines a new "breed" of End User who a) does not at all fit the original definition of an End User, while b) does completely fit the definition of an Internet Registry. Put it another way, the new (1st level) type of End User created by the proposal appears to me to be an LIR in all but name.

It will probably be some kind of IR, just not an LIR nor an End User.

So what I'm thinking is that it's better to call a spade a spade as far as address policy go, and instead have the NCC/AGM/Board decide exactly how they want to go about charging for the different flavours of spades.

It's not really a spade, that organisation will be able to use the address space or sub-allocate (parts of) it to other organisations. However, these will have the same right (use or sub-allocate). What do we do then? call everyone an 'associate' ?

But that's just my €0.02. Like I said earlier, this should not be mistaken for opposition to the current proposal, just a suggestion.

...

So I'm not sure it's worth abandoning the established concept of sponsoring LIR right away (especially since doing away with it would affect IPv4 PI as well...). It wouldn't make a difference anyway :-) - if we want to give people the option to take a /48 because it's big enough for them, we'd then still have "two standard sizes"...

Or we could simply tell the requesters to pick their favourite number between 28 and 49... as long as policy says it's should be possible to extend up to and including /29 it doesn't really matter what they start out with as far as keeping delegations aggregated go (and routing is another matter entirely).

It's up to /29 for LIRs. How did you get to the numbers 28 or 49? It's either /48 if the organisation is sure that they will not need more; or a /32 if they do plan to sub-allocate to other customers. Adding intermediary numbers does not make any sense, allowing intermediary numbers may cause all kinds of problems: - billing issues, if at some time the AGM will decide to bill based on the size (as it used to do with IPv4 in the past) - filtering issues - aggregation issues

...

So, yes, another avenue could be "abandon /48 assignments/allocations", but *that* brings up another can of worms (what about an enterprise that has 5 locations that all have local ISP upstreams and want to do BGP multihoming? 5x /48 suits them well today, 1x /32 with someone blocking more-specifics from that because no site is announcing the /32 aggregate would not be that good).

But that's the route6 object, not the inet6num. If someone is filtering on the inet6num without accepting more specifics they're already asking for trouble (their users would surely complain about lack of connectivity to the more-specifics inside 2a02:26f0::/32, for starters).

I already answered in my previous message. See 5.2.1 from the proposed text.

Tore

Elvis

Hi Tore, I'll respond below to all the suggestions. On 9/30/13 6:41 PM, Tore Anderson wrote:

* Elvis Velea

...

There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC to End user (we may decide to change the name) via the Sponsoring LIR.

Hi Elvis,

Just thinking out loud here, so don't mistake this for opposition to the current proposal, it's not, but we are in the bikeshe^Wdiscussion phase after all...

right :)

I'm thinking that the "Sponsoring LIR" concept is an NCC operational issue that perhaps doesn't really belong in address policy to begin with. Perhaps it would result in a more concise and elegant policy if instead of "unifying" PA with PI, this proposal simply just removed the PI concept altogether? Simply just delete section 7 of the policy document and leave it at that - as far as the policy document goes anyway.

Then you would have only one path and no confusion:

RIR[RIPE NCC] -> LIR -> End User

Nick already responded to this, and actually, my personal belief is that we should aim to have everyone pay the same fee but not force everyone to become an LIR. Some companies will/can not be members of other organisations (RIPE NCC). The scheme we have right now works fine: RIPE NCC -> LIR -> End User ->[...] -> End Site (this is already possible with the LIR sub-allocating to the end user even with the current policy) RIPE NCC -> End User ->[...] -> End Site this is basically the big thing introduced by this policy proposal, allowing the non-LIRs to offer services over IPv6 to any kind of customers they may have.

Everything that follows below could be considered operational issues that's for the NCC/AGM/Board to decide on...but just to elaborate a bit more on where I'm thinking something like this could lead to:

Q: But what about existing PI holders and their blocks? A: Just start considering them to be LIRs. Upon implementation of the new policy, the NCC could automatically convert all existing inet6num in the database with status ASSIGNED PI to ones with status "ASSIGNED" (PA), and add a congruent object with status ALLOCATED-BY-RIR.

This will happen anyway, all the ASSIGNED PI will become ALLOCATED.

Q: They wouldn't want to pay the full membership price for being LIRs! A: We don't have to make them. It could be possible to be a RIPE region LIR even though you're not a direct/full member of the RIPE NCC. RIPE NCC members could be seen as "sponsors of LIR status" instead of "sponsors for PI blocks". It could even cost the same €50 as before.

This is what will happen with this current proposal. However, the RIPE NCC will make the allocation to the End User and not to the LIR.

Q: How would that work? A: We could end up with two levels of RIPE NCC membership, e.g. "full" like we have today, and "associate". Both would be fully-blown LIRs, but to keep the operational overhead in NCC billing/finance low, the membership fee for these "associate" members would be charged by the NCC to the full members who are sponsoring them (just like with PI).

We will have two levels, just not two levels of membership. We will have members and non-members. The non-members will have to pay the invoice for maintenance of these resources to their Sponsoring LIR.

Q: Why would anyone want to be a full member then? A: Access to certain NCC services such as the LIR Portal, Atlas credit boost, etc. could be limited to full members only.

In any case - those would be operational and mercantile issues we could leave out of the policy (but perhaps provide suggestions/guidance on in the supporting notes). Maybe I'm off my rocker, but this is what was going through my head on the bus back home today... :-)

Correct, if someone wants to become a member they can benefit from all the services the RIPE NCC can offer. Otherwise, they can just request an allocation via the Sponsoring LIR and (maybe) pay (a bit) less. cheers, elvis

Hi Sacha, On 9/30/13 9:27 PM, Sascha Luck wrote:

On Mon, Sep 30, 2013 at 05:22:52PM +0200, Elvis Velea wrote:

...

There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC to End user (we may decide to change the name) via the Sponsoring LIR.

I would be in favour of converting all resources into "independent resources" and the path going, in all cases:

hum, that will open a lot of can of worms, what do we do if every current LIR decides to become a customer of a Sponsoring LIR?

RIR -> Sponsoring LIR -> End User. Advantages: - End Users can transfer "their" resources to a different Sponsoring LIR

ok...

- Specialist LIRs can be established that have the necessary skills to manage resources properly, End Users wouldn't have to worry about resource management and it may result in reducing the work-load on the RIR..

we already have those entities in a few countries. I know at least of a few entities that mostly do IR management in various countries in the region.. Nobody is stopping the Specialists to just open a registry and start offering services. We are already doing that and we have just registered a few weeks ago :-)

Disadvantages:

- This opens the door to the establishment of "N(ational)IRs", something which some states have expressed an interest in.

I would not see this a disadvantage.

- There is a probability of de-aggregation of resources as they move between Sponsoring LIRs - could possibly be mitigated by making the minimum assignments big enough.

this would probably be a big disadvantage.

- RIR membership will likely decline - this could also be an advantage.

Not really, we will have less LIRs paying a lot more.

rgds, Sascha Luck

cheers, elvis

PS: in such a scenario I would even consider supporting 2012-08 ;)

PS: me too :-) but this scenario is out of scope of this policy proposal as the policy proposal does not cover IPv4 :-)

Hi Roger, On 10/1/13 9:43 AM, Roger Jørgensen wrote:

On Mon, Sep 30, 2013 at 9:27 PM, Sascha Luck <lists-ripe@c4inet.net> wrote:

...

On Mon, Sep 30, 2013 at 05:22:52PM +0200, Elvis Velea wrote:

...

There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC to End user (we may decide to change the name) via the Sponsoring LIR.

I would be in favour of converting all resources into "independent resources" and the path going, in all cases:

RIR -> Sponsoring LIR -> End User. [...] You're talking about a quite radical changes to how we think of IP space.

Correct, current proposal is quite a radical change. However, it does not change much the reality today. Companies do request /48 PI assignments saying that they will use it only for their infrastructure and then start giving bits of it to customers without actually registering the assignment/sub-allocation and basically violating the policy.

What you're hinting at are not that difficult from something we're discussing on IETF level, and in the concept of LISP. Get a new block of address space that will be distributed directly to end-users. It's just IP space.

LISP is a totally different story. Let's not mix them up, please :-)

It do include a tons of pitfalls and difficult consideration, alot.

On the other hand, what is the real difference from what you're suggestion and what current reality are? The LIR "concept"?

The LIR concept is a well defined concept. Based on the discussions on this list in the past few days I do realise that we need to define the previously known PI user and I see that the term 'End User' does not match with the role. cheers, elvis

Hi Tore, On 9/27/13 8:49 AM, Tore Anderson wrote:

Some comments from the top of my head (probably not exhaustive since I need some more time to digest the totality of the proposal):

- I find the new graphics slightly confusing. There is drawn a link between the Sponsoring LIR to between the RIPE NCC and the End User, as expected, but also between the Sponsoring LIR and the 1st and 2nd level End Users (i.e. between the End User holding the allocation and its downstream End Users). Why is that? I don't see that the Sponsoring LIR has any responsibilities on this level? Also, is there some significance to be read into the fact that the line between the 2nd level End User and its End Site is dotted, while between the 1st level End User and its End Site it is solid?

The dotted line between the RIPE NCC and End User shows that this request can be done by the Sponsoring LIR. The dotted line between the End User and End Site is there to show that there can be an infinite number of end users in between.

- The proposal should update ripe-592 section 5.6.2, bullet 2. This makes a reference to the IPv6 IXP document which this proposal retires, as I understand it. So in order to avoid this reference not pointing anywhere useful, the the original definition into ripe-592 (I believe this would be the PDO's preference), or to update the reference to point to the proposed unified IPv6 document.

hum, right.. I did not know that in the IPv4 policy there is a reference to the IPv6 assignments made to IXPs :) Do we need to change the IPv4 policy if this policy proposal is accepted?

- I find the precise definition of the term "End User" to be hollowed out to some extent. In the proposed model, the 1st level End User is for all practical purposes operating as an LIR - the only significant difference seems to be related to which organisation it needs to pay for the privilege (i.e. the RIPE NCC or the Sponsoring LIR). To me the implied meaning of "End User" is the "final" recipient, i.e., someone who is actually *using* the addresses, while a 1st level End User certainly meets the definition of IR in section 2.1. I would therefore consider instead calling this role a "Sponsored LIR" or something along those lines.

Well, any end-user will become some sort of an IR. I had the intent to define an other IR (lower than the LIR) but the consent amongst us, the proposers, was that this would complicate too much the proposal.

- In a similar vein, the LIRs have some NCC-provided tools at their disposal, such as for example the LIR Portal, which is the only place where at least some information can be updated. RPKI is another. Has it been thought whether the "Sponsored LIRs" will be given direct access to these tools, or if their resources will appear in the interface of the Sponsoring LIR, who will have the responsibility to maintain this information on their behalf (which would be an increased responsibility compared to sponsored PI), or something else such as LIR Portal access being one of the incentives for becoming a "proper" LIR?

This would be out of scope for this proposal, I think 2013-04 touches this service. The RIPE Database objects for current v6PI assignments can be changed by the maintainer, RPKI may be available after 2013-04 is approved. The only thing that I did not think of, and just realised now, is that if an End User needs to make more than a /48 sub-allocation, it will need to request an approval from the RIPE NCC. I am not sure how this approval can be recorded by the RIPE NCC, the Sponsoring LIR and the End User. This will probably be touched by the RIPE NCC in their Impact Analysis.

- When it comes to the counterpoint regarding taking away the incentive to become "proper" LIRs. Well - it's been possible to run consumer-based ISPs on IPv4 PI for quite a while, yet the NCC is failing to turn a deficit even though it allegedly is trying, so I'm not terribly concerned. :-) More seriously though, I don't think this is likely to be much of a problem before the same "Sponsored LIR" concept is backported to IPv4, and not necessarily then either.

I don't think this proposal will cause any problems either. But I've heard this argument so many times, we had to put it in the rationale. cheers, elvis

I support the general idea of this proposal. Med vänlig hälsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Besöksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se Den 2013-09-27 12:25 skrev Tero Toikkanen <Tero.Toikkanen@nebula.fi>:

Dear all,

In general I support the direction of this proposal.

I have already mentioned some of my observations on other ongoing conversations, but here are a couple more:

5.2.3 "results in a doubling of the address space allocated to it" With larger blocks this seems a bit drastic to me. I.e. if a large corporation needs a new /32, but already has 4 of them, they will automagically get 4 /32s more. I assume this is to enable aggregation, but without making large reservations in the address pool for each End User, it probably wouldn't work for that purpose. In order to assess how reasonable this clause is, we would need to know how addresses are allocated and from where. I my opinion aggregation = good, large reservations for every single End User with a /32 = bad.

5.3.1 "When more than a /48 is to be sub-allocated to the same customer, the LIR or the End User (via the Sponsoring LIR) must request an approval from the RIPE NCC." This is a bit vague wording, which would probably be better by just removing the parentheses. I assume the idea is that the End User submits the request to the Sponsoring LIR, which then hands it over to RIPE NCC?

____________________________________ Tero Toikkanen Nebula Oy