[address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)

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

Cheers,
Sander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20161022/f14667b1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: page13image3088.png
Type: image/png
Size: 212 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20161022/f14667b1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/address-policy-wg/attachments/20161022/f14667b1/attachment.sig>