<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><br>
</tt><tt><br>
</tt><tt>am 16.11.2016 um 15:29 schrieb Ondřej Caletka:</tt><tt><br>
</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><br>
</tt><tt>I don't agree on "</tt><tt>any device getting an address is
getting an
</tt><tt>assignment"</tt><tt><br>
</tt><tt>in the first place. Let's refer to ripe-655's definition:</tt><tt><br>
</tt><tt><br>
</tt>
<blockquote type="cite"><tt>2.6. Assign</tt><tt><br>
</tt> <tt><br>
</tt><tt>
To “assign” means to delegate address space to an ISP or End
User for</tt><tt><br>
</tt><tt>specific use within the Internet infrastructure they
operate.</tt><tt><br>
</tt><tt>Assignments must only be made for specific purposes
documented by specific</tt><tt><br>
</tt><tt>organisations and are not to be sub-assigned to other
parties.</tt></blockquote>
<tt><br>
</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><br>
</tt><tt><br>
</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><br>
</tt><tt><br>
</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><br>
</tt><tt><br>
</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><br>
</tt><tt><br>
</tt><tt>Sander gave the context:</tt><tt><br>
</tt>
<blockquote type="cite"><tt>[…]</tt><tt><br>
</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><br>
</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><br>
</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><br>
</tt> <tt><br>
</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><br>
</tt> <tt><br>
</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><br>
</tt> <tt><br>
</tt><tt>
> - No DSL</tt><tt><br>
</tt><tt>
> - No Cable</tt><tt><br>
</tt><tt>
> - VPN</tt><tt><br>
</tt><tt>
> - No co-location</tt><tt><br>
</tt><tt>
> - No virtual servers</tt><tt><br>
</tt><tt>
> - No SSL hosting</tt><tt><br>
</tt><tt>
></tt><tt><br>
</tt><tt>
> No buts and no exceptions</tt><tt><br>
</tt> <tt><br>
</tt><tt>
And that's where we are today, and what this policy proposal is
trying to change.</tt></blockquote>
<tt><br>
</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><br>
</tt><tt><br>
</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><br>
</tt><tt><br>
</tt><tt>On the other hand: hasn't reality already overtaken policy
already? Considering [1], this shouln't have worked?<br>
<br>
</tt><tt></tt>
<blockquote type="cite"><tt>wusel@ysabell:~$ sudo traceroute -A -T
-6 space.net</tt><tt><br>
</tt><tt>
traceroute to space.net (2001:608:2:88::1), 30 hops max, 80 byte
packets</tt><tt><br>
</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><br>
</tt><tt>
[…]</tt><tt><br>
</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><br>
</tt>
</blockquote>
<tt><br>
</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><br>
</tt><tt><br>
</tt>
<blockquote type="cite"><tt> root@gw-gt:~# traceroute -A -T -6
facebook.com -s 2402:9e80:21:1::1</tt><tt><br>
</tt><tt>
traceroute to facebook.com (2a03:2880:f100:83:face:b00c:0:25de),
30 hops max, 80 byte packets</tt><tt><br>
</tt><tt>
1 de3-gut1.as206946.net (2a07:a907:50c:f700::1) [AS206946]
30.946 ms 30.898 ms 31.433 ms</tt><tt><br>
</tt><tt>
[…]</tt><tt><br>
</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><br>
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><br>
</tt><tt><br>
To sum things up:<br>
<br>
- Policy actually encourages people to ask for PI space<br>
</tt><tt> - NCC is not really acting by policy letters<br>
- PA is freely routable these days<br>
<br>
</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><br>
</tt><tt><br>
</tt><tt>Regards,</tt><tt><br>
</tt><tt>-kai</tt><tt><br>
</tt><tt><br>
</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><span
class="limited"></span></tt>
</body>
</html>