On 21 October 2016 at 12:55, Maximilian Wilhelm <max@rfc2324.org> wrote:

Anno domini 2016 David Croft scripsit:

...

I note that the "New policy text" does not specify the replacement text for the "Contractual Requirements"

That doesn't seem neccessary as the point in question - the definiton of a sub-assignment - is specified in the new version of ripe-655.

What are you missing?

It appears in the "Current policy text" section, which implied that it was going to be changed in the "New policy text" section, but I guess it's just there for context then. David -- David Croft For support enquiries please always contact support at sargasso.net and not any named individual. UK: 0845 034 5020 USA: 212-400-1694 Sargasso Networks Ltd. Registered in England and Wales No. 06404839. Registered Office: 46a Albert Road North, Reigate, Surrey, RH2 9EL http://www.sargasso.net/

+1 Richard Sent by mobile; excuse my brevity.

Anno domini 2016 Kai 'wusel' Siering scripsit: Hi Kai,

am 21.10.2016 um 10:32 schrieb David Croft:

...

Strong support in principle. We have been denied IPv6 temporary assignments due to the NCC's interpretation that a single DHCP lease on wifi is a "subassignment" to another entity, which was clearly not the intention.

I'm new to this, so please bear with my simple-mindedness here, but to me it looks like »the NCC's interpretation that a single DHCP lease on wifi is a "subassignment" to another entity« iswhat should be addressed, instead of special-caseing something intoan already complex policy document.

Reading through ripe-655 multiple times, I can't find a basisfor counting an temporal, RA/DHCP-based, lease of PI space by an organisation holding Provider Independent Resources as a sub- assignment of a/128 prefix. [...] An »assignment« therefore is something that – to prevent the word »assign« here – dedicates an address space to someone for a specifc purpose and this act needs to be registered (see 5, and esp. 5.5) in an RIR database. But PI assignments cannot be assigned further, as clearly stated.

Operating a WiFi network for employees, relatives, event-visitors or even the general public (i. e. open WiFi, no WPA2) as an End User of Provider Independent Resources does not constitute an »assignment«, neither in terms of ripe-655 nor in real life.

As far as I understand the process, this WG suggests the policies which the NCC implements? So, unless there was a previous call from this WG to the NCC to interpret things as it is reportedly done – which, from the comment, wasn't the case? –, why not just vote on a statement that NCC's interpretation is outside of the scope or intention of ripe-655?

There is no such thing as a "vote on a statement hat NCC's interpretation is outside of the scope". See below.

I mean, it's not the policy that's at fault here; there exists an _interpretation_, used by the RIPE NCC during evaluation of PI space requests, which at least to me is not even remotely covered by ripe-655. Don't mess with what's not broken, fix what is broken ;)

As previously discussed via IRC the means of the community to "tell the RIPE NCC how to interpret things and do it's job" are the RIPE policies, such as ripe-655. Obviously the current policy is "broken" - to use your wording - as there have been multiple interpretations within the NCC. The proposed policy change tries to close this room for interpretation by defining "an interpretaton" for the point in question following the Policy Development Process. See https://www.ripe.net/participate/policies for details about this. Best Max

Although I see the intent of the policy, the question that I have is : If a PI space holder is offering free wifi .. they are offering an access service for other to be used in their building or realm ... that qualifies as their infrastructure ... The users of the service, are not making any claims that they require a specific (set of) number assigned ... the user isn't moving into a contractual ( subscription ) agreement for it .. if we are under the current policy disallowing people using the usage of wifi, it would be similar to disallowing people coffee from the network connected coffee machine.. or not allowing guests walking through a hall with CTV camera's with PI IPv6... especially if they can see what the camera's are capturing on a screen ... /brrrr. ;-) An assignment by policy, is setting aside a dedicated set of number(s) to be used by a party. The current PI IPv6 policy does not allow further sub-assignments to third parties. And using the IP space isn't the same as getting an (sub-) assignment from that prefix.. Going into that kind of thinking would be similar to not allowing external voice calls to IPv6 PI assigned phones, because some third party should be able to make use of it.. This discussion is different if we are actually (commercially) hosting services on a (semi)permanent basis on the PI assigned space... like if a third party is actually offering webservice hosting or voip services over that WIFI .. But if the wifi is for regular public wifi access, to allow guests that roam in a public environment on an ad-hoc basis ... it falls perfectly under the current policy imho. That this might be open for interpertation, doesn't directly mean that the current policy is flawed. I know from working with the NCC, that some of the IPRA's haven't been around since this particular policy was discussed and some might have different views .. So it is good that these particular corner cases are re-discussed from time to time imho.. And I would also like to ask the NCC before we try to implement this into a change, how the NCC would see this and how the IPRA's are instructed currently on this, on how to evaluate this. ( before the formal IA further in the PDP ) Regards, Erik Bais

Op 22 okt. 2016 om 11:17 heeft William Waites <ww@hubs.net.uk> het volgende geschreven:

...

A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" is now available for discussion.

I support this proposal as well. The current interpretation of the policy seems pathological to be honest. It could be supposed that given the Freifunk precedent, a local government (for example) would not be able to get a PI assignment because they provide complimentary Wifi in their lobby. I find it hard to believe that the original policy could have been intended to be read like this and indeed am a little surprised that the NCC has taken such an interpretation. So there is clearly a bug in the policy and this patch appears to fix it.

Best wishes, -w

-- William Waites Network Engineer HUBS AS60241

Hi Erik,

Going into that kind of thinking would be similar to not allowing external voice calls to IPv6 PI assigned phones, because some third party should be able to make use of it..

This discussion is different if we are actually (commercially) hosting services on a (semi)permanent basis on the PI assigned space... like if a third party is actually offering webservice hosting or voip services over that WIFI ..

And there is where it gets complicated :) A bit of history: The IPv4 policy had the text "IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure." This "loophole" made it possible for IPv4 service providers to connect users to their network without making a separate assignment. Originally the idea was that the interconnect wasn't an assignment but the address space routed over that interconnect was. Cases where a single 3rd party server was connected were also not considered assignments because of this rule. Then IPv4 NAT came along, and most residential ISPs started to not assign addresses to customers at all anymore: they only got the interconnect and were expected to NAT using the interconnect's address. That made it possible for ISPs to run their ISP completely on PI addresses. The IPv6 policy then closed the loophole for (IIRC) two reasons: - it was considered unfair that some ISPs used cheap PI addresses while others paid for running the NCC (this included hosters using PI space as well as access ISPs) - the fear that allowing interconnects on cheap PI space would encourage ISPs to force their users to use NAT on IPv6 This of course forced all ISPs to use PA space, but situations where the "ISP" vs "End user" boundary wasn't the classical one had problems. This was discussed on RIPE62 (https://ripe62.ripe.net/presentations/209-apwg.pdf starting at slide 9, it took me a lot of effort trying to find that one, I couldn't imagine it already being 5 years ago) and because of that an effort was started to stop distributing different "colours" of address space and unify PA and PI. Unfortunately that effort failed because it turned out to cause too many complications (see https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_...), which is why we are at the current policy and interpretation as presented 5 years ago:

- No DSL - No Cable - VPN - No co-location - No virtual servers - No SSL hosting

No buts and no exceptions

And that's where we are today, and what this policy proposal is trying to change. Cheers, Sander

Hello Kai,

Sander, thanks for the historical context.

It explains this statement from the proposal: »Today, organisation networks usually include some kind of guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to customers’ sites, or anything similar where devices of non-members of the organisation would get assigned an IP out of the organisation’s prefix. Strictly following the current RIPE policy regarding eligibility for IPv6 PI space, organisations aren't allowed to be provided with PI space when this is the case.«

But there's nothing about that in ripe-655:»To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region” [reference goes to ripe-637 as of this writing].«

Thus, there seems to be a policy, and an interpretation of that policy, the later hidden in some slides?

Now I do agree that the policy needs fixing, as it neither refers nor at least mentions these »interpretations«. By policy's text, if you sign the Independent Assignment Request and Maintenance Agreement with a sponsoring LIR, you are qualified to receive IPv6 PI space, no?

Yes, but the RIPE NCC checks your intended usage to confirm that it doesn't conflict with the policy.

BUT: how would the simple addition of »[w]ithin the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter« will solve the issue that mentioning WiFi in the PI request leads to it's refusal? (Note that »no WiFi« is not even present on above's list.)

There are dozens (maybe hundreds) of ways in which to use address space. Those examples aren't meant to be exclusive. Now, the problem is that we never properly defined what a sub-assignment in this context is. Just based on the language, every case where I tell you to use an address is an assignment. If I were to give you a bit of paper that says "you can use 2001:db8::1" then that is an assignment. I just assigned 2001:db8::1 to you. (Yes, we could get into the discussion that SLAAC isn't technically an assignment in this context but stateful DHCPv6 is, but let's not go there). Basically, under the current policy, based on the English language, letting any 3rd party use your IPv6 PI address space is a violation of the policy.

If above's »interpretation« is still the current one, it misses WiFi, so that should not have led to refusal of PI assignments. If not, where is the current one and how does the APWG influence it – and how does the general public, e. g. an End User looking for PI space to IPv6- number his or her gear once-and-for-all, learn about it?

That were some examples, not a complete list. There is no such list. And 3rd party usage of IPv6 PI addresses is currently not allowed. What this policy tries to define is what sub-assignment, and define it as a /64 or more. So letting 3rd parties connect to your WiFi (which will assign them a couple of addresses) is fine, as is letting someone host a server on your network. But you're not allowed to give them their own /64 or more. If you do that then (under the proposed policy text) you are sub-assigning, which isn't allowed. Basically, what is proposed is: assigning separate addresses is fine, whole subnets is not. One of the things I would like to see discussed here is whether the current text is doing what it is supposed to. Is putting a limit at /64 a good criterium? I could comments like "this encourages people to make non-/64 subnets" etc. On the other hand, say we would instead write in the policy that assigning subnets to 3rd parties isn't allowed no matter which size, would that make /127 point-to-point connections impossible? Speaking as a chair: this issue has been around for a long time, and it keeps coming up. Without us (this WG) giving extra guidance to the RIPE NCC their interpretation of what we mean by "sub-assignment" can only be based on the English language, where assignment without any further qualification/quantification means *any* assignment, even if it's just a single address. So I would like to properly define in policy what we as a working group would like to happen. Cheers, Sander

Hi Sander,

Yes, but the RIPE NCC checks your intended usage to confirm that it doesn't conflict with the policy.

...

BUT: how would the simple addition of »[w]ithin the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter« will solve the issue that mentioning WiFi in the PI request leads to it's refusal? (Note that »no WiFi« is not even present on above's list.) There are dozens (maybe hundreds) of ways in which to use address space. Those examples aren't meant to be exclusive. Now, the problem is that we never properly defined what a sub-assignment in this context is. Just based on the language, every case where I tell you to use an address is an assignment. If I were to give you a bit of paper that says "you can use 2001:db8::1" then that is an assignment. I just assigned 2001:db8::1 to you. (Yes, we could get into the discussion that SLAAC isn't technically an assignment in this context but stateful DHCPv6 is, but let's not go there). Basically, under the current policy, based on the English language, letting any 3rd party use your IPv6 PI address space is a violation of the policy.

I beg to differ, it's not about (interpretation of) English language. The policy defines, what »to assign« means in the context of the policy. Article 2.6. states: »To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.« (Which, btw, means there's no difference between PA and PI here. Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent interpretation. Eeks.) The WiFi is part of my (internet-facing) infrastructure I operate. It needs address space to work as designed, so where do I take that from? My routers, switches and internal systems are numbered from my PI space; do I need non-PI space for my WiFi? (Another /48 for maybe 20 devices?) Anyway, I don't intend to nit-pick here; I would like to understand why things are as they obviously are, although there already are definitions for the terms used. Then, I'd like to get things fixed in a way that looking at the »document [which] defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations« (self-definition of ripe-655) it is clear what can be done with the address space requested and/or received and when the request can/will be denied. Currently, to me it's anything but clear from that document, as hidden rules exist that are neither documented nor mentioned.

And 3rd party usage of IPv6 PI addresses is currently not allowed.

Well, if reading the policy that way, neither is it for non-PI space?

What this policy tries to define is what sub-assignment, and define it as a /64 or more. So letting 3rd parties connect to your WiFi (which will assign them a couple of addresses) is fine, as is letting someone host a server on your network. But you're not allowed to give them their own /64 or more. If you do that then (under the proposed policy text) you are sub-assigning, which isn't allowed.

This is because »assignment« isn't used as defined by the policy, imho. If the proposed change solves the issue that fellow Freifunkas can not get IPv6 PI space, well, +1. But as WiFi is mentioned nowhere, this looks like wishful thinking to me. Let's play it through: The policy change gets approved and implemented, and now a /64 of my IPv6 PI for my WiFi is ok. (And giving a /64 or less to my kids/neighbour/barber is as well?) But, I actually operate two WiFis, one for the general public and one for my family. Thus, I now use a /63 in total, but only a /64 each, for WiFi. Ok, not ok?Ok, as: »Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.« (Actually, it would not be ok, as »/64 or shorter« still prohibts use of /64 for e. g. WiFi. The proposal therefore should read »/63 or shorter« or »shorter than /64«, I think, or SLAAC is not an option anymore.)

Speaking as a chair: this issue has been around for a long time, and it keeps coming up. Without us (this WG) giving extra guidance to the RIPE NCC their interpretation of what we mean by "sub-assignment" can only be based on the English language, where assignment without any further qualification/quantification means *any* assignment, even if it's just a single address. So I would like to properly define in policy what we as a working group would like to happen.

That sums up pretty well my issues with the proposed change (while I still see a clear definition of »assignment« in the policy and wonder why only me understands it as that; is my understanding of the English really that flawed?). Regards, -kai P.S. I don't aim for IPv6 PI for the WiFi part of our Freifunk setup; I'm just tired of renumbering 10+ systems and 20+ tunnels on every change of the upstream used, thus I looked into getting IPv6 PI, which led me here. Renumbering really sucks and I'm currently looking into NPTv6 as the ultimate solution to that; especially, as IPv6 PI obviously comes with too many hidden strings attached. And if it's in place at the egdeanyway, NPTv6 for the WiFi part comes for free. NATs are good, it seems. -- Kai Siering Schalückstraße 107, 33332 Gütersloh eMail: Kai.Siering@uu.org ISN: 98735*1796 × Phone: +49 172 8635608 ---------------------------------------------------------------------- "Getdate firmly believes that years after 1999 do not exist; getdate will have to be killed by the year 2000." -- From the "Bugs" section of cnews-020592/libc/getdate.3

On 10/22/2016 02:30 PM, Sander Steffann wrote: [...]

You are misunderstanding. We're not talking about what you configure on your Wi-Fi, we're talking about what you delegate to third parties: the users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the proposed policy.

So prefix delegation is OK as long as the prefix is longer than a /64? Regards, Leo Vegoda

HI Sander, Sander Steffann wrote: [...]

...

So prefix delegation is OK as long as the prefix is longer than a /64?

Technically that's what the proposal is currently proposing. I'm curious about the opinions of working group members about that.

Taking no position on the proposal itself, I'd like to draw people's attention to RFC 7421 (Analysis of the 64-bit Boundary in IPv6 Addressing). Section 4.4 deals with Implementation and Deployment Issues and might be a helpful read when considering a proposal that might lead to significant pressure to deploy infrastructures designed to delegate prefixes longer than /64. Kind regards, Leo Vegoda

Moin, just a quick reply as well. Am 22.10.2016 um 23:30 schrieb Sander Steffann:

...

Let's play it through: The policy change gets approved and implemented, and now a /64 of my IPv6 PI for my WiFi is ok. (And giving a /64 or less to my kids/neighbour/barber is as well?) But, I actually operate two WiFis, one for the general public and one for my family. Thus, I now use a /63 in total, but only a /64 each, for WiFi. Ok, not ok?Ok, as: »Within the context of these policies, a sub-assignment is an assignment of a length of /64 or shorter.«

(Actually, it would not be ok, as »/64 or shorter« still prohibts use of /64 for e. g. WiFi. The proposal therefore should read »/63 or shorter« or »shorter than /64«, I think, or SLAAC is not an option anymore.) You are misunderstanding. We're not talking about what you configure on your Wi-Fi, we're talking about what you delegate to third parties: the users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the proposed policy.

Bear with me; I still cannot accept the conflicting-with-policy definition of »delegate« or »assign« in the context of RA or DHCPv6. Proposal states: »As an example, some Freifunk Communities in Germany have been had their PI request declined because some 1-digit-number of subnets would have been used as IPv6 prefixes on public WIFIs. This usage of the IP space in the End User’s infrastructure has been interpreted as a sub-assignment of a /128 prefix. This would have been "assigned" to a user device of the public WIFI network as the device would get an IP address via SLAAC (or any other means for that matter).« So, since anything _above_ /64 (e. g. /65 to /128) would be whitewashed by the proposal, using a whole /48 PA or PI for /64s for WiFis would be ok, as long as each WiFi user only gets less than a /64 »assigned«? Proposal states: »Today, organisation networks usually include some kind of guest networks, (public) WIFI hotspots in their offices, PTP-VPN links to customers’ sites, or anything similar where devices of non-members of the organisation would get assigned an IP out of the organisation’s prefix.« These days I configure P2P links as /64 (with ::1 and ::2 being the endpoints), because ... people actually tried to hit me with cluebats when I carried over IPv4-behaviour of /32 or /31 links into IPv6 (/127). So, even after this proposal, I am not allowed to use my IPv6 PA or PI space to build P2P-links outside my organisation, e. g. for peering, with a netmask of /64? But at least anything above /64 (read: /127) in PI would be ok, which currently isn't, neither for PA nor PI? Regards, -kai

On Sat, Oct 22, 2016, at 23:30, Sander Steffann wrote:

...

(Actually, it would not be ok, as »/64 or shorter« still prohibts use of /64 for e. g. WiFi. The proposal therefore should read »/63 or shorter« or »shorter than /64«, I think, or SLAAC is not an option anymore.)

You are misunderstanding. We're not talking about what you configure on your Wi-Fi, we're talking about what you delegate to third parties: the users of the Wi-Fi. Unless you assign a whole /64 to a single Wi-Fi user it's within the proposed policy.

... and this is where technical implementation comes and messes things up.... If you are functioning in "subscriber management" mode, you equipment may impose you that each subscriber has its own subnet for interconnection (mine does) - obvious choice being a /64. But being in "subscriber management" mode may not be the case for somebody offering wifi on a non-commercial basis, but if it still is, you may always try to use "longer than /64" (??? /128 ???) subnet per device. I haven't tried to see if "longer than /64" works with my equipment, since for me it's a non problem (I do assignments from PAs). -- Radu-Adrian FEURDEAN

Hi Kai, * Kai 'wusel' Siering

(Which, btw, means there's no difference between PA and PI here. Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent interpretation. Eeks.)

[...]

...

And 3rd party usage of IPv6 PI addresses is currently not allowed.

Well, if reading the policy that way, neither is it for non-PI space?

I think you're right. An assignment is an assignment. If the policy currently disallows using assignments (PI or PA) for things like wireless networks for guests, then I'd say that 2016-04 doesn't go far enough. Tore

This is also my interpertation... If you use DHCP of any kind on the network to randomly provide a number for a device to connect to the network on a temp lease, it isn't an assignment to the letter of the policy. That is also not how the intent of the policy was written. If you assign a number or subnet to a specific device and that is fixed in the configuration, so the next time you connect, you will get the same number/subnet, you can see that as an assignment. Especially if that is part of a contractual agreement / service / subscription. Most users/devices are looking for a single digit number, not a subnet for their connectivity need. The difference between the two is in the duration and the expectation. Most roaming wifi users won't be asking for a complete subnet or prefix on their laptop or hosting services / third party apps on a wifi link ... Most wifi users just want to avoid telco charges while listening to spotify, skype or watch youtube/twitch/netflix while in a waiting room .. or do some whatsapp while in a wiating room of their healthcare provider.. these are not permanent roamers lurkers to avoid RIPE charges or trying to scam their infra behind some public provided wifi connection. If the specific wifi/network implementation required to use a /64 or smaller per connecting device/user, for security reasons for instance, it would still be the same if those prefixes would be selected dynamically. If the situation is as stated above, the usage should be perfectly within the current policy. Regards, Erik Bais

Op 23 okt. 2016 om 10:11 heeft JORDI PALET MARTINEZ <jordi.palet@consulintel.es> het volgende geschreven:

If I’ve a PI for my company … and I offer WiFi for the laptops or phones of my employees, and their families and customers when they come to my office … are those assignments? Clearly they are “others”, not the same organization that got the PI.

That’s why I think we need to consider that assignment is for infrastructure, not end devices, at least this seems to be my reading of the definition.

Saludos, Jordi

-----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Tore Anderson <tore@fud.no> Responder a: <tore@fud.no> Fecha: domingo, 23 de octubre de 2016, 10:06 Para: Kai 'wusel' Siering <wusel+ml@uu.org> CC: "address-policy-wg@ripe.net Working Group" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)

Hi Kai,

* Kai 'wusel' Siering

...

(Which, btw, means there's no difference between PA and PI here. Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent interpretation. Eeks.)

[...]

...

...

And 3rd party usage of IPv6 PI addresses is currently not allowed.

Well, if reading the policy that way, neither is it for non-PI space?

I think you're right. An assignment is an assignment.

If the policy currently disallows using assignments (PI or PA) for things like wireless networks for guests, then I'd say that 2016-04 doesn't go far enough.

Tore

********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

Hi, am 16.11.2016 um 15:29 schrieb Ondřej Caletka:

Dne 23.10.2016 v 10:06 Tore Anderson napsal(a):

...

Hi Kai,

* Kai 'wusel' Siering

...

...

(Which, btw, means there's no difference between PA and PI here. Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent interpretation. Eeks.)

[...]

...

...

And 3rd party usage of IPv6 PI addresses is currently not allowed. Well, if reading the policy that way, neither is it for non-PI space? I think you're right. An assignment is an assignment.

If the policy currently disallows using assignments (PI or PA) for things like wireless networks for guests, then I'd say that 2016-04 doesn't go far enough. +1

My opinion is that 2016-04 goes completely wrong way because it makes the exception "longer than /64 is not an assignment" valid only for PI, not for PA addresses.

So if we agree that any device getting an address is getting an assignment, which has to be registered properly in the database, this problem is same for PI and PA addresses.

[…] And this is not only about Wi-Fi networks. All the VPS providers I know have just one block assigned to themselves from which they delegate one or more IP address per customer-controlled VPS.

I think it would be better to clarify the 2.6 section of ripe-655 to explicitly state what is not an assignment. Using a prefix length of "longer than /64" seem to be a good criteria, although it makes me little bit scared of possibly wrong interpretation by some non-LIR ISPs who would start delegating very long prefixes to avoid the need of becoming LIR.

I don't agree on "any device getting an address is getting an assignment" in the first place. Let's refer to ripe-655's definition:

2.6. Assign

To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.

From my point of view, the sentence is really clear already, and shouln'tbe able to be interpreted in the way it currently seems to be ;) An assignment is a bureaucratic act, executed by an organisation (IR) in favor of another organisation (non-IR). An assignment is considered to exist for a prolonged duration and as such to be documentedin the RIPE Database. Nothing of that happens when mechanisms like SLAAC or DHCPv6 suggest, to a requesting device, which IPv6 Prefix is being used/which IPv6 address itshould use. So, what “are not to be sub-assigned to other parties” (2.6) and especially“cannot be further assigned to other organisations” (7) are trying toprevent in the first place? Sander gave the context:

[…] Then IPv4 NAT came along, and most residential ISPs started to not assign addresses to customers at all anymore: they only got the interconnect and were expected to NAT using the interconnect's address. That made it possible for ISPs to run their ISP completely on PI addresses. The IPv6 policy then closed the loophole for (IIRC) two reasons: - it was considered unfair that some ISPs used cheap PI addresses while others paid for running the NCC (this included hosters using PI space as well as access ISPs) - the fear that allowing interconnects on cheap PI space would encourage ISPs to force their users to use NAT on IPv6

This of course forced all ISPs to use PA space, but situations where the "ISP" vs "End user" boundary wasn't the classical one had problems. This was discussed on RIPE62 (https://ripe62.ripe.net/presentations/209-apwg.pdf starting at slide 9, it took me a lot of effort trying to find that one, I couldn't imagine it already being 5 years ago) and because of that an effort was started to stop distributing different "colours" of address space and unify PA and PI.

Unfortunately that effort failed because it turned out to cause too many complications (see https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_...), which is why we are at the current policy and interpretation as presented 5 years ago:

...

- No DSL - No Cable - VPN - No co-location - No virtual servers - No SSL hosting

No buts and no exceptions

And that's where we are today, and what this policy proposal is trying to change.

If above reflects the (agreed on?) “current policy and interpretation”, as ripe-655 _is_ the document that specifies the “IPv6 Address Allocation and Assignment Policy”, it must be added there in a proper and consistent way in the first place.(Althoughnot being allowed to use IPv6 PI inhouse for virtual servers would be ridiculous at best: Green IT? Only over RIPE's dead body.) I really think the whole of ripe-655 should be reworked, especially as the published policy and the ‘lived’ interpretation are totally out of sync. “To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled ‘Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region’” means: anyone who is willing to sign the funny document with an LIR is eligible to receive IPv6 PI space, period. This, obviously, is in clear contrast to RIPE NCC's execution of ripe-655 and in contrast of the goals stated: “In IPv6 address policy, the goal of aggregation is considered to be the most important.” Oddly enough, RIPE NCC would rather assign PI in 3x /48 instead of /47 + /48 or, pragmatically, an /46 (with e. g. the fourth /48 put in an allocated state “for future use” or whatever). To put it all in a nutshell, thingsareseverely out of sync here. On the other hand: hasn't reality already overtaken policy already? Considering [1], this shouln't have worked?

wusel@ysabell:~$ sudo traceroute -A -T -6 space.net traceroute to space.net (2001:608:2:88::1), 30 hops max, 80 byte packets 1 gw-gt.uu.org (2a07:a907:50c:1000:219:99ff:fe5b:cc93) [AS206946] 6.072 ms 6.073 ms 9.125 ms […] 8 www.space.net (2001:608:2:88::1) [AS5539] 68.685 ms 66.751 ms 66.750 ms

I'm using a /48 PA I 'purchased' from an UK LIR and ‘GRE-tunnel’ it home. There's no connection routing-wise between me and the LIR (um, well, I do announce my /48 from a VM there over their upstream, but there's nearly ever any traffic coming in), but getting it announced to the right upstreams (HE, NTT), things ‘just worked’. Curiosity took over, so ... Well, the same applies to a /47 APNIC-PA:

root@gw-gt:~# traceroute -A -T -6 facebook.com -s 2402:9e80:21:1::1 traceroute to facebook.com (2a03:2880:f100:83:face:b00c:0:25de), 30 hops max, 80 byte packets 1 de3-gut1.as206946.net (2a07:a907:50c:f700::1) [AS206946] 30.946 ms 30.898 ms 31.433 ms […] 15 edge-star-mini6-shv-01-mia1.facebook.com (2a03:2880:f100:83:face:b00c:0:25de) [AS32934] 151.048 ms 150.789 ms 148.580 ms

IPv6 PA seems to be pay-as-you-go already. As you need to pay for v6 PI as well (actually more than for v6 PA, at least in my case), what's the point of IPv6 PI anyway? (Don't get me wrong, I'm a happy camper with my personal stuff on v4 ERX/PI, never needed to touch my setup, regardless of what ISP was used for the upstream connectivity, in the last 20 years. I wanted the same for v6, but as PA was much more easy to get, I started playing with that.) To sum things up: - Policy actually encourages people to ask for PI space - NCC is not really acting by policy letters - PA is freely routable these days As an related topic,who is actually enforcing “5.5 Registration“? Out of 2003::/19, at least 2003:c9:cb00::/48 is heavily used (with /64s and /56s assigned to the same end user for 14+ days), but there's no assignment at all in the RIPE DB. Obviously LIRs have a card blance ignoring ripe-655 post-allocation :-( Or is the RIPE NCC so busy scrutinizing PI requests that they don't have time to check on LIRs behaviour? Something is really wierd here. Regards, -kai [1] https://www.space.net/~gert/RIPE/ipv6-filters.html