Welcome to the Local Internet Registry Tutorial

1
Welcome to theLocal Internet Registry Tutorial
15 September 2000 Grand Ball Room, 1400-1730

RIPE Network Co-ordination Centre Vesna
Manojlovic ltBECHA_at_ripe.netgt, Eamonn McGuinness
lteamonn_at_ripe.netgt http//www.ripe.net/ripe/meetin
gs/archive/ripe-37/presentations/lir-tutorial/ ftp
//ftp.ripe.net/ripe/presentations/lir-tutorial-ri
pe37
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
• Customers Request
• Elementary evaluation
• RIPE Database
• Evaluation of specific assignment cases
• Large request
• PI request
• Renumbering
• Assignment Window
• New allocation

3
Introduction to RIPE NCC
4
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

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

6
RIPE NCC Activities (1)
Member Services

• Registration Services
• IPv4 addresses
• IPv6 addresses
• AS numbers
• LIR Training Courses
• lthostmaster_at_ripe.netgt
• Reverse domain name delegation
• NOT registering domain names

7
RIPE NCC Activities (2)
Public Services

• RIPE database maintenance
• Routing Registry Maintenance (RR)
• Co-ordination
• RIPE support
• Liaison with
• LIRs / RIRs / ICANN / etc
• Information dissemination
• New Projects
• Test Traffic Measurements
• Routing Information Service (RIS)
• Routing Registry Consistency (RR)

8
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
• Server whois.ripe.net
• UNIX command line queries
• http//www.ripe.net/ripencc/pub-services/db/

9
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

10
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

11
Questions?
12

• Terminology
• Global Registry System

13
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
14
Classful Notation
network
host
8
16,777,216
0
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

15
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 Cs
255.255.240.0
8192
/19
32 Cs
255.255.224
16384
/18
64 Cs
255.255.192
32768
/17
128 Cs
255.255.128
65536
/16
1 B
255.255.0.0
...
...
...
...
16
Goals of the Internet Registry System

• Aggregation
• Conservation
• Registration
• uniqueness

17
Regional Registry Structure
IANA / ICANN

RIPE NCC
ARIN
APNIC
Local IR / ISP
Enterprise Local IR
ISP
ISP / End user
End user
18
Service Regions
19
Questions?
20
Initial Administrivia of Becoming LIR
21
Becoming LIR

• Completed application form (ripe-212)
• Provided Reg-ID contact persons
• ltnew-lir_at_ripe.netgt
• Read relevant RIPE documents
• Signed contract (ripe-191)
• agreed to follow policies and procedures
• Paid the sign-up yearly fee
• ltbilling_at_ripe.netgt

22
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
• ltlocal-ir_at_ripe.netgt
• ltncc-co_at_ripe.netgt

23
Registry Identification (RegID)

• Distinguishes between contributing registries and
  individuals
• Format
• ltcountry codegt . ltregistry namegt
• Include with every message
• Suggestion - modify mail header
• X-NCC-RegID nl.bluelight
  
  

24
Questions?
25
New Registrys First Request

• Completing the request form
• Communication with the hostmaster

26
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 lthostmaster_at_ripe.netgt
• RIPE NCC evaluate and approve request
• With first assignment LIR automatically receives
  /20 allocation

27
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

28
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

29
Addressing Plan Template
dynamic dial-up Amsterdam web/mail/ftp servers
Amsterdam customers servers Amsterdam training
room LAN Amsterdam Amsterdam office LAN
(1) dynamic dial-up Utrecht web/mail/ftp
servers Utrecht Inet cafe Utrecht training room
LAN Utrecht
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.176 0.0.0.192 0.0.1.0 0.0.1.128
0.0.1.160 0.0.1.176
128 32 16 16 64 128 32 16
16 448
Relative Subnet Mask Size Imm 1yr 2yr
Description Prefix
100 10 8 14 24 0
0 14 0
100 12 10 14 35 100 12 14 0
100 16 13 14 50
100 25 14 10
170 297 342 Totals
(1) Office LAN workstations, router, 2
printers and 1 fileserver
30
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
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
31
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 Adam
• 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
32
Person template
Jan Jansen Blue Light Internet Oudezijds
Achterburgwal 13 Amsterdam The Netherlands
jan_at_bluelight.nl 31-20-555 5555 AUTO-1
BLUELIGHT-MNT jan_at_bluelight.nl 19990906 RIPE
person address address address address e-mail
phone nic-hdl mnt-by changed source


33
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 jan_at_bluelight.nl
19990906 RIPE
34
Communication with lthostmaster_at_ripe.netgt
35
Ticketing System

• Unique ticket number
• facilitates retrieval / archiving
• NCCYYYYMMXXXX
• e.g. NCC2000053280
• Check status of ticket on the web
• http//www.ripe.net/cgi-bin/rttquery
• open ncc
• open reg
• closed

36
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

37
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

38
Questions?
39
Customers Request

• Evaluation
• Basic Database Issues

40
Assignment Process
Gathering information
Completing ripe-141
Customer
no
Documentation completed?
yes
RIPE NCC evaluation
no
Documentation completed?
approval
notify customer
update local records
update RIPE database
? Assignment
41
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

42
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

43
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
• customers contact for LIR

44
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?

45
Evaluation -- Network Template

• inetnum value
• specifies the size of assignment
• actual range is not necessary
• Relevant netname
• descriptive uppercase letters, numbers -
• RIPE NCCs only reference to LIRs 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

46
Internal Administration

• Wait for approval from lthostmaster_at_ripe.netgt
  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

47
Creating Database Objects
48
Creating person Object

• Check if person object exists in RIPE DB
• whois persons name email address
• only one object per person
• Obtain and complete a template
• whois -t person
• -v (verbose)
• Send to ltauto-dbm_at_ripe.netgt
• Each person object has unique nic-hdl

49
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

50
nic-hdl

• Mandatory attribute
• Only way to clear ambiguity in person objects
• Format ltinitialsgtltnumbergt-ltregional registrygt
• e.g. AB123-APNIC, CD567-RIPE
• Combination of person name and nic-hdl is the
  primary key for person object
• Use AUTO- placeholders

person Jan van der Bruk ... nic-hdl
AUTO-initials
person Piet Bakker ... nic-hdl AUTO-1
AUTO-1JVDB
PB1234-RIPE
JVDB1-RIPE
51
ltauto-dbm_at_ripe.netgt 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 toltripe-dbm_at_ripe.netgt
• Include error report

52
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 ltauto-dbm_at_ripe.netgt
• with the keyword NEW in the subject line

53
Check Your Database Data

• Before you notify the customer
• whois customers IP range
• whois customers netname
• whois -m your allocated IP range
• will show your first level customer(s) network(s)
• whois -L customers IP range
• will show your own data

54
Example DB Query
whois -M 195.35.64.0/19 whois -m 195.35.64.0/19
195.35.64.0 - 195.35.95.255
195.35.64.0- 195.35.65.191
195.35.92.8/29 ENGO-8
195.35.92/29 ENGO-7
195.35.88/26
195.35.80/25
...
Goody2Shoes
eNGOs
Blue Light
whois -L 195.35.92.10
55
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

56
Questions?
57
Evaluation ofSpecific Assignment Cases

• Large Request
• PI request
• Renumbering

58
Large Request
59
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

60
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?

61
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

62
Sample Deployment Plan

• Needed when big expansion planned
• Matching addressing plan
• Relative Subnet Mask Size Imm. 1yr
  2yr Description
• Prefix
• 0.0.0.0 255.255.252.0 2048 0 1024 2048
  London POP
• 0.0.4.0 255.255.252.0 2048 0 1024 2048
  Berlin POP
• 0.0.8.0 255.255.252.0 2048 0 1024 2048
  Moscow POP
• 0.0.12.0 255.255.252.0 2048 0 1024 2048
  Paris POP

63
(New) Technologies

• If special hardware/software is used
• include the URLs of manufacturers 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
64
PI Request
65
PA vs. PI Assignments

• Provider Aggregatable
• customer uses addresses out of your 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
• Make contractual agreements
• ripe-127

66
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?

67
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

68
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 hostmaster_at_ripe.net 19991111
• source RIPE

69
Renumbering

• is easy!

70
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 LIRs AW
• Procedure made easier to encourage renumbering
• More info http//www.isi.edu/div7/pier/

71
Renumbering Request

• Complete ripe-141 request form
• Double check current addresses in DB
• whois -L ltcustomers IP rangegt gt UpstreamISP
  inetnum
• whois -m ltUpstreamISP rangegt
• Show how addresses were used
• Show how new addresses will be used
• Time frame guidelines - 3 months
• address-space-returned
• 195.100.35/24 to UpstreamISP1 in 20000901
• 194.200.70/24 to UpstreamISP2 in 20001001
• ...

72
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

73
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

74
Questions?
75
Assignment Window Policies and Procedures
76
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

77
Initially AW0

• Send
• EVERY customers 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

78
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

79
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 lthostmaster_at_ripe.netgt

80
Assignment Window Size

• Assignment Local IR Assignment limit
• Window (host addresses)
• AW 0 All new Registries
• AW /28 requests ?16 addr
• AW /27 requests ? 32 addr
• AW /26 requests ? 64 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

Increasing Responsibility of Local IR
81
Assignment Process

• Between Local IRs and their customers

no
Documentation completed?
ask for more Documentation
Gathering information
yes
LIR Evaluate request
Evaluation
no
no
need 2nd opinion?
yes
yes
Approach RIPE NCC
Finish the assignment
82
Assignment Process
( Finish the assignment )
( Approach RIPE NCC )
Pick addresses
Add comments recommendations
Update RIPE database
Send to RIPE NCC lthostmaster_at_ripe.netgt
Wait for acknowledgement
RIPE NCC evaluates approves
Notify customer
( Finish the assignment )
83
Questions?
84
New allocation
85
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

86
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 gt
• requesting new allocation appropriate when
  previous allocated space used 80 !

87
Requesting New Allocation

• Send request to lthostmaster_at_ripe.netgt
• 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
• ...

88
Evaluation of New Allocation Request

• Are LIRs records consistent with
• RIPE NCCs 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

89
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

90
Allocation inetnum Object

• inetnum 195.35.64.0 - 195.35.127.255
• netname NL-BLUELIGHT-19990909
• descr Provider Local Registry
• country NL
• admin-c JJ231-RIPE
• tech-c JAJA1-RIPE
• status ALLOCATED PA
• mnt-by RIPE-NCC-HM-MNT
• mnt-lower BLUELIGHT-MNT
• changed hostmaster_at_ripe.net 19990909
• changed hostmaster_at_ripe.net 20000303
• source RIPE

91
Questions?
92
The End ...
unless there is still some time for

• Reverse Delegation
• AS Numbers
• Advanced database issues
• protecting your data
• Advanced reverse delegation
• Routing Registry
• Administrivia
• audit activity, billing, closing LIR
• IPv6

93
Reverse Delegation Procedures
94
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)

95
IN-ADDR.ARPA Domain
. (ROOT)
nl
edu
arpa
net
com
bluelight
amsterdam
in-addr
www
195.35.65.130
195
193
194
213
212
217
62
35
Forward mapping
(A 195.35.65.1)
65
130 130.65.35.195.in-addr.arpa
Reverse mapping
(PTR www.bluelight.nl)
96
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

97
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 ltauto-inaddr_at_ripe.netgt
• include Reg-ID

98
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
  lthostmaster_at_ripe.netgt
• this is mentioned when we approve your IP
  requests
• registered after the approval date

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

100
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
• changed jan_at_bluelight.nl 19991110
• source RIPE

101
Request the Delegation

• Send domain template to ltauto-inaddr_at_ripe.netgt
• an automatic mailbox
• Tool will
• check assignment validity
• check if zone is correctly setup
• (try to) enter object to RIPE DB

102
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 ltinaddr_at_ripe.netgt
• please include the full error report

103
lt /24 Delegations

• Reverse delegation is also possible for a /24
  shared by more customers
• gt 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)

104
?CNAME Example Zonefile at Provider Primary
Nameserver

• 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
• 72 IN PTR www.qwerty.nl.

105
Questions?
106
Autonomous System Numbers
107
Policy Based Routing

• end-user end-user
• 
  
• 
  ISP
• 
  Regional Transit Provider
• Backbone
• Provider
• 
  BlueLight Goody2Shoes
• 
  

108
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

109
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 lthostmaster_at_ripe.netgt
• web syntax check http//www.ripe.net/cgi-bin/web1
  47cgi
• Being multihomed and routing policy are
  mandatory!

110
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 NEW
• as-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

111
AS Example 1
as-in from AS2 10 accept AS2 as-out to NEW
announce AS2
112
AS Example 2
as-in from AS2 10 accept AS2
as-out to NEW announce AS2
ANY
as-in from AS2 200 accept ANY
113
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

114
aut-num Object

• aut-num NEW
• descr Bluelight AS
• as-in from AS2 10 accept AS2
• as-in from AS2 200 accept ANY
• as-in from AS3 100 accept ANY
• as-out to AS3 announce NEW
• as-out to AS2 announce NEW
• default AS2 5
• admin-c JJ231-RIPE
• tech-c JAJA1-RIPE
• mnt-by NEW-MNT
• changed hostmaster_at_ripe.net 19991010
• source RIPE

AS42
AS42
AS42
BLUELIGHT-MNT

115
Questions?
116
Advanced Database Issues

• DB administration
• using role object
• updating
• deleting
• Protection
• Test Database

117
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

118
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_at_bluelight.nl
• trouble 24/7 phone number 31-60-123-4567
• nic-hdl BL112-RIPE
• notify hm-dbm-msgs_at_ripe.net
• notify auto-hm_at_bluelight.nl
• mntner BLUELIGHT-MNT
• changed hostmaster_at_bluelight.nl 20000202
• source RIPE

119
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 hm-dbm-msgs_at_ripe.net
• whois -i notify jan_at_bluelight.nl

120
Recursive Lookups

• whois 193.35.64.82 gt inetnum,route,person(s)
• whois -r 193.35.64.82 gt
  inetnum, route
• whois -T inetnum 193.35.64.82 gt
  inetnum,persons
• whois -r -T inetnum 193.35.64.82 gt inetnum
• whois -T route 193.35.64.82 gt route
• whois 62.80.0.0 gt inetnum, role, person
• whois CREW-RIPE gt role, persons
• whois -r CREW-RIPE gt role

121
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

122
Case Study -- Replacing Tech-c

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

Inetnum
person 195.35.64.80 JAJA1-RIPE
JAJA1-RIPE
person
...
Inetnum 195.35.64.130 JAJA1-RIPE
123
Replacing tech-c Using role Object

• 1. Create person object for each tech-c
• 2. Create role object for all tech-cs
• 3. Change the tech-c reference in all inetnum
• objects to reference role object
• 4. Keep role object up-to-date with staff changes

person
195.35.64.80 JJ231-RIPE
JJ231-RIPE
...
195.35.64.130 JJ231-RIPE
124
Deleting an Object (example)

• person Piet Bakker
• address Goody 2 Shoes
• address Warmoesstraat 1
• address Amsterdam
• phone [phone]
• e-mail piet_at_goody2shoes.nl
• nic-hdl PIBA2-RIPE
• changed jan_at_bluelight.nl 19991010
• source RIPE
• delete hostmaster_at_bluelight.nl duplicate object
  20000202

125
Protecting DB Objects
126
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

127
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

128
Authorisation Mechanism

• inetnum 195.35.64.0 - 195.35.65.191
• netname BLUELIGHT-1
• descr Blue Light Internet
• ..
• mnt-by BLUELIGHT-MNT
• mntner BLUELIGHT-MNT
• descr Maintainer for all Bluelight objects
• admin-c JJ231-RIPE
• tech-c BL112-RIPE
• auth CRYPT-PW q5nd!sfhk0
• upd-to hostmaster_at_bluelight.nl
• mnt-nfy auto-mnt_at_bluelight.nl
• mnt-by BLUELIGHT-MNT
• changed hostmaster_at_bluelight.nl 19991112
• source RIPE

129
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 ltripe-dbm_at_ripe.netgt

130
Authentication Methods

• 1. auth NONE
• could be used with mnt-nfy attribute
• 2. auth MAIL-FROM e-mail, reg-exp
• e.g. MAIL-FROM ._at_bluelight\.nl
• protection from typos
• 3. auth CRYPT-PW encrypted password
• include password attribute in your updates
• 4. auth PGP-KEY-ltargumentgt
• key-cert object
• see ripe-190 ripe-189
• RIPE NCC can provide you with a licence for free

131
Hierarchical Authorisation

• inetnum 195.35.64.0 - 195.35.95.255
• netname NL-BLUELIGHT-19990909
• ...
• status ALLOCATED PA
• mnt-by RIPE-NCC-HM-MNT
• mnt-lower BLUELIGHT-MNT
• changed hostmaster_at_ripe.net 19990909
• changed hostmaster_at_ripe.net 19991112
• source TEST
• Ask lthostmaster_at_ripe.netgt for mnt-lower attribute
• mnt-lower protects
• only against creation
• only one level below
• Include also in assignment inetnum objects

?
132
Test Database

• Non-production DB
• Similar interface as real Database
• whois email
• whois -h test-whois.ripe.net test-dbm_at_ripe.net
• 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

133
Advanced Reverse Delegation
134
Reverse Delegation of Multiple /24

• for range of consecutive zones
• represented in single inetnum object
• Shorthand notation for domain attribute
• inetnum 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

135
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

136
Changing Delegation

• Change the nserver lines in domain object
• submit domain object to ltauto-inaddr_at_ripe.netgt
• To change contact details in domain object
• submit updated object to ltauto-dbm_at_ripe.netgt
• Deleting a delegation is automatic
• include delete attribute to the exact copy of the
  object
• send to ltauto-inaddr_at_ripe.netgt

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

138
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

139
Useful DNS Tools

• nslookup (part of BIND)
• host
• dig
• More detailed info
• http//www.dns.net/dnsrd/tools.html

140
Questions?
141
Routing Registry
142
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

143
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

144
Global Internet Routing Registry
IRR
APNIC
RIPE RR
...
RADB
CW

ARIN
http//www.radb.net/docs/list.html
145
Routing Registry Objects

• aut-num
• route
• as-macro
• community
• dom-prefix
• inet-rtr

146
The Route Object

• route 195.35.64/19
• descr BLUELIGHT-NET
• origin AS42
• mnt-by BLUELIGHT-MNT
• changed hostmaster_at_bluelight.com 19991010
• source RIPE
• Represents a route in the Internet
• This route originates in AS42
• Only one origin recommended

147
cross-mnt Attribute in aut-num Object

• route 195.35.64/19
• origin AS42
• route 195.35.74/25 (new)
• origin AS9999
• aut-num AS42
• cross-mnt BLUELIGHT-MNT
• mntner BLUELIGHT-MNT
• mnt-nfy auto-mnt_at_bluelight.net
• ltauto-mnt_at_bluelight.netgt gets a notification

148
as-macro

• 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
• changed roman_at_itar-tass.com 19990914
• source RIPE

149
as-macro Usage

• aut-num AS8955
• descr ARCON Autonomous System
• ...
• as-out to AS8563 announce AS-ARCON
• as-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
• ...

150
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 ltIP address or rangegt
• whois -h whois.arin.net ltIP address or rangegt

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

152
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

153
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
• ltauto-rip_at_ripe.netgt

154
Questions?
155
Administrivia

• Audit
• Billing
• Closing

156
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

157
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

158
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

159
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
• ltbilling_at_ripe.netgt

160
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 lthostmaster_at_ripe.netgt 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

161
Questions?
162
IPv6
163
Why IPv6?

• Next generation protocol
• scalability -- 128 bits addresses
• security
• dynamic hosts numbering
• Interoperable with IPv4
• simple and smooth transition
• hardware vendors
• applications

164
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

165
IPv6 Allocation Policies

• "Provisional IPv6 Assignment and Allocation
  Policy Document (ripe-196)
• discussion on ipv6-wg_at_ripe.net and
  lir-wg_at_ripe.net
• Bootstrap Phase Criteria
• Peering with 3 ? Ases
• AND
• Plan to provide IPv6 services within 12 months
• ? 40 IPv4 customers
• AND either OR
• 6bone experience

166
IPv6 Allocations

• Request form (ripe-195)
• Slow start
• first allocation to a TLA Registry will be a /35
  block