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

Hi,

am 16.11.2016 um 15:29 schrieb Ondřej Caletka:
> Dne 23.10.2016 v 10:06 Tore Anderson napsal(a):
>> Hi Kai,
>>
>> * Kai 'wusel' Siering
>>
>>>> (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.)
>>>>
>>>> [...]
>>>>>> And 3rd party usage of IPv6 PI addresses is currently not allowed.  
>>>> Well, if reading the policy that way, neither is it for non-PI space?
>> 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.
> +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.

I don't agree on "any device getting an address is getting an assignment"
in the first place. Let's refer to ripe-655's definition:

> 2.6. Assign
>
> To “assign” means to delegate address space to an ISP or End User for
> specific use within the Internet infrastructure they operate.
> Assignments must only be made for specific purposes documented by specific
> organisations and are not to be sub-assigned to other parties.

From my point of view, the sentence is really clear already, and shouln'tbe able to be interpreted in the way it currently seems to be ;)

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 documentedin the RIPE Database.

Nothing of that happens when mechanisms like SLAAC or DHCPv6 suggest, to a requesting device, which IPv6 Prefix is being used/which IPv6 address itshould use.

So, what “are not to be sub-assigned to other parties” (2.6) and especially“cannot be further assigned to other organisations” (7) are trying toprevent in the first place?

Sander gave the context:
> […]
> 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.

If above reflects the (agreed on?) “current policy and interpretation”, as ripe-655 _is_ the document that specifies the “IPv6 Address Allocation and Assignment Policy”, it must be added there in a proper and consistent way in the first place.(Althoughnot being allowed to use IPv6 PI inhouse for virtual servers would be ridiculous at best: Green IT? Only over RIPE's dead body.)

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: “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, thingsareseverely out of sync here.

On the other hand: hasn't reality already overtaken policy already? Considering [1], this shouln't have worked?

> wusel at ysabell:~$ sudo traceroute -A -T -6 space.net
> traceroute to space.net (2001:608:2:88::1), 30 hops max, 80 byte packets
>  1  gw-gt.uu.org (2a07:a907:50c:1000:219:99ff:fe5b:cc93) [AS206946]  6.072 ms  6.073 ms  9.125 ms
> […]
>  8  www.space.net (2001:608:2:88::1) [AS5539]  68.685 ms  66.751 ms  66.750 ms

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:

> root at gw-gt:~# traceroute -A -T -6 facebook.com -s 2402:9e80:21:1::1
> traceroute to facebook.com (2a03:2880:f100:83:face:b00c:0:25de), 30 hops max, 80 byte packets
>  1  de3-gut1.as206946.net (2a07:a907:50c:f700::1) [AS206946]  30.946 ms  30.898 ms  31.433 ms
> […]
> 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

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

To sum things up:

 - Policy actually encourages people to ask for PI space
 - NCC is not really acting by policy letters
 - PA is freely routable these days

As an related topic,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.

Regards,
-kai

[1] https://www.space.net/~gert/RIPE/ipv6-filters.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20161117/e6199c7c/attachment.html>