Feedback from RIPE NCC Registration Services. Alex Le Heux - RIPE NCC RIPE62, May 2011, Amsterdam

Size: px

Start display at page:

Download "Feedback from RIPE NCC Registration Services. Alex Le Heux - RIPE NCC RIPE62, May 2011, Amsterdam"

Arthur O’Connor’
5 years ago
Views:

1 Feedback from RIPE NCC Registration Services Alex Le Heux - RIPE NCC RIPE62, May 2011, Amsterdam

2 Outline ASN32 success, a competitive disadvantage? Last /8 implementation detail Upgrade of /32 IPv6 allocations IPv6 PI sore points and background information 2

3 ASN32 Update byte 2-btye 3

4 ASN32 Update 4-byte ASN Assignments 86% 3% 8% 1% 2% APNIC ARIN RIPENCC LACNIC AFRINIC 4

5 ASN32 Update RIPE NCC ASN32 Assignments Visible in BGP 52% Not visble 23% Returned 25% 5

6 Competitive disadvantage?

7 Last /8 implementation Last /8 implementation: Address space returned to the RIPE NCC after the last /8 policy comes into effect will be treated the same way as the last /8. 7

8 Upgrade of /32 allocations First IPv6 allocation on file: August 12, 1999 Detailed deployment plans were rare in those days Years later, some holders of /32s realise they actually have a few million customers Solution: Return the /32 & re-evaluate 8

9 IPv6 PI Sore points and background information

10 Report on Registration Services experience with the current policy Provide some background information and numbers relevant to the current IPv6 PI discussion 10

11 Current IPv4 PI policy: PI space cannot be re-assigned or further assigned to other parties. IP addresses used solely for the connection of an End User to a service provider [...] are considered part of the service provider's infrastructure. 11

12 Current IPv6 policy: Assignments [...] are not to be sub-assigned to other parties. 12

13 No DSL No Cable VPN No co-location No virtual servers No SSL hosting No buts and no exceptions 13

14 Sore points: Thousands of current IPv4 PI space holders see no way to deploy IPv6 Hard to explain why we can assign IPv4 but not IPv6 Blurred distinction between ISP and end-user 14

15 In the past, when ISPs were real ISPs and endusers were real end-users... The world was probably a simpler place ISP PI Customer 15

16 In the past, when ISPs were real ISPs and endusers were real end-users... The world was probably a simpler place ISP PI Customer 16

17 17

18 MPLS 18

19 MPLS 19

20 MPLS 20

21 Application Service Provider Writes software for clients Then hosts the application as well Sets up a completely independent infrastructure for each client End-site? ISP? 21

22 The sharp distinction between end-user and ISP is gone Old-school end-users still exist, of course But more and more complex services are built on top of other complex services built on top of... 22

23 The complexity of deciding if something is an ISP or an end-user has increased If it even makes sense to make the distinction at all, in some cases This is hard to do in a fair and consistent manner 23

24 Background information 24

25 IPv4 PI Usage Access 36% End-site 33% Hosting & Access 6% Hosting 25% 25

26 300 IPv4 vs IPv6 PI Requests / month IPv4 PI IPv6 PI 26

27 Look at the IPv4 routing table to see what might happen with IPv6 RIR delegated stats files Anything assigned or allocated before 1996 considered legacy RIS A prefix considered in the DFZ if seen by at least 10 RIS peers 27

28 Global IPv4 BGP prefixes allocated 35% legacy 43% assigned 22% 28

29 RIPE NCC Service region IPv4 BGP prefixes LIR allocations 70% PI assignments 21% Legacy 10% 29

30 Summary, RIPE NCC service region: Number given out BGP entries in DFZ Ratio ALLOCATED ASSIGNED

31 Questions?

RIPE Address Policy Working Group

RIPE 62, Amsterdam 1 RIPE Address Policy Working Group May 5, 2011 RIPE 62, Amsterdam WG Chairs: Gert Döring, & Sander Steffann please remember: this session is webcast Agenda APWG overall Agenda A. administrative