1. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 1 “How to Run a Local Internet Registry” or all your IPs are belong to us! RIPE Network Coordination Centre

2. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 3 Schedule RIPE & RIPE NCC IP Address Space Distribution –obtaining the Address Spaceobtaining 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 4 Introduction to 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 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 5 How RIPE Works RIPE works as –open forum –voluntary participation –decisions made by consensus –meetings –working groups mailing lists web archived –not a legal entity –does NOT develop Internet Standards RIPE chair

6. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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)

8. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 11 RIPE NCC in Global Context PSOASODNSO RIPE NCC ARIN APNIC ICANN RIPEAPNIC mtg.ARIN mtg. At Large IETF, w3c, ETSI,...

12. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 12 Service Regions

13. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 14 RIPE NCC R&D Test Traffic Measurements ( www.ripe.net/ttm/ ) www.ripe.net/ttm/ –independent measurements of connectivity parameters (delays and routing-vectors) in the Internet. Routing Information Service ( www.ripe.net/ris/ ) 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/ ) www.ripe.net/disi/ –Deployment of Internet Security Infrastructures –e.g. DNSSEC

15. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 15 Questions?

16. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 16 IP Address Space Distribution

17. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 18 Classless Notation (CIDR) AddressesPrefixClassfulNet Mask... 8 /29 255.255.255.248 16/28255.255.255.240 32/27255.255.255.224 64/26255.255.255.192 128/25255.255.255.128 256/241 C255.255.255.0... 4096/2016 C’s255.255.240.0 8192/1932 C’s255.255.224 16384 32768 65536 /18 /17 /16 64 C’s 128 C’s 1 B 255.255.192 255.255.128 255.255.0.0...

19. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 19 Global Registries Structure Global Authority RIR /8 LIR (ISP/Enterprise) /20 +RIPE NCC Members ISP / End Users /32 + Anybody with a network / host

20. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 20 Goals of the Registry Structure Fairness Conservation Aggregation Registration

21. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 24 Terms Illustrated IANA / ICANN RIPE NCC Enterprise LIR Local IR Registry ISP End User Allocating Assigning PI assignment

25. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 25 Obtaining the Address Space through the existing LIR

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

27. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 29 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 128 32 16 64 128 32 16 448 255.255.255.128 255.255.255.224 255.255.255.240 255.255.255.192 255.255.255.128 255.255.255.224 255.255.255.240 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 170 297 342Totals (*1) Office LAN = workstations, router, 2 printers and 1 fileserver Relative Subnet Mask Size Imm 1yr 2yr Description Prefix Example: #[ Addressing Plan Template ]# 100 12 10 14 35 100 12 14 0 Cumulative, total numbers 100 10 8 14 24 0 14 0 Real needs 100 16 13 14 50 100 25 14 10 Concrete plans

30. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 30 Questions?

31. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 31 Being an LIR Setting up an LIR First Allocation Requesting Assignment Approval Managing Allocated Address Space

32. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 32 Setting up an LIR Completed application form  Provided Reg-ID & contact persons –  Read relevant RIPE documents –ripe-185 etc Signed contract - “Service agreement” –agreed to follow policies and procedures  Paid the sign-up & yearly fee –

33. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 33 Registry Identification (Reg-ID) Distinguishes between member registries and individuals Format. Include with every message Suggestion - modify mail header X-NCC-RegID: nl.bluelight

34. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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.netlir-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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 37 Sending the Request RIPE-219 : http://www.ripe.net/docs/iprequest.html (ex ripe-141) http://www.ripe.net/docs/iprequest.html Web form (example)example –filling in the requests & syntax check http://www.ripe.net/cgi-bin/web141/web141.pl.cgihttp://www.ripe.net/cgi-bin/web141/web141.pl.cgi source: ftp://ftp.ripe.net/tools/web141.pl.cgiftp://ftp.ripe.net/tools/web141.pl.cgi Frequently asked questions http://www.ripe.net/ripencc/faq/http://www.ripe.net/ripencc/faq Short tips and tricks http://www.ripe.net/ripencc/tips/tips.htmlhttp://www.ripe.net/ripencc/tips/tips.html All data kept strictly confidential Documentation has to be in English

38. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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) Amsterdam Utrecht /24 BlueLight Infrastructure /24 BlueLight reserved /25 Laika Dialup + /25 reserved Laika Infrastructure /25 /25 Laika Dialup + /25 reserved /26 Laika Infrastructure

40. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 40 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 How to Manage Allocation

41. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 41 Assignments to (Small) ISPs LIR can not allocate 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 42 Non-Overlapping Assignments 195.35.88/26 ENGO-infrastr... 195.35.92/29 ENGO-rgb 195.35.92.8/29 ENGO-cmyk wrong  Assignment for ISP ENGOS & all its (future) customers Overlapping (second level) assignments for separate customers of ENGOS right Internal Reservations for ENGOS’s customers 195.35.88/22 ENGOS-and-all Assignments for separate customers of ENGOS BlueLight’s Allocation

43. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 43 Registering Address Space in 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 44 Additional Policies and Procedures Assignment Window evaluation policies Additional Allocations PI Assignments

45. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 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. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 50 Questions?

51. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 51 Reverse Delegation Procedures /24 zone multiple /24 zones /16 zone zone smaller then /24 assuming basic DNS knowledge assuming LIR perspective

52. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 52 What is the Difference Between Forward and Reverse DNS Delegation ? Forward DNS –enables naming of IP hosts on the Internet –hierarchical authority for domain registration organisational structure Reverse DNS –enables association of IP addresses with domain names –hierarchical authority delegation for reverse zone depends on who distributed the address space –reverse delegation takes place on octet boundaries

53. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 53 IN-ADDR.ARPA Domain. (ROOT) edu arpa com net nl in-addr 193 195 194 35 65 130 = 130.65.35.195.in-addr.arpa bluelight www 195.35.65.130 Forward mapping Reverse mapping (A 195.35.65.130) (PTR www.amsterdam.bluelight.nl) 213 212 62 217 amsterdam 80 81 RIPE NCC

54. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 54 Why Do You Need Reverse DNS Delegation ? All host-IP mappings in the DNS (A record) should have a corresponding IP-host mapping (PTR record) Failure to have this will likely –block users from various services (ftp, mail) –make troubleshooting more difficult (traceroute) –produce more useless network traffic in general

55. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 55 Overview of the Request Procedure LIRs have to request reverse delegation /24 zones are delegated –to LIR / end-user –as the address space gets assigned Steps  valid assignments of address space  /24 reverse zone setup  on LIR or end-users nameserver(s), or both  send domain object to always include Reg-ID –e.g. X-NCC-Regid: nl.bluelight

56. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 56 “Valid” Assignment According to ripe-185 policies Within “Assignment Window” -or approved from RIPE NCC Hostmaster inetnum object registered in RIPE Database –netname attribute is RIPE NCC's only reference of approved assignment do NOT change netname without notifying lir-help@ripe.netlir-help@ripe.net this is mentioned when we approve your IP requests –registered after the approval date

57. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 57 /24 Reverse Zone Setup Recommendations At least two nameservers required –one nameserver setup as primary –at least one another nameserver as secondary SOA values reasonably RFC1912 compliant Nameservers not on same physical subnet –preferably with another provider Serial numbers YYYYMMDDnn format Use name of nameserver instead of IP address Do NOT use rev-srv attribute in inetnum object Do NOT put a dot at the end of domain or nserver attributes –the RIPE DB does not support them

58. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 58 Example domain Object whois -t domain domain: 80.35.195.in-addr.arpa descr: Reverse delegation for Bluelight Customers SPLITBLOCK admin-c: JJ231-RIPE tech-c: JAJA1-RIPE zone-c: WF2121-RIPE nserver: ns.bluelight.nl nserver: ns2.bluelight.nl mnt-by: BLUELIGHT-MNT changed: jan@bluelight.nl source: RIPE Notice: DB SW will add date!

59. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 59 Request the Delegation Send domain template to “Marvin” will 1.check if zone is correctly setup 2.check assignments’ validity 3.(try to) enter object to RIPE DB RIPE NCC systems enter NS lines into the parent zone file

60. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 60 Problems with inaddr Robot? Error report will be sent to requester –correct errors and re-send to For questions, see FAQ –http://www.ripe.net/reverse/http://www.ripe.net/reverse/ If error reports continue –for any technical questions contact inaddr@ripe.net please include the full error report –for address space validity issues contact hostmaster@ripe.net

61. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 61 Reverse Delegation of Multiple /24 Shorthand notation for domain attribute –for (sub)range of consecutive zones (compound object) –if represented in single inetnum object, e.g. inetnum: 212.73.10.0 - 212.73.15.255 domain: 10-15.73.212.in-addr.arpa –submit as one domain object processed separately separate response –recommended and preferred method! will not work with auth: PGPKEY Possible to include up to 100 reverse domain objects in one email message even if they are not consecutive

62. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 62 Reverse Delegation of /16 Allocation If an LIR has a /16 allocation, the RIPE NCC can delegate the entire reverse zone to the LIR Requirements and procedures the same as /24, except –/16 domain object –three nameservers needed –ns.ripe.net a mandatory secondary After delegation, LIR should –continue to check sub-zone setup before further delegation (usage of the inaddr robot TEST keyword or web check is recommended)

63. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 63 Changing the Delegation Change the nserver lines in the domain object –submit domain object to auto-inaddr@ripe.net> include RIPE DB authentication, if the object is protected –NOT enough to update the object in RIPE DB! Deleting a delegation is automatic –include delete attribute to the exact copy of the object value: email address, reason, date include RIPE DB authentication, if the object is protected –send to To change contact details in domain object –submit updated object to

64. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 64 < /24 Delegations Reverse delegation is also possible for a /24 shared by more customers => NOT reason for classfull assignments RIPE NCC reverse delegate authority for the entire /24 to LIR –procedure and requirements the same as for /24 If customer wants to run own primary nameserver –LIR delegates parts as address space gets assigned –use CNAME to create an extra point of delegation (RFC 2317)

65. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 65 $ORIGIN 80.35.195.in-addr.arpa. 0-31 IN NS ns.goody2shoes.nl. 0-31 IN NS ns2.bluelight.nl. 32-71 IN NS ns.cyberfalafel.nl. 32-71 IN NS ns2.bluelight.nl. 0 IN CNAME 0.0-31 1 IN CNAME 1.0-31... 31 IN CNAME 31.0-31 32 IN CNAME 32.32-71 33 IN CNAME 33.32-71... 71 IN CNAME 71.32-71 73 IN PTR www.qwerty.nl. CNAME Example Zonefile at Provider Primary Nameserver

66. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 66 CNAME Example Zonefiles at Customers’ Nameservers $ORIGIN 0-31.80.35.195.in-addr.arpa. @ IN NS ns.goody2shoes.nl. @ IN NS ns2.bluelight.nl. 1INPTRwww.goody2shoes.nl. 2INPTRmail.goody2shoes.nl.... 31INPTRkantoor.goody2shoes.nl. $ORIGIN 32-71.80.35.195.in-addr.arpa. @ IN NS ns.cyberfalafel.nl. @ IN NS ns2.bluelight.nl. 33INPTRwww.cyberfalafel.nl.... 70 INPTRcafe3.cyberfalafel.nl.

67. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 67 Questions?

68. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 68 Autonomous System Numbers and the Routing Registry It is assumed that attendee is familiar with BGP routing, and have interest in obtaining public ASN

69. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 69 Autonomous System Definition: a group of IP networks run by one or more network operators which has a unique and clearly defined routing policy RIR is allocated a range of AS numbers by IANA RIR assigns unique AS number –for LIR or for the customer  AS number, routing policy and originating routes are registered in the Routing Registry

70. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 70 How to Get an AS Number ? Complete request form: –aut-num object template contact person(s) mntner object template –address space to be announced with this AS# Send to –web syntax check: http://www.ripe.net/cgi-bin/web147cgihttp://www.ripe.net/cgi-bin/web147cgi

71. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 71 Criteria for Evaluation of ASN Request Being multihomed and specifying routing policy are mandatory requirements –how long will it take you to achieve multihomed status? –please provide e-mail addresses of peers Is it feasible to peer with specified ASNs? Is it possible to use private ASN? – 64512 to 65535

72. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 72 RPSL Routing Policy Specification Language (RFC 2622) –replacing RIPE-181 language RPS Security (RFC 2725) –stronger and hierarchical authorisation and authentication Syntax aut-num: NEW export: to AS3 announce NEW import: from AS2 action pref=120; accept ANY –the lower the value of “pref”, the more preferred route RPSL!

73. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 73 AS2 aut-num: AS2 import: from AS2 action pref=20; accept AS2 export: to NEW announce AS2 AS Example NEW aut-num: NEW export: to AS2 announce NEW Internet aut-num: AS3 AS3 export: to NEW announce ANY import: from NEW action pref=200; accept NEW import: from AS3 action pref=100; accept ANY import: from NEW action pref=120; accept NEW export: to AS3 announce NEW ANY import: from AS2 action pref=200; accept ANY

74. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 74 Registration in RIPE Database RIPE NCC hostmaster - creates aut-num object (and maintainer) - informs requester User is responsible for keeping up to date –routing policy (aut-num, route objects) –referenced contact info (person/role, mntner) RIPE NCC hostmaster regularly checks consistency of data in Routing Registry –http://abcoude.ripe.net/ris/asinuse.cgihttp://abcoude.ripe.net/ris/asinuse.cgi

75. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 75 aut-num: NEW as-name: BLUELIGHT descr: Bluelight AS# import: from AS2 action pref=20; accept AS2 import: from AS3 action pref=100; accept ANY import: from AS2 action pref=200; accept ANY export: to AS2 announce NEW export: to AS3 announce NEW admin-c: JJ231-RIPE tech-c: JAJA1-RIPE mnt-by: BLUELIGHT-MNT mnt-routes: BLUELIGHT-MNT changed: hostmaster@ripe.net 20001010 source: RIPE aut-num Template AS42 Object RPSL!

76. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 76 The Route Object route: 195.35.64.0/20 descr: BLUELIGHT-NET origin: AS42 mnt-by: BLUELIGHT-MNT mnt-routes: BLUELIGHT-MNT changed: hostmaster@bluelight.com 20001010 source: RIPE To create route object, send completed template to Authorisation required when creating/changing the object –mntner of the address space block –mntner of the originating ASN –mntner of the encompassing route object –mntner referenced in the object itself New in RPSS!

77. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 77 Internet Routing Registry Globally distributed DB with routing policy information –provides a map of global routing policy (ASExplorer) –shows routing policy between any two ASes (prpath) –allows simulation of routing policy effects –enables creation of aut-num based on router conf (aoe) –enables router configuration (rtconfig) –provides contact information (whois) RIPE Routing Registry –subset of information in RIPE database  See “The DB Transition Handout” RPSL!

78. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 78 aut-num Changes in RPSL aut-num: [mandatory] [single] [primary/look-up key] as-name: [mandatory] [single] descr: [mandatory] [multiple] as-in: [optional] [multiple] [ ] as-out: [optional] [multiple] [ ] interas-in: [optional] [multiple] [ ] interas-out: [optional] [multiple] [ ] as-exclude: [optional] [multiple] [ ] member-of: [optional] [multiple] [inverse key] *** New in RPSL *** import: [optional] [multiple] *** as-in in RIPE 181 *** export: [optional] [multiple] *** as-out in RIPE 181 *** default: [optional] [multiple] remarks: [optional] [multiple] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] cross-mnt: [optional] [multiple] [inverse key] cross-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] *** RPS auth *** mnt-routes: [optional] [multiple] [inverse key] *** RPS auth *** mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] source: [mandatory] [single] automatically translated, new, preserved, deprecated RPSL!

79. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 79 Questions?

80. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 80 IPv6

81. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 81 Why IPv6? Next generation protocol –scalability -- 128 bits addresses –security –dynamic hosts numbering –QoS Interoperable with IPv4 simple and smooth transition –hardware vendors –applications

82. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 82 Get IPv6 Addresses From: Using 2002::/16 prefix 6bone (sub)TLA holder RIR

83. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 83 IPv6 Introduction Current format boundaries |-3|--13-|--13-|-6-|--13-|--16--|------64 bits-----| +--+-----+-----+---+-----+------+------------------+ |FP|-TLA-|-sub-|Res|-NLA-|--SLA-|---Interface ID---| |--|-ID--|-TLA-|---|--ID-|--ID--|------------------| |----public topology ----|-site-|-----Interface----| +--+-----+-----+---+-----+------+------------------+ /23 /29 /35 /48 /64 Classfull; another level of hierarchy –(sub)TLA –NLA –SLA Hexadecimal representation of addresses

84. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 84 IPv6 Allocation Policies "Provisional IPv6 Assignment and Allocation Policy Document” (ripe-196) –discussion on and “Bootstrap Phase” Criteria A) Peering with 3  Autonomous Systems (in Default Free Zone) AND B) Plan to provide IPv6 services within 12 months C)  40 IPv4 customers AND either OR D) 6bone experience

85. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 85 IPv6 Allocations Request form (ripe-195) ”Slow start” –first allocation to a TLA Registry will be a /35 block representing 13 bits of NLA space –additional 6 bits reserved by RIR for the allocated sub-TLA for subsequent allocations Reverse Delegation of an IPv6 Sub-TLA –http://www.ripe.net/reverse/http://www.ripe.net/reverse/ IANA allocations –APNIC 2001:0200::/23(33+ subTLAs) –ARIN 2001:0400::/23(20+ subTLAs) –RIPE NCC 2001:0600::/23(42+ subTLAs) –http://www.ripe.net/ipv6/http://www.ripe.net/ipv6/

86. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 86 IPv6 Database Object inet6num: 2001:0600::/23 netname: EU-ZZ-2001-0600 descr: RIPE NCC descr: European Regional Registry country: EU admin-c: NN32-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: SUBTLA mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT changed: hostmaster@ripe.net 19990810 changed: hostmaster@ripe.net 20000615 source: RIPE Generated by the DB!

87. NATO Advanced Networking Workshop. Ljubljana, 19 September 2001. http://www.ripe.net 87 Questions? http://www.ripe.net/training/