Welcome to the Local Internet Registry Course

1. Welcome to theLocal Internet Registry Course RIPE Network Co-ordination Centre <training@ripe.net> NEW version for RPSL launch to be ready for 3rd April!!!

2. Logistics • Mobile phones, toilets, fire exits, parking, smoking places ... • Time line • breaks • lunch (vegetarians?) • early departures? • Material • slides • handouts • reference booklet • URLs included • trainers

3. Method and Notations • Flow of the content • material divided into sections • from general to more specific issues • from simple to more complex examples • Notation in slides:  details follow in the rest of the current section * advanced issue; to be clarified later on  find enclosed in handouts • Questions • exchange of experience • useful feedback for improvement

4. Schedule • DB • how to create network object • advanced queries • Assignment Window • 13:00 lunch • Reverse Delegation • AS Numbers • 15:00 tea break • Advanced database issues • updating objects • protecting objects • New allocation • PI Request • IPv6 9:30 Introduction • RIPE & RIPE NCC • Basic RIPE Database • querying DB • creating person/role object • Initial Administrivia • setting up the LIR • terminology • first request • Requesting Address Space • assignment process • completing the request form • communication with hostmasters 11:00 coffee break • Evaluationof requests • policies • administering your allocation

5. Course Background ? • Course objective - to make LIR’s life easier by • explaining how RIPE NCC does it’s job • teaching how LIRs can interact with RIPE NCC • bringing the latest details about policies • listening to comments and input form LIRs • Discovering faces behind e-mail addresses • History and background • given since 1995 • in whole RIPE NCC service region • but in English • paid as a part of startup fee

6. RIPE and RIPE NCC

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

8. Introduction to RIPE

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

10. RIPE Meetings • 3 times a year • RIPE 39, Bologna, Italy, 30 April - 4May 2001 • RIPE 40, Prague, Czech Republic, 1-5 Oct. 2001 • ~4.5 day long • 300+ participants • Working group meetings • Plenary • Presentations • Long breaks • Social events • Terminal room • IPv4, IPv6, wireless connectivity • <meeting@ripe.net>

11. Introduction to

12. RIPE NCC History • Actions agreed in RIPE community needed • continuity and professionalism • neutrality and impartiality • Birth - April 1992 • TERENA legal umbrella • BecameRIR in September 1992 • Contributing LIRs in 1995 • In 1998 independent • A new structure (ripe-161) • not-for-profit association

13. Formal Decision Making “Consensus” Model RIPE proposes activity plan RIPE NCC proposes budget to accompany activity plan (ripe-213) General Assembly votes on both activities and budget at yearly meeting

14. Vital Statistics • Statistics 1992 • 3 staff members • No Local IR’s • 182,528 hosts in European Internet • 7,955 objects in RIPE database (June ‘92) • Statistics Now • 67 staff (22 nationalities) • 2,595+ participating Local IR’s • 12,088,135+ countable hosts in the RIPE NCC region • 3,792,085+ objects in the database

15. Service Regions

16. RIPE NCC Services • Member Services • Registration Services • IPv4 addresses • IPv6 addresses • AS numbers • LIR Training Courses • <hostmaster@ripe.net> • Reverse domain delegation • NOT registering domain names • Test Traffic Measurements • Public Services • RIPE whois DB maintenance • Routing Registry Maintenance • Co-ordination • RIPE support • liaison with: • LIRs / RIRs / ICANN - ASO/etc • Information dissemination • New Projects • RIS, R2C2, DISI • Maintenance of tools

17. Summary: RIPE & RIPE NCC Two separate organisations, closely interdependent • RIPE • open forum for discussing policies • RIPE NCC • legitimate, not-for-profit association • formal membership • neutral and impartial

18. Questions?

19. RIPE Database Description How to query the Database How to create contact information objects

20. RIPE Database Intro • Public Network Management Database • Software Management • RIPE NCC • Database Working Group (RIPE community) • Data Management • LIRs • other users • RIPE NCC • Information content not responsibility of RIPE NCC • Protection mechanisms not default, but strongly encouraged

21. Migration to DB Version 3 • Re-implementation of DB software • re-written server and client • Routing Policy Specification Language • RPSL compliant (RFC-2622) • some attributes and objects changed • e.g. mandatory protection of inetnum-s • most changes in the RR • user query scripts need re-writing • Everybody will be affected! • http://www.ripe.net/rpsl/

22. Database Migration Time Line • 23-Apr-2001: switching to the RPSL database • queries return RPSL only • RIPE-181 updates possible; automatically converted to RPSL Date | 23 April | 14 May | 15 October ---------------------------------------------------------------------- RPSL |auto-rpsl@ripe.net | auto-dbm@ripe.net RIPE-181|auto-dbm@ripe.net | auto-181@ripe.net| N / A • 15-Oct-2001: RIPE-181 updates no longer possible

23. Querying RIPE Database

24. Object Types • Information about objects IP address space inetnum, inet6num reverse domains domain routing policies route, aut-num contact details person, role, mntner • Server whois.ripe.net • UNIX command line queries • http://www.ripe.net/db/ • Most important documents • ripe-157, ripe-181

25. Basic Queries • Whois (command line, web interface) • searches only look-up keys • returns exact match • some inverse look-ups possible using “-i” flag • Glimpse - full text search • Look-up keys - usually the object name • person, role: name, email, nic-hdl • inetnum: address (or range), netname • Inverse keys • notify, mnt-by, mnt-lower, admin-c, tech-c, zone-c, Examples

26. Creating Database Objects

27. Transition to RPSL Creating person Object • Check if person object exists in RIPE DB • whois {person’s name; email address} • only one object per person • Obtain and complete a template • whois -t person • -v (verbose) • Send to <auto-dbm@ripe.net> • see “The DB Transition Handout” (23.4.01-15.10.01) • Each person and role object has unique nic-hdl

28. whois -t person person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]

29. nic-hdl • Format: <initials>[number]-<regional registry> • e.g. AB123-APNIC, CD567-RIPE • Used in all the attributes where contact info needed • nic-hdl is the primary key for person and role objects • Use “AUTO-#” placeholders person: Piet Bakker ... nic-hdl: AUTO-1 PB1234-RIPE role: Technical BlueLight Staff ... nic-hdl: AUTO-#initials AUTO-2BL BL112-RIPE

30. Database Robot Responses • Successful update • acknowledgement • Warnings • object accepted but might be ambiguous • object corrected and accepted • Errors • object NOT corrected and NOT accepted • diagnostics in acknowledgement • If not clear send questions to <ripe-dbm@ripe.net> • include error report

31. ‘role’ Object % whois -h whois.ripe.net -t role role: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] trouble: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]

32. Usage of role Objects • To describe the group of technical contacts • To describe the contact persons for LIR • Steps: • create one person object per staff • create role object and reference all person objects • use role object nic-hdl in tech-c attribute • Use trouble and notify attributes

33. Role Object for Contact Persons role: BlueLight Contact Role description: Hostmaster for Blue Light BV admin-c: JAJA1-RIPE tech-c: AB321-RIPE tech-c: WF2121-RIPE email: hostmaster@bluelight.nl trouble: 24/7 phone number: +31-60-123-4567 nic-hdl: BL112-RIPE notify: hm-dbm-msgs@ripe.net notify: auto-hm@bluelight.nl mntner: BLUELIGHT-MNT changed: hostmaster@bluelight.nl 20000202 source: RIPE

34. Creating Maintainer Object • Protection of objects mandatory • except for person, role and domain • updates of objects that contain mnt-by attribute must pass the authentication rules in the mntner object • 1) Decide on the authentication method • ripe-157, ripe-189, ripe-190 documents • 2) Complete the object template • whois -t mntner • 3) Manual registration necessary • send the object to <ripe-dbm@ripe.net> • requester need to be from the LIR • See also: Protection of RIPE DB objects

35. Creating DB Objects(Summary) • Steps: • 1) complete the object template • 2) send in email to <auto-dbm@ripe.net> • See also: • creating inetnum objects • querying RIPE DB • protection of DB objects • updating DB information

36. Questions?

37. Initial Administrative Details • Becoming LIR • Terminology • First Request

38. Setting up LIR • Completed application form (ripe-212) • Provided Reg-ID & contact persons • <new-lir@ripe.net> • Read relevant RIPE documents • ripe-185 etc • Signed contract (ripe-191) • agreed to follow policies and procedures • Paid the sign-up & yearly fee • <billing@ripe.net>

39. Terminology Set aside? • Allocation • address space given to registries which is held by them to assign to customers or to own organisation • Assignment • address space given to end-users for use in operational networks • also called: ticket, request, approval, network, block, range, object /20 allocation = 4096 addresses assignment assignment

40. Goals of the Internet Registry SystemResponsibilities of Local Internet Registries • Aggregation • routability • ... • Conservation • determine operational needs • prevent stockpiling addresses • Registration • uniqueness • troubleshooting

41. Registry Internet Registry Structure IANA / ICANN ARIN RIPE NCC APNIC Local IR Enterprise LIR ISP End User End User

42. 24 110 256 192.0.0.0 - 223.255.255.255 Obsolete Classful Notation network host 8 0 16,777,216 Class A 0.0.0.0 - 127.255.255.255 16 10 65,536 Class B 128.0.0.0 - 191.255.255.255 Class C • Obsolete because of • depletion of B space • too many routes from C space • Solution • Classless Inter Domain Routing • hierarchical address space allocation

43. History of IP Addressing • Classfull • Subnetting • using subnet mask in Class B and Class C networks • Supernetting • using multiple Class C networks • Variable Length Subnet Mask • CIDR (Classless Inter Domain Routing) • flexible boundary between network and host part • source and destination address in the prefix format • route aggregation • Hierarchical address space allocation

44.  Classless Notation 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 ... ... ... ...

45. First Request • LIR wants a block of IP addresses • e.g. for own network / infrastructure • do not include needs of customers yet • no need to justify usage of the whole allocation • Steps: • Complete request form ripe-141 • Send request to <hostmaster@ripe.net> • RIPE NCC evaluate and approve request • With the first ASSIGNMENT approved, RIPE NCC also makes an ALLOCATION • default minimum size /20 (4096 addresses)

46. New in RPSL! First Request Approved • RIPE NCC hostmaster enters allocation and assignment objects into the RIPE database • only at the first request • /24 & /25 & /26 (448) instead of /23 (512) • at the beginning of the block (can be modified later) • with RIPE-NCC-NONE-MNT (or LIR mntner) • Whole allocated range can be announced immediately • AW=0 • Every request has to be sent to RIPE NCC for approval

47. Requesting the Address Space • Assignment Process • Completing the request form • Communication with the hostmaster • Answers from the HM robot • Creating DB objects

48. Assignment Process

49. Assignment Process (TXT) • 1. Gather information • 2. Complete the request form • 3. Send it to the HM (robot) <hostmaster@ripe.net> • wait for 2-7 days • 4. Read the answer • and correct errors • 5. Re-send, using the same ticket number • (message without errors goes to the wait q) • 6. Answer the questions from HM staff (Evaluation loop) • (wait for approval) • 7. Choose address range • 8. Register network in the RIPE Database

50. When to Send a Request • For your own infrastructure • one block of many clients with 4 or less IPs per client • leased lines • dial-up • p2p links (???) • web hosting • For each customer • more then /30 • For ISP-client’s infrastructure • For ISP-client’s customers • => Separate request form needed