local internet registries. training course. 1 welcome to the local internet registry course ripe...

1Local Internet Registries . Training Course . http://www.ripe.net

Welcome to theLocal Internet Registry

Course

RIPE Network Co-ordination Centre

<[email protected]>

NEW version for RPSL launchto be ready for 3rd April!!!

Local Internet Registries . Training Course . http://www.ripe.net 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


Method and Notations• Flow of the content

– material divided into sections– 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


Schedule9:30 Introduction

• RIPE & RIPE NCC• Basic RIPE Database

– querying DB– creating person/role object

• Initial Administrivia– setting up the LIR– terminology– first request

• Requesting Address Space– assignment process– completing the request form– communication with hostmasters

11:00 coffee break• Evaluation of requests

– policies– administering your allocation

•DB•how to create network object•advanced queries

•Assignment Window13:00 lunch

• Reverse Delegation• AS Numbers

15:00 tea break•Advanced database issues

–updating objects–protecting objects

• New allocation• PI Request

• IPv6


Course Background ?

• Course objective - to make LIR’s life easier by– explaining how RIPE NCC does it’s job– teaching how LIRs can interact with RIPE NCC– bringing the latest details about policies– listening to comments and input form LIRs

• Discovering faces behind e-mail addresses• History and background

– given since 1995– in whole RIPE NCC service region– but in English– paid as a part of startup fee


RIPE and RIPE NCC


RIPE and RIPE NCC

• Réseaux IP Européens (1989)– RIPE is a collaborative organisation open to all

parties interested in Internet administration, development and network operations

• RIPE Network Co-ordination Centre– membership organisation which supports its

members and RIPE community– one of 3 Regional Internet Registries (RIR)


Introduction to RIPE


How RIPE Works • RIPE works as

– open forum– voluntary participation– decisions made by consensus– meetings– working groups mailing lists

• <[email protected]>• web archived

– NO legal power does NOT develop Internet Standards

• RIPE chair <[email protected]>


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


Introduction to


RIPE NCC History

• Actions agreed in RIPE community needed– continuity and professionalism

– neutrality and impartiality

• 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


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


Vital Statistics• Statistics 1992

– 3 staff members– No Local IR’s– 182,528 hosts in European Internet– 7,955 objects in RIPE database (June ‘92)

• Statistics Now– 67 staff (22 nationalities) 2,595+ participating Local IR’s 12,088,135+ countable hosts in the RIPE NCC region 3,792,085+ objects in the database


Service Regions


RIPE NCC Services

• Member Services• Registration Services

– IPv4 addresses

– IPv6 addresses

– AS numbers

– LIR Training Courses

• <[email protected]>

• Reverse domain delegation– NOT registering domain names

• Test Traffic Measurements

Public Services RIPE whois DB maintenance

Routing Registry Maintenance

• Co-ordination– RIPE support

– liaison with:• LIRs / RIRs / ICANN - ASO/etc

• Information dissemination• New Projects

– RIS, R2C2, DISI

• Maintenance of tools


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?


RIPE Database

•Description•How to query the Database•How to create contact information objects


RIPE Database Intro

• Public Network Management Database• 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


Migration to DB Version 3

• Re-implementation of DB software– re-written server and client – Routing Policy Specification Language

• RPSL compliant (RFC-2622)– 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/


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

RIPE-181|[email protected] | [email protected] | N / A

• 15-Oct-2001: RIPE-181 updates no longer possible


Querying RIPE Database


Object Types

• Information about objectsIP 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/db/

• Most important documents– ripe-157, ripe-181


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-c, tech-c, zone-c,

Examples


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]> see “The DB Transition Handout” (23.4.01-15.10.01)

• Each person and role object has unique nic-hdl

Transitionto RPSL


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


role: Technical BlueLight Staff ...nic-hdl: AUTO-#initials

AUTO-2BL

nic-hdl

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

• Format: <initials>[number]-<regional registry>– e.g. AB123-APNIC, CD567-RIPE

• Used in all the attributes where contact info needed• nic-hdl is the primary key for person and role objects

Use “AUTO-#” placeholders

BL112-RIPE


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 <[email protected]>– include error report


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


Usage of role Objects

• To describe the group of technical contacts• To describe the contact persons for LIR• Steps:

– create one person object per staff– create role object and reference all person objects – use role object nic-hdl in tech-c attribute

• Use trouble and notify attributes


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


Creating Maintainer Object

• Protection of objects mandatory• except for person, role and domain

– updates of objects that contain mnt-by attribute must pass the authentication rules in the mntner object

• 1) Decide on the authentication method– ripe-157, ripe-189, ripe-190 documents

• 2) Complete the object template– whois -t mntner

• 3) Manual registration necessary– send the object to <[email protected]>– requester need to be from the LIR

See also: Protection of RIPE DB objects


Creating DB Objects(Summary)

• Steps:– 1) complete the object template– 2) send in email to <[email protected]>

• See also:– creating inetnum objects– querying RIPE DB– protection of DB objects– updating DB information


Questions?


Initial Administrative Details

• Becoming LIR

• Terminology

• First Request


Setting up LIR

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

– <[email protected]>

Read relevant RIPE documents– ripe-185 etc

• Signed contract (ripe-191)– agreed to follow policies and procedures

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


Terminology

• Allocation– address space given to registries which is held by them

to assign to customers or to own organisation• Assignment

– address space given to end-users for use in operational networks

– also called: ticket, request, approval, network, block, range, object

assignment

/20 allocation = 4096 addresses

assignment

Set aside?


Goals of the Internet Registry System

Responsibilities of Local Internet Registries

• Aggregation– routability– ...

• Conservation– determine operational needs– prevent stockpiling addresses

• Registration– uniqueness– troubleshooting


Internet Registry Structure

IANA / ICANN

RIPE NCCARIN APNIC

EnterpriseLIR

Local IRRegistry

ISP

End UserEnd User


Obsolete 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


• 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

History of IP Addressing


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


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 <[email protected]> RIPE NCC evaluate and approve request

• With the first ASSIGNMENT approved, RIPE NCC also makes an ALLOCATION– default minimum size /20 (4096 addresses)


First Request Approved

RIPE NCC hostmaster enters allocation and assignment objects into the RIPE database – only at the first request- /24 & /25 & /26 (448) instead of /23 (512)- at the beginning of the block (can be modified later)- with RIPE-NCC-NONE-MNT (or LIR mntner)

• Whole allocated range can be announced immediately

• AW=0– Every request has to be sent to RIPE NCC for approval

New in RPSL!


Requesting the Address Space

• Assignment Process

• Completing the request form

• Communication with the hostmaster

• Answers from the HM robot

• Creating DB objects


Assignment Process


Assignment Process (TXT)• 1. Gather information• 2. Complete the request form• 3. Send it to the HM (robot) <[email protected]>

– wait for 2-7 days

• 4. Read the answer• and correct errors• 5. Re-send, using the same ticket number

– (message without errors goes to the wait q)

6. Answer the questions from HM staff (Evaluation loop)– (wait for approval)

7. Choose address range

8. Register network in the RIPE Database


When to Send a Request

• For your own infrastructure – one block of many clients with 4 or less IPs per client

• leased lines• dial-up• p2p links (???)• web hosting

• For each customer– more then /30

• For ISP-client’s infrastructure• For ISP-client’s customers• => Separate request form needed


Request Formhttp://www.ripe.net/docs/ripe-141.html

I. General InformationOverview of Organisation

Contact Information

Current Address Space Usage

II. The RequestRequest Overview

Addressing Plan

III. Database Information

IV. Optional Information


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

• Frequently asked questions• http://www.ripe.net/ripencc/faq/

• Short tips and tricks• http://www.ripe.net/ripencc/tips/tips.html

•Link to:


Tips for Completing the Request Form

• Complete all the “templates”– otherwise hostmasters will ask you questions

• Add additional information– help us understand your (client’s) network– more info, less questions to ask!

• All the data communicated with RIPE NCC is kept strictly confidential

• Documentation for RIPE NCC has to be in English


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


#[ 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 addressesAll segments in use


Design of the Network• How many physical segments it will consist of?

– each described in the separate row in the Addressing Plan– equal to the number of subnets-year-2

• What is each segment going to be used for? (“Description”)– including equipment used

• How many network interfaces in each segment? (“Imm”)• Expectations of growth? (“1yr”, “2yr”)

– cumulative, total numbers– plan for the network to grow!

• Classless segment size (“Size”)– minimum CIDR block that contains number of hosts in “2yr”– add 2 more “loopback” and “broadcast” for small networks

• Relative prefix starts from all zeroes– starting address for each segment


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 Cumulative, total numbers

Real needs Concrete plans


#[ 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”


#[ Network template ]#

inetnum:netname:descr:

country:admin-c:tech-c:status:mnt-by:changed:source:

BLUELIGHT Company infrastructure in both locations NL AB231-RIPE JJ213-RIPE ASSIGNED PA RIPE-NCC-NONE-MNT [email protected] RIPE

*New in RPSL!

Notice: no date needed!

Notice: no value needed!


Communication with Registration Services

(link back to the Assignment Process)


LIR Contact Persons Stored in RIPE NCC internal file for each registry

– confidential

• To keep them be up-to-date– write to <[email protected]>– not automatically updated from the RIPE Database! – use role object: notify: [email protected]

• Only registered contact persons can – send requests to hostmasters– change contact information

• Always sign your e-mail messages– PGP optional (soon)

Members’ mailing lists – not majordomo maintained

– <[email protected]> (lst-localir) ; <[email protected]> (lst-contrib)


Registry Identification (RegID)

• Distinguishes between member registries and individuals

• Format <country code> . <registry name>

• Include with every message

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


RIPE NCC Mailboxes

• <[email protected]>– IPv4, IPv6, ASN requests

– ticketised

– …

• <[email protected]>– updating contact information

– updating allocation inetnum objects

– updating PI assignment objects info

– questions unrelated to address space requests

– …

• Always include Reg-ID


Ticketing System

• Unique ticket number per request– given by the robot upon receiving email without one– facilitates retrieval / archiving– format: NCC#YYYYMMXXXX e.g. NCC#2001053280

• Check status of your 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– list of the headers of all the messages exchanged

Example


Hostmaster-robot

• Checks request form– Reg-ID, contact persons– syntax

• e.g. missing templates, cross-template inconsistencies

– policy problems• e.g. inefficient usage

• Acknowledgement & diagnostics– please read very carefully– use LONGACK for more detailed info– in case of questions, ask <[email protected]>

• Warnings– …………..


HM Robot Error Response• Error message

– the request/ticket is NOT sent to the wait-queue – necessary to correct & re-send the request– use the same ticket number

• HOW??? HM - have you tried this??– NOAUTO to bypass further robot checks

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

• Next step: evaluation• human hostmasters will ask you additional questions

– followed by approval


Questions?


Evaluation(link to the assignment process)

We saw HOW to complete the request form,

now we will see WHY

- what policies apply

- what questions might HM staff ask

- what do you need to ask your customers


#[ Current Address Space Usage ]#Evaluation

• Are there any previous assignments?– also from other LIRs

• ALL active previous assignments need to be specified

• Investigate by querying the RIPE Database– see Section “Querying the RIPE DB”

• Can request be fulfilled with previous assignment?


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

in “Request Overview”? – OUT?! ROBOT WILL CHECK THIS??

• Are all subnets classless?– segments do not need to be one CIDR block (Leo?)

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

– 1yr and 2yr periods can be adjusted to your planing• Can address space be conserved by using

– different subnet sizes?


(New) Technologies

• If special hardware/software is used• include the URLs of manufacturer’s 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


Different “Policies”

• ADSL?

• All the policies specified in ripe-185 document– to influence the policy, take part in [email protected]


Motivation for ‘No Reservations’ Policy

• Def.: Address space set aside for future use – internal reservations

• space between two assignments within allocation

– requested reservations• zero segments in the “Addressing Plan”

• RIPE NCC does not approve requested reservations– administrative convenience not catered for– 2 year network growth planning sufficient

• But, LIRs are free to make internal reservations– See “Administering your allocation”


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


Possible Additional Information

• Include pointer to web site

Deployment plan purchase/delivery receipts

Topology map (design of the network)

• Additional info can be faxed– handled and kept confidentially – include ticket number and Reg-ID


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

– but providing more detailsRelative Subnet Mask Size Imm. 1yr 2yr DescriptionPrefix0.0.0.0 255.255.248.0 2048 0 1024 2048 London POP0.0.4.0 255.255.248.0 2048 0 1024 2048 Berlin POP0.0.8.0 255.255.248.0 2048 0 1024 2048 Moscow POP0.0.12.0 255.255.248.0 2048 0 1024 2048 Paris POPPlannedoperationalDate

DateEquipmentordered

Type of Equipment

Number of hosts

Location

01/200203/200203/200207/2002

02/200105/200105/2001--------

modemsmodemsmodemsmodems

2048204820482048

LondonBerlinParisMoscow


Renumbering Request

• Mention explicitly that customer is already using addresses• Customer(s) changing providers

• returning PA addresses to OldISP • renumbering to the PA range of NewISP

– encourage customer to renumber whole network to new addresses

• Changing from PI (or UNSPECIFIED) to PA

• Send a request if amount is above LIR’s AW

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


Renumbering Many Customers

• Procedure made easier to encourage renumbering

– DHCP recommended when setting up the network

• If all ‘1-1’ renumberings– include all in one request form– separate inetnum and addressing plan for each

• “50% utilisation” guideline

• After the return date– If you are previous ISP of this customer

• make sure you remove old data from RIPE Database

– RIPE NCC hostmasters send regular reminders

check ‘return’ lines in your “Reg file” data

??????????


Evaluation -- Network Template Relevant netname

• Contact persons– need to be registered as person objects beforehand– can be multiple– reference nic-hdls (may be a role object)– admin-c

• responsible for the network, able to make decisions• on site

– tech-c• technical setup of the network• can be from LIR, or contractor, or from client’s site


How to Choose a netname

• Look-up key, not unique

• Syntax: uppercase letters, numbers & “-”• Hints

– [LIR name]-[client’s_name]-{type_of_service, location}– do not use the same netname for different clients – use the same netname for multiple assignments to the

same client• RIPE NCC’s only reference to LIR’s assignment (AW=0)

– keep the approved netname when creating DB object– checked during reverse delegation, new allocation, AW

and audit procedures


… approval (link to the assignment process)

and then:

Choosing the Address Range


• Wait for the approval 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

Assignment for customer’s network

Assignment for LIR’s network

Internal Administration


• Aggregate within your allocation• Sensible internal reservations

– keep free space for some customers to grow– but - may never be claimed– fragments address space =>

• requesting new allocation appropriate when previous allocated space used ~ 80% !

• Divide your allocation based on types of services• Divide your allocation based on locations • But - LIR can have only one “open” allocation

– open = more then 20% unused space

How to Administer Allocation


Assignments to (Small) ISPs

• LIR cannot allocate address space to an ISP • If the customer of LIR is an ISP, distinguish

– ISP’s infrastructure

– ISP’s customers

• Separate assignments need to be– requested

– evaluated / approved

– registered in the RIPE Database

Avoid overlapping assignments – i.e. “big” assignment/object for ISP & all its customers,

plus for separate customers


Non-Overlapping Assignments

195.35.64.0-

195.35.65.191195.35.88/26

195.35.64.0 -

195.35.95.255

195.35.80/25

BLUELIGHT GOODY2SHOES ENGOS ...195.35.92/29

ENGO-7

195.35.92.8/29

ENGO-8

wrong!


Questions?


Registering Address Spacein the RIPE Database


• Address space is considered in use only if registered in the RIPE Database– to provide contact info for troubleshooting– to enable overview of address space used– assignment is “valid” only in (correctly) registered

• Register all end-user networks separately– avoid overlapping inetnum objects – by default, database will not prevent creation of

overlapping inetnum objects


Creating network object

• AW=0– take the “network template” from approved ripe-141

form

• AW>0– whois -t inetnum

• Send to <[email protected]> see “The DB Transition Handout” (23.4.01-15.10.01)

– with the keyword NEW in the subject line• to avoid over-writing the existing objects • (address range is the primary key for inetnum)

Transition to RPSL!


inetnum Object Templateinetnum: [mandatory] [single] [primary/look-up key]netname: [mandatory] [single] [lookup key]descr: [mandatory] [multiple] [ ]country: [mandatory] [multiple] [ ]admin-c: [mandatory] [multiple] [inverse key]tech-c: [mandatory] [multiple] [inverse key]rev-srv: [optional] [multiple] [inverse key]status: [generated] [single] [ ]remarks: [optional] [multiple] [ ]notify: [optional] [multiple] [inverse key]mnt-by: [mandatory] [multiple] [inverse key]mnt-lower: [optional] [multiple] [inverse key]mnt-routes: [optional] [single] [inverse key]changed: [mandatory] [multiple] [ ]source: [mandatory] [single] [ ]


Pay attention to...• Insert the address range

– in the ‘network template’ from the approved request form

– can not be in prefix notation!

• Keep the same netname attribute as approved– or see “How to Choose a netname”

• In the change attribute leave out the date– DB will add the current date

Protection is mandatory • mnt-by: BLUELIGHT-MNT

Recommended: include mnt-lower

New in RPSL!


Most Common Warnings and Errors


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 supports:

– MIME – PGP (GnuPG)

• Access control to “public” and “contact” data

New in RPSL!


Questions?


Querying Address Ranges


Querying Address Ranges

– whois [customer’s IP range]– whois [customer’s netname]

• not unique search key

– whois -m [your allocated IP range]• will show list of all LIR’s first level customer(s) network(s)• first level more specific address ranges

– whois -L [customer’s IP range]• will show LIR’s own allocation object

• EXAMPLES!! Web interface!


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

BLUELIGHT 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


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


RIPE DB Flags

• -h• … (NEW ONES!)


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

• All approved assignments registered • Policies understood, procedures followed• Valid DB objects are

– approved, with correct• netname• size• date

– unapproved - must be within AW size Complete documentation with requests AW not always automatically raised

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 for LIR, and not for person or company AW is per 12 months per customer

IncreasingResponsibilityof Local IR


LIR Responsibilities With the AW• Evaluate all the requests within your AW size

– implement all the polices from ripe-185 document– make classless, conservative assignments– implement dynamic solutions when possible

• promote NAT, DHCP, http1.1, dynamic dial-up...

• Keep all the documentation about your decisions– useful for administration, and if client comes back– RIPE NCC might ask for it later

• Register all the assigned networks in RIPE DB– choose appropriate netname

• Chase the previous ISP after renumbering– to delete the outdated DB objects


Assignment Process With AW

Between Local IR’s and their customers

Documentationcompleted?

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 With AW (cont’d)

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?


Reverse Delegation Procedures

• /24 zone• Smaller zone• Multiple /24 zones• /16 zone


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


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

(PTR www.amsterdam.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 YYYYMMDDnn format• Use IP address instead of name of nameserver • Do NOT use rev-srv attribute in inetnum object


Example domain Objectwhois -t domain

domain: 80.35.195.in-addr.arpa

descr: Reverse delegation for Bluelight Customers

SPLITBLOCK

admin-c: JJ231-RIPE

tech-c: JAJA1-RIPE

zone-c: WF2121-RIPE

nserver: ns.bluelight.nl

nserver: ns2.bluelight.nl

mnt-by: BLUELIGHT-MNT

changed: [email protected]

source: RIPE

*Notice: no date needed!


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

73 IN PTR www.qwerty.nl.

CNAME Example Zonefile at Provider Primary Nameserver


CNAME Example Zonefiles at Customers’ Nameservers

$ORIGIN 0-31.80.35.195.in-addr.arpa.

@ IN NS ns.goody2shoes.nl.@ IN NS ns2.bluelight.nl.

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.

@ IN NS ns.cyberfalafel.nl.@ IN NS ns2.bluelight.nl.

33 IN PTR www.cyberfalafel.nl.... ...70 IN PTR cafe3.cyberfalafel.nl.


Reverse Delegation of Multiple /24

– for range of consecutive zones • possible also for sub-range

– if 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

• Recommended


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]>– NOT enough to update the object in RIPE DB!

• Deleting a delegation is automatic– include delete attribute to the exact copy of the object

– send to <[email protected]>

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


Summary of the Process

• 1) Assign address space• 2) Zone setup on the nameservers• 3) Complete the domain object template• 4) Send the domain object to

<[email protected]>

• nurani??


Questions?


Autonomous System Numbers

•It is assumed that attendee is familiar with BGP routing, and have interest in obtaining public ASN


AS3

AS2

AS2

AS3

Policy Based Routing

Internet

Internet

NEW

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


RPSL• Routing Policy Specification Language

– allows for more refined policy details– allows hierarchical authentication – replacing ripe-181 language

• Syntaxaut-num: NEW

export: to AS3 announce NEW

import: from AS2

action pref=120;

accept ANY

• pref defines ….. RPSL!


AS2

aut-num: AS2

import: from AS2 action pref=120; accept AS2 export: to NEW announce AS2

AS Example

NEWaut-num: NEWexport: to AS2 announce NEW

Internet

aut-num: AS3AS3 export: to NEW announce ANY

import: from NEW action pref=120; accept NEW

import: from AS3 action pref=100; accept ANY

import: from NEW action pref=120;

accept NEW

export: to AS3 announce NEWANY

import: from AS2 action pref=200; accept ANY


Evaluation of ASN Request

• What address space will be announced?• How long it will take you to achieve

multihomed status?• Is it feasible to peer with specified ASNs?

• (etc.. HM!!)


Registration in RIPE Database

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

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

• RIPE NCC hostmaster regularly checks consistency of data in Routing Registry– http://abcoude.ripe.net/ris/asinuse.cgi


aut-num: NEWdescr: Bluelight AS#

import: from AS2 action pref=120; accept AS2 import: from AS3 action pref=120; accept ANY import: from AS2 action pref=120; accept ANY

export: to AS2 announce NEW export: to AS3 announce NEW admin-c: JJ231-RIPE

tech-c: JAJA1-RIPEmnt-by: NEW-MNTchanged: [email protected] 19991010source: RIPE

aut-num TemplateAS42

AS42

AS42

BLUELIGHT-MNT

Object RPSL!


The Route Object

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

• Authorisation required when creating the object– mntner of the address space block– mntner of the originating ASN– mntner of the encompassing route object– mntner referenced in the object itself

New inRPSL!


Internet Routing Registry

• Globally distributed DB with routing policy information– provides a map of global routing policy (ASExplorer)– shows routing policy between any two ASes (prpath)– allows simulation of routing policy effects – enables creation of aut-num based on router conf (aoe)– enables router configuration (rtconfig)– provides contact information (whois)

• RIPE Routing Registry– subset of information in RIPE database– syntax description in RFC-2622

• previously RIPE-181 RPSL!


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: <mnt_name> [ rpsl list of prefixes | ANY]• referral-by: <mnt_name>• auth-override: YYYYMMDD

RPSL!


aut-num Changes in RPSLaut-num: [mandatory] [single] [primary/look-up key]as-name: [mandatory] [single]descr: [mandatory] [multiple]as-in: [optional] [multiple] [ ] as-out: [optional] [multiple] [ ] interas-in: [optional] [multiple] [ ] interas-out: [optional] [multiple] [ ] as-exclude: [optional] [multiple] [ ] member-of: [optional] [multiple] [inverse key] *** New in RPSL *** import: [optional] [multiple] *** as-in in RIPE 181 ***export: [optional] [multiple] *** as-out in RIPE 181 ***default: [optional] [multiple]remarks: [optional] [multiple]admin-c: [mandatory] [multiple] [inverse key]tech-c: [mandatory] [multiple] [inverse key]cross-mnt: [optional] [multiple] [inverse key]cross-nfy: [optional] [multiple] [inverse key]notify: [optional] [multiple] [inverse key]mnt-lower: [optional] [multiple] [inverse key] *** RPS auth ***mnt-routes: [optional] [multiple] [inverse key] *** RPS auth ***mnt-by: [mandatory] [multiple] [inverse key]changed: [mandatory] [multiple]source: [mandatory] [single]

automatically translated , new, preserved, deprecated

RPSL!


Questions?


Advanced Database Issues

• DB administration– updating– deleting

• Protection• Test Database


DB Update Procedure• Changing an object

– obtain object from RIPE DB– 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


When to Change Your Objects • Fixing overlapping assignments• Merging two inetnum (domain, route) objects Splitting one assignment into more smaller ones• Changing the netname• Protecting unprotected objects

– including mnt-by attribute

• Updating peering agreements in aut-num Updating references to new contact persons/roles

– admin-c, tech-c, zone-c

• Updating contact info– phone/address change in person/role/mntner


Primary Keys (????)


Inetnum: person:

195.35.64.80 JAJA1-RIPE JAJA1-RIPE

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:

195.35.64.130

JAJA1-RIPE

...CD2-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:


Case Study: Replacing one assignment with smaller ones

• RIPE NCC registers first assignment as one block, at the beginning of allocated range

• To administer your allocation better, you can split this assignment into several smaller– delete the original object– create two of more new ones– keep the same netname

• or let RIPE NCC know of the change

– be careful when choosing the size of internal reservation

Add EXAMPLE!


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

changed: [email protected] 19991010

source: RIPE

delete: [email protected] duplicate object 20000202

Exact copy of the DB object


Protecting DB Objects


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

New in RPSL!


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 => mnt-by: RIPE-NCC-NONE-MNT

Transition to RPSL!


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]

referral-by: RIPE-DBM-MNTmnt-by: BLUELIGHT-MNTchanged: [email protected] 19991112source: RIPE New in RPSL!


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 mntner

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

New in RPSL!


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• http://www.ripe.net/cgi-bin/cgicrypt.pl.cgi

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

see: ripe-190 & ripe-189

RIPE NCC can provide you with a licence for free


GnuPG Authentication


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] 19991111source: TEST

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

– only against creation – only one level below

• Include also in assignment inetnum objects


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 => mnt-by: RIPE-NCC-NONE-MNT

• Reserved prefixes (RP)– in transition phase: – mntner: <RP><mt_name> => mntner: MNT-<RP><mt_name>

New inRPSL!


Test Database

• Non-production whois Database• Similar interface as “real” RIPE whois 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


Questions?


PI Request


PA vs. PI Assignments• Provider Aggregatable

• customer uses addresses out of LIR’s 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 ISP

possible routing problems

• Make contractual agreements– example: ripe-127– the only way to distinguish PA and PI space


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?

• impossible to get contiguous range in the future


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.209.255 netname: GOODY2SHOES-2

descr: Own Private Network 4 Goody2Shoesdescr: Amsterdam, Netherlandscountry: NLadmin-c: PIBA2-RIPEtech-c: JAJA1-RIPEstatus: ASSIGNED PI

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

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

mnt-by: BLUELIGHT-MNT

changed: [email protected] 19991111

source: RIPE


Questions?


New allocation


Allocation Procedures

• ‘Slow Start’– default minimum first allocation /20

• LIR announces the whole prefix

– size of future allocations depends on current usage rate• presumably enough for next two years • not always contiguous

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


Requesting New Allocation

• If previous allocated space used ~ 80% !• Send e-mail to <[email protected]>

• 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

...


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 Objectinetnum: 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] 19991111changed: [email protected] 20000303source: RIPE


Questions?


IPv6


Why IPv6?

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

• Interoperable with IPv4• simple and smooth transition

– hardware vendors– applications


Get IPv6 Addresses From:

• RIR• (sub)TLA holder• 6bone• Using 2002::/16 prefix


Transition Mechanisms


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 Autonomous Systems (in DFZ)

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 (23+ subTLAs)– ARIN 2001:0400::/23 (12+ subTLAs)– RIPE NCC 2001:0600::/23 (30+ subTLAs)– http://www.ripe.net/ripencc/mem-services/general/allocs6.html


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

Generated by the DB!


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]

local internet registries. training course. 1 welcome to the local internet registry course ripe...

Documents