“How to Run a Local Internet Registry” or all your IPs are belong to us!

1. “How to Run aLocal Internet Registry”orall your IPs are belong to us! RIPE Network Coordination Centre <BECHA@ripe.net>

2. Objectives • to make participants familiar with terminology of Internet resources distribution • to broadly/quickly describe procedures and policies • to point to references (documents, tools…) • Assumption about audience • clients of existing Local Internet Registries • will soon be employed by a Registry • will want to establish LIR themselves • Scope • mostly administrative • no technical details about running an ISP • ALWAYS ASK QUESTIONS!

3. Schedule • RIPE & RIPE NCC • IP Address Space Distribution • obtaining the Address Space through the existing LIR • Being an LIR • setting up an LIR • requesting assignment approval • how to manage your allocation • Additional Policies and Procedures • assignment window & evaluation • additional allocation • Provider Independent address space • Reverse DNS • AS Numbers and Routing Registry • IPv6 • Next: RIPE whois Database

4. Introduction toRIPE and RIPE NCC • Réseaux IP Européens (1989) • RIPE is a collaborative organisation open to all parties interested in Internet administration, development and operations of IP networks • RIPE Network Co-ordination Centre • membership organisation which supports its members and RIPE community • one of 3 Regional Internet Registries (RIR)

5. How RIPE Works • RIPE works as • open forum • voluntary participation • decisions made by consensus • meetings • working groups mailing lists • <majordomo@ripe.net> • web archived • not a legal entity • does NOT develop Internet Standards • RIPE chair <chair@ripe.net>

6. Join RIPE Working Groups • Local Internet Registries (LIR) • join the open process of making address space policies! • RIPE Database (DB) • IP version 6 (IPv6) • European Internet Exchange Forum (EIX) • Routing / MBONE • Domain Name System (DNS) • NETNEWS Co-ordination • Anti-Spam • European Operators Forum (EOF) • Tools (new) • Technical security (new)

7. RIPE Meetings • 3 times a year • RIPE 40, Prague, Czech Republic, 1-5 Oct. 2001 • 4 to 5 day long • 300+ participants • Working group meetings • Plenary • Long breaks / social events • Connectivity (IPv4, IPv6, wireless) • <meeting@ripe.net>

8. Why a NCC? • RIPE participation was increasing • Too much RIPE work to be done on a voluntary basis • Activities require continuity and co-ordination • Neutrality and impartiality are needed • Contact point inside and outside RIPE region • From ’92 till ’98 part of TERENA • In ’98 registered as not-for-profit association • Since ’95 funded by contributing members

9. Vital Statistics • Statistics 1992 • 3 staff members • No Local IRs • 182,528 hosts in European Internet • 7,955 objects in RIPE database (June ‘92) • Statistics Now • 70 staff (23 nationalities) • 2,900+ participating Local IRs • 15,200,000+ countable hosts in the RIPE NCC region • 3,500,000+ objects in the database

10. Formal Decision Making “Consensus” Model RIPE proposes activity plan RIPE NCC proposes budget to accompany activity plan (ripe-213) At Annual General Meeting membership votes on both activities and budget

11. RIPE NCC in Global Context ICANN PSO ASO DNSO At Large IETF, w3c, ETSI, ... RIPE NCC ARIN APNIC RIPE ARIN mtg. APNIC mtg.

12. Service Regions

13. RIPE NCC Services Member Services • Registration Services • IPv4 addresses • IPv6 addresses • AS numbers • LIR Training Courses • Reverse domain delegation • NOT registering domain names • Test Traffic Measurements Public Services • RIPE whois DB maintenance • Routing Registry Maintenance • Co-ordination and liaison • RIPE support • Information dissemination • New Projects • RIS, R2C2, DISI • Maintenance of tools

14. RIPE NCC R&D • Test Traffic Measurements ( www.ripe.net/ttm/ ) • independent measurements of connectivity parameters (delays and routing-vectors) in the Internet. • Routing Information Service ( www.ripe.net/ris/ ) • collect information about BGP routing much like the "looking glass" services, not only in real time but also for user selectable time periods in the past & at different locations around the Internet • DISI ( www.ripe.net/disi/ ) • Deployment of Internet Security Infrastructures • e.g. DNSSEC

15. Questions?

16. IP Address Space Distribution

17. Problems and Solutions • History: • Classfull (A,B,C; fast depletion, routing table growth) • Subnetting • Supernetting • Variable Length Subnet Mask • Classless Inter Domain Routing (‘94) • flexible boundary between network and host part • source and destination address in the prefix format • route aggregation • Hierarchical registry structure • topologically significant address allocation

18. Classless Notation (CIDR) Addresses Prefix Classful Net Mask ... ... ... ... /29 8 255.255.255.248 16 /28 255.255.255.240 32 /27 255.255.255.224 64 /26 255.255.255.192 128 /25 255.255.255.128 256 /24 1 C 255.255.255.0 ... ... ... ... 4096 /20 16 C’s 255.255.240.0 8192 /19 32 C’s 255.255.224 16384 /18 64 C’s 255.255.192 32768 /17 128 C’s 255.255.128 65536 /16 1 B 255.255.0.0 ... ... ... ...

19. Global Authority LIR (ISP/Enterprise) /20 + RIPE NCC Members Global Registries Structure RIR /8 /32 + ISP / End Users Anybody with a network / host

20. Goals of the Registry Structure • Fairness • Conservation • Aggregation • Registration

21. Terminology / Jargon • Local Internet Registry (LIR) • organisation which assigns address space to end-users • member of RIPE NCC, receives membership services • Allocation • address space given to registries which is held by LIRs to assign to customers or LIR’s own organisation • Assignment • address space given to end-users for use in operational networks

22. Even More Terminology • Assignment Window • maximum amount of address space an LIR can assign to each of its customers (and itself) per 12 months • initially set to 0 (ZERO) • LIR needs to REQUEST approval from RIPE NCC for any assignment • Policies and procedures • ripe-185 for IPv4 space • ripe-196 for IPv6 space • rfc-2050 for global policies • all of them being in the process of re-writing!

23. … Address Space • Provider Aggregatable ... • good for routing tables • customer must renumber if changing ISP/LIR • Provider Independent ... • customer takes addresses when changing ISP/LIR • possible routing problems (ripe-222) • Private ... • rfc-1918 (10/8, 172.16/12, 192.168/16) • Portable ... • PI assignment, PA allocation, IPv6 subTLA • RIPE NCC responsible for the reverse DNS delegation

24. Terms Illustrated IANA / ICANN RIPE NCC PI assignment Allocating Registry Local IR Enterprise LIR ISP End User Assigning End User

25. Obtaining the Address Space • through the existing LIR

26. PA Assignment Process client LIR Evaluates Request yes (*) Total size of the request plus any other address space assigned within last 12 months (*) request > AW? yes no Approach RIPE NCC RIPE NCC evaluates & approves need 2nd opinion? no LIR Chooses Addresses LIR Updates Local Records inetnum object: netname, size, date LIR Updates RIPE Database

27. Providing Information (1) • Overview of organisation • name and location of the company? • activities? • structure? • does it have subsidiaries and where? • for what part of the company are the addresses requested? • Current Address Space Usage • renumbering and returning? (encouraged!) • Additional Information • deployment plan, purchase receipts • topology map

28. Providing Information (2) • Design of the network • how many physical segments will network consist of? • what is each segment going to be used for? • including equipment used • how many hosts are in each segment? • expectations of growth • Efficient utilisation • 25% immediately, 50% in one year • operational needs; no reservations • Can address space be conserved by using: • different subnet sizes? • avoiding padding between subnets?

29. Real needs Concrete plans 100 10 8 14 24 0 0 14 0 100 16 13 14 50 100 25 14 10 Cumulative, total numbers Example: #[ Addressing Plan Template ]# dynamic dial-up Amsterdam web/mail/ftp servers Amsterdam customers’ servers Amsterdam training room LAN Amsterdam Amsterdam office LAN (*1) dynamic dial-up Utrecht web/mail/ftp servers Utrecht Inet cafe Utrecht training room LAN Utrecht 0.0.0.0 0.0.0.128 0.0.0.160 0.0.0.176 0.0.0.192 0.0.1.0 0.0.1.128 0.0.1.160 0.0.1.176 255.255.255.128 255.255.255.224 255.255.255.240 255.255.255.240 255.255.255.192 255.255.255.128 255.255.255.224 255.255.255.240 255.255.255.240 128 32 16 16 64 128 32 16 16 448 Relative Subnet Mask Size Imm 1yr 2yr Description Prefix 100 12 10 14 35 100 12 14 0 170 297 342 Totals (*1) Office LAN = workstations, router, 2 printers and 1 fileserver

30. Questions?

31. Being an LIR • Setting up an LIR • First Allocation • Requesting Assignment Approval • Managing Allocated Address Space

32. Setting up an LIR • Completed application form • Provided Reg-ID & contact persons • <new-lir@ripe.net> • Read relevant RIPE documents • ripe-185 etc • Signed contract - “Service agreement” • agreed to follow policies and procedures • Paid the sign-up & yearly fee • <billing@ripe.net>

33. Registry Identification (Reg-ID) • Distinguishes between member registries and individuals • Format • <country code> . <registry name> • Include with every message • Suggestion - modify mail header • X-NCC-RegID: nl.bluelight

34. LIR Contact Persons • Stored in RIPE NCC internal (“Reg”) file for each registry • confidential • only registered contact persons can • send requests to hostmasters • change contact information • To keep contact info up-to-date • write to lir-help@ripe.net • for each contact person create person object in the RIPE DB • possible to use role object • “Reg” file not automatically updated from the RIPE Database! • Always sign your e-mail messages • PGP optional (soon)

35. First Allocation • LIR requires a block of IP addresses • send an “assignment request” • no need to justify usage of the whole allocation • do not ask for PI space as first request • soon: criteria for first allocation - /22 already used • With the first ASSIGNMENT approved, RIPE NCC also makes an ALLOCATION (PA) • default minimum size /20 (4096 addresses) • Whole allocated range can be announced immediately

36. Requesting Assignment Approval • If the needed address space is bigger then AW • Separate request forms needed: • for each customer • using more than /30 • for LIR’s own infrastructure • extensions of LIR internal network • combine many clients with up to 4 IPs into one block • e.g. leased lines, dial-up, p2p links, web hosting, server housing • for ISP-client’s infrastructure • for each one of ISP-client’s customers

37. Sending the Request • <hostmaster@ripe.net> • RIPE-219 :http://www.ripe.net/docs/iprequest.html(ex ripe-141) • Web form (example) • filling in the requests & syntax check • http://www.ripe.net/cgi-bin/web141/web141.pl.cgi • source: ftp://ftp.ripe.net/tools/web141.pl.cgi • Frequently asked questions • http://www.ripe.net/ripencc/faq/ • Short tips and tricks • http://www.ripe.net/ripencc/tips/tips.html • All data kept strictly confidential • Documentation has to be in English

38. Approval • Approval message is sent to LIR • size • NOT the address range!!! • “netname” • name of the RIPE DB network object • date • “Assignment is only valid as long as original criteria remain valid” (ripe-185) • Next steps: • choosing the address range within the allocation • registering network object in the RIPE DB

39. Internal Administration • LIR decides on the range of addresses • classless assignment on bit boundary • Update local records for later reference • archive original documents with assignment • Be careful when choosing the size of “internal reservations” • e.g. BL-LAIKA: /24 & /25 & /26 (448) Utrecht Amsterdam /25 Laika Dialup + /25 reserved /26 Laika Infrastructure /25 Laika Dialup + /25 reserved Laika Infrastructure /25 /24 BlueLight Infrastructure /24 BlueLight reserved

40. How to Manage Allocation • Aggregate within allocation • Sensible internal “reservations” • keep free space for some customers to grow • but - might never be claimed • fragments allocated address space => • Divide allocation based on types of services • Divide allocation based on locations • But - LIR can have only one “open” allocation • open = more than 20% unused space

41. Assignments to (Small) ISPs • LIR can notallocate address space to an ISP • If an LIR’s customer is an ISP, distinguish • ISP’s infrastructure • ISP’s customers • Separate assignments need to be • requested • evaluated / approved • registered in the RIPE Database • Avoid overlapping assignments • i.e. “big” assignment/object for ISP & all its customers, plus for separate customers

42. Non-Overlapping Assignments BlueLight’s Allocation right  wrong  Assignment for ISP ENGOS & all its (future) customers 195.35.88/22 Internal Reservations for ENGOS’s customers ENGOS-and-all 195.35.92.8/29 ENGO-cmyk 195.35.92/29 ENGO-rgb 195.35.88/26 Overlapping (second level) assignments for separate customers of ENGOS ... ENGO-infrastr Assignments for separate customers of ENGOS

43. Registering Address Spacein the RIPE Database • Assignment is considered “valid” by RIPE NCC only if (correctly) registered • to provide contact info for troubleshooting • to enable overview of address space used • invalid DB objects influence procedures with: reverse DNS, AW, additional allocations, audit… • All end-user networks need to be registered separately • if bigger then 4 IPs (/29+) • avoid overlapping inetnum objects

44. Additional Policies and Procedures • Assignment Window • evaluation policies • Additional Allocations • PI Assignments

45. Assignment Window Policy • Assignment Window • maximum amount of address space LIR can assign without prior approval of the RIPE NCC • AW is for LIR, and not for person or company • AW is per 12 months per each customer • Why necessary? • support to LIRs during start up • familiarisation with RIPE NCC procedures • align criteria for request evaluation • maintain contact between LIRs and RIPE NCC

46. LIR Responsibilities with the AW • Evaluate all the requests within LIR AW size • based on the ripe-185 policies • Keep the documentation about LIR assignments • useful for administration, and if client comes back • RIPE NCC may ask for it later • Register all the assigned networks in RIPE DB • choosing appropriate netname • Remind the customer’s previous ISP after renumbering • to delete the outdated DB objects

47. Evaluating Client’s Requests • Efficient utilisation • 25% immediately, 50% in one year • No “reservations” • Dynamic addressing solutions preferred over static • Dynamic dial-up is preferred over static • Name-based virtual web hosting is preferred over IP-based • known exceptions are accepted (SSL, ftp&mail servers..) • Special verification methods apply for more then /22 to: • discourage and control wasteful (static) usage • also for xDSL, cable, GPRS… • DHCP recommended to make renumbering easier • Mandatory renumbering and returning of PA space

48. Allocation Policies • ‘Slow Start’ • default minimum first allocation /20 • LIR announces the whole prefix • size of future allocations depends on current usage rate • presumably enough for next two years • not always contiguous • Next allocation when previous used ~ 80% ! • LIR can not have two “open” blocks • Motivation for ‘slow start’ • fair distribution of address space • keeps pace with customer base growth • slows down exhaustion of IPv4 address space

49. PA vs. PI Assignments • Provider Aggregatable • customer uses addresses out of LIR’s allocation • good for routing tables • customer must renumber if changing ISP • Provider Independent • customer receives range of addresses from RIPE NCC • customer takes addresses when changing ISP • possible routing problems (ripe-222) • impossible to get contiguous range in the future • Make contractual agreements (ripe-127) • the only way to distinguish PA and PI space • check with other LIR before accepting clients with PA

50. Questions?