<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Erik,<div class=""><br class=""><blockquote type="cite" class="">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.. <br class=""><br class="">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 .. <br class=""></blockquote><br class="">And there is where it gets complicated :)</div><div class=""><br class=""></div><div class="">A bit of history:</div><div class=""><br class=""></div><div class="">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."</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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: </div><div class="">- 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)</div><div class="">- the fear that allowing interconnects on cheap PI space would encourage ISPs to force their users to use NAT on IPv6</div><div class=""><br class=""></div><div class="">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 (<a href="https://ripe62.ripe.net/presentations/209-apwg.pdf" class="">https://ripe62.ripe.net/presentations/209-apwg.pdf</a> 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.</div><div class=""><br class=""></div><div class="">Unfortunately that effort failed because it turned out to cause too many complications (see <a href="https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf" class="">https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf</a>), which is why we are at the current policy and interpretation as presented 5 years ago:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">- No DSL<br class="">- No Cable<br class="">- VPN<br class="">- No co-location</div><div class="">- No virtual servers</div><div class="">- No SSL hosting<br class=""><br class="">No buts and no exceptions<br class=""></div></blockquote><div class=""><br class=""></div>And that's where we are today, and what this policy proposal is trying to change.<div class=""><br class=""></div><div class="">Cheers,</div><div class="">Sander</div><div class=""><br class=""><div class=""><img alt="page13image3088" width="849" height="3" apple-inline="yes" id="F0B96470-41F9-4C0D-8C44-8818578F92B1" apple-width="yes" apple-height="yes" src="cid:BE03F767-57A1-458C-AFD2-A284C587E527@home" class=""></div></div></body></html>