Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 31

RIPE Meeting:

31

Working Group:

Routing

Status:

FINAL

Revision Number:

1

Please mail comments/suggestions on:

Report of Meeting, 23rd September 1998

Chair:

Joachim Schmitz (JS395-RIPE)

Scribe:

Mirjam Kühne (MK16-RIPE), Julia Edwards (JE316-RIPE)

Attenders:

99
A. Preliminaries (Joachim Schmitz)
Joachim Schmitz opened the working group session, passed the attenders' list around, and asked for a volunteer scribe. Mirjam Kühne volunteered as scribe. During the session Julia Edwards took over. The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list.
Review of actions RIPE 30
29.R1 G.Winters, J.Schmitz, RIPE NCC
Definition of the IRR and an AUP
-in progress-
Gerald Winters is giving a presentation in this session on work done so far on this topic
29.R3: RIPE NCC, JLS Damas
Implementation of PGP
-to be closed-
The action may be considered closed because it will be moved to beta in the next two weeks
30.R1: RIPE NCC, JLS Damas
Implementation of autnum authorization
-postponed-
Implementation has been postponed because this is one special feature within the more general scope of the RPS Authorization draft
30.R2: RIPE NCC, J. Schmitz, W. Woeber
Organize RPSL tutorials for RIPE 31
-done-
The RPSL tutorial has been held.
B. Report from the RPSL Tutorial (Joachim Schmitz)
RPSL is the "Routing Policy Specification Language" developed by the IETF RPS Working Group. For those who are not familiar with this topic the following pointers may be of interest:
http://www.ietf.org/html.charters/rps-charter.html
http://www.isi.edu/ra

RPSL is in the stage of deployment phase 2 with the final transition phase from RIPE-181 in sight. Part of the transition is education to make it easier for users to apply RPSL. After some tutorials in the US we had the first RPSL tutorial in Europe just prior to this RIPE meeting. There were approximately 90 participants.

The training materials are available electronically at http://www.isi.edu/ra/rps/training. Future tutorials will be held at the next RIPE meeting, and plans to offer them as part of the LIR tutorials are currently considered.

Joachim Schmitz then thanked the trainers Cengiz Allaetinoglu, David Kessens, and the RIPE NCC, for preparing and performing this tutorial.

C. Report from the RIPE NCC (Joao Luis Silva Damas)
The report included a general update on NCC activities. In the database software, cross notification was added, making use of the two tags "cross-nfy" and "cross-mnt". The functionality follows the specifications developed by the Routing WG in earlier sessions, both regarding notification in relation to "autnum" and "route" objects.

In addition, PGP authentication will also become available in approximately two weeks for production after this RIPE meeting. This method is supplied in parallel to "none", "e-mail address", "UNIX style password" but offers significantly better security. This method may currently be tested at

queries:

beta-whois.ripe.net

submissions:

[email protected]

in beta status. The implementation follows the Internet draft draft-ietf-rps-dbsec-pgp-authent-00.txt developed in the RIPE Database Security Taskforce, and written up by its member Janos Zsako.
D. Reports on RPSL Deployment at Registries
  1. RIPE NCC (Joao Luis Silva Damas)

    Phase II of the transition has been completed, meaning that a mirror of the production database is installed and running. The mirror according to definition of transition phases is one-way only (RIPE-181 -> RPSL). The phase II database is accessible at

    Submissions in RIPE 181 format are still possible and will be translated into RPSL. At the same time straight RPSL submissions are possible. Only autnum objects are currently handled in RPSL format.

    The database is running using ISI's code written by David Kessens. The usage is still low (which is no wonder because the server just became available).

    In the future, as part of the database reimplementation, the RPSL capable database will support the full set of RPSL features, and also support the RAToolSet.

  2. ISI (David Kessens)

    There are three phases proposed in the transition from RIPE-181 to RPSL:

phase 1:

software development

done

phase 2:

tool development, testing, training

real time mirror of IRR in RPSL format

special RPSL update path for "autnum" objects

status of today

phase 3:

switch over

incoming RIPE-181 objects are automatically converted to RPSL

expected during 1999

RIPE, ANS, and Merit are currently in phase 2. MCI and CANET are testing RPSL software. Telstra moved to RPSL, and Connect (AU) is already configuring their routers using the alpha RAToolSet for RPSL. A set of others is known to evaluate.

Regarding training and education the following tutorials were held so far

  • Jun 1998, NANOG in Detroit
  • Sep 1998, RIPE-31 Edinburgh
  • Mar 1999, APNIC, Apricot (planned)

To make use of RPSL, the following software is available:

  • RAToolSet
  • RIPE database with RPSL extensions which is compatible to RIPE db 2.1.3. The full RPSL support will move to beta soon.
  • RIPE-181 to RPSL database objects converter

The software is available on the web.
  • RADB (Gerald Winters)

    Merit offers a public RPSL server

    • rpsl.merit.edu 43
    since spring/summer 1998. Usage is on the rise, and comments from users are focusing on two items
    • why is the system rejecting my AS object
    • here is a bug I see

    In Gerald's personal opinion, a large number of RADB users has not yet logged on to the RPSL server because
    • the old software works and still seems to satisfy their needs
    • a steady influx of users exist who do not know RPSL
    • there is a group of "regular" registry users who think the ISP will do it all

    Therefore, Gerald lists the following suggestions:
    • continue the current education strategy
    • include informative footer messages in email transaction responses
    • I do not see things as bleak
    • registry admin's will certainly be putting in extra email consulting hours.

    Usage and involvement by ISPs at this time is not much. Most of it comes from specialists, or users already interested having discovered the potential in RPSL. Usage outside the US, especially in Europe is still low. It is obvious that more training is needed, and work to make it more useful. Users will definitely change their attitude if usability is better.
    • E. Do we need a Routing Registry for IPV6? (Joachim Schmitz)
    In the introduction, a short review was given of what currently is part of the IPv4 routing registries, and what benefits its users have from it. It is obvious that today no IPv6registry exists, and the question was raised whether one is needed.

    Then the current situation regarding IPv6 was described, and the expected development of IPv6 "Inter6net" with its interaction towards IPv4 listed.

    Looking at the benefits the IPv4 IRR offers, it seemed obvious that they are also applicable to an IPv6 routing registry. Consequently, the conclusion was drawn that a need for an IPv6 routing registry exists, which may even add more value by easing the coexistence of IPv4 and IPv6, and may help in transition to IPv6. The time to raise the topic is not too early because during the 1st quarter of 1999 IPv6 address allocation is likely to begin.

    The presentation was finished with a call for participation to explore the idea and to define the requirements.

    F. An AUP for the IRR (Gerald Winters, Pierre Thibaudeau, Joachim Schmitz)
    The authors feel that a need exists to build an acceptable use policy for the IRR. To start with, the question was discussed what an AUP is. It may simply be defined as a document which lists acceptable IRR practices and data, covering topics for the users like
    • what purposes should the IRR be used for?
    • what types of data would I register?
    • Are there important relationships between objects I should be aware of?
    • Can I find suggestions for maintaining my data?

    The goals of the AUP may be summarized as
    • add value to the IRR
    • address the concerns of (the user and db admin)
    • provide an easy to understand single point of reference
    • prevent abuse

    The AUP may then be used
    • as reference point, especially for new users
    • by registry admins signing the AUP to declare the data as conformant with it
    • by users (eg, comparable to the implied consent from the RIPE copyright in the RIPE.db)

    The AUP is still under development. The work on it is not yet complete, and some of the suggestions require further detailed discussion. The talk was given to make the community aware of the AUP, to solicit feedback, and to ask for support.

    The IRR AUP will definitely acknowledge other efforts. Others are currently defining relevant policy rules or have already done so

    • RPS (rps-auth)
    • RIPE NCC
    • Merit

    Some of the ideas to follow overlap or duplicate existing policies. This is not a bad thing, and it shows consistency with our goal to provide a single point of reference.

    In the following part of the presentation, a starting framework for an AUP was shown:

    • Contact information should be kept up to date
      "Contact information is important data which facilitates communication between network parties. Therefore it is encouraged to keep role and person object data up to date as well as all tech-c and admin-c references."
    • Commercial uses of the IRR
      "All commercial uses are stricly forbidden. Contact information must not be used for commercial purposes, advertising purposes, or any other purpose beyond the scope of activities relating to the successful operation of the Internet."
    • Old objects
      Old objects are a matter of concern. They are not necessarily invalid. However, current does not imply up to date. So aging out objects based on a "changed:" time stamp (even machine generated) is probably a bad idea. Using global routing data with IRR information is a better solution. A suggestion may build on read time stamps, because it shows that even old data is still accessed, and therefore most likely still valid. Yet, it must be explored whether this approach is practical.

    Obviously, there is a series of items which needs further discussion. This includes the concept of cross notification and whether it is recommendable or not. The following discussion did not very much enter this area but focused on the abuse of data in the registry, including contact information by spammers, reluctance of service providers to disclose their policies (company policy and possible business impact), and security of data in the database.
    G. Routing Policy System Security (Cengiz Allaettinoglu)
    Due to time constraints the presentation on this topic was moved to the Database Working Group session. Joachim Schmitz apologized to Cengiz, and thanked Wilfried Wöber for accepting the transfer.
    Y. I/O with other WGs
    The presentation on whether a Routing Registry for IPv6 is needed was also given as input at the IPv6 Working Group.
    Z. AOB
    There were no additional comments or issues.

    Agenda

    - Routing Working Group Meeting -

    Agenda for RIPE 31, September 1998, Edinburgh

    A. Preliminaries (Joachim Schmitz)
    • introduction
    • participants' list
    • volunteering of scribe
    • agenda bashing
    • RIPE 30 minutes
    • actions from earlier meetings
    B. Recent Developments (Joachim Schmitz)
    • RPSL tutorial
    C. Report from the RIPE NCC (Joao Luis Silva Damas)
    D. Report on RPSL Deployment at the Registries
    • ISI (David Kessens)
    • RIPE NCC (Joao Luis Silva Damas)
    • RADB (Gerald Winters)
    E. Do we need a Routing Registry for IPv6? (Joachim Schmitz)
    F. An AUP for the IRR (Gerald Winters)
    G. Routing Policy System Security (David Kessens, Cengiz Allaettinoglu)
    Y. General Input from Other WGs
    Z. AOB

    Summary of Actions

    Action 29.R1: G. Winters, J. Schmitz
    Definition of the IRR and an AUP
    Action 31.R1: RIPE NCC, J. Schmitz, D. Kessens
    Basic Design for an IPv6 IRR

    Mirjam Kühne, Julia Edwards, Joachim Schmitz
    21 January 1999