1 / 179

Welcome to the Local Internet Registry Course

Welcome to the Local Internet Registry Course. RIPE Network Co-ordination Centre <training@ripe.net> NEW version for RPSL launch to be ready for 3rd April!!!. Logistics. Mobile phones, toilets, fire exits, parking, smoking places ... Time line breaks lunch ( vegetarians? )

jaime-britt
Download Presentation

Welcome to the Local Internet Registry Course

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 • life-cycle of the registry • 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 • Evaluation of specific cases • Large request • PI request • Renumbering • 15:00 tea break • New allocation • Advanced reverse delegation • Routing Registry • Administrivia • audit activity, billing, closing LIR • IPv6 • 17:00-18:00 closing discussion 9:00 Introduction • RIPE & RIPE NCC • Initial Administrivia • First Request 11:00 coffee break • Customer’s Request • evaluation • RIPE Database • Reverse Delegation • AS Numbers 13:00 lunch • Advanced database issues • Assignment Window

  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. Introduction to RIPE

  8. What is RIPE? • Réseaux IP Européens (1989) • RIPE is a collaborative organisation open to all parties interested in Internet administration, development and network operations • RIPE is • open forum • voluntary participation • works by consensus • NO legal power • does NOT develop Internet Standards

  9. Global Context • World-wide Internet • Technical Development & Standards Body • World-wide Operators Forum IETF IEPG NANOG RIPE APRICOT

  10. How RIPE Works • RIPE chair <chair@ripe.net> • Chair is: Rob Blokzijl (Nikhef) • How does it work? • working groups mailing lists • <majordomo@ripe.net> • web archived • meetings • You make it possible!

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

  12. Introduction to RIPE NCC

  13. What is the RIPE NCC? • Network Co-ordination Centre • The RIPE NCC is a “co-ordination” and support service for its members and RIPE community • One of 3 Regional Internet Registries (RIR) • Why a NCC ? Actions agreed in RIPE community needed • continuity and professionalism • neutrality and impartiality

  14. RIPE NCC History • 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 • General Assembly of all members • Executive Committee of elected nominees

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

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

  17. Service Regions

  18. 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 database maintenance • Routing Registry Maintenance • Co-ordination • RIPE support • liaison with: • LIRs / RIRs / ICANN - ASO/etc • Information dissemination • Maintenance of tools

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

  20. Questions?

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

  22. RIPE Database (1) • Public Network Management Database • 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/ripencc/pub-services/db/

  23. RIPE Database (2) • 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

  24. Migration to DB Version 3 • Re-implementation of DB software • re-written server and client • Routing Policy Specification Language • RPSL compliant • 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/

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

  26. Querying RIPE Database

  27. 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-/tech-/zone-c, Example

  28. Creating Database Objects

  29. 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 object has unique nic-hdl

  30. 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] [ ]

  31. nic-hdl • Mandatory attribute • Only way to clear ambiguity in person objects • Format: <initials><number>-<regional registry> • e.g. AB123-APNIC, CD567-RIPE • Combination of person nameandnic-hdl is the primary key for person object • Use “AUTO-#” placeholders person: Piet Bakker ... nic-hdl: AUTO-1 person: Jan van der Bruk ... nic-hdl: AUTO-#initials PB1234-RIPE AUTO-2JVDB JVDB1-RIPE

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

  33. ‘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] [ ]

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

  35. Questions?

  36. Setting up a Local Internet Registry • Becoming LIR • Terminology • First Request

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

  38. Terminology • Allocation • address space given to registries which is held by them to assign to customers • Assignment • address space given to end-users for use in operational networks /20 allocation = 4096 addresses assignment assignment

  39. Goals of the Internet Registry System • Aggregation • routability • …. • Conservation • … • …. • Registration • uniqueness • troubleshooting

  40. Local IR Regional Registry Structure IANA / ICANN ARIN RIPE NCC APNIC Local IR Enterprise Local IR ISP End User End User

  41. 24 110 256 192.0.0.0 - 223.255.255.255 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

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

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

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

  45. 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 for approval to RIPE NCC

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

  47. Assignment Process

  48. When to send a request • For your own infrastructure • leased lines • dial-up • p2p links • For each customer • 8 or more addresses • For ISP client’s infrastructure • For ISP client’s customers

  49. Request Formripe-141 I. General Information Overview of Organisation Contact Information Current Address Space Usage II. The Request Request Overview Addressing Plan III. Database Information IV. Optional Information

  50. Before Submitting the Request • Web form • filling in the requests • syntax check • http://www.ripe.net/cgi-bin/web141/web141.pl.cgi • ftp://ftp.ripe.net/tools/web141.pl.cgi • Complete documentation reduces need for iteration • All the data communicated with RIPE NCC is kept strictly confidential • Documentation for RIPE NCC has to be in English • Link to:

More Related