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