welcome to the local internet registry tutorial

1Local Internet Registries Tutorial . RIPE 37, Amsterdam 12-15 2000. . http://www.ripe.net

Welcome to theLocal Internet Registry

Tutorial

RIPE Network Co-ordination Centre Vesna Manojlovic <[email protected]>,

Eamonn McGuinness <[email protected]>

http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/lir-tutorial/

ftp://ftp.ripe.net/ripe/presentations/lir-tutorial-ripe37

15 September 2000 Grand Ball Room, 14:00-17:30

Local Internet Registries Tutorial . RIPE 37, Amsterdam 12-15 2000. . http://www.ripe.net 2

Schedule• Requesting Address Space

• Introduction to RIPE NCC• Global Registry System• Initial Administrivia of Becoming LIR

• First Request• Completing the request form• Communication with hostmasters

• Customer’s Request• Elementary evaluation• RIPE Database

• Evaluation of specific assignment cases• Large request• PI request• Renumbering

• Assignment Window

• New allocation


Introduction to RIPE NCC


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


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– 62 staff (22 nationalities) 2,018+ participating Local IR’s 11,390,000+ countable hosts in the RIPE NCC region 3,041,650+ objects in the database


RIPE NCC Activities (1)

• Registration Services– IPv4 addresses

– IPv6 addresses

– AS numbers

– LIR Training Courses• <[email protected]>

• Reverse domain name delegation– NOT registering domain names

Member Services


RIPE NCC Activities (2)

RIPE database maintenance Routing Registry Maintenance (RR)• Co-ordination

– RIPE support– Liaison with:

• LIRs / RIRs / ICANN / etc …– Information dissemination

• New Projects– Test Traffic MeasurementsRouting Information Service (RIS)Routing Registry Consistency (RR)

Public Services


RIPE Database (1)

• Public Network Management Database

• Information about objectsIP address space inetnum, inet6num

reverse domains domain

routing policies route, aut-num

contact details person, role

• Server whois.ripe.net• UNIX command line queries

• http://www.ripe.net/ripencc/pub-services/db/


RIPE Database (2)

• Software Management• server and client

– NOT relational

– 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


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


Questions?


• Terminology

• Global Registry System


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

assignment

/20 allocation = 4096 addresses

assignment


Classful Notation

16,777,216

65,536

network host

8

16

Class A

Class B

Class C

0.0.0.0 - 127.255.255.255

128.0.0.0 - 191.255.255.255

256

24

192.0.0.0 - 223.255.255.255

110

10

0

• Obsolete because of– depletion of B space– too many routes from C space

• Solution– Classless Inter Domain Routing hierarchical address space allocation


Classless NotationAddresses Prefix Classful Net Mask... ... ... ...

8 /29 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

32768

65536

/18

/17

/16

64 C’s

128 C’s

1 B

255.255.192

255.255.128

255.255.0.0... ... ... ...


Goals of the Internet Registry System

• Aggregation

• Conservation

• Registration– uniqueness


Regional Registry Structure

IANA / ICANN

RIPE NCCARIN APNIC

EnterpriseLocal IR

Local IR / ISP

Local IR

ISPISP /

End user

End user


Service Regions


Questions?


Initial Administrivia of Becoming LIR


Becoming LIR

• Completed application form (ripe-212) Provided Reg-ID & contact persons

– <[email protected]>

Read relevant RIPE documents• Signed contract (ripe-191)

– agreed to follow policies and procedures

* Paid the sign-up & yearly fee– <[email protected]>


Contact Persons

Stored in RIPE NCC internal file for each registry– confidential

• Only registered contact persons can – send requests to hostmasters

– change contact information• PGP optional (soon)

Use ‘role’ object– for multiple admin-c and tech-c

• Members’ mailing lists– <[email protected]>– <[email protected]>


Registry Identification (RegID)

• Distinguishes between contributing registries and individuals

• Format <country code> . <registry name>

• Include with every message

• Suggestion - modify mail header X-NCC-RegID: nl.bluelight


Questions?


New Registry’s First Request

• Completing the request form• Communication with the hostmaster


Sample First Request

Example: Blue Light Internet• LIR wants a block of IP addresses

– e.g. for own network / infrastructure• do not include needs of customers yet

Steps: Complete request form ripe-141 Send request to <[email protected]> RIPE NCC evaluate and approve request

With first assignment LIR automatically receives /20 allocation


Request Formripe-141

I. General InformationOverview of Organisation

Contact Information

Current Address Space Usage

II. The RequestRequest Overview

Addressing Plan

III. Database Information

IV. Optional Information


Completing the Request Form (starting from Addressing Plan)

Gathering Information

• Design of the network– how many physical segments it will consist of– what is each segment going to be used for

• including equipment used

– how many hosts are in each segment– expectations of growth


dynamic dial-up Amsterdam web/mail/ftp servers Amsterdamcustomers’ servers Amsterdamtraining room LAN AmsterdamAmsterdam office LAN (*1)dynamic dial-up Utrecht web/mail/ftp servers UtrechtInet cafe Utrechttraining room LAN Utrecht

128 32 16 16 64 128 32 16 16

448

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

0.0.0.0 0.0.0.128 0.0.0.160 0.0.0.1760.0.0.1920.0.1.0 0.0.1.128 0.0.1.160 0.0.1.176

100 10 8 14 24 0 0 14 0 170 297 342 Totals

(*1) Office LAN = workstations, router, 2 printers and 1 fileserver

Relative Subnet Mask Size Imm 1yr 2yr DescriptionPrefix

#[ Addressing Plan Template ]#

100 12 10 14 35100 12 14 0

100 16 13 14 50 100 25 14 10


#[ Request Overview Template ]#

request-size: 448 addresses-immediate: 170 addresses-year-1: 297 addresses-year-2: 342 subnets-immediate: 6 subnets-year-1: 8 subnets-year-2: 9

Totals: 448 170 297 342

inet-connect: YES, already connected to “UpstreamISP” country-net: NL private-considered: Yes request-refused: NO PI-requested: NO address-space-returned: 195.20.42.0/25, to UpstreamISP, “in 3 months”


#[ Current Address Space Usage Template ]#

Prefix Subnet Mask Size Imm 1yr 2yr Description

195.20.42.0 255.255.255.192 64 16 30 50 Dynamic dial-up A’dam

195.20.42.64 255.255.255.224 32 10 22 29 Amsterdam office LAN

195.20.42.96 255.255.255.240 16 4 6 8 Utrecht office LAN

195.20.42.112 255.255.255.240 16 6 10 13 Mail servers

128 36 68 100 Totals

Actual addresses


#[Person template]#

person:address:address:address:address:e-mail:phone:nic-hdl:mnt-by:changed:source:

Jan Jansen Blue Light Internet Oudezijds Achterburgwal 13 Amsterdam The Netherlands [email protected] +31-20-555 5555 AUTO-1 BLUELIGHT-MNT [email protected] 19990906 RIPE

**


#[Network template]#

inetnum:netname:descr:descr:country:admin-c:tech-c:status:mnt-by:changed:source:

x.x.x.x/23 BLUELIGHT-1 Company infrastructure in both locations NL AB231-RIPE AUTO-1 ASSIGNED PA BLUELIGHT-MNT [email protected] 19990906 RIPE

*

*


Communication with <[email protected]>


Ticketing System

• Unique ticket number– facilitates retrieval / archiving– NCC#YYYYMMXXXX e.g. NCC#2000053280

• Check status of ticket on the web– http://www.ripe.net/cgi-bin/rttquery

• open ncc • open reg• closed


Hostmaster-robot• Checks request form

– Reg-ID, contact persons– syntax– policy problems

• Acknowledgement & diagnostics– LONGACK

• Error message– correct & re-send the request– use same ticket number– NOAUTO

• No errors: hostmaster wait-queue– “ongoings” directly to hostmasters


Request Approved

• With the first ASSIGNMENT approved LIR automatically gets an ALLOCATION– /20 (4096 addresses)

Hostmaster enters allocation and assignment objects into the RIPE database at this time- /24 & /25 & /26 instead of /23

• Whole allocated range can be announced immediately

• Every request has to be sent for approval to RIPE NCC – addresses for LIRs own infrastructure

– all customers’ request


Questions?


Customer’s Request

Evaluation

Basic Database Issues


RIPE NCC evaluation

Assignment Process

Documentationcompleted?

Completing ripe-141

update localrecords

update RIPEdatabase

notifycustomer

no

yes

Assignment

Gatheringinformation


no

approval

Customer


Gathering Information

• One request form per customer

• Ask the same questions RIPE NCC asks LIR – enough information to complete ripe-141

• Add comments

Example: Goody 2 Shoes


Before Submitting the Request

• Syntax check the request on the Web

• 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


Evaluation -- General Information

• #[Overview of organisation template]#• information relevant to the address space request

– Name and location of the company?– What are the company activities?– What is the structure?

• Does it have subsidiaries and where?• For what part of the company are the addresses requested?

• #[Requester Template]#– LIR contact for RIPE NCC

• #[User Template]#– customer’s contact for LIR


Evaluation -- Addressing Plan• Do totals in “Addressing Plan” match numbers in

“Request Overview”?

• Are all subnets classless?– are the subnet masks real?

• Utilisation and efficiency guidelines: 25% immediately, 50% in one year

• Can address space be conserved by using– different subnet sizes?– avoiding padding between subnets?


Evaluation -- Network Template• inetnum value

– specifies the size of assignment– actual range is not necessary

• Relevant netname– descriptive; uppercase letters, numbers & “-”

• RIPE NCC’s only reference to LIR’s assignment

• Contact persons– can be multiple reference nic-hdls (may be a role object)– admin-c

• responsible for the network, able to make decisions

– tech-c• technical setup of the network


• Wait for approval from <[email protected]> prior to assignment and registration

• Decide on the range of within your address space– classless assignment on bit boundary

• Update local records– archive original documents with assignment

Internal Administration

Assignment for customer’s network

Assignment for LIR’s network


Creating Database Objects


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 <[email protected]>

• Each person object has unique nic-hdl


whois -t person

person: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ]

e-mail: [optional] [multiple] [look-up key]

phone: [mandatory] [multiple] [ ]

notify: [optional] [multiple] [inverse key]

nic-hdl: [mandatory] [single] [primary/look-up key]

changed: [mandatory] [multiple] [ ]

source: [mandatory] [single] [ ]


person: Jan van der Bruk...nic-hdl: AUTO-#initials

AUTO-1JVDB

nic-hdl

person: Piet Bakker...nic-hdl: AUTO-1PB1234-RIPE

• Mandatory attribute• Only way to clear ambiguity in person objects • Format: <initials><number>-<regional registry>

– e.g. AB123-APNIC, CD567-RIPE

• Combination of person name and nic-hdl is the primary key for person object Use “AUTO-#” placeholders

JVDB1-RIPE


<[email protected]> 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<[email protected]>• Include error report


Creating Network Object

• inetnum– insert the address range in the ‘network template’

approved by hostmasters

– keep the same netname attribute

– in change attribute use current date• or leave out the date completely

• Send to <[email protected]>– with the keyword NEW in the subject line


Check Your Database Data

• Before you notify the customer– whois [customer’s IP range]– whois [customer’s netname]

– whois -m [your allocated IP range]• will show your first level customer(s) network(s)

– whois -L [customer’s IP range]• will show your own data


Example DB Query

195.35.64.0-

195.35.65.191195.35.88/26

195.35.64.0 -

195.35.95.255

195.35.80/25

Blue Light Goody2Shoes

whois -M 195.35.64.0/19

whois -m 195.35.64.0/19

whois -L 195.35.92.10

eNGOs ...195.35.92/29

ENGO-7

195.35.92.8/29

ENGO-8


Notify the Customer

• Make sure customer has same data as you– cut and paste output of the whois query

• Address space is considered in use only if registered in the RIPE Database


Questions?


Evaluation ofSpecific Assignment Cases

• ‘Large’ Request• PI request• Renumbering


‘Large’ Request


Submitting a Large Request

• Complete ripe-141 request form – only include addresses you have concrete need

for (no reservations)

• Possible additional information– pointer to web site deployment plan new technologies purchase receipts topology map (design of the network)

• can be faxed

• handled and kept confidentially

• include ticket number and Reg-ID


Current Address Space UsageEvaluation

• Are there any previous assignments?– ask customer

• Querying the RIPE Database– whois.ripe.net

• exact match

– http://www.ripe.net/ripencc/pub-services/db/• full text search using glimpse• whois web interface

• Can request be fulfilled with previous assignment?


Private Address Space• RFC-1918 (Address Allocation for Private Internets)

• Suitable for– partial connectivity– limited access to outside services

• can use application layer gateways (fire walls, NAT)

• Motivation– saves public address space– allows for more flexibility– security


Sample Deployment Plan• Needed when big expansion planned• Matching addressing plan

Relative Subnet Mask Size Imm. 1yr 2yr DescriptionPrefix0.0.0.0 255.255.252.0 2048 0 1024 2048 London POP0.0.4.0 255.255.252.0 2048 0 1024 2048 Berlin POP0.0.8.0 255.255.252.0 2048 0 1024 2048 Moscow POP0.0.12.0 255.255.252.0 2048 0 1024 2048 Paris POP

PlannedoperationalDate

DateEquipmentordered

Type of Equipment

Number of hosts

Location

09/200011/200011/200003/2001

05/200007/200007/2000--------

modemsmodemsmodemsmodems

2048204820482048

LondonBerlinParisMoscow


(New) Technologies

• If special hardware/software is used• include the URLs of manufacturer’s sites if available

• Special allocation and verification procedures apply• cable modems, ADSL

• GPRS?

static dial up assignments

IP based virtual web hosting

– recommended

investigate and implement dynamic assignment technologies

whenever possible

} STRONGLY DISCOURAGED


PI Request


PA vs. PI Assignments• Provider Aggregatable

• customer uses addresses out of your allocation

good for routing tablescustomer must renumber if changing ISP

• Provider Independent• customer receives range of addresses from RIPE NCC

customer takes addresses when changing ISPpossible routing problems

• Make contractual agreements– ripe-127


Requesting PI Space

• LIR sends request on behalf of PI customer• Complete ripe-141 as usual• Differences:

#[Request Overview Template]#PI-requested: YES

#[Network Template]#status: ASSIGNED PI

• Explain why the customer wants PI – aware of the consequences?


Evaluation of PI Request

• Conservative estimates– will NOT get more addresses (then needed) to prevent

routing problems• Classless • Assignment is only valid as long as original

criteria remain valid (ripe-185)

• After approval– RIPE NCC assigns a block from own range– RIPE NCC puts assignment in database

with RIPE-NCC-HM-PI-MNT


Example PI DB Entry inetnum: 194.1.208.0 - 194.1.215.255

netname: GOODY2SHOES-2

descr: Own Private Network 4 Goody2Shoes

descr: Amsterdam, Netherlands

country: NL

admin-c: PIBA2-RIPE

tech-c:JAJA1-RIPE

status: ASSIGNED PI

mnt-by: RIPE-NCC-HM-PI-MNT

mnt-by: BLUELIGHT-MNT

changed: [email protected] 19991111

source: RIPE


Renumbering

… is easy!


When to Send Renumbering Request?

• Customer(s) changing providers– already using address space– returning PA addresses to OldISP – renumbering to the PA range of NewISP

• Changing from PI (or UNSPECIFIED) to PA

• Only if amount is above LIR’s AW

• Procedure made easier to encourage renumbering

• More info: http://www.isi.edu/div7/pier/


Renumbering Request• Complete ripe-141 request form

• Double check current addresses in DB– whois -L <customer’s IP range> => UpstreamISP inetnum– whois -m <UpstreamISP range>

• Show how addresses were used• Show how new addresses will be used

• Time frame guidelines - 3 monthsaddress-space-returned: 195.100.35/24 to UpstreamISP1 in 20000901194.200.70/24 to UpstreamISP2 in 20001001...


Renumbering Many Customers

• If all ‘1-1’ renumberings– include all in one request form

• making procedure easier

– separate inetnum and addressing plan for each• “50% utilisation” guideline

• If not ‘1-1’ (customer will need more addresses)– send one request per customer


After the Return Date

• If you are the “new” ISP for this customer– encourage your customer to renumber their whole

network to your address space

• If you are the “old” ISP of this customer– make sure you remove data from RIPE Database

• Hostmasters send regular reminders


Questions?


Assignment Window Policies and Procedures


Assignment Window Policy

• Assignment Window– maximum amount of address space LIR can assign

without prior approval of the NCC initially AW equals zero gradually raised

• 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


Initially: AW=0

• SendEVERY customer’s request

and

EVERY request for assignment to your own infrastructure / network

to the RIPE NCC for evaluation

• Separate request forms needed• Do not send too many at the same time


When is AW Size Raised

• Understood procedures• Complete NCC documentation

• Experience– with RIPE Database– different policies– evaluating and processing requests

Not always automatically approach us


When is AW Size Lowered

• New staff need training

After negative auditing report

To enforce payment

To find out the AW size– asm-window line

– write to <[email protected]>


Assignment Window SizeAssignment Local IR Assignment limit

Window (host addresses)

AW =0 All new Registries

AW =/28 requests 16 addr



. . . . . .AW =/22 requests 1024 addr

AW =/21 requests 2048 addr … ...

AW size corresponds to average size of requests AW is per 12 months per customer

IncreasingResponsibilityof Local IR


Assignment Process Between Local IR’s and their customers


ask for moreDocumentation

LIR Evaluaterequest

no

yes

Gatheringinformation

Approach RIPE NCC

Evaluation

request > AW? need 2nd opinion?

yes

no

Finish the assignment

no

yes


Update RIPEdatabase

Assignment Process

Add Registry ID

Add comments &recommendations

Send to RIPE NCC<[email protected]>

Complete the request form

Update localrecords

Notifycustomer

Pick addresses

Wait foracknowledgement

RIPE NCCevaluates &

approves

( Finish the assignment )( Approach RIPE NCC )

( Finish the assignment )


Questions?


New allocation


Allocation Procedures

• ‘Slow Start’– 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

• Motivation for ‘slow start’– fair distribution of address space– keeps pace with customer base growth– slows down exhaustion of IPv4 address space


Motivation for ‘No Reservations’ Policy

• Def.: Address space set aside for future use • Reservations may never be claimed

– customers may need more (or less) address space than is reserved

• Administrative convenience not catered for

• Fragments address space =>– requesting new allocation appropriate when

previous allocated space used ~ 80% !


Requesting New Allocation

• Send request to <[email protected]> • NOT ripe-141 form• NEWBLOCK in subject line

– summary of addresses assigned / free– list assignments of the last allocation

Suggested format:

Allocation: 195.35.64.0/19 assigned: 7372 free: 820 Range Netname

195.35.64.0 - 195.35.65.191 BLUELIGHT-1

195.35.80.0 - 195.35.80.127 GODY2SHOES-1

195.35.80.128 - 195.35.80.159 CYB-FAL

195.35.88.0 - 195.35.88.31 ENGOS-1

...


Evaluation of New Allocation Request

• Are LIR’s records consistent with • RIPE NCC’s local records • RIPE database

– RIPE NCC wants to see 3 random requests

• Are all assignments valid?• within AW• correct netname attribute & the date

• Quality of RIPE DB records• up-to-date person & role objects• no overlapping inetnum objects

• Tool available: asused-public


Prior to Making New Allocation

• If inconsistencies are found– LIR will be asked to correct data first – AW is reviewed

• When data is corrected or deadline for correction is set– RIPE NCC

• allocates new block to LIR updates the DB

• LIR announces new prefix


Allocation inetnum Object

inetnum: 195.35.64.0 - 195.35.127.255netname: NL-BLUELIGHT-19990909descr: Provider Local Registrycountry: NLadmin-c: JJ231-RIPEtech-c: JAJA1-RIPEstatus: ALLOCATED PAmnt-by: RIPE-NCC-HM-MNTmnt-lower: BLUELIGHT-MNTchanged: [email protected] 19990909changed: [email protected] 20000303source: RIPE


Questions?


The End ...

• Reverse Delegation• AS Numbers• Advanced database issues

– protecting your data• Advanced reverse delegation

• Routing Registry

• Administrivia–audit activity, billing, closing LIR

• IPv6

… unless there is still some time for…


Reverse Delegation Procedures


What is Forward and Reverse DNS Delegation ?

• Forward Delegation– enables naming of IP hosts on the Internet– hierarchical authority for domain registration

• organisational structure

• Reverse Delegation– enables association of IP addresses with domain names– hierarchical authority for reverse zone

• depends on who distributed the address space

– reverse delegation takes place on octet boundaries (classful)


IN-ADDR.ARPA Domain . (ROOT)

edu

arpacom

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

(PTR www.bluelight.nl)

213 212 62217

amsterdam


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 – produce more useless network traffic in general


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 assignment of address space /24 reverse zone setup

on LIR or end-users nameserver(s), or both send domain object to <[email protected]>

• include Reg-ID


“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 NCC's only reference if

assignment approved • do NOT change netname without notifying

<[email protected]>

this is mentioned when we approve your IP requests

– registered after the approval date


/24 Reverse Zone Setup Recommendations

• At least two nameservers required– one nameserver setup as primary– at least one other as secondary

• SOA values reasonably RFC1912 compliant• Nameservers not on same physical subnet

– preferably with another provider

• Serial numbers YYYYMMDDnnn format


Example domain Object

domain: 80.35.195.in-addr.arpa

descr: Reverse delegation for Bluelight Customers

admin-c: JJ231-RIPE

tech-c: JAJA1-RIPE

zone-c: WF2121-RIPE

nserver: ns.bluelight.nl

nserver: ns2.bluelight.nl

mnt-by: BLUELIGHT-MNT


source: RIPE

*


Request the Delegation

• Send domain template to <[email protected]>

– an automatic mailbox

• Tool will– check assignment validity – check if zone is correctly setup– (try to) enter object to RIPE DB


Problems with inaddr Robot?

• Error report will be sent to requester– correct errors and re-send

• For questions see FAQ

• If error reports continue– contact <[email protected]>– please include the full error report


< /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)


$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-311 IN CNAME 1.0-31... ...31 IN CNAME 31.0-31

32 IN CNAME 32.32-7133 IN CNAME 33.32-71... ...71 IN CNAME 71.32-71

72 IN PTR www.qwerty.nl.

CNAME Example Zonefile at Provider Primary Nameserver


Questions?


Autonomous System Numbers


AS3

NEW

AS2

AS2

AS3

Policy Based Routing

Internet

Internet

end-user end-user

ISP

Regional Transit Provider Backbone Provider

BlueLight Goody2Shoes


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– 16 bit number

• RIR assigns unique AS number– for LIR or for the customer

* AS number, routing policy and originating routes are registered in the Routing Registry


How To Get an AS Number ?

• Complete request form: ripe-147 – aut-num object template

• contact person(s)

mntner object template– address space to be announced with this AS#

• Send to <[email protected]>– web syntax check: http://www.ripe.net/cgi-bin/web147cgi

• Being multihomed and routing policy are mandatory!


RIPE-181 Language• RIPE-181 used to describe routing policies• Developed in PRIDE project

– accepted in IRR and translated into RFC-1786

• Example syntax:aut-num: NEWas-out: to AS3 announce NEW

as-in: from AS2 200 accept AS2

• Cost defines the preference– the lower the cost, the more preferred route– cost relative per aut-num object


AS Example #1

NEW

aut-num: NEWas-out: to AS2 announce NEW

Internet

aut-num: AS3AS3

AS2

aut-num: AS2

as-out: to NEW announce ANY

as-in: from NEW 20 accept NEW

as-in: from AS3 100 accept ANYas-in: from AS2 10 accept AS2 as-out: to NEW announce AS2


as-out: to AS3 announce NEW


NEW

aut-num: NEWas-out: to AS2 announce NEW

Internet

aut-num: AS3AS3

AS2

aut-num: AS2

as-out: to NEW announce ANY


as-in: from AS3 100 accept ANYas-in: from AS2 10 accept AS2 as-out: to NEW announce AS2ANY

as-in: from AS2 200 accept ANY

AS Example #2


as-out: to AS3 announce NEW


Registration in RIPE Database• Evaluation

• RIPE NCC hostmaster - creates aut-num object (and maintainer)- informs requester

• User is responsible for keeping up to date– routing policy – referenced contact info (person/role, mntner)

• RIPE NCC hostmaster regularly checks consistency of data in Routing Registry


aut-num: NEWdescr: Bluelight AS#

as-in: from AS2 10 accept AS2 as-in: from AS2 200 accept ANY

as-in: from AS3 100 accept ANYas-out: to AS3 announce NEWas-out: to AS2 announce NEWdefault: AS2 5admin-c: JJ231-RIPEtech-c: JAJA1-RIPEmnt-by: NEW-MNTchanged: [email protected] 19991010source: RIPE

aut-num Object AS42

AS42 AS42

BLUELIGHT-MNT*


Questions?


Advanced Database Issues

• DB administration– using role object– updating– deleting

• Protection• Test Database


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


Role Object for Contact Persons

role: BlueLight Contact Roledescription: Hostmaster for Blue Light BVadmin-c: JAJA1-RIPEtech-c: AB321-RIPEtech-c: WF2121-RIPEemail: [email protected]: 24/7 phone number: +31-60-123-4567 nic-hdl: BL112-RIPEnotify: [email protected]: [email protected]: BLUELIGHT-MNTchanged:[email protected] 20000202source: RIPE


Inverse Lookups in RIPE DB• whois -i admin-c,tech-c,zone-c JAJA1-RIPE

– whois -i admin-c,tech-c,zone-c -T domain JAJA1-RIPE– whois -i zone-c JAJA1-RIPE– whois -r -i admin-c,tech-c -T role JAJA1-RIPE

• whois -i notify [email protected]

• whois -i notify [email protected]


Recursive Lookups

• whois 193.35.64.82 => inetnum,route,person(s)– whois -r 193.35.64.82 => inetnum, route– whois -T inetnum 193.35.64.82 => inetnum,persons– whois -r -T inetnum 193.35.64.82 => inetnum– whois -T route 193.35.64.82 => route

• whois 62.80.0.0 => inetnum, role, person– whois CREW-RIPE => role, persons– whois -r CREW-RIPE => role


DB Update Procedure

• Changing an object– make needed changes

– keep the same primary key

– add the changed line to the new version of object• value: email address and date

* do not forget authentication (password, PGP key)

Deleting an object– add delete line to the exact copy of current object

– value: email address, reason and date

– submit to the database


Inetnum: person:

195.35.64.80 JAJA1-RIPE JAJA1-RIPE

Case Study -- Replacing Tech-c1. whois -i tech-c JAJA1-RIPE

2. Create new person object (for Carl Dickens, new guy)

3. Change the tech-c reference in all inetnum objects

4. Delete old person object

CD2-RIPE

Inetnum:

195.35.64.130

JAJA1-RIPE

...CD2-RIPE

CD2-RIPE

person:


195.35.64.130

JJ231-RIPE

195.35.64.80

JJ231-RIPE

Replacing tech-c Using role Object

1. Create person object for each tech-c

2. Create role object for all tech-c:s

3. Change the tech-c reference in all inetnum

objects to reference role object

4. Keep role object up-to-date with staff changes

JJ231-RIPEBL112-RIPE

BL112-RIPE

... BL112-RIPECD2-RIPE

JJ231-RIPE

role:person:

CD2-RIPE

person:


Deleting an Object (example)

person: Piet Bakker

address: Goody 2 Shoes

address: Warmoesstraat 1

address: Amsterdam

phone: +31-20-666 6666

e-mail: [email protected]

nic-hdl: PIBA2-RIPE


source: RIPE

delete: [email protected] duplicate object 20000202


Protecting DB Objects


Notification / Authorisation

• notify attribute (optional)– sends notification of change to the email address

specified

mnt-by attribute & mntner object– objects that contain mnt-by must pass the

authentication rules in the mntner object

Hierarchical authorisation for inetnum & domain objects– mnt-lower attribute


How To Protect DB Data

• Read documents (ripe-157, ripe-189) choose authentication method

Create mntner object

• Existing objects must be changed– include mnt-by attribute referencing mntner object

• When creating new objects – include mnt-by attribute referencing mntner object


Authorisation Mechanism inetnum: 195.35.64.0 - 195.35.65.191

netname: BLUELIGHT-1

descr: Blue Light Internet…………..mnt-by: BLUELIGHT-MNT mntner: BLUELIGHT-MNTdescr: Maintainer for all Bluelight objectsadmin-c: JJ231-RIPEtech-c: BL112-RIPEauth: CRYPT-PW q5nd!~sfhk0#upd-to: [email protected]: [email protected]: BLUELIGHT-MNTchanged: [email protected] 19991112source: RIPE


Maintainer Object Attributes

auth attribute (mandatory, multiple)• upd-to attribute (mandatory)

– notification for failed updates

• mnt-by attribute (mandatory)– can reference the object itself

• mnt-nfy attribute (optional)– works like notify but for all objects that refer to this

maintainer object

• Manual registration of object necessary

• Send object to <[email protected]>


Authentication Methods

1. auth: NONE• could be used with mnt-nfy attribute

2. auth: MAIL-FROM {e-mail, reg-exp}– e.g. MAIL-FROM .*@bluelight\.nl

• protection from typos

3. auth: CRYPT-PW {encrypted password}• include password attribute in your updates

4. auth: PGP-KEY-<argument>key-cert object

see: ripe-190 & ripe-189

RIPE NCC can provide you with a licence for free


Hierarchical Authorisationinetnum: 195.35.64.0 - 195.35.95.255netname: NL-BLUELIGHT-19990909… ...status: ALLOCATED PAmnt-by: RIPE-NCC-HM-MNTmnt-lower: BLUELIGHT-MNTchanged: [email protected] 19990909changed: [email protected] 19991112source: TEST

• Ask <[email protected]> for mnt-lower attribute• mnt-lower protects

– only against creation – only one level below

• Include also in assignment inetnum objects


Test Database

• Non-production DB• Similar interface as “real” Database

– whois & email• whois -h test-whois.ripe.net ; [email protected]

– syntax checking – error reports

• Enable to submit your own maintainer• Ideal for testing

– various authorisation schemes– self-made scripts that update RIPE DB

• Source: TEST


Advanced Reverse Delegation


Reverse Delegation of Multiple /24

– for range of consecutive zones – represented in single inetnum object

• Shorthand notation for domain attributeinetnum: w.z.x.0 - w.z.y.255 212.73.10.0-212.73.15.255

domain: x-y.z.w.in-addr.arpa 10-15.73.212.in-addr.arpa

• Submit as one domain object• Processed separately• Separate response


Reverse Delegation of /16 Allocation

• If a 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– recommended use of the inaddr robot TEST keyword or web

check


Changing Delegation

• Change the nserver lines in domain object– submit domain object to <[email protected]>

• To change contact details in domain object– submit updated object to <[email protected]>

• Deleting a delegation is automatic– include delete attribute to the exact copy of the object– send to <[email protected]>


Common Errors

• DB / request inconsistency

(netname attribute, update date)• IP addresses instead of names of nameservers

in domain object• Trying to get reverse delegation for /19

allocation– has to be on octet boundaries– send request for each /24 as it becomes used

• DNS setup (RFC-1912)


Changes With New Robot

• Requests accepted only with Reg-ID• No RIPE DB updates necessary• No zone transfer necessary• Deletion requests handled (almost) automatically • Request for each zone processed separately• Successfully passed checks cached • Shorthand notation for ranges of objects• Delegation checks possible via web interface • LONGACK and CHANGE keywords no more


• nslookup (part of BIND)

• host

• dig

• More detailed info– http://www.dns.net/dnsrd/tools.html

Useful DNS Tools


Questions?


Routing Registry


Internet Routing Registry (IRR)• Goals of the IRR

– consistency and stability of routing – enable development of tools to use information

• Local IR responsibilities– register policy information in RR– maintain RR information

• Regional IR responsibilities– assigning Autonomous System Numbers– consistency checking of data– maintenance of RR support tools


Internet Routing Registry

• Globally distributed DB with routing policy information– provides a map of global routing policy– shows routing policy between any two ASes– allows simulation of routing policy effects– enables router configuration– provides contact information

• RIPE Routing Registry– subset of information in RIPE database– syntax description in ripe-181


Global Internet Routing Registry

RIPE RRAPNIC

RADB...

IRR

ARINC&W

http://www.radb.net/docs/list.html


Routing Registry Objects

• aut-num route as-macro

• community• dom-prefix • inet-rtr


The Route Object

route: 195.35.64/19 descr: BLUELIGHT-NET origin: AS42 mnt-by: BLUELIGHT-MNT changed: [email protected] 19991010 source: RIPE

• Represents a “route” in the Internet• This route originates in AS42• Only one origin recommended


“cross-mnt” Attribute in “aut-num” Object

route: 195.35.64/19origin: AS42[…]

route: 195.35.74/25 (new)origin: AS9999[…]

aut-num: AS42cross-mnt: BLUELIGHT-MNT[…]

mntner: BLUELIGHT-MNTmnt-nfy: [email protected][…]

<[email protected]> gets a notification


as-macro: AS-ARCON

descr: ARCON TML customers AS list

as-list: AS8955 AS6809 AS12500 AS-MACRO-B

tech-c: BZ318-RIPE

admin-c: VV82

mnt-by: ARCON-MNT


source: RIPE

as-macro


aut-num: AS8955descr: ARCON Autonomous System...as-out: to AS8563 announce AS-ARCONas-out: to AS2854 announce AS-ARCON...

aut-num: AS8563

descr: DirectNet Autonomous System

descr: JSC DirectNet Telecommunications

as-in: from AS8955 100 accept AS-ARCON

...

as-macro Usage


whois Flags in RR

• whois -T route 195.35.64/19

• whois -i origin AS42• whois -i mnt-by BLUELIGHT-MNT• whois -i cross-mnt BLUELIGHT-MNT

• whois -v as-macro

• whois -a <IP address or range>• whois -h whois.arin.net <IP address or range>


RR Tools• RAToolSet

• sources: http://www.isi.edu/ra/*– AS Object Editor (aoe)– Aggregation optimisation (CIDR Advisor)– Configuration (rtconfig)– Visualisation Tool (ASExplorer)

– IRRj http://www.merit.net/ipma/javairr/irr.html• java interface to IRR

– prtraceroute

• Looking glasses– http://www.ripe.net/cgi-bin/looking-glass– http://www.traceroute.org/


Special Projects(Part of RIPE NCC Public Services)

• Routing Information Service– collect routing information

• between Autonomous Systems (AS) • development over time

– information available to the RIPE community– improve network operations

• Routing Registry Consistency Project– improve data quality in the Internet routing registry– improve data accessibility and processing capabilities


Next Generation - RPSL

• New language is being developed: Routing Policy Specification Language– allows for more refined policy details– will eventually replace ripe-181– transition to RPSL will be smooth

• Test– rpslii.ripe.net

• Re-implementation – reimp.ripe.net at port 43

– <[email protected]>


Questions?


Administrivia

• Audit• Billing• Closing


Audit Motivation

• Audit Activity is a service– requested by the community– ensure equal treatment– LIR can ask for an audit

• Help LIRs to– keep RIPE Database tidy– keep up-to-date with new policies


Audit Activity

• Described in ripe-170• Initiated for

– infrequent contact with the RIPE NCC

– random selection

– referral by Hostmaster

– (anonymous) LIR complaint

• Audit procedure– LIR answers list of questions

– RIPE NCC check database


Audit Steps

• When LIR responds– discuss the issue(s) & try to resolve them– review AW size

• If LIR does not co-operate– send reminders & phone – still no reaction

• further actions taken


Billing Procedure• LIRs pay yearly fee (based on size)

– ripe-198

• If payment is late - email reminders– 1st phase - 4 weeks after the invoice

• no action taken

– 2nd phase - 2 weeks afterwards • lower AW to 0• mnt-lower on allocation

– 3rd phase - 2 weeks afterwards• service level NONE

– if still no payment …

• Discuss payment / invoices– <[email protected]>


Closing / Takeover of the Registry

1) Registry closes completely

2) Registry takes over another registry and one closes

3) Registry takes over another registry and both remain open

4) Non-registry takes over a registry ...

• Contact <[email protected]> for details• address space issues• billing issues

• new service agreement • No need to change current Reg-ID

• neither after company changes the name• additional ‘start-up’ fee is being charged


Questions?


IPv6


Why IPv6?

• Next generation protocol– scalability -- 128 bits addresses – security– dynamic hosts numbering

• Interoperable with IPv4• simple and smooth transition

– hardware vendors– applications


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


IPv6 Allocation Policies

• "Provisional IPv6 Assignment and Allocation Policy Document” (ripe-196)– discussion on [email protected] and [email protected]

• Bootstrap Phase CriteriaPeering with 3 Ases

AND

Plan to provide IPv6 services within 12 months

40 IPv4 customers

AND either OR

6bone experience


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/

• IANA allocations– APNIC 2001:0200::/23 (12 subTLAs)– ARIN 2001:0400::/23 ( 4 subTLAs)– RIPE NCC 2001:0600::/23 (19 subTLAs)


Database Object

inet6num: 2001:0600::/23netname: EU-ZZ-2001-0600descr: RIPE NCCdescr: European Regional Registrycountry: EUadmin-c: MK16-RIPEadmin-c: DK58tech-c: OPS4-RIPEstatus: SUBTLAmnt-by: RIPE-NCC-HM-MNTmnt-lower: RIPE-NCC-HM-MNTchanged: [email protected] 19990810source: RIPE


Questions?


Questionnaire

Please, complete the questionnaire

• precious feedback • constant improvement

Thank you

www.ripe.net/ripencc/mem-services/training/lir-questionnaire.html


RIPE NCCRecycling Procedures

Please return the reusable badges.

Thank you

[email protected]

welcome to the local internet registry tutorial

Documents

ripe ripe ncc

ripe nccwhat

ripe communityone

ripe ncc region3

databaseripe ncc activities

depletion of b space

c space solution classless

support service