Welcome to the local internet registry tutorial
Download
1 / 170

Welcome to the Local Internet Registry Tutorial - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

Welcome to the Local Internet Registry Tutorial. 15 September 2000 Grand Ball Room, 14:00-17:30. RIPE Network Co-ordination Centre Vesna Manojlovic <[email protected]>, Eamonn McGuinness <[email protected]> http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/lir-tutorial/

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Welcome to the Local Internet Registry Tutorial' - kendall


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Welcome to the local internet registry tutorial

Welcome to theLocal Internet Registry Tutorial

15 September 2000

Grand Ball Room, 14:00-17:30

RIPE Network Co-ordination Centre

Vesna Manojlovic <[email protected]>,

Eamonn McGuinness <[email protected]>

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

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


Schedule
Schedule

  • Requesting Address Space

    • Introduction to RIPE NCC

    • Global Registry System

    • Initial Administrivia of Becoming LIR

  • First Request

    • Completing the request form

    • Communication with hostmasters

  • Customer’s Request

    • Elementary evaluation

    • RIPE Database

  • Evaluation of specific assignment cases

    • Large request

    • PI request

    • Renumbering

  • Assignment Window

  • New allocation



  • What is the ripe ncc
    What is the RIPE NCC?

    • Network Co-ordination Centre

      • The RIPE NCC is a “co-ordination” and support service for its members and RIPE community

    • One of 3 Regional Internet Registries (RIR)

    • Why a NCC ?

      Actions agreed in RIPE community needed

      • continuity and professionalism

      • neutrality and impartiality


    Vital statistics
    Vital Statistics

    • Statistics 1992

      • 3 staff members

      • No Local IR’s

      • 182,528 hosts in European Internet

      • 7,955 objects in RIPE database (June ‘92)

    • Statistics Now

      • 62 staff (22 nationalities)

      • 2,018+ participating Local IR’s

      • 11,390,000+ countable hosts in the RIPE NCC region

      • 3,041,650+ objects in the database


    Ripe ncc activities 1
    RIPE NCC Activities (1)

    Member Services

    • Registration Services

      • IPv4 addresses

      • IPv6 addresses

      • AS numbers

      • LIR Training Courses

    • <[email protected]>

    • Reverse domain name delegation

      • NOT registering domain names


    Ripe ncc activities 2
    RIPE NCC Activities (2)

    Public Services

    • RIPE database maintenance

    • Routing Registry Maintenance (RR)

    • Co-ordination

      • RIPE support

      • Liaison with:

        • LIRs / RIRs / ICANN / etc …

      • Information dissemination

    • New Projects

      • Test Traffic Measurements

      • Routing Information Service (RIS)

      • Routing Registry Consistency (RR)


    Ripe database 1
    RIPE Database (1)

    • Public Network Management Database

    • Information about objects

      IP address space inetnum, inet6num

      reverse domains domain

      routing policies route, aut-num

      contact details person, role

    • Server whois.ripe.net

      • UNIX command line queries

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


  • Ripe database 2
    RIPE Database (2)

    • Software Management

      • server and client

        • NOT relational

    • RIPE NCC

    • Database Working Group (RIPE community)

  • Data Management

    • LIRs

    • other users

    • RIPE NCC

  • Information content not responsibility of RIPE NCC

  • Protection mechanisms not default, but strongly encouraged


  • Summary ripe ripe ncc
    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




    Terminology
    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


    Classful notation

    24

    110

    256

    192.0.0.0 - 223.255.255.255

    Classful Notation

    network

    host

    8

    0

    16,777,216

    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


    Classless notation

    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 C’s

    255.255.240.0

    8192

    /19

    32 C’s

    255.255.224

    16384

    /18

    64 C’s

    255.255.192

    32768

    /17

    128 C’s

    255.255.128

    65536

    /16

    1 B

    255.255.0.0

    ...

    ...

    ...

    ...


    Goals of the internet registry system
    Goals of the Internet Registry System

    • Aggregation

    • Conservation

    • Registration

      • uniqueness


    Regional registry structure

    Local IR

    Regional Registry Structure

    IANA / ICANN

    ARIN

    RIPE NCC

    APNIC

    Local IR / ISP

    Enterprise

    Local IR

    ISP

    ISP /

    End user

    End user





    Becoming lir
    Becoming LIR

    • Completed application form (ripe-212)

    • Provided Reg-ID & contact persons

    • Read relevant RIPE documents

    • Signed contract (ripe-191)

      • agreed to follow policies and procedures

    • Paid the sign-up & yearly fee


    Contact persons
    Contact Persons

    • Stored in RIPE NCC internal file for each registry

      • confidential

    • Only registered contact persons can

      • send requests to hostmasters

      • change contact information

        • PGP optional (soon)

    • Use ‘role’ object

      • for multiple admin-c and tech-c

    • Members’ mailing lists


    Registry identification regid
    Registry Identification (RegID)

    • Distinguishes between contributing registries and individuals

    • Format

    • <country code> . <registry name>

    • Include with every message

    • Suggestion - modify mail header

    • X-NCC-RegID: nl.bluelight



    New registry s first request

    New Registry’s First Request

    • Completing the request form

    • Communication with the hostmaster


    Sample first request
    Sample First Request

    • Example: Blue Light Internet

    • LIR wants a block of IP addresses

      • e.g. for own network / infrastructure

        • do not include needs of customers yet

          Steps:

      • Complete request form ripe-141

      • Send request to <[email protected]>

      • RIPE NCC evaluate and approve request

        With first assignment LIR automatically receives /20 allocation


    Request form ripe 141
    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


    Completing the request form starting from addressing plan gathering information
    Completing the Request Form (starting from Addressing Plan)Gathering Information

    • Design of the network

      • how many physical segments it will consist of

      • what is each segment going to be used for

        • including equipment used

      • how many hosts are in each segment

      • expectations of growth


    Addressing plan template
    #[ Addressing Plan Template ]#

    dynamic dial-up Amsterdam

    web/mail/ftp servers Amsterdam

    customers’ servers Amsterdam

    training room LAN Amsterdam

    Amsterdam office LAN (*1)

    dynamic dial-up Utrecht

    web/mail/ftp servers Utrecht

    Inet cafe Utrecht

    training room LAN Utrecht

    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

    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

    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


    Request overview template

    Totals: 448 170 297 342

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


    Current address space usage template
    #[ Current Address Space Usage Template ]#

    Prefix Subnet Mask Size Imm 1yr 2yr Description

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

    195.20.42.64 255.255.255.224 32 10 22 29 Amsterdam office LAN

    195.20.42.96 255.255.255.240 16 4 6 8 Utrecht office LAN

    195.20.42.112 255.255.255.240 16 6 10 13 Mail servers

    128 36 68 100 Totals

    Actual addresses


    Person template
    #[Person template]#

    Jan Jansen

    Blue Light Internet

    Oudezijds Achterburgwal 13

    Amsterdam

    The Netherlands

    [email protected]

    +31-20-555 5555

    AUTO-1

    BLUELIGHT-MNT

    [email protected] 19990906

    RIPE

    person:

    address:

    address:

    address:

    address:

    e-mail:

    phone:

    nic-hdl:

    mnt-by:

    changed:

    source:

    *

    *


    Network template

    *

    *

    #[Network template]#

    inetnum:

    netname:

    descr:

    descr:

    country:

    admin-c:

    tech-c:

    status:

    mnt-by:

    changed:

    source:

    x.x.x.x/23

    BLUELIGHT-1

    Company infrastructure

    in both locations

    NL

    AB231-RIPE

    AUTO-1

    ASSIGNED PA

    BLUELIGHT-MNT

    [email protected] 19990906

    RIPE



    Ticketing system
    Ticketing System

    • Unique ticket number

      • facilitates retrieval / archiving

      • NCC#YYYYMMXXXX

      • e.g. NCC#2000053280

    • Check status of ticket on the web

      • http://www.ripe.net/cgi-bin/rttquery

        • open ncc

        • open reg

        • closed


    Hostmaster robot
    Hostmaster-robot

    • Checks request form

      • Reg-ID, contact persons

      • syntax

      • policy problems

    • Acknowledgement & diagnostics

      • LONGACK

    • Error message

      • correct & re-send the request

      • use same ticket number

      • NOAUTO

    • No errors: hostmaster wait-queue

      • “ongoings” directly to hostmasters


    Request approved
    Request Approved

    • With the first ASSIGNMENT approved LIR automatically gets an ALLOCATION

      • /20 (4096 addresses)

    • Hostmaster enters allocation and assignment objects into the RIPE database at this time

      • /24 & /25 & /26 instead of /23

    • Whole allocated range can be announced immediately

    • Every request has to be sent for approval to RIPE NCC

      • addresses for LIRs own infrastructure

      • all customers’ request



    Customer s request

    Customer’s Request

    Evaluation

    Basic Database Issues


    Assignment process
    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


    Gathering information
    Gathering Information

    • One request form per customer

    • Ask the same questions RIPE NCC asks LIR

      • enough information to complete ripe-141

    • Add comments

    • Example: Goody 2 Shoes


    Before submitting the request
    Before Submitting the Request

    • Syntax check the request on the Web

    • Complete documentation reduces need for iteration

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

    • Documentation for RIPE NCC has to be in English


    Evaluation general information
    Evaluation -- General Information

    • #[Overview of organisation template]#

      • information relevant to the address space request

    • Name and location of the company?

    • What are the company activities?

    • What is the structure?

      • Does it have subsidiaries and where?

      • For what part of the company are the addresses requested?

  • #[Requester Template]#

    • LIR contact for RIPE NCC

  • #[User Template]#

    • customer’s contact for LIR


  • Evaluation addressing plan
    Evaluation -- Addressing Plan

    • Do totals in “Addressing Plan” match numbers in “Request Overview”?

    • Are all subnets classless?

      • are the subnet masks real?

    • Utilisation and efficiency guidelines:

      25% immediately, 50% in one year

    • Can address space be conserved by using

      • different subnet sizes?

      • avoiding padding between subnets?


    Evaluation network template
    Evaluation -- Network Template

    • inetnum value

      • specifies the size of assignment

      • actual range is not necessary

    • Relevant netname

      • descriptive; uppercase letters, numbers & “-”

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

    • Contact persons

      • can be multiple

      • reference nic-hdls (may be a role object)

      • admin-c

        • responsible for the network, able to make decisions

      • tech-c

        • technical setup of the network


    Internal administration

    Assignment for customer’s network

    Assignment for LIR’s network

    Internal Administration

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

    • Decide on the range of within your address space

      • classless assignment on bit boundary

    • Update local records

      • archive original documents with assignment



    Creating person object
    Creating person Object

    • Check if person object exists in RIPE DB

      • whois {person’s name; email address}

      • only one object per person

    • Obtain and complete a template

      • whois -t person

      • -v (verbose)

    • Send to <[email protected]>

    • Each person object has unique nic-hdl


    Whois t person
    whois -t person

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

    address: [mandatory] [multiple] [ ]

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

    phone: [mandatory] [multiple] [ ]

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

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

    changed: [mandatory] [multiple] [ ]

    source: [mandatory] [single] [ ]


    Nic hdl
    nic-hdl

    • Mandatory attribute

    • Only way to clear ambiguity in person objects

    • Format: <initials><number>-<regional registry>

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

    • Combination of person nameandnic-hdl is the primary key for person object

      • Use “AUTO-#” placeholders

    person: Piet Bakker

    ...

    nic-hdl: AUTO-1

    person: Jan van der Bruk

    ...

    nic-hdl: AUTO-#initials

    PB1234-RIPE

    AUTO-1JVDB

    JVDB1-RIPE


    Auto dbm@ripe net responses
    <[email protected]> Responses

    • Successful update

      • acknowledgement

    • Warnings

      • object accepted but might be ambiguous

      • object corrected and accepted

    • Errors

      • object NOT corrected and NOT accepted

      • diagnostics in acknowledgement

    • If not clear send questions to<[email protected]>

    • Include error report


    Creating network object
    Creating Network Object

    • inetnum

      • insert the address range in the ‘network template’ approved by hostmasters

      • keep the same netname attribute

      • in change attribute use current date

        • or leave out the date completely

    • Send to <[email protected]>

      • with the keyword NEW in the subject line


    Check your database data
    Check Your Database Data

    • Before you notify the customer

      • whois [customer’s IP range]

      • whois [customer’s netname]

      • whois -m [your allocated IP range]

        • will show your first level customer(s) network(s)

      • whois -L [customer’s IP range]

        • will show your own data


    Example db query
    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.80/25

    195.35.88/26

    ...

    Goody2Shoes

    eNGOs

    Blue Light

    whois -L 195.35.92.10


    Notify the customer
    Notify the Customer

    • Make sure customer has same data as you

      • cut and paste output of the whois query

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



    Evaluation of specific assignment cases

    Evaluation ofSpecific Assignment Cases

    ‘Large’ Request

    PI request

    Renumbering



    Submitting a large request
    Submitting a Large Request

    • Complete ripe-141 request form

      • only include addresses you have concrete need for (no reservations)

    • Possible additional information

      • pointer to web site

      • deployment plan

      • new technologies

      • purchase receipts

      • topology map (design of the network)

        • can be faxed

        • handled and kept confidentially

        • include ticket number and Reg-ID


    Current address space usage evaluation
    Current Address Space UsageEvaluation

    • Are there any previous assignments?

      • ask customer

    • Querying the RIPE Database

      • whois.ripe.net

        • exact match

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

        • full text search using glimpse

        • whois web interface

    • Can request be fulfilled with previous assignment?


    Private address space
    Private Address Space

    • RFC-1918 (Address Allocation for Private Internets)

    • Suitable for

      • partial connectivity

      • limited access to outside services

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

    • Motivation

      • saves public address space

      • allows for more flexibility

      • security


    Sample deployment plan

    Planned

    operational

    Date

    Date

    Equipment

    ordered

    Type of

    Equipment

    Number

    of hosts

    Location

    modems

    modems

    modems

    modems

    2048

    2048

    2048

    2048

    London

    Berlin

    Paris

    Moscow

    09/2000

    11/2000

    11/2000

    03/2001

    05/2000

    07/2000

    07/2000

    --------

    Sample Deployment Plan

    • Needed when big expansion planned

    • Matching addressing plan

      Relative Subnet Mask Size Imm. 1yr 2yrDescription

      Prefix

      0.0.0.0 255.255.252.0 2048 0 1024 2048 London POP

      0.0.4.0 255.255.252.0 2048 0 1024 2048 Berlin POP

      0.0.8.0 255.255.252.0 2048 0 1024 2048 Moscow POP

      0.0.12.0 255.255.252.0 2048 0 1024 2048 Paris POP


    New technologies
    (New) Technologies

    • If special hardware/software is used

      • include the URLs of manufacturer’s sites if available

  • Special allocation and verification procedures apply

    • cable modems, ADSL

    • GPRS?

    • static dial up assignments

    • IP based virtual web hosting

  • recommended

    • investigate and implement dynamic assignment technologies whenever possible

  • } STRONGLY DISCOURAGED



    Pa vs pi assignments
    PA vs. PI Assignments

    • Provider Aggregatable

      • customer uses addresses out of your allocation

    • good for routing tables

    • customer must renumber if changing ISP

  • Provider Independent

    • customer receives range of addresses from RIPE NCC

  • customer takes addresses when changing ISP

  • possible routing problems

  • Make contractual agreements

    • ripe-127


  • Requesting 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?


    Evaluation of pi request
    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
    Example PI DB Entry

    • inetnum: 194.1.208.0 - 194.1.215.255

    • netname: GOODY2SHOES-2

      descr: Own Private Network 4 Goody2Shoes

      descr: Amsterdam, Netherlands

      country: NL

      admin-c: PIBA2-RIPE

      tech-c: JAJA1-RIPE

      status: ASSIGNED PI

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

      mnt-by: BLUELIGHT-MNT

      changed: [email protected] 19991111

      source: RIPE


    Renumbering

    Renumbering

    … is easy!


    When to send renumbering request
    When to Send Renumbering Request?

    • Customer(s) changing providers

      • already using address space

      • returning PA addresses to OldISP

      • renumbering to the PA range of NewISP

    • Changing from PI (or UNSPECIFIED) to PA

    • Only if amount is above LIR’s AW

    • Procedure made easier to encourage renumbering

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


    Renumbering request
    Renumbering Request

    • Complete ripe-141 request form

    • Double check current addresses in DB

      • whois -L <customer’s IP range> => UpstreamISP inetnum

      • whois -m <UpstreamISP range>

    • Show how addresses were used

    • Show how new addresses will be used

    • Time frame guidelines - 3 months

      address-space-returned:

      195.100.35/24 to UpstreamISP1 in 20000901

      194.200.70/24 to UpstreamISP2 in 20001001

      ...


    Renumbering many customers
    Renumbering Many Customers

    • If all ‘1-1’ renumberings

      • include all in one request form

        • making procedure easier

      • separate inetnum and addressing plan for each

        • “50% utilisation” guideline

    • If not ‘1-1’

      (customer will need more addresses)

      • send one request per customer


    After the return date
    After the Return Date

    • If you are the “new” ISP for this customer

      • encourage your customer to renumber their whole network to your address space

    • If you are the “old” ISP of this customer

      • make sure you remove data from RIPE Database

    • Hostmasters send regular reminders



    Assignment window policies and procedures

    Assignment Window Policies and Procedures


    Assignment window policy
    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
    Initially: AW=0

    • Send

      EVERY 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
    When is AW Size Raised

    • Understood procedures

    • Complete NCC documentation

    • Experience

      • with RIPE Database

      • different policies

      • evaluating and processing requests

    • Not always automatically

      • approach us


    When is aw size lowered
    When is AW Size Lowered

    • New staff need training

    • After negative auditing report

    • To enforce payment

    • To find out the AW size


    Assignment window size
    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


    Assignment process1

    request > AW?

    Assignment Process

    • Between Local IR’s 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


    Assignment process2

    Update local

    records

    Add Registry ID

    Complete the

    request form

    Assignment Process

    ( Finish the assignment )

    ( Approach RIPE NCC )

    Pick

    addresses

    Add comments &

    recommendations

    Update RIPE

    database

    Send to RIPE NCC

    <[email protected]>

    Wait for

    acknowledgement

    RIPE NCC

    evaluates &

    approves

    Notify

    customer

    ( Finish the assignment )




    Allocation procedures
    Allocation Procedures

    • ‘Slow Start’

      • first allocation /20

        • LIR announces the whole prefix

      • size of future allocations depends on current usage rate

        • presumably enough for next two years

        • not always contiguous

    • Motivation for ‘slow start’

      • fair distribution of address space

      • keeps pace with customer base growth

      • slows down exhaustion of IPv4 address space


    Motivation for no reservations policy
    Motivation for ‘No Reservations’ Policy

    • Def.: Address space set aside for future use

    • Reservations may never be claimed

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

    • Administrative convenience not catered for

    • Fragments address space =>

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


    Requesting new allocation
    Requesting New Allocation

    • Send request to <[email protected]>

      • NOTripe-141 form

      • NEWBLOCK in subject line

    • summary of addresses assigned / free

    • list assignments of the last allocation

      Suggested format:

      Allocation: 195.35.64.0/19

      • assigned: 7372

      • free: 820

      • Range Netname

        195.35.64.0 - 195.35.65.191 BLUELIGHT-1

        195.35.80.0 - 195.35.80.127 GODY2SHOES-1

        195.35.80.128 - 195.35.80.159 CYB-FAL

        195.35.88.0 - 195.35.88.31 ENGOS-1

        ...


    Evaluation of new allocation request
    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
    Prior to Making New Allocation

    • If inconsistencies are found

      • LIR will be asked to correct data first

      • AW is reviewed

    • When data is corrected

      or deadline for correction is set

      • RIPE NCC

        • allocates new block to LIR

        • updates the DB

    • LIR announces new prefix


    Allocation inetnum object
    Allocation inetnum Object

    inetnum: 195.35.64.0 - 195.35.127.255

    netname: NL-BLUELIGHT-19990909

    descr: Provider Local Registry

    country: NL

    admin-c: JJ231-RIPE

    tech-c: JAJA1-RIPE

    status: ALLOCATED PA

    mnt-by: RIPE-NCC-HM-MNT

    mnt-lower: BLUELIGHT-MNT

    changed: [email protected] 19990909

    changed: [email protected] 20000303

    source: RIPE



    The end
    The End ...

    … unless there is still some time for…

    • Reverse Delegation

    • AS Numbers

    • Advanced database issues

      • protecting your data

    • Advanced reverse delegation

    • Routing Registry

    • Administrivia

      • audit activity, billing, closing LIR

    • IPv6



    What is forward and reverse dns delegation
    What is Forward and Reverse DNS Delegation ?

    • Forward Delegation

      • enables naming of IP hosts on the Internet

      • hierarchical authority for domain registration

        • organisational structure

    • Reverse Delegation

      • enables association of IP addresses with domain names

      • hierarchical authority for reverse zone

        • depends on who distributed the address space

      • reverse delegation takes place on octet boundaries (classful)


    In addr arpa domain
    IN-ADDR.ARPA Domain

    . (ROOT)

    nl

    edu

    arpa

    net

    com

    bluelight

    amsterdam

    in-addr

    www

    195.35.65.130

    195

    217

    212

    213

    193

    194

    62

    35

    Forward mapping

    (A 195.35.65.1)

    65

    Reverse mapping

    130 = 130.65.35.195.in-addr.arpa

    (PTR www.bluelight.nl)


    Why do you need reverse dns delegation
    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
    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
    “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
    /24 Reverse Zone Setup Recommendations

    • At least two nameservers required

      • one nameserver setup as primary

      • at least one other as secondary

    • SOA values reasonably RFC1912 compliant

    • Nameservers not on same physical subnet

      • preferably with another provider

    • Serial numbers YYYYMMDDnnn format


    Example domain object
    Example domain Object

    domain: 80.35.195.in-addr.arpa

    descr: Reverse delegation for Bluelight Customers

    admin-c: JJ231-RIPE

    tech-c: JAJA1-RIPE

    zone-c: WF2121-RIPE

    nserver: ns.bluelight.nl

    nserver: ns2.bluelight.nl

    mnt-by: BLUELIGHT-MNT

    changed: [email protected] 19991110

    source: RIPE

    *


    Request the delegation
    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
    Problems with inaddr Robot?

    • Error report will be sent to requester

      • correct errors and re-send

    • For questions see FAQ

    • If error reports continue


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


    Cname example zonefile at provider primary nameserver
    CNAME Example Zonefile at Provider Primary Nameserver

    $ORIGIN 80.35.195.in-addr.arpa.

    0-31 IN NS ns.goody2shoes.nl.

    0-31 IN NS ns2.bluelight.nl.

    32-71 IN NS ns.cyberfalafel.nl.

    32-71 IN NS ns2.bluelight.nl.

    0 IN CNAME 0.0-31

    1 IN CNAME 1.0-31

    ... ...

    31 IN CNAME 31.0-31

    32 IN CNAME 32.32-71

    33 IN CNAME 33.32-71

    ... ...

    71 IN CNAME 71.32-71

    72 IN PTR www.qwerty.nl.




    Policy based routing

    Internet

    Internet

    AS2

    AS2

    AS3

    AS3

    NEW

    Policy Based Routing

    end-user end-user

    ISP

    Regional Transit Provider

    Backbone

    Provider

    BlueLight Goody2Shoes


    Autonomous system
    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
    How To Get an AS Number ?

    • Complete request form: ripe-147

      • aut-num object template

        • contact person(s)

      • mntner objecttemplate

      • address space to be announced with this AS#

    • Send to <[email protected]>

      • web syntax check: http://www.ripe.net/cgi-bin/web147cgi

    • Being multihomed and routing policy are mandatory!


    Ripe 181 language
    RIPE-181 Language

    • RIPE-181 used to describe routing policies

    • Developed in PRIDE project

      • accepted in IRR and translated into RFC-1786

    • Example syntax:

      aut-num: NEW

      as-out: to AS3 announce NEW

      as-in: from AS2 200 accept AS2

    • Cost defines the preference

      • the lower the cost, the more preferred route

      • cost relative per aut-num object


    As example 1

    Internet

    aut-num: AS3

    AS3

    as-out: to NEW announce ANY

    as-in: from NEW 10 accept NEW

    AS2

    NEW

    aut-num: NEW

    aut-num: AS2

    as-out: to AS2 announce NEW

    as-in: from NEW 20 accept NEW

    as-in: from AS3 100 accept ANY

    as-out: to AS3 announce NEW

    AS Example #1

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


    As example 2

    Internet

    aut-num: AS3

    AS3

    as-out: to NEW announce ANY

    as-in: from NEW 10 accept NEW

    AS2

    NEW

    aut-num: NEW

    aut-num: AS2

    as-out: to AS2 announce NEW

    as-in: from NEW 20 accept NEW

    as-in: from AS3 100 accept ANY

    as-out: to AS3 announce NEW

    AS Example #2

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

    ANY

    as-in: from AS2 200 accept ANY


    Registration in ripe database
    Registration in RIPE Database

    • Evaluation

    • RIPE NCC hostmaster

      - creates aut-num object (and maintainer)

      - informs requester

    • User is responsible for keeping up to date

      • routing policy

      • referenced contact info (person/role, mntner)

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


    Aut num object
    aut-num Object

    AS42

    aut-num: NEW

    descr: Bluelight AS#

    as-in: from AS2 10 accept AS2

    as-in: from AS2 200 accept ANY

    as-in: from AS3 100 accept ANY

    as-out: to AS3 announce NEW

    as-out: to AS2 announce NEW

    default: AS2 5

    admin-c: JJ231-RIPE

    tech-c: JAJA1-RIPE

    mnt-by: NEW-MNT

    changed: [email protected] 19991010

    source: RIPE

    AS42

    AS42

    BLUELIGHT-MNT

    *



    Advanced database issues

    Advanced Database Issues

    DB administration

    using role object

    updating

    deleting

    Protection

    Test Database


    Role object
    ‘role’ Object

    % whois -h whois.ripe.net -t role

    role: [mandatory] [single] [primary/look-up key]

    address: [mandatory] [multiple] [ ]

    phone: [optional] [multiple] [ ]

    fax-no: [optional] [multiple] [ ]

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

    trouble: [optional] [multiple] [ ]

    admin-c: [mandatory] [multiple] [inverse key]

    tech-c: [mandatory] [multiple] [inverse key]

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

    remarks: [optional] [multiple] [ ]

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

    mnt-by: [optional] [multiple] [inverse key]

    changed: [mandatory] [multiple] [ ]

    source: [mandatory] [single] [ ]


    Role object for contact persons
    Role 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: [email protected]

    trouble: 24/7 phone number: +31-60-123-4567

    nic-hdl: BL112-RIPE

    notify: [email protected]

    notify: [email protected]

    mntner: BLUELIGHT-MNT

    changed: [email protected] 20000202

    source: RIPE


    Inverse lookups in ripe db
    Inverse Lookups in RIPE DB

    • whois -i admin-c,tech-c,zone-c JAJA1-RIPE

      • whois -i admin-c,tech-c,zone-c -Tdomain JAJA1-RIPE

      • whois -i zone-c JAJA1-RIPE

      • whois -r -i admin-c,tech-c -T role JAJA1-RIPE

    • whois -i notify [email protected]

    • whois -i notify [email protected]


    Recursive lookups
    Recursive Lookups

    • whois 193.35.64.82 => inetnum,route,person(s)

      • whois -r 193.35.64.82 => inetnum, route

      • whois -T inetnum 193.35.64.82 => inetnum,persons

      • whois -r -T inetnum 193.35.64.82 => inetnum

      • whois -T route 193.35.64.82 => route

    • whois 62.80.0.0 => inetnum, role, person

      • whois CREW-RIPE => role, persons

      • whois -r CREW-RIPE => role


    Db update procedure
    DB Update Procedure

    • Changing an object

      • make needed changes

      • keep the same primary key

      • add the changed line to the new version of object

        • value: email address and date

      • do not forget authentication (password, PGP key)

    • Deleting an object

      • add delete line to the exact copy of current object

      • value: email address, reason and date

      • submit to the database


    Case study replacing tech c

    CD2-RIPE

    CD2-RIPE

    CD2-RIPE

    Case Study -- Replacing Tech-c

    1. whois -i tech-c JAJA1-RIPE

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

    3. Change the tech-c reference in allinetnum objects

    4. Delete old person object

    Inetnum: person:

    195.35.64.80

    JAJA1-RIPE JAJA1-RIPE

    person:

    ...

    Inetnum:

    195.35.64.130

    JAJA1-RIPE


    Replacing tech c using role object

    role:

    person:

    JJ231-RIPE

    BL112-RIPE

    CD2-RIPE

    CD2-RIPE

    BL112-RIPE

    BL112-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 allinetnum

    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


    Deleting an object 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



    Notification authorisation
    Notification / Authorisation

    • notify attribute (optional)

      • sends notification of change to the email address specified

    • mnt-by attribute & mntner object

      • objects that contain mnt-by must pass the authentication rules in the mntner object

    • Hierarchical authorisation for inetnum & domain objects

      • mnt-lower attribute


    How to protect db data
    How To Protect DB Data

    • Read documents (ripe-157, ripe-189)

      • choose authentication method

    • Create mntner object

    • Existing objects must be changed

      • include mnt-by attribute referencing mntner object

    • When creating new objects

      • include mnt-by attribute referencing mntner object


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

    mnt-nfy: [email protected]

    mnt-by: BLUELIGHT-MNT

    changed: [email protected] 19991112

    source: RIPE


    Maintainer object attributes
    Maintainer Object Attributes

    • auth attribute (mandatory, multiple)

    • upd-to attribute (mandatory)

      • notification for failed updates

    • mnt-by attribute (mandatory)

      • can reference the object itself

    • mnt-nfy attribute (optional)

      • works like notify but for all objects that refer to this maintainer object

    • Manual registration of object necessary

    • Send object to <[email protected]>


    Authentication methods
    Authentication Methods

    1. auth:NONE

    • could be used with mnt-nfy attribute

      2. auth: MAIL-FROM {e-mail, reg-exp}

  • e.g. MAIL-FROM .*@bluelight\.nl

    • protection from typos

      3. auth: CRYPT-PW {encrypted password}

    • include password attribute in your updates

      4. auth: PGP-KEY-<argument>

      key-cert object

      see: ripe-190 & ripe-189

      RIPE NCC can provide you with a licence for free


  • Hierarchical authorisation
    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: [email protected] 19990909

    changed: [email protected] 19991112

    source: TEST

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

    • mnt-lower protects

      • only against creation

      • only one level below

    • Include also in assignment inetnum objects


    Test database
    Test Database

    • Non-production DB

    • Similar interface as “real” Database

      • whois & email

      • 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



    Reverse delegation of multiple 24
    Reverse Delegation of Multiple /24

    • for range of consecutive zones

    • represented in single inetnum object

  • Shorthand notation for domain attribute

    inetnum:w.z.x.0 - w.z.y.255 212.73.10.0-212.73.15.255

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

  • Submit as one domain object

  • Processed separately

  • Separate response


  • Reverse delegation of 16 allocation
    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
    Changing Delegation

    • Change the nserver lines in domain object

    • To change contact details in domain object

    • Deleting a delegation is automatic


    Common errors
    Common Errors

    • DB / request inconsistency

      (netname attribute, update date)

    • IP addresses instead of names of nameservers in domain object

    • Trying to get reverse delegation for /19 allocation

      • has to be on octet boundaries

      • send request for each /24 as it becomes used

    • DNS setup (RFC-1912)


    Changes with new robot
    Changes With New Robot

    • Requests accepted only with Reg-ID

    • No RIPE DB updates necessary

    • No zone transfer necessary

    • Deletion requests handled (almost) automatically

    • Request for each zone processed separately

    • Successfully passed checks cached

    • Shorthand notation for ranges of objects

    • Delegation checks possible via web interface

    • LONGACK and CHANGE keywords no more


    Useful dns tools
    Useful DNS Tools

    • nslookup (part of BIND)

    • host

    • dig

    • More detailed info

      • http://www.dns.net/dnsrd/tools.html




    Internet routing registry irr
    Internet Routing Registry (IRR)

    • Goals of the IRR

      • consistency and stability of routing

      • enable development of tools to use information

    • Local IR responsibilities

      • register policy information in RR

      • maintain RR information

    • Regional IR responsibilities

      • assigning Autonomous System Numbers

      • consistency checking of data

      • maintenance of RR support tools


    Internet routing registry
    Internet Routing Registry

    • Globally distributed DB with routing policy information

      • provides a map of global routing policy

      • shows routing policy between any two ASes

      • allows simulation of routing policy effects

      • enables router configuration

      • provides contact information

    • RIPE Routing Registry

      • subset of information in RIPE database

      • syntax description in ripe-181


    Global internet routing registry
    Global Internet Routing Registry

    IRR

    APNIC

    RIPE RR

    ...

    RADB

    C&W

    ARIN

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


    Routing registry objects
    Routing Registry Objects

    • aut-num

    • route

    • as-macro

    • community

    • dom-prefix

    • inet-rtr


    The route object
    The Route Object

    • route: 195.35.64/19

    • descr: BLUELIGHT-NET

    • origin: AS42

    • mnt-by: BLUELIGHT-MNT

    • changed: [email protected] 19991010

    • source: RIPE

  • Represents a “route” in the Internet

  • This route originates in AS42

  • Only one origin recommended


  • Cross mnt attribute in aut num object
    “cross-mnt” Attribute in “aut-num” Object

    route: 195.35.64/19

    origin: AS42

    […]

    route: 195.35.74/25 (new)

    origin: AS9999

    […]

    aut-num: AS42

    cross-mnt: BLUELIGHT-MNT

    […]

    mntner: BLUELIGHT-MNT

    mnt-nfy: [email protected]

    […]

    <[email protected]> gets a notification


    As macro
    as-macro

    as-macro: AS-ARCON

    descr: ARCON TML customers AS list

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

    tech-c: BZ318-RIPE

    admin-c: VV82

    mnt-by: ARCON-MNT

    changed: [email protected] 19990914

    source: RIPE


    As macro usage
    as-macro Usage

    aut-num: AS8955

    descr: ARCON Autonomous System

    ...

    as-out: to AS8563 announce AS-ARCON

    as-out: to AS2854 announce AS-ARCON

    ...

    aut-num: AS8563

    descr: DirectNet Autonomous System

    descr: JSC DirectNet Telecommunications

    as-in: from AS8955 100 accept AS-ARCON

    ...


    Whois flags in rr
    whois Flags in RR

    • whois -T route 195.35.64/19

    • whois -i origin AS42

    • whois -i mnt-by BLUELIGHT-MNT

    • whois -i cross-mnt BLUELIGHT-MNT

    • whois -v as-macro

    • whois -a <IP address or range>

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


    Rr tools
    RR Tools

    • RAToolSet

      • sources: http://www.isi.edu/ra/*

    • AS Object Editor (aoe)

    • Aggregation optimisation (CIDR Advisor)

    • Configuration (rtconfig)

    • Visualisation Tool (ASExplorer)

    • IRRj http://www.merit.net/ipma/javairr/irr.html

      • java interface to IRR

    • prtraceroute

  • Looking glasses

    • http://www.ripe.net/cgi-bin/looking-glass

    • http://www.traceroute.org/


  • Special projects part of ripe ncc public services
    Special Projects(Part of RIPE NCC Public Services)

    • Routing Information Service

      • collect routing information

        • between Autonomous Systems (AS)

        • development over time

      • information available to the RIPE community

      • improve network operations

    • Routing Registry Consistency Project

      • improve data quality in the Internet routing registry

      • improve data accessibility and processing capabilities


    Next generation rpsl
    Next Generation - RPSL

    • New language is being developed: Routing Policy Specification Language

      • allows for more refined policy details

      • will eventually replace ripe-181

      • transition to RPSL will be smooth

    • Test

      • rpslii.ripe.net

    • Re-implementation



    Administrivia

    Administrivia

    Audit

    Billing

    Closing


    Audit motivation
    Audit Motivation

    • Audit Activity is a service

      • requested by the community

      • ensure equal treatment

      • LIR can ask for an audit

    • Help LIRs to

      • keep RIPE Database tidy

      • keep up-to-date with new policies


    Audit activity
    Audit Activity

    • Described in ripe-170

    • Initiated for

      • infrequent contact with the RIPE NCC

      • random selection

      • referral by Hostmaster

      • (anonymous) LIR complaint

    • Audit procedure

      • LIR answers list of questions

      • RIPE NCC check database


    Audit steps
    Audit Steps

    • When LIR responds

      • discuss the issue(s) & try to resolve them

      • review AW size

    • If LIR does not co-operate

      • send reminders & phone

      • still no reaction

        • further actions taken


    Billing procedure
    Billing Procedure

    • LIRs pay yearly fee (based on size)

      • ripe-198

    • If payment is late - email reminders

      • 1st phase - 4 weeks after the invoice

        • no action taken

      • 2nd phase - 2 weeks afterwards

        • lower AW to 0

        • mnt-lower on allocation

      • 3rd phase - 2 weeks afterwards

        • service level NONE

      • if still no payment …

    • Discuss payment / invoices


    Closing takeover of the registry
    Closing / Takeover of the Registry

    1) Registry closes completely

    2) Registry takes over another registry and one closes

    3) Registry takes over another registry and both remain open

    4) Non-registry takes over a registry

    ...

    • Contact <[email protected]> for details

      • address space issues

      • billing issues

      • new service agreement

    • No need to change current Reg-ID

      • neither after company changes the name

      • additional ‘start-up’ fee is being charged




    Why ipv6
    Why IPv6?

    • Next generation protocol

      • scalability -- 128 bits addresses

      • security

      • dynamic hosts numbering

    • Interoperable with IPv4

      • simple and smooth transition

    • hardware vendors

    • applications


    Ipv6 introduction
    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
    IPv6 Allocation Policies

    • "Provisional IPv6 Assignment and Allocation Policy Document” (ripe-196)

    • Bootstrap Phase Criteria

      Peering with 3  Ases

      AND

      Plan to provide IPv6 services within 12 months

       40 IPv4 customers

      AND either OR

      6bone experience


    Ipv6 allocations
    IPv6 Allocations

    • Request form (ripe-195)

    • ”Slow start”

      • first allocation to a TLA Registry will be a /35 block

        • representing 13 bits of NLA space

      • additional 6 bits reserved by RIR for the allocated sub-TLA for subsequent allocations

    • Reverse Delegation of an IPv6 Sub-TLA

      • http://www.ripe.net/reverse/

    • IANA allocations

      • APNIC 2001:0200::/23 (12 subTLAs)

      • ARIN 2001:0400::/23 ( 4 subTLAs)

      • RIPE NCC 2001:0600::/23 (19 subTLAs)


    Database object
    Database Object

    inet6num: 2001:0600::/23

    netname: EU-ZZ-2001-0600

    descr: RIPE NCC

    descr: European Regional Registry

    country: EU

    admin-c: MK16-RIPE

    admin-c: DK58

    tech-c: OPS4-RIPE

    status: SUBTLA

    mnt-by: RIPE-NCC-HM-MNT

    mnt-lower: RIPE-NCC-HM-MNT

    changed: [email protected] 19990810

    source: RIPE



    Questionnaire
    Questionnaire

    • Please, complete the questionnaire

    • precious feedback

    • constant improvement

      Thank you

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


    Ripe ncc recycling procedures
    RIPE NCCRecycling Procedures

    Please return the reusable badges.

    Thank you

    [email protected]


    ad