Welcome to the Local Internet Registry Course - PowerPoint PPT Presentation

1 / 179
About This Presentation
Title:

Welcome to the Local Internet Registry Course

Description:

IPv4, IPv6, wireless connectivity meeting_at_ripe.net 12. Local ... most changes in the RR. user query scripts need re-writing. Everybody will be affected! ... – PowerPoint PPT presentation

Number of Views:172
Avg rating:3.0/5.0
Slides: 180
Provided by: vesn8
Category:

less

Transcript and Presenter's Notes

Title: Welcome to the Local Internet Registry Course


1
Welcome to theLocal Internet Registry Course

RIPE Network Co-ordination Centre
lttraining_at_ripe.netgt NEW version for RPSL
launch to be ready for 3rd April!!!
2
Logistics
  • Mobile phones, toilets, fire exits, parking,
    smoking places ...
  • Time line
  • breaks
  • lunch (vegetarians?)
  • early departures?
  • Material
  • slides
  • handouts
  • reference booklet
  • URLs included
  • trainers

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

4
Schedule
  • Evaluation of specific cases
  • Large request
  • PI request
  • Renumbering
  • 1500 tea break
  • New allocation
  • Advanced reverse delegation
  • Routing Registry
  • Administrivia
  • audit activity, billing, closing LIR
  • IPv6
  • 1700-1800 closing discussion
  • 900 Introduction
  • RIPE RIPE NCC
  • Initial Administrivia
  • First Request
  • 1100 coffee break
  • Customers Request
  • evaluation
  • RIPE Database
  • Reverse Delegation
  • AS Numbers
  • 1300 lunch
  • Advanced database issues
  • Assignment Window

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

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

9
Global Context
World-wide Internet Technical Development
Standards Body World-wide Operators
Forum
IETF
IEPG
NANOG
RIPE
APRICOT
10
How RIPE Works
  • RIPE chair ltchair_at_ripe.netgt
  • Chair is Rob Blokzijl (Nikhef)
  • How does it work?
  • working groups mailing lists
  • ltmajordomo_at_ripe.netgt
  • web archived
  • meetings
  • You make it possible!

11
RIPE Meetings
  • 3 times a year
  • RIPE 39, Bologna, Italy, 30 April - 4May 2001
  • RIPE 40, Prague, Czech Republic, 1-5 Oct. 2001
  • 4.5 day long
  • 300 participants
  • Working group meetings
  • Plenary
  • Presentations
  • Long breaks
  • Social events
  • Terminal room
  • IPv4, IPv6, wireless connectivity
  • ltmeeting_at_ripe.netgt

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

14
RIPE NCC History
  • Birth - April 1992
  • TERENA legal umbrella
  • Became RIR in September 1992
  • Contributing LIRs in 1995
  • In 1998 independent
  • A new structure (ripe-161)
  • not-for-profit association
  • General Assembly of all members
  • Executive Committee of elected nominees

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

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

17
Service Regions
18
RIPE NCC Services
  • Member Services
  • Registration Services
  • IPv4 addresses
  • IPv6 addresses
  • AS numbers
  • LIR Training Courses
  • lthostmaster_at_ripe.netgt
  • Reverse domain delegation
  • NOT registering domain names
  • Test Traffic Measurements
  • Public Services
  • RIPE whois database maintenance
  • Routing Registry Maintenance
  • Co-ordination
  • RIPE support
  • liaison with
  • LIRs / RIRs / ICANN - ASO/etc
  • Information dissemination
  • Maintenance of tools

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

20
Questions?
21
RIPE Database
  • Description
  • How to query the Database
  • How to create contact information objects

22
RIPE Database (1)
  • Public Network Management Database
  • Information about objects
  • IP address space inetnum, inet6num
  • reverse domains domain
  • routing policies route, aut-num
  • contact details person, role, mntner
  • Server whois.ripe.net
  • UNIX command line queries
  • http//www.ripe.net/ripencc/pub-services/db/

23
RIPE Database (2)
  • Software Management
  • RIPE NCC
  • Database Working Group (RIPE community)
  • Data Management
  • LIRs
  • other users
  • RIPE NCC
  • Information content not responsibility of RIPE
    NCC
  • Protection mechanisms not default, but strongly
    encouraged

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

25
Database Migration Time Line
  • 23-Apr-2001 switching to the RPSL database
  • queries return RPSL only
  • RIPE-181 updates possible automatically
    converted to RPSL
  • Date 23 April 14 May 15 October
  • --------------------------------------------------
    --------------------
  • RPSL auto-rpsl_at_ripe.net
    auto-dbm_at_ripe.net
  • RIPE-181auto-dbm_at_ripe.net auto-181_at_ripe.net
    N / A
  • 15-Oct-2001 RIPE-181 updates no longer possible

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

Example
28
Creating Database Objects
29
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
  • see The DB Transition Handout
    (23.4.01-15.10.01)
  • Each person object has unique nic-hdl

30
whois -t person
person mandatory single lookup
key address mandatory multiple phone
mandatory multiple fax-no optional
multiple e-mail optional multiple
lookup key nic-hdl mandatory single
primary/look-up key remarks optional
multiple notify optional multiple
inverse key mnt-by optional multiple
inverse key changed mandatory multiple
source mandatory single
31
nic-hdl
  • Mandatory attribute
  • Only way to clear ambiguity in person objects
  • Format 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-2JVDB
PB1234-RIPE
JVDB1-RIPE
32
Database Robot Responses
  • Successful update
  • acknowledgement
  • Warnings
  • object accepted but might be ambiguous
  • object corrected and accepted
  • Errors
  • object NOT corrected and NOT accepted
  • diagnostics in acknowledgement
  • If not clear send questions to ltripe-dbm_at_ripe.netgt
  • include error report

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

34
Role Object for Contact Persons
  • role BlueLight Contact Role
  • description Hostmaster for Blue Light BV
  • admin-c JAJA1-RIPE
  • tech-c AB321-RIPE
  • tech-c WF2121-RIPE
  • email hostmaster_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

35
Questions?
36
Setting up a Local Internet Registry
  • Becoming LIR
  • Terminology
  • First Request

37
Becoming LIR
  • Completed application form (ripe-212)
  • Provided Reg-ID contact persons
  • 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

38
Terminology
  • Allocation
  • address space given to registries which is held
    by them to assign to customers
  • Assignment
  • address space given to end-users for use in
    operational networks

/20 allocation 4096 addresses
assignment
assignment
39
Goals of the Internet Registry System
  • Aggregation
  • routability
  • .
  • Conservation
  • .
  • Registration
  • uniqueness
  • troubleshooting

40
Regional Registry Structure
IANA / ICANN

RIPE NCC
ARIN
APNIC
Local IR
Enterprise Local IR
ISP
End User
End User
41
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

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

43
Classless Notation
?
Addresses
Prefix
Classful
Net Mask
...
...
...
...
/29
8
255.255.255.248
16
/28
255.255.255.240
32
/27
255.255.255.224
64
/26
255.255.255.192
128
/25
255.255.255.128
256
/24
1 C
255.255.255.0
...
...
...
...
4096
/20
16 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
...
...
...
...
44
First Request
  • LIR wants a block of IP addresses
  • e.g. for own network / infrastructure
  • do not include needs of customers yet
  • no need to justify usage of the whole allocation
  • Steps
  • Complete request form ripe-141
  • Send request to lthostmaster_at_ripe.netgt
  • RIPE NCC evaluate and approve request
  • With the first ASSIGNMENT approved, RIPE NCC also
    makes an ALLOCATION
  • default minimum size /20 (4096 addresses)

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

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

47
Assignment Process
48
When to send a request
  • For your own infrastructure
  • leased lines
  • dial-up
  • p2p links
  • For each customer
  • 8 or more addresses
  • For ISP clients infrastructure
  • For ISP clients customers

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

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

51
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

52
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
53
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

54
Addressing Plan Template
Real needs
Concrete plans
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
55
Tips
  • Complete all the parts of the request
  • so-called templates
  • No wage descriptions
  • is dial-up is dynamic?
  • is web hosting name based?
  • Cumulative, total numbers in 1yr,2yr columns
  • Classless segment size

56
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
57
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 RIPE-NCC-NONE-MNT
jan_at_bluelight.nl 19990906 RIPE
58
Communication with lthostmaster_at_ripe.netgt
59
Contact Persons
  • Stored in RIPE NCC internal file for each
    registry
  • confidential
  • should be up-to-date write to ltlir-help_at_ripe.netgt
  • Only registered contact persons can
  • send requests to hostmasters
  • change contact information
  • Use role object
  • for multiple admin-c and tech-c
  • Always sign your e-mail messages
  • PGP optional (soon)
  • Members mailing lists
  • ltlocal-ir_at_ripe.netgt (lst-localir)
  • ltncc-co_at_ripe.netgt (lst-contrib)

60
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


61
Ticketing System
  • Unique ticket number
  • facilitates retrieval / archiving
  • NCCYYYYMMXXXX
  • e.g. NCC2001053280
  • Check status of ticket on the web
  • http//www.ripe.net/cgi-bin/rttquery
  • open ncc
  • open reg
  • closed
  • age of your ticket and oldest ticket in queue

62
Hostmaster-robot
  • Checks request form
  • Reg-ID, contact persons
  • syntax
  • policy problems
  • Acknowledgement diagnostics
  • LONGACK
  • Error message
  • correct re-send the request
  • use the same ticket number
  • NOAUTO
  • No errors hostmaster wait-queue
  • ongoings directly to hostmasters

63
Frequently Asked Questions
  • List of answers
  • http//www.ripe.net/ripencc/faq/index.html
  • Short tips and tricks
  • http//www.ripe.net/ripencc/tips/tips.html
  • Ask hostmaster
  • ltlir-help_at_ripe.netgt
  • include your Reg-ID
  • Supporting Notes for the European IP Address
    Space Request Form (ripe-142)

64
Questions?
65
Evaluation
66
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
67
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

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

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

70
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

71
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

72
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.248.0 2048 0 1024 2048
    London POP
  • 0.0.4.0 255.255.248.0 2048 0 1024 2048
    Berlin POP
  • 0.0.8.0 255.255.248.0 2048 0 1024 2048
    Moscow POP
  • 0.0.12.0 255.255.248.0 2048 0 1024 2048
    Paris POP

73
(New) Technologies
  • If special hardware/software is used
  • include the URLs of manufacturers sites if
    available
  • Special allocation and verification procedures
    apply
  • static dial up assignments
  • IP based virtual web hosting
  • cable modems, ADSL
  • GPRS?
  • recommended
  • investigate and implement dynamic assignment
    technologies whenever possible

STRONGLY DISCOURAGED
74
Evaluation -- Network Template
  • inetnum value (look-up key, unique)
  • specifies the size of assignment
  • actual range is not necessary
  • Relevant netname (look-up key, not unique)
  • 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
  • Protection is mandatory
  • mnt-by BLUELIGHT-MNT

75
Internal Administration
  • Wait for the approval from lthostmaster_at_ripe.netgt
    prior to assignment and registration
  • Decide on the range of addresses within your
    address space
  • classless assignment on bit boundary
  • Update local records for later reference
  • archive original documents with assignment

76
  • Address space is considered in use only if
    registered in the RIPE Database
  • Register all end-users separately
  • avoid overlapping inetnum objects

77
Assignments to (Small) ISPs
  • LIR cannot allocate address space to an ISP
  • If the customer of LIR is an ISP, distinguish
  • ISPs infrastructure
  • ISPs 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

example
78
Registering Address Spacein RIPE Database
79
Creating network object
  • AW0
  • take the network template from approved
    ripe-141 form
  • AWgt0
  • whois -t inetnum
  • Send to ltauto-dbm_at_ripe.netgt
  • see The DB Transition Handout
    (23.4.01-15.10.01)
  • with the keyword NEW in the subject line

80
Pay attention to...
  • insert the address range in the network
    template from the request form approved by the
    hostmasters
  • keep the same netname attribute
  • How to choose the netname
  • in the change attribute use current date
  • or leave out the date completely
  • protection is mandatory
  • mnt-by BLUELIGHT-MNT
  • recommended include mnt-lower

81
Querying Address Ranges
  • whois customers IP range
  • whois customers netname
  • not unique search key
  • whois -m your allocated IP range
  • will show list of all LIRs first level
    customer(s) network(s)
  • first level more specific address ranges
  • whois -L customers IP range
  • will show LIRs own allocation object

82
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
...
ENGOS
GOODY2SHOES
BLUELIGHT
whois -L 195.35.92.10
83
Questions?
84
Assignment Window Policies and Procedures
85
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

86
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

87
When is AW Size Raised
  • Understood procedures
  • Complete NCC documentation
  • Experience
  • with RIPE Database
  • different policies
  • evaluating and processing requests
  • Not always automatically raised
  • approach us

88
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 ltlir-help_at_ripe.netgt

89
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
90
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
91
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 )
92
Questions?
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

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.130)
65
130 130.65.35.195.in-addr.arpa
Reverse mapping
(PTR www.amsterdam.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 YYYYMMDDnn format

100
Example domain Objectwhois -t domain
  • 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
  • 73 IN PTR www.qwerty.nl.

105
? CNAME Example Zonefiles at Customers
Nameservers
  • ORIGIN 0-31.80.35.195.in-addr.arpa.
  • _at_ IN NS ns.goody2shoes.nl.
  • _at_ IN NS ns2.bluelight.nl.
  • 1 IN PTR www.goody2shoes.nl.
  • 2 IN PTR mail.goody2shoes.nl.
  • ... ...
  • 31 IN PTR kantoor.goody2shoes.nl.

ORIGIN 32-71.80.35.195.in-addr.arpa. _at_ IN NS
ns.cyberfalafel.nl. _at_ IN NS
ns2.bluelight.nl. 33 IN PTR www.cyberfalafel.nl.
... ... 70 IN PTR cafe3.cyberfalafel.nl.
106
Reverse Delegation of Multiple /24
  • for range of consecutive zones
  • possible also for sub-range
  • 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

107
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

108
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

109
Questions?
110
Autonomous System Numbers
111
Policy Based Routing
  • end-user end-user


  • ISP

  • Regional Transit Provider
  • Backbone
  • Provider

  • BlueLight Goody2Shoes


112
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

113
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

114
RPSL
  • Routing Policy Specification Language
  • allows for more refined policy details
  • allows hierarchical authentication
  • replacing ripe-181 language
  • Syntax
  • aut-num NEW
  • export to AS3 announce NEW
  • import from AS2
  • action pref120
  • accept ANY
  • pref defines ..

115
AS Example
import from AS2 action pref120 accept AS2
export to NEW announce AS2
ANY
import from AS2 action pref200 accept ANY
116
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
  • http//abcoude.ripe.net/ris/asinuse.cgi

117
aut-num Template
Object
  • aut-num NEW
  • descr Bluelight AS
  • import from AS2 action pref120
    accept AS2
  • import from AS3 action pref120
    accept ANY
  • import from AS2 action pref120
    accept ANY
  • export to AS2 announce NEW
  • export to AS3 announce NEW
  • 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
118
The Route Object
  • route 195.35.64/24
  • descr BLUELIGHT-NET
  • origin AS42
  • mnt-by BLUELIGHT-MNT
  • changed hostmaster_at_bluelight.com 19991010
  • source RIPE
  • Authorisation required when creating the object
  • mntner of the address space block
  • mntner of the originating ASN
  • mntner of the encompasing route object
  • mntner referenced in the object itself

119
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 RFC-2622
  • previously RIPE-181

120
Changes in RR with RPSL
  • New set objects
  • as-set (ex as-macro), route-set (ex community)
  • peering-set, filter-set, rtr-set, as-block
  • hierarchical set names
  • New attributes
  • member-of, mbrs-by-ref (implicit membership)
  • Reserved prefixes (RP)
  • AS-, RS-, RTRS-, FLTR-, PRNG-
  • RSP-Auth (RFC-2725)
  • stronger and hierarchical authorisation and
    authorisation
  • mnt-routes ltmnt_namegt rpsl list of prefixes
    ANY
  • referral-by ltmnt_namegt
  • auth-override YYYYMMDD

121
Questions?
122
Advanced Database Issues
  • DB administration
  • using role object
  • updating
  • deleting
  • Protection
  • Test Database

123
Inverse Lookups in RIPE DB
  • whois -i attribute value
  • 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 -i mnt-by BLUELIGHT-MNT
  • whois -i notify jan_at_bluelight.nl

124
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

125
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
  • keep the old changed lines in
  • 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

126
Changes with RPSL
  • Objects format - stricter syntax checks!!!
  • line continuation
  • attribute order is relevant
  • support for end of line comments
  • no empty attributes allowed
  • New flags for querying
  • Submission to the DB
  • MIME support
  • PGP support (GnuPG)
  • Access control to public and contact data

127
Case Study -- Contact Person Left
  • 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
...
Inetnum 195.35.64.130 JAJA1-RIPE
128
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
129
Deleting an Object (example)
  • person Piet Bakker
  • address Goody 2 Shoes
  • address Warmoesstraat 1
  • address Amsterdam
  • phone 31-20-666 6666
  • 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

Exact copy of the DB object
130
Protecting DB Objects
131
Notification / Authorisation
  • notify attribute (optional)
  • sends notification of change to the email address
    specified
  • mnt-by attribute mntner object
  • mnt-by mandatory (except dn, pn, ro)
  • Hierarchical authorisation for inetnum domain
    objects
  • mnt-lower attribute

132
How To Protect DB Data
  • Read documents (ripe-157, ripe-189)
  • choose authentication method
  • Create mntner object
  • Existing objects must be updated
  • include mnt-by attribute referencing mntner
    object
  • When creating new objects
  • include mnt-by attribute referencing mntner
    object
  • No mnt-by gt mnt-by RIPE-NCC-NONE-MNT

133
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 jan_at_bluelight.nl
  • mnt-nfy auto-mnt_at_bluelight.nl
  • referral-by RIPE-DBM-MNT
  • mnt-by BLUELIGHT-MNT
  • changed hostmaster_at_bluelight.nl 19991112
  • source RIPE

134
Maintainer Object Attributes
  • auth (mandatory, multiple)
  • upd-to (mandatory)
  • notification for failed updates
  • mnt-nfy (optional, encouraged)
  • works like notify but for all objects that refer
    to this maintainer object
  • mnt-by (mandatory)
  • can reference the object itself
  • referral-by (mandatory)
  • references mntner object that created this
    object
  • Manual registration of object necessary
  • Send object to ltripe-dbm_at_ripe.netgt

135
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
  • http//www.ripe.net/cgi-bin/cgicrypt.pl.cgi
  • 4. auth PGP-KEY-ltargumentgt
  • key-cert object
  • see ripe-190 ripe-189
  • RIPE NCC can provide you with a licence for free

136
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 19991111
  • source TEST
  • Ask ltlir-help_at_ripe.netgt for mnt-lower attribute
  • mnt-lower protects
  • only against creation
  • only one level below
  • Include also in assignment inetnum objects

?
137
DB protection and RPSL(summary)
  • referral-by attribute mandatory in mntner objects
  • references mntner object that created this
    object
  • in transition phase RIPE-DB-MNT
  • mnt-by mandatory attribute in all objects
  • except dn, pn, ro
  • in transition phase no mnt-by gt mnt-by
    RIPE-NCC-NONE-MNT
  • Reserved prefixes (RP)
  • n transition phase
  • mntner ltRPgtltmt_namegt gt mntner MNT-ltRPgtltmt_namegt

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

139
Questions?
140
Evaluation ofSpecific Assignment Cases
  • Large Request
  • PI request
  • Renumbering

141
Large Request
142
PI Request
143
PA vs. PI Assignments
  • Provider Aggregatable
  • customer uses addresses out of LIRs 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
  • example ripe-127
  • the only way to distinguish PA and PI space

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

145
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

146
Example PI DB Entry
  • inetnum 194.1.208.0 - 194.1.209.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-lowerRIPE-NCC-HM-PI-MNT
  • mnt-by BLUELIGHT-MNT
  • changed hostmaster_at_ripe.net 19991111
  • source RIPE

147
Renumbering
  • is easy!

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

149
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 20010510
  • 194.200.70/24 to UpstreamISP2 in 20010701
  • ...

150
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

151
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
  • RIPE NCC hostmasters send regular reminders
  • check return lines in your Reg file data

152
Questions?
153
New allocation
154
Allocation Procedures
  • Slow Start
  • default 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

155
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 !

156
Requesting New Allocation
  • Send e-mail to lthostmaster_at_ripe.netgt
  • NOT ripe-141 form
  • NEWBLOCK in the subject line for higher priority
  • 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 GOODY2SHOES-1
  • 195.35.80.128 - 195.35.80.159 CYB-FAL
  • 195.35.88.0 - 195.35.88.31 ENGOS-1
Write a Comment
User Comments (0)
About PowerShow.com