<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix"><tt>Hi,</tt><tt> </tt><tt> </tt><tt>am 16.11.2016 um 15:29 schrieb Ondřej Caletka:</tt><tt> </tt></div> <blockquote cite="mid:a5805584-85dd-2c0c-981b-37285f90d14e@cesnet.cz" type="cite"> <pre wrap="">Dne 23.10.2016 v 10:06 Tore Anderson napsal(a): </pre> <blockquote type="cite"> <pre wrap="">Hi Kai, * Kai 'wusel' Siering </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">(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.) [...] </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">And 3rd party usage of IPv6 PI addresses is currently not allowed. </pre> </blockquote> </blockquote> <pre wrap=""> Well, if reading the policy that way, neither is it for non-PI space? </pre> </blockquote> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> +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. </pre> </blockquote> <tt> </tt><tt>I don't agree on "</tt><tt>any device getting an address is getting an </tt><tt>assignment"</tt><tt> </tt><tt>in the first place. Let's refer to ripe-655's definition:</tt><tt> </tt><tt> </tt> <blockquote type="cite"><tt>2.6. Assign</tt><tt> </tt> <tt> </tt><tt> To “assign” means to delegate address space to an ISP or End User for</tt><tt> </tt><tt>specific use within the Internet infrastructure they operate.</tt><tt> </tt><tt>Assignments must only be made for specific purposes documented by specific</tt><tt> </tt><tt>organisations and are not to be sub-assigned to other parties.</tt></blockquote> <tt> </tt><tt>From my point of view, the sentence is really clear already, and shouln't</tt><tt> </tt><tt>be able to be interpreted in the way it currently seems to be ;)</tt><tt> </tt><tt> </tt><tt>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 documented</tt><tt> </tt><tt>in the RIPE Database.</tt><tt> </tt><tt> </tt><tt>Nothing of that happens when mechanisms like SLAAC or DHCPv6 suggest, to a requesting device, which IPv6 Prefix is being used/which IPv6 address it</tt><tt> </tt><tt>should use.</tt><tt> </tt><tt> </tt><tt>So, what “</tt><tt>are not to be sub-assigned to other parties</tt><tt>” (2.6) and especially</tt><tt> </tt><tt>“</tt><tt>cannot be further assigned to other organisations” (7) are trying to</tt><tt> </tt><tt>prevent in the first place?</tt><tt> </tt><tt> </tt><tt>Sander gave the context:</tt><tt> </tt> <blockquote type="cite"><tt>[…]</tt><tt> </tt><tt>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:</tt><tt> </tt><tt> - 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)</tt><tt> </tt><tt> - the fear that allowing interconnects on cheap PI space would encourage ISPs to force their users to use NAT on IPv6</tt><tt> </tt> <tt> </tt><tt> 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 class="moz-txt-link-freetext" href="https://ripe62.ripe.net/presentations/209-apwg.pdf">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.</tt><tt> </tt> <tt> </tt><tt> Unfortunately that effort failed because it turned out to cause too many complications (see <a class="moz-txt-link-freetext" href="https://ripe67.ripe.net/presentations/215-20131016_-_PA:PI_Unification_IPv6_Address_Space.pdf">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:</tt><tt> </tt> <tt> </tt><tt> > - No DSL</tt><tt> </tt><tt> > - No Cable</tt><tt> </tt><tt> > - VPN</tt><tt> </tt><tt> > - No co-location</tt><tt> </tt><tt> > - No virtual servers</tt><tt> </tt><tt> > - No SSL hosting</tt><tt> </tt><tt> ></tt><tt> </tt><tt> > No buts and no exceptions</tt><tt> </tt> <tt> </tt><tt> And that's where we are today, and what this policy proposal is trying to change.</tt></blockquote> <tt> </tt><tt>If above reflects the (agreed on?) “</tt><tt>current policy and interpretation</tt><tt>”, as ripe-655 _is_ the </tt><tt>document </tt><tt>that specifies </tt><tt>the </tt><tt>“</tt><tt>IPv6 Address Allocation and Assignment Policy”, it must be added there in a proper and consistent way in the first place.</tt><tt> </tt><tt></tt><tt>(Although</tt><tt> </tt><tt>not being allowed to use IPv6 PI inhouse for virtual servers would be ridiculous at best: Green IT? </tt><tt>O</tt><tt>nly over RIPE's dead body.</tt><tt>)</tt><tt> </tt><tt> </tt><tt>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: “</tt><tt>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, things</tt><tt> are</tt><tt> severely out of sync here.</tt><tt> </tt><tt> </tt><tt>On the other hand: hasn't reality already overtaken policy already? Considering [1], this shouln't have worked? </tt><tt></tt> <blockquote type="cite"><tt>wusel@ysabell:~$ sudo traceroute -A -T -6 space.net</tt><tt> </tt><tt> traceroute to space.net (2001:608:2:88::1), 30 hops max, 80 byte packets</tt><tt> </tt><tt> 1 gw-gt.uu.org (2a07:a907:50c:1000:219:99ff:fe5b:cc93) [AS206946] 6.072 ms 6.073 ms 9.125 ms</tt><tt> </tt><tt> […]</tt><tt> </tt><tt> 8 <a class="moz-txt-link-abbreviated" href="http://www.space.net">www.space.net</a> (2001:608:2:88::1) [AS5539] 68.685 ms 66.751 ms 66.750 ms</tt><tt> </tt> </blockquote> <tt> </tt><tt>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</tt><tt>:</tt><tt> </tt><tt> </tt> <blockquote type="cite"><tt> root@gw-gt:~# traceroute -A -T -6 facebook.com -s 2402:9e80:21:1::1</tt><tt> </tt><tt> traceroute to facebook.com (2a03:2880:f100:83:face:b00c:0:25de), 30 hops max, 80 byte packets</tt><tt> </tt><tt> 1 de3-gut1.as206946.net (2a07:a907:50c:f700::1) [AS206946] 30.946 ms 30.898 ms 31.433 ms</tt><tt> </tt><tt> […]</tt><tt> </tt><tt> 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</tt></blockquote> <tt> </tt><tt> 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.)</tt><tt> </tt><tt> To sum things up: - Policy actually encourages people to ask for PI space </tt><tt> - NCC is not really acting by policy letters - PA is freely routable these days </tt><tt>As an related topic,</tt><tt> 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.</tt><tt> </tt><tt> </tt><tt>Regards,</tt><tt> </tt><tt>-kai</tt><tt> </tt><tt> </tt><tt>[1] </tt><tt><a class="moz-txt-link-freetext" href="https://www.space.net/~gert/RIPE/ipv6-filters.html">https://www.space.net/~gert/RIPE/ipv6-filters.html</a></tt><tt></tt> </body> </html>