Hi there, am 22.10.2016 um 16:28 schrieb Sander Steffann: > 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.pdfstarting 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_Address_Space.pdf), > 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.
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? 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.) If above's »interpretation« is still the current one, it misses WiFi, so that should not have led to refusal of PI assigments. 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? Regards, -kai -- Kai Siering Schalückstraße 107, 33332 Gütersloh eMail: [email protected] 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
