nato advanced networking workshop. ljubljana, 19 september 2001. 1 “how to run a local internet...

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

“How to Run aLocal Internet Registry”

or

all your IPs are belong to us!

RIPE Network Coordination Centre <[email protected]>

NATO Advanced Networking Workshop . Ljubljana, 19 September 2001 . http://www.ripe.net2

Objectives

– to make participants familiar with terminology of Internet resources distribution

– to broadly/quickly describe procedures and policies– to point to references (documents, tools…)

• Assumption about audience– clients of existing Local Internet Registries– will soon be employed by a Registry– will want to establish LIR themselves

• Scope– mostly administrative– no technical details about running an ISP

• ALWAYS ASK QUESTIONS!


Schedule• RIPE & RIPE NCC• IP Address Space Distribution

– obtaining the Address Spacethrough the existing LIR

• Being an LIR– setting up an LIR– requesting assignment approval – how to manage your allocation

• Additional Policies and Procedures– assignment window & evaluation– additional allocation– Provider Independent address space

• Reverse DNS

• AS Numbers and Routing Registry• IPv6• Next: RIPE whois Database


Introduction toRIPE and RIPE NCC

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

parties interested in Internet administration, development and operations of IP networks

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

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


How RIPE Works • RIPE works as

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

• <[email protected]>• web archived

– not a legal entity– does NOT develop Internet Standards

• RIPE chair <[email protected]>


Join RIPE Working Groups

• Local Internet Registries (LIR)– join the open process of making address space policies!

• RIPE Database (DB)• IP version 6 (IPv6)• European Internet Exchange Forum (EIX)• Routing / MBONE• Domain Name System (DNS)• NETNEWS Co-ordination• Anti-Spam• European Operators Forum (EOF)• Tools (new)• Technical security (new)


RIPE Meetings• 3 times a year

• RIPE 40, Prague, Czech Republic, 1-5 Oct. 2001

• 4 to 5 day long• 300+ participants• Working group meetings• Plenary• Long breaks / social events• Connectivity (IPv4, IPv6, wireless)

• <[email protected]>


Why a NCC?

• RIPE participation was increasing• Too much RIPE work to be done on a

voluntary basis• Activities require continuity and co-ordination• Neutrality and impartiality are needed• Contact point inside and outside RIPE region

• From ’92 till ’98 part of TERENA– In ’98 registered as not-for-profit association

• Since ’95 funded by contributing members


Vital Statistics• Statistics 1992

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

• Statistics Now– 70 staff (23 nationalities)– 2,900+ participating Local IRs– 15,200,000+ countable hosts in the RIPE NCC region– 3,500,000+ objects in the database


Formal Decision Making

“Consensus” Model

RIPE proposes activity plan

RIPE NCC proposes budget to accompany

activity plan (ripe-213)

At Annual General Meeting

membership votes

on both activities and budget


RIPE NCC in Global Context

PSO ASO DNSO

RIPE NCC ARIN APNIC

ICANN

RIPE APNIC mtg.ARIN mtg.

At Large

IETF, w3c, ETSI, ...


Service Regions


RIPE NCC Services

Member Services• Registration Services

– IPv4 addresses

– IPv6 addresses

– AS numbers

– LIR Training Courses

• Reverse domain delegation– NOT registering domain names

• Test Traffic Measurements

Public Services

• RIPE whois DB maintenance– Routing Registry Maintenance

• Co-ordination and liaison– RIPE support

• Information dissemination

• New Projects

– RIS, R2C2, DISI

• Maintenance of tools


RIPE NCC R&D

• Test Traffic Measurements ( www.ripe.net/ttm/ )– independent measurements of connectivity parameters

(delays and routing-vectors) in the Internet.

• Routing Information Service ( www.ripe.net/ris/ )– collect information about BGP routing much like the

"looking glass" services, not only in real time but also for user selectable time periods in the past & at different locations around the Internet

• DISI ( www.ripe.net/disi/ )– Deployment of Internet Security Infrastructures– e.g. DNSSEC


Questions?


IP Address Space Distribution


Problems and Solutions

• History:– Classfull (A,B,C; fast depletion, routing table growth)– Subnetting– Supernetting– Variable Length Subnet Mask

• Classless Inter Domain Routing (‘94)– flexible boundary between network and host part

• source and destination address in the prefix format– route aggregation

• Hierarchical registry structure– topologically significant address allocation


Classless Notation (CIDR)Addresses 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... ... ... ...


Global Registries Structure

Global Authority

RIR/8

LIR (ISP/Enterprise)/20 + RIPE NCC Members

ISP / End Users/32 + Anybody with a network / host


Goals of the Registry Structure

• Fairness

• Conservation

• Aggregation

• Registration


Terminology / Jargon

• Local Internet Registry (LIR)– organisation which assigns address space to end-users– member of RIPE NCC, receives membership services

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

to customers or LIR’s own organisation

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


Even More Terminology

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

to each of its customers (and itself) per 12 months– initially set to 0 (ZERO) LIR needs to REQUEST approval from RIPE NCC for

any assignment

• Policies and procedures• ripe-185 for IPv4 space• ripe-196 for IPv6 space• rfc-2050 for global policies

– all of them being in the process of re-writing!


… Address Space

• Provider Aggregatable ...good for routing tablescustomer must renumber if changing ISP/LIR

• Provider Independent ...customer takes addresses when changing ISP/LIRpossible routing problems (ripe-222)

• Private ...– rfc-1918 (10/8, 172.16/12, 192.168/16)

• Portable ...– PI assignment, PA allocation, IPv6 subTLA– RIPE NCC responsible for the reverse DNS delegation


Terms IllustratedIANA / ICANN

RIPE NCC

EnterpriseLIR

Local IRRegistry

ISPEnd User

End User

Allocating

Assigning

PI assignment


Obtaining the Address Space

• through the existing LIR


PA Assignment Process

LIR Evaluates Request

Approach RIPE NCC

(*) request > AW?

need 2nd opinion?

yes

no

no

yes

LIR Updates RIPE Database

LIR Updates Local Records

LIR Chooses Addresses

RIPE NCCevaluates &

approves

(*) Total size of the request plus any other address space assigned within last 12 months

inetnum object:netname, size, date

client


Providing Information (1)

Overview of organisation– name and location of the company?– activities?– structure?

• does it have subsidiaries and where?• for what part of the company are the addresses requested?

• Current Address Space Usage– renumbering and returning? (encouraged!)

• Additional Information– deployment plan, purchase receipts– topology map


Providing Information (2)

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

• including equipment used

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

• Efficient utilisation– 25% immediately, 50% in one year– operational needs; no reservations

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


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

170 297 342 Totals

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

Relative Subnet Mask Size Imm 1yr 2yr DescriptionPrefix

Example: #[ Addressing Plan Template ]#

100 12 10 14 35100 12 14 0

Cumulative, total numbers

100 10 8 14 24 0 0 14 0

Real needs

100 16 13 14 50 100 25 14 10

Concrete plans


Questions?


Being an LIR

• Setting up an LIR

• First Allocation

• Requesting Assignment Approval

• Managing Allocated Address Space


Setting up an LIR

• Completed application form Provided Reg-ID & contact persons

– <[email protected]>

Read relevant RIPE documents– ripe-185 etc

• Signed contract - “Service agreement”– agreed to follow policies and procedures

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


Registry Identification (Reg-ID)

• Distinguishes between member registries and individuals

• Format <country code> . <registry name>

• Include with every message

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


LIR Contact Persons Stored in RIPE NCC internal (“Reg”) file for each registry

– confidential– only registered contact persons can

• send requests to hostmasters• change contact information

• To keep contact info up-to-date– write to [email protected]– for each contact person create person object in the RIPE DB– possible to use role object– “Reg” file not automatically updated from the RIPE Database!

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


First Allocation• LIR requires a block of IP addresses

– send an “assignment request” – no need to justify usage of the whole allocation do not ask for PI space as first request– soon: criteria for first allocation - /22 already used

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

• Whole allocated range can be announced

immediately


Requesting Assignment Approval If the needed address space is bigger then AW• Separate request forms needed:

– for each customer• using more than /30

– for LIR’s own infrastructure • extensions of LIR internal network• combine many clients with up to 4 IPs into one block

– e.g. leased lines, dial-up, p2p links, web hosting, server housing

– for ISP-client’s infrastructure

for each one of ISP-client’s customers


Sending the Request• <[email protected]>• RIPE-219 : http://www.ripe.net/docs/iprequest.html (ex ripe-141)

• Web form (example)– filling in the requests & syntax check

• http://www.ripe.net/cgi-bin/web141/web141.pl.cgi

• source: 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

• All data kept strictly confidential• Documentation has to be in English


Approval

• Approval message is sent to LIR – size

• NOT the address range!!!– “netname”

• name of the RIPE DB network object– date

• “Assignment is only valid as long as original criteria remain valid” (ripe-185)

• Next steps:– choosing the address range within the allocation– registering network object in the RIPE DB


Internal Administration

• LIR decides on the range of addresses – classless assignment on bit boundary

• Update local records for later reference– archive original documents with assignment

Be careful when choosing the size of “internal reservations”

• e.g. BL-LAIKA: /24 & /25 & /26 (448)

Amsterdam Utrecht

/24 BlueLight Infrastructure

/24 BlueLight reserved

/25 Laika Dialup

+ /25 reserved

Laika Infrastructure /25

/25 Laika Dialup

+ /25 reserved

/26 Laika Infrastructure


• Aggregate within allocation• Sensible internal “reservations”

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

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

– open = more than 20% unused space

How to Manage Allocation


Assignments to (Small) ISPs

• LIR can not allocate address space to an ISP • If an LIR’s customer is an ISP, distinguish

– ISP’s infrastructure

– ISP’s customers

• Separate assignments need to be– requested

– evaluated / approved

– registered in the RIPE Database

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

plus for separate customers


Non-Overlapping Assignments

195.35.88/26

ENGO-infrastr ...195.35.92/29

ENGO-rgb

195.35.92.8/29

ENGO-cmyk

wrong

Assignment for

ISP ENGOS &

all its (future)

customers

Overlapping (second level) assignments

for separate customers of ENGOS

right

Internal Reservations

for ENGOS’s customers

195.35.88/22

ENGOS-and-all

Assignments for separate customers of ENGOS

BlueLight’s Allocation


Registering Address Spacein the RIPE Database

• Assignment is considered “valid” by RIPE NCC only if (correctly) registered

• to provide contact info for troubleshooting• to enable overview of address space used invalid DB objects influence procedures with:

reverse DNS, AW, additional allocations, audit…

• All end-user networks need to be registered separately– if bigger then 4 IPs (/29+)– avoid overlapping inetnum objects


Additional Policies and Procedures

• Assignment Window• evaluation policies

• Additional Allocations • PI Assignments


Assignment Window Policy

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

without prior approval of the RIPE NCC– AW is for LIR, and not for person or company– AW is per 12 months per each customer

• Why necessary?– support to LIRs during start up

– familiarisation with RIPE NCC procedures

– align criteria for request evaluation

– maintain contact between LIRs and RIPE NCC


LIR Responsibilities with the AW• Evaluate all the requests within LIR AW size

– based on the ripe-185 policies

• Keep the documentation about LIR assignments– useful for administration, and if client comes back– RIPE NCC may ask for it later

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

• Remind the customer’s previous ISP after renumbering– to delete the outdated DB objects


Evaluating Client’s Requests• Efficient utilisation

– 25% immediately, 50% in one year

• No “reservations”• Dynamic addressing solutions preferred over static

– Dynamic dial-up is preferred over static– Name-based virtual web hosting is preferred over IP-based

• known exceptions are accepted (SSL, ftp&mail servers..)

– Special verification methods apply for more then /22 to:• discourage and control wasteful (static) usage

• also for xDSL, cable, GPRS…

– DHCP recommended to make renumbering easier

• Mandatory renumbering and returning of PA space


Allocation Policies

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

• LIR announces the whole prefix

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

• Next allocation when previous used ~ 80% !– LIR can not have two “open” blocks

• Motivation for ‘slow start’– fair distribution of address space

– keeps pace with customer base growth

– slows down exhaustion of IPv4 address space


PA vs. PI Assignments• Provider Aggregatable

• customer uses addresses out of LIR’s allocationgood 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 (ripe-222)

impossible to get contiguous range in the future

• Make contractual agreements (ripe-127)– the only way to distinguish PA and PI space– check with other LIR before accepting clients with PA


Questions?


Reverse Delegation Procedures

• /24 zone• multiple /24 zones• /16 zone• zone smaller then /24

• assuming basic DNS knowledge• assuming LIR perspective


What is the Difference Between Forward and Reverse DNS Delegation ?

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

• organisational structure

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

• depends on who distributed the address space

– reverse delegation takes place on octet boundaries


IN-ADDR.ARPA Domain . (ROOT)

edu

arpacom

net

nl

in-addr

193 195

19435

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

8081

RIPE NCC


Why Do You Need Reverse DNS Delegation ?

• All host-IP mappings in the DNS (A record) should have a corresponding IP-host mapping (PTR record)

• Failure to have this will likely– block users from various services (ftp, mail)– make troubleshooting more difficult (traceroute)– produce more useless network traffic in general


Overview of the Request Procedure

• LIRs have to request reverse delegation• /24 zones are delegated

– to LIR / end-user – as the address space gets assigned

• Steps valid assignments of address space /24 reverse zone setup

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

• always include Reg-ID – e.g. X-NCC-Regid: nl.bluelight


“Valid” Assignment

• According to ripe-185 policies• Within “Assignment Window”

- or approved from RIPE NCC Hostmaster

• inetnum object registered in RIPE Database– netname attribute is RIPE NCC's only reference of

approved assignment• do NOT change netname without notifying [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 another nameserver as secondary

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

– preferably with another provider

• Serial numbers YYYYMMDDnn format• Use name of nameserver instead of IP address • Do NOT use rev-srv attribute in inetnum object• Do NOT put a dot at the end of domain or nserver attributes

– the RIPE DB does not support them


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: DB SW will add date!


Request the Delegation

• Send domain template to <[email protected]>

• “Marvin” will1. check if zone is correctly setup2. check assignments’ validity3. (try to) enter object to RIPE DB

• RIPE NCC systems enter NS lines into the parent zone file


Problems with inaddr Robot?

• Error report will be sent to requester– correct errors and re-send to <[email protected]>

• For questions, see FAQ– http://www.ripe.net/reverse/

• If error reports continue– for any technical questions contact [email protected]

• please include the full error report

– for address space validity issues contact [email protected]


Reverse Delegation of Multiple /24

• Shorthand notation for domain attribute– for (sub)range of consecutive zones (compound object)– if represented in single inetnum object, e.g.

inetnum: 212.73.10.0 - 212.73.15.255domain: 10-15.73.212.in-addr.arpa

– submit as one domain object• processed separately• separate response

– recommended and preferred method!• will not work with auth: PGPKEY

• Possible to include up to 100 reverse domain objects in one email message

• even if they are not consecutive


Reverse Delegation of /16 Allocation

• If an LIR has a /16 allocation, the RIPE NCC can delegate the entire reverse zone to the LIR

• Requirements and procedures the same as /24, except– /16 domain object– three nameservers needed– ns.ripe.net a mandatory secondary

• After delegation, LIR should– continue to check sub-zone setup before further delegation(usage of the inaddr robot TEST keyword or web check is

recommended)


Changing the Delegation

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

• include RIPE DB authentication, if the object is protected– NOT enough to update the object in RIPE DB!

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

• value: email address, reason, date• include RIPE DB authentication, if the object is protected

– send to <[email protected]>

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


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


Questions?


Autonomous System Numbersand the Routing Registry

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


Autonomous System

• Definition: a group of IP networks run by one or more network

operators which has a unique and clearly defined routing policy

• RIR is allocated a range of AS numbers by IANA• RIR assigns unique AS number

– for LIR or for the customer

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


How to Get an AS Number ?

• Complete request form:– aut-num object template

• contact person(s)• mntner object template

– address space to be announced with this AS#

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


Criteria for Evaluation of ASN Request

• Being multihomed and specifying routing policy are mandatory requirements– how long will it take you to achieve multihomed status?– please provide e-mail addresses of peers

• Is it feasible to peer with specified ASNs?

• Is it possible to use private ASN?– 64512 to 65535


RPSL

• Routing Policy Specification Language (RFC 2622)– replacing RIPE-181 language

• RPS Security (RFC 2725) – stronger and hierarchical authorisation and authentication

• Syntax aut-num: NEWexport: to AS3 announce NEW

import: from AS2

action pref=120;

accept ANY

– the lower the value of “pref”, the more preferred route

RPSL!


AS2

aut-num: AS2

import: from AS2 action pref=20; 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=200; accept NEW

import: from AS3 action pref=100; accept ANY

import: from NEW action pref=120;

accept NEW

export: to AS3 announce NEW

ANY

import: from AS2 action pref=200; accept ANY


Registration in RIPE Database

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

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

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


aut-num: NEWas-name: BLUELIGHTdescr: Bluelight AS#

import: from AS2 action pref=20; accept AS2 import: from AS3 action pref=100; accept ANY import: from AS2 action pref=200; accept ANY

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

tech-c: JAJA1-RIPEmnt-by: BLUELIGHT-MNTmnt-routes: BLUELIGHT-MNTchanged: [email protected] 20001010source: RIPE

aut-num TemplateAS42

AS42 AS42

Object RPSL!


The Route Object route: 195.35.64.0/20 descr: BLUELIGHT-NET origin: AS42 mnt-by: BLUELIGHT-MNT mnt-routes: BLUELIGHT-MNT changed: [email protected] 20001010 source: RIPE

• To create route object, send completed template to <[email protected]>

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

New inRPSS!


Internet Routing Registry

• Globally distributed DB with routing policy information– provides a map of global routing policy (ASExplorer)

– shows routing policy between any two ASes (prpath)

– allows simulation of routing policy effects

– enables creation of aut-num based on router conf (aoe)

– enables router configuration (rtconfig)

– provides contact information (whois)

• RIPE Routing Registry– subset of information in RIPE database

See “The DB Transition Handout”RPSL!


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?


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:

• Using 2002::/16 prefix

• 6bone

• (sub)TLA holder

• RIR


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” CriteriaA) Peering with 3 Autonomous Systems

(in Default Free Zone)

AND

B) Plan to provide IPv6 services within 12 months

C) 40 IPv4 customers

AND either OR

D) 6bone experience


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 (33+ subTLAs)– ARIN 2001:0400::/23 (20+ subTLAs)– RIPE NCC 2001:0600::/23 (42+ subTLAs)– http://www.ripe.net/ipv6/


IPv6 Database Object

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

Generated by the DB!


Questions?

http://www.ripe.net/training/

nato advanced networking workshop. ljubljana, 19 september 2001. 1 “how to run a local internet...

Documents