RIPE 23 Minutes

1. Opening

1.1. Welcome

Rob Blokzijl welcomed the participants to the 23rd RIPE meeting hosted by NIKHEF in Amsterdam, The Netherlands.

1.2. Papers tabled

• Agenda for the 23rd RIPE meeting
• Working Group Agendas
• List of Participants of the 23rd RIPE meeting

2. Agenda

The agenda was approved. Note: some of the agenda items were rescheduled during the meeting but they are minuted as originally scheduled.

3. Minutes of the last meeting

The minutes of the 22nd RIPE meeting were approved with no changes.

4. Review of the action list of the last meeting

The action items from the 22nd RIPE meeting minutes were reviewed. The following list comprises the ongoing action items only. All other action items were closed.

Action 21.3 on Daniel Karrenberg, Mike Norris
To draft a recommendation on charging by local IRs until September

Action 21.9 on Erik-Jan Bos (Wilfried Woeber)
To update the proposal "A Multicast Router in the Routing Registry" delegation process.

Action 22.12 on David Kessens
To work with A. Blasco Bonito to improve the WAIS functionality for access to the database information on info.ripe.net. auto-assign).

Action 22.16 on RIPE NCC
To follow up on and implement the NOC-Object.

5. NCC REPORT

Daniel Karrenberg started the NCC report, after which Mirjam Kuehne, as the new manager Registration Services, took over most of the presentation. The slides of this presentation provide a concise but complete overview of the report. They can be found at:

• ftp://ftp.ripe.net/ripe/presenatations/ripe-m23-dfk-NCC-REPORT.ps.gz
• ftp://ftp.ripe.net/ripe/presenatations/ripe-m23-mir-RS-REPORT.ps.gz

Questions and remarks made following the presentation:

Mike Norris expressed concern about the growing number of small registries while the number of medium and large registries stayed fairly stable. He proposed that the NCC would make a suggestion to registries that they upgrade to a higher category, if this seems appropriate. The answer from Daniel was that this is indeed being done at certain points in time.

Regarding the fact that the RIPE NCC will restart some technical activities, Wilfried Woeber asked if and how the RIPE community should be involved in steering the direction of these activities. Daniel noted that the RIPE NCC is well in touch with the various RIPE working groups on this, and that the emphasis is currently on issues that the routing working group is dealing with.

6. RIPE NCC Activity Plan - evaluation / update

Rob Blokzijl announced that it would soon be time to reevaluate the RIPE NCC action plan, as is done every two years. He announced that an electronic mailinglist would be set up to discuss these matters. Rob urged everyone interested to participate in the revision of the action plan. The creation of this new mailinglist 'ncc-review@ripe.net' would soon be announced at the 'ripe-list' mailinglist.

7. NSF: RA report

Elise Gerich gave a presentation covering the activities that MERIT is currently involved with. The presentation emphasised mainly on the tools, having to do with Internet Routing, that are being developed. An overview of these can be found in the slides of the presentation, which will be available at:

• ftp://ftp.ripe.net/ripe/presentations/

as soon as they are received by the RIPE NCC.

Elise stressed that these tools are developed for the Internet community as a whole and that MERIT is keen on any input that helps or steers them in the process of development.

8. European NetNews Coordination

Willi Huber reported on the NetNews BOF that was held earlier during the meeting. The minutes of this BOF can be found after the minutes of the Working Groups.

9. Address Space: Aggregation versus Conservation

Daniel Karrenberg introduced this point that was put on the agenda to create some discussion among the RIPE members, and eventually reach consensus on the way to approach the issue.

The presented issue has two problems whose solutions work against each other. The first is the future runout of IPv4 address space, which causes Internet Registries to be conservative in handing out address space. The second is the runout of routing table space, which makes it necessary that address space is assigned in an aggregatable way. Aggregation could be improved by handing out larger blocks to Local Registries, but this goes against the goal of conservation of address space.

A current issue is that at least one large Internet Service Provider threatens only to route prefixes of size /18 or shorter across its networks, in the 195.0.0.0/8 block. (This is the block that will soon be used by the RIPE NCC for allocating address space to its Local Registries.) This is in conflict with the RIPE NCC's allocation policy to hand out /19 prefixes to new registries. In addition, the IANA has recently stated that allocation policies from regional registries should not be influenced by the policies from individual ISPs.

Daniel first made clear that this /18 restriction only goes for the 195/8 block and not for the 193/8 and 194/8 blocks. After that he asked for input from the audience (the RIPE community) concerning the way the NCC should go with regard to this issue. He hinted at two possible ways to go:

• ask US Sprint not to filter prefixes in the 195/8 block, based on the good track record that the European ISP community has regarding aggregation;
• ask the IANA to change its policy statement regarding allocations from Regional Registries.

The discussion that followed is partially represented below.

(Havard Eidnes) We should try to reduce the number of routes in 193/8 and 194/8. Then we will have more justification to go to Sprint and ask them to change the policy for 195/8.

(DK) Agreed - the question is how we achieve this.

(Geert Jan de Groot) There is not much more that can be won in 193/8 and 194/8 by eliminating unnecessary route entries. If they want to reduce or even stabilise the number of routes, the ISPs should agree not to take customers that have their own IP numbers out of another ISP's block. The customer should be told to renumber. All ISPs should agree to do this in order for this to work.

(Lars-Johan Liman) Can we set a goal (in terms of number of routes)?

(Wilfried Woeber) The goal should not only include the number of routes but also where these routes are measured, since the number varies per location.

(DK) The number of routes measured in Amsterdam does not vary dramatically with the rest of the world.

(Peter Galbavy) We should make people see regularly who creates the biggest number of routes. 'Embarrass them'.

(DK) This was also done in the past.

10. Working Groups Reports

The chairs from the various working groups gave reports on the working group meetings that were held earlier. The minutes made by each working group chair/scribe follow below. At the end of each minutes, questions may be found that were asked by the RIPE23 audience following the reports.

10.1. European Operators Forum

Chair: Peter Lothberg
Scribe: Havard Eidnes

10.1.1. Welcome

Peter Lothberg (PL) welcomed everyone to the meeting.

10.1.2. Agenda bashing

No additions to the agenda were proposed.

10.1.3. Minute taker

HE volunteered.

10.1.4. Apologies

None received.

10.1.5. Previous minutes

No comments were presented. The previous minutes were approved.

10.1.6. Status updates of interconnect points

PL invited updates on

• Status
• WWW info availability

Stockholm D-GIX

Changes since last time: about to expand geographical coverage of the D-GIX via fiber cables provided by Stokab, providing D-GIX functionality at carrier colocate facilities. Locating equipment at KTH remains possible. Web pointer: http://www.sunet.se/dgix/

French GIX

The main model is still that France Telecom owns and manages customer routers connected to the interconnect point. The interconnect is a shared ethernet, and FT charges 50K FFR a year for this service.

A new offer is currently being provided where each ISP can rent rack space and house and manage their own router connected to the IX. Prices for this service are not yet available.

The shared ethernet will be replaced by switched ethernet, possibly interconnected switches with fast ethernet (100baseT). All customer connections are for the immediate future foreseen to remain at 10 Mbit/s ethernet speed.

Web information available from:

• http://www.urec.fr/Renater/gix/gix1000.html (french) and
• http://www.urec.fr/Renater/gix/gixangl.html (english)

LINX

There are now 17 connected providers. Recent activities include formalizing the organizational matters of the LINX. For 1995-1996 the fees are 5000 GBP/year plus 5000 GBP in startup fee. The LINX is currently housed in three racks housing respectively telco equipment, routers and switches. The LINX is located at Telehouse in London.

Technically the LINX is implemented with two Cisco Catalyst switches interconnected with FDDI. Currently there is no switching of >10Mbit/s medium, they are currently looking at alternatives (FDDI or 100Mbit/s switched ethernet), and are wondering whether 100Mbit/s ether is a good idea. Peter Lothberg commented that "In theory, it's not a good idea", and said that the Digital GigaSwitch can throttle a sender under congestion by temporarily "stealing" the token, thus pushing the requirement for buffering back at the connected router.

The LINX is not to be used for providing transit service, however private "backdoor" connections can be established in the same physical facility should that be required.

Web pages are available from: http://www.linx.net/

Moscow

Implemented with an ethernet switch. The fee for connecting is approx. 200 USD/month, the policy is "bring (and manage) your own box".

Oslo

The Norwegian Internet eXchange (NIX) in Oslo has been in operation since April 1993. It currently connects 7 different service providers, most of them providers with Norwegian coverage of their services. The current implementation is an ethernet switch. No web information is currently available.

Exchange points in Munich, Portugal, Ljubljana and Prague were also briefly mentioned. Either there was no new information (the three first (?)) or the exchange point was yet to be fully established (Prague). Updated web pointers were solicited for those currently lacking these.

10.1.7. European issues for NANOG

PL would attend NANOG in San Diego 15-16 February, and solicited input. No input appeared.

10.1.8. Filtering of prefixes (routes)

As most know by now, US Sprint has imposed prefix length filtering in certain network blocks. Specifically, US Sprint will not admit prefixes longer than 18 bits in the address space 207.0.0.0/8 and 208.0.0.0/8. The same kind of filtering is set up for 195.0.0.0/8. This will soon start to impact the european service providers who are allocated address space out of this block. In particular, this conflicts with the RIPE policy of only allocating a /19 prefix to new registries until a usage rate has been established.

While routing is a slightly separate issue from allocation of address space, the obvious for a newly established service provider would be to announce his /19 block with routing, and if he has addresses in the 195.0.0.0/8 block he will not be able to communicate with customers of US Sprint.

Sean Doran explained that the same limit has been set for 195 as for 207 and 208 on the grounds of consistency, and that if that should change a solid explanation has to be presented.

Daniel Karrenberg suggested that as long as the number of routes in 195.0.0.0/18 remains below 1024, US Sprint should allow /19 prefixes in this block. This has the obvious problem that if this target is not met, people who were earlier able to communicate with US Sprint using a /19 prefix would be blocked when the limit had to be raised to only accepting
/18 and shorter prefixes. Also, the RIPE NCC cannot give any guarantees that the number of routes in this block will remain fewer than 1024, as it has no way to apply force towards the service providers.

[I must admit I didn't catch any conclusion here, if there was any]

10.1.9. Renumbering

Peter Lothberg did a presentation written by Yakov Rekhter on renumbering. The essence was that *some* need to renumber, and some current and near-future techniques for assisting in renumbering were mentioned: DHCP, Dynamic DNS update, Graceful host renumbering (interface aliases) and use of NATs (Network Address Translators), ALGs (Application-Layer Gateways), SOCKS (essentially IP tunnelling (?)) etc.

It was also mentioned that IPv6 with the current routing schemes proposed has essentially the same problems as IPv4 in this area: renumbering will in some cases have to be performed to permit sufficient scaling of the Internet routing architecture. [Ed.: some claim that the auto-renumber hooks in IPv6 solve this problem, while other think it merely is a modest assistance in the matter.]

10.1.10. Aggregation of CIDR blocks cross-Atlantic

This was merely briefly mentioned as a possibility, and that it "may be possible". [This remains to be seen, though.]

10.1.11. Internet World Fair / Internet Railroad

The "Internet World Fair" is basically "like a world fair, but on the net". Anyone may put up their own "pavilion" on this exposition. To support this initiative an "Internet Railroad" network is being built. It's topology will be approximately as sketched here (sorry 'bout the ASCII graphics, it's all I can do with this medium, though...):

Seoul------Tokyo-------Washington DC-----New York
! !
! !
! !
Taiwan !
!
Stockholm------Helsinki
/!\ \ !
/ \ \ !
/ ! \ \ !
/ \ \ !
/ ! \ \ St.Petersburg
/ \ \ !
London ! \ \
Paris \ !
Amsterdam Munich
!
!
Moscow

The "sparsely dotted" lines are a little uncertain.

All the lines will be either T3 or E3.

There will be an AUP for this network, and that is that usage of the network should be "good for the Internet". There will be a number of servers scattered about on this network. Quite substantial amounts of sponsorship has been gathered for the project, among others for bandwidth and for disk space -- Quantum has donated 1TB of disk drives to the project.

More information is available from: http://park.org/

10.1.12. Any other business

None.

10.1.13. Next meeting

In conjunction with the next RIPE meeting, i.e. 22 April in Berlin.

Meeting adjourned.

10.2. DNS Working Group

Chair: Antonio-Blasco Bonito
Scribe: Carol Orange

10.2.1. Scribe

Carol Orange took notes.

10.2.2. Agenda

The agenda was agreed to without changes.

10.2.3. DNS Working Group Chair

Rob Blokzijl:

• announced that the former DNS-WG chair (Leonid A. Yegoshin) had to resign due to a change in both job and residence.
• invited people to suggest candidates for the DNS working group chair.

Hopefully a new chair will be appointed during the next RIPE meeting.

10.2.4. Status of 'in-addr.arpa' automatic checking

David Kessens gave an update on the tool he created for 'in-addr.arpa' automatic checking and delegation. His report included the following information:

To use the tool, one must:

• submit the appropriate RIPE database template (inetnum or domain).
• send the template to <auto-inaddr@ripe.net>.

The tool will:

• check the setup of the primary and secondary name servers.
• if no errors are detected, forward request to human operator for final approval.
• report back to user.

The tool will *not*:

• check the relative location of servers.
• check whether the corresponding address space is allocated or assigned.
• check whether /24's which fall under a /16 to be delegated, have been delegated.

The latest version has several software improvements including:

• a standardised output transaction format.
• tools for RIPE support staff to check what the tool does not check (see above).
• a number of bug fixes.

Currently under development:

• a tool to automatically update RIPE NCC zone files after human approval.

Plans to integrate the tool in RIPE database will mean:

• requests should be submitted to database with keyword.
• the RIPE database authentication mechanism will be used to validate requests.

The tool is available in:

• ftp://ftp.ripe.net/tools/inaddrcheck-960110.tar.gz

Following David's report, the following discussion ensued.

Documentation about reverse delegation procedures was requested. David replied that the necessary information will be provided in ripe-104++.

Whether the automated mechanisms for inverse delegations will work with IPv6 came up. There was some discussion as to whether this is important given the slow progress of IPv6. However it was also mentioned that as test beds are becoming operational, these and other tools will be needed to support them. It is expected that at most minor modifications to these mechanisms will be required for use with IPv6.

Randy Bush raised the issue of data integrity of DNS, and asked whether steps are being taken to prevent corruption of the inaddr.arpa name space delegated in Europe. After some discussion on this topic, Randy said he has some tools available for inspecting the integrity of DNS name space. Those interested are welcome to contact him.

This was followed by a discussion of how lame delegations come into being and why they need to be cleaned up. It was pointed out that the number of bad entries in the inaddr.arpa name space will increase as renumbering goes in to effect. It was also mentioned that currently the integrity of the European inaddr.arpa name space data is quite good.

10.2.5. Status of the BIND software

Blasco Bonito announced that a the final version of Bind 4.9.3 has been released.

Geert Jan de Groot recommended that nameserver functionality should be split up between recursive (non-authoritive) and authoritive nameservers. For authoritive nameservers, he recommend to use the 'no recursion' option to prevent data pollution, and to control data sizes.

Action 23.1 on Geert Jan de Groot
To write up recommendations for managing nameserver configurations.

Finally, Randy Bush reported that a new version of TGV is available for VMS users. Their new release contains, among much other stuff, a modern version of BIND with all the recent improvements (performance, security, etc). Folks should be strongly encouraged to upgrade. By the way, TGV was recently bought by cisco.

10.2.6. Report of problems experienced

There have been some problems with the delegation of TLD names under non TLD domains. For example, someone recently delegated the name sgi.net.co.uk. The result is that sgi.com couldn't be resolved anymore when using some old resolvers. As a large number of similar names were generated, the DNS name space became severely polluted, and it took two days to clear it up.

According to Geert Jan, the problem is caused in part by old bind software, which in accordance with RFC1535 should no longer be used, but in practice is.

Guy Davis says that in the UK, delegation of top level domain names under TLDs (e.g. net.uk) will no longer be permitted.

It was reported that this is already the case in other countries (i.e. Germany, Italy, ...) and that DNS second level administrators are also discouraged from allowing top level domain names to be used.

There was some discussion as to whether the problem should be solved by getting administrators to replace old resolver software or by getting them to abstain from delegating TLD names. In the end, there was consensus that the problem should be tackled as a combined effort.

It was mentioned again that the security issues are discussed in RFC-1535 and that DNS administrators should be reminded to review that document carefully.

10.2.7. Report on European TLD administrator's questionnaire

Guy Davis reported on a questionnaire he sent out to European TLD administrators. The questionnaire was designed to determine the policies used in DNS delegations by the TLD administrators. A summary of the report he presented follows.

DNS TLD - Questionnaire

• 22 response for 24 top level domains
• Full set of answers available on request

EDITED HIGHLIGHTS

1. Who defines your policies?

Org Running TLD - 15 1
The Government - 1 1
ISPs by consensus - 4

2. How do you establish your policies?

By Working Group - 2
Told by Govt. - 1 1/2
Decided by Org Running TLD - 7 1/2
ISPs by Concensus - 10

3. What Legal Status do your decisions/policies have?

None - 19 1/2
As defined by Govt. - 1 1

4a Public Subdomains?
Yes - 7
No - 15

b Geographic Subdomains?
Yes - 6
No - 16

c 2nd level categories (private & public) in parallel?
Yes - 6
No - 16

d If you have public subdomains must everybody's request be accepted?
Yes - 7
N/A - 15

e How would you split your TLD
See full listing - 6
N/A - 16

5a Sub. TLD?
Yes - 20
No -2

b Sub. public TLD?
Yes - 7
No - 15

6a Who can obtain domains?
Anyone - 11
Just Orgs - 11

8 Must the requester be local?
Yes - 16
No - 6

9a More than one domain per Org. ?
Yes - 12
No - 10

17a Do you charge ?
Yes - 5
No - 16

19 Are you likely to change the system within 12 months?
Yes - 14
No - 5
Don't know - 3

22 Do you use automation?
Yes - 11
No - 11

After Guy's presentation of the above data, a discussion started regarding the charging fees and schedules. Most TLD administrators presently don't charge, but are thinking about doing so to cover their costs. Among those who do charge, some have only a one time fee, and some have a yearly administration fee.

There does not appear to be competition among the national TLD administrators. Moreover, running a TLD is primarily performed as a non-profit service to the Internet community.

Blasco suggested a need for better coordination among TLD administrators, so they can consult one another on technical and policy matters. It was pointed out that this does not mean they will all follow the same policy.

The question was raised as to whether some private forum for communication among TLD administrators should be created, so they can exchange information easily.

Whether or not 2nd level domain administrators might be included in the "private" communication was considered.

Action 23.2 on RIPE NCC
To set up a mailing list for TLD administrators.

A need was also expressed that the policies of TLD administrators be made public.

Action 23.3 on RIPE NCC
To incorporate a page where TLD policies can be published at its WWW site.

It was suggested the questionnaire be repeated in 6 months so that changes in policy can be monitored.

10.2.8. Delegation of International TLDs (Randy Bush)

Randy Bush explained that there is a lot of talk in the US at the moment about whether and why new TLDs should be created. International TLDs are com, org & net. The main reason for expanding these is to create healthy competition in the market. Also, the US government (NSF here) wants to be out of the IP and DNS delegation business.

Randy also presented a set of guidelines that should be used in determining whether a new TLD can be created.

There was some discussion as to whether or not names should be used for profit. Also, whether a white pages service (which is what DNS provides) is sufficient, or whether we should start looking into yellow page models for directory services.

Back to the name space: it is perceived that the US wants to control the name space. Who gave them the right to edu, mil, and gov? Basically, it was stated that the US came up with
those names, so they have a right to them. Still the process remains unclear.

Piet Beertema said the US should use the extension "us" just as other countries use country extensions.

Randy then summarised the proposal they are submitting to slowly expand the number of TLDs. The number of TLDs would be increased at a rate of about 3-5 per year. Basically, anyone suggesting a new domain should argue that it will serve some purpose that none of the currently existing TLDs do, and agree that it will be managed responsibly following the guidelines agreed to in RFC1591 (as well as some new ones: non-discrimination policies, appeals procedures, etc.).

Piet B. pointed out that those changes only generate a false sense of order in the chaos. The new policies only apply to new TLDs, not to the old ones. No similar restrictions are applied to second level domain administrators.

Mike Norris pointed out that DNS administration is experienced as a public service in Europe.

Randy said that "com" on the other hand is turning into a high profit monopoly, and the new suggestions are intended to curb its power.

A discussion surrounding the trademark wars surrounding domain names started up. Should the names be delegated on a "first come, first served" or should DNS administrators be required to control trademarks.

Back to the issue as to whether new TLDs should be created:

It was suggested that whereas the US TLDs fall under ".", they should be placed under "us" (e.g. com.us, mil.us, edu.us, etc). In other words, the problems surrounding "name for profit" monopolies are US based, and should be solved there. To clarify this, Randy asked the audience whether they should be removed from the root. There was general consensus about that.

That was about it for the DNS working group.

10.3. MBONE Working group

Chair: Magnus Danielson (KTH/IT)
Scribe: Kurt Kayser (ECRC)

10.3.1. Opening

10.3.1.1. Welcome

Magnus Danielson, Chair of the MBone WG welcomed everybody.

10.3.1.2. Apologies

No apologies were received

10.3.1.3. Minute taker

Kurt Kayser volunteered for the scribe of the meeting minutes

10.3.1.4. Outstanding action items

21.9 no progress yet, will be done (did nowhere find a list of current action items... maybe we should publish them on the web, or on the ftp-server?)

10.3.2. The Mbone topology in Europe (and the US)

10.3.2.1. Strategy for intradomain topology management

Magnus recommended that all mrouter administrators should enable the unicast reachability due to problem isolation and troubleshooting issues. It helps a lot to create statistics and provide answers to connections that are currently down or unreachable hosts.

Existing M-tools (like mstat, mrinfo, mtrace and others) provide an easy mechanism to show the current status of tunnels, utilization and errors.

There are 2 relatively new tools which are called mconfig and mview which provide a GUI interface for the mrouted's configuration file (/etc/mrouted.conf) and shows also an overview of the configured VIFs and their addresses plus actual status.

Magnus promised to publish the sources and pointers to the FTP-Servers on the mailing-list.

Action 23.4 on Magnus Danielson
To publish the sources of mconfig and mview and send pointers to the sources to the mailinglist.

10.3.2.2. Software versions and global optimation

The 'cleanup raid' DVMRP contains some RIP code which causes some scalability problems with the current expansion of the Internet/Mbone. The algorithms used in DVMRP are hard to debug and on heavily loaded lines sometimes instable.

Magnus asked if someone had heard of the "cleanup-raid" before. Nobody had. He explained that it is an effort to 'cleanup' the different versions of mrouted and already deployed Cisco PIM code that is currently not supported anymore or even outdated and harms the functionality of the international Mbone. These versions are mrouteds before 3.5 and Cisco IOS Versions 10.2 and 10.3 because of pruning problems and incorrect routing-table behaviour.

Magnus showed a comparison of European countries and their percentages of different versions currently in use.

A comparison with the US shows clearly that the version numbers in Europe are quite higher than in the US.

World Table of Mrouted/IOS versions

10.3.2.3. Maps - A constant concern. Why are they needed?

Still under development by Magnus and Kurt Kayser. Magnus explained his way of notation of a tunnel description: metric/threshold/bandwidth It is a convention that should be kept by other European metric or topology changes as well. It is suggested that all changes are forwarded to WG so that we can keep track of the current topology.

Maps are currently collected and evaluated. Magnus is also working on integrating online information elements into a postscript map that printout could reflect the current status of the European Mbone connectivity.

10.3.2.4. Link description list/map

A question was how other countries or institutions (US or NASA i.e.) keep track of their connectivity and topology integrity. Action item could be to contact other Mbone administrators to get this info?!

Maps should also show a link description with speed and metric values for both ends.

10.3.3. Various Issues

10.3.3.1. Presentation of the TF-ATM/MICE test network results

Victor Reijs gave a presentation of the experiences that were gathered during usage of the Pan-European ATM test network in conjunction with MBone applications. (include some slides or excerpts?) URL to the Terena Server where the project was homed is:

• http://www.terena.com/

10.3.3.2. MBone EU FAQ and web pages - call for more info

The EU-Mbone-FAQ was moved to:

• http://www.it.kth.se/~e93_mda/mbone/ripewg/eufaq.html

Action 23.5 on RIPE NCC
To include a pointer to the EU-Mbone-FAQ in the RIPE WWW-server.

10.3.4. Closing

10.3.4.1. Summary of new actions

10.3.4.2. Thanks

Thanks to Victor Reijs for his presentation and Kurt Kayser for scribe.

10.4. Local IR working group

Chair: Mike Norris
Scribe: Anne Lord

At the working group meeting there were 111 attenders.

10.4.1. Preliminaries

A scribe was volunteered :) and the agenda which was previously circulated to the Local IR mailing list was agreed with some modifications to the order of the discussion. The minutes will reflect the order in which items appeared on the agenda.

10.4.2. RIPE 22

10.4.2.1. Minutes

The minutes of the 22nd RIPE meeting had been circulated shortly after that meeting to the Local IR mailing list for comment and minor corrections were made to the text. The minutes were then accepted.

10.4.2.2. Review of actions

Action 21.3 on Daniel Karrenberg, Mike Norris
To draft a recommendation on charging by local IRs until September.

Action is still open. A first outline had been written but needed further study and elaboration before a draft would be sent to the list.

Action 22.1 on Mike Norris and RIPE NCC
To find volunteers from the Local IR working group to continue working on the revision of ripe-104++ without waiting for the publication of rfc1466++.

This action was closed. In addition to the RIPE NCC, the members of the editorial committee were:

• Mike Norris
• Wilfried Woeber
• Sabine Dolderer
• Hans Petter Holen
• Holger Weinhardt
• Janos Zsako

10.4.3. Reports from registries

10.4.3.1. European Regional Registry (RIPE NCC)

As the formal report from the European IR was presented in the RIPE meeting plenary, the report to the working group was brief. The shortened report was as follows:

• there are now 308 local IR's.
• the predictions for the workload for 1995 were accurate.
• new staff are now fully trained.
• the "wait" queue is now empty ("wait" queue is non-assigned requests).
• approximately one new registry per working day is now being signed up.

10.4.3.2. Other Registries

There were no comments from other local registries.

It was suggested that this might be a good opportunity to organise a local IR workshop in conjunction with the next meeting. There was consensus within the group that this should not be organised in parallel with the EOF meeting. An action item was taken on by the RIPE NCC.

Action 23.6 on RIPE NCC
To organise a Local IR workshop in conjunction with RIPE24.

10.4.4. Registry Procedures

10.4.4.1. European registries - ripe-104++

The draft document "European Internet Registry, Policies and Procedures" (ftp://ftp.ripe.net/ripe/drafts/ripe-104++.{txt,ps}) was previously circulated to the Local IR mailing list for comment. There has been and still was considerable discussion on the mailing list. Within the working group the aim was to isolate the salient points and to resolve any differences of opinion so that consensus could be agreed and the document progressed.

The following points were discussed:

Assignment procedures

VSEs

• It was commented that the assignment procedures are too complicated for VSEs. The common situation being one or two externally facing hosts and the rest behind a firewall. It was suggested that the end customer does not necessarily have to complete a network number application form in such cases, but the information might be collected by the Local IR. The important point is however, that the information is archived.

PI/PA address space issues

• There was a discussion about PA (Provider Aggregatable) and PI (Provider Independent) address space. If your customer insists, PI address space can be allocated. Local IRs can apply on a per case basis for PI address space from the EU IR or they can apply for a PI block. As specified in ripe-127, there will be no guarantees over the routability of such blocks assigned and using such address space is *strongly* discouraged.
• It was also suggested that ripe-104++ could include a sentence to strongly recommend that ISPs/Local IRs should *not* accept PA address space from new customers which is outside their own CIDR address space. This was agreed.
• There was a question about the existing allocation registration information in the RIPE database. It was agreed that unless a contractual arrangement existed with the customer, assignments in the RIPE database without the "status" attribute marked as PA are considered PI (Provider Independent). If local IRs can make such contractual arrangements retrospectively, then such allocations can be considered PA and marked as such. Agreed.
• Assignments of address space are only valid as long as the assignment criteria under which the original addresses were allocated are still true. Agreed.
• It was suggested that the assignment messages from the RIPE NCC could be made clearer to reflect the significance of the PA assigned address space.

Renumbering

• There was some discussion around the procedures for renumbering. It was agreed, that this would be encouraged by making the procedures as easy as possible for those who had agreed to renumber and words to the effect that the size of the previous assignment would not be questioned unless the efficiency was extremely low.

Reservations Policy

• It was agreed to base assignments on a 2 year plan from the requester. No reservations policy was endorsed.

Static assignments for dial up

• The document strongly discourages the use of static IP assignments for dial up service. Strongly discourages means that if a strong technical reason is given and
  accepted, then assignments will be made for a vastly shortened time scale - 3 months was mentioned.

Assignment window anomaly

• The largest current assignment window for any local IR is /19 -1. This refers to the amount of address space that they can assign without referring first to the RIPE NCC. The proposal in ripe-104++ was to reduce this to /20. After some discussion and by way of compromise, it was agreed to make the new maximum /19 rather than /20. However, for every local IR with a /19 -1 assignment window, the current value of it's assignment window will be set to /20, with the understanding that it can be increased to a /19 based on the usual criteria (as specified in ripe-104++). It was agreed that this would come into effect immediately after the meeting.

Work remaining on ripe-104++

Sections 5,6,7 and 8 remain to be drafted. Section 5 will be drafted shortly after the RIPE meeting when the editorial committee meet and the draft will be circulated to the list shortly after the meeting.

10.4.5. Registry services and charges

10.4.5.1. RIPE NCC charging model

The contributors committee had agreed on a charging model for 1996. All documents relating to the Contributors Committee meetings and revenue and expenditure documents can be found in:

• ftp://ftp.ripe.net/ripe/new-registry/ncc-co/

10.4.5.2. Charging by local IRs

As reported under item 2.2 a draft outline had been prepared. The reviewed document will be circulated to the mailing list after the RIPE meeting, once it has been reviewed and edited. The main emphasis of the document is that it is acceptable practice for Local IRs to charge for their services. There will probably also be some wording included to the effect that any remaining Last Resort Registries should not charge for profit.

10.4.6. Tools

All Local IRs were encouraged to make any tools developed for local use available to the wider community if they thought that they could be useful to others. The RIPE NCC offered to "house" these tools and make their location visible.

10.4.7. Input from other Working Groups

10.4.7.1. DNS

Ripe-105 will be incorporated into ripe-104++.

10.4.7.2. Database

A proposal was made to the Database WG mailing list to incorporate the functionality of <auto-inaddr@ripe.net> into the general database update procedure. In future, it was pro-
posed that in-addr updates could be sent to <auto-dbm@ripe.net> with a special tag which could be something like "INADDRREQUEST".

10.4.8. AOB

10.4.8.1. Reverse delegation for partially assigned class B networks

There was a question about in-addr.arpa delegations for assigned portions of class B address space. It was suggested that either you could ask the Internic to delegate 128 zones to the Local IR or to channel this request through the RIPE NCC. It was suggested that it might be useful to include a reference to this in ripe-104++.

Action 23.7 on RIPE NCC
To include a paragraph in rpe-104++ on procedures for the reverse delegation of partially assigned class B networks.

10.4.8.2. Handing back of networks from block 192.0.0.0/8

In a mail of the PIER working group it was proposed that by 1997 users of non-aggregatable 192 address space should consider renumbering.

There was a question concerning where 192 address space should be returned to. It was suggested to return it to the RIPE NCC in all cases, and the RIPE NCC will handle it as appropriate. Any queries can be sent to the RIPE NCC <host-master@ripe.net>.

10.5. Database Working Group

Chair: Wilfried Woeber
Scribe: Kurt Kayser

10.5.1. Administrative stuff

Kurt Kayser, ECRC, volunteered to take notes.

The WG meeting was split into two sessions

• part 1 to deal with current topic, problems and ideas
• part 2 the more traditional stuff

The proposed WG-agenda was accepted.

10.5.2. Databases and registries

B. Manning's review of the 192.0.0.0/8 address range prompted a brief discussion of where the authoritative information should be maintained. The general feeling was that networks used in Europe should be documented in the RIPE-DB.

[A comment was received after the WG-meeting to ask the Internic (and other registries?) to expand the standard referral text ("The InterNIC Registration Services Host contains...") to include pointers to the RIPE-DB and maybe other registry sources.]

From the user's point of view it would be very convenient to send updates to a "local" database and have the software forward the message(s) to the appropriate database(s) according to the source: attribute.

Currently the RIPE-NCC holds copies of the following databases: RA, MCI, APNIC, CA*Net - but NOT the InterNIC.

While things are to improve with the introduction of the shadow-dbs, mirror copies are always sort of out-dated by definition. RIPE intends to have a 10min delay.

Other problems identified:

• uniqueness of names / keys across different databases
• lookup and processing of entries from more than one DB (e.g. evaluate AS-Macros from different DB...) -> minority problem for the time being.
• quality control on information,
  • like duplicate entries alert,
  • automatic handle assignment,
  • semantics for more than one person object for a given individual
  • Registry ID information is maintained manually, this might change by building links to objects in the public database.

10.5.3. User interface(s)

• access to the data in a more clever (selective) way by WAIS and/or WWW. A. Blasco Bonito and Paolo Bevilacqua have a test-version available for a WWW interface that
  supports logical AND and OR of keys.
• whois "help" gives on-line documentation hypertext version being considered
• An on-line survey form is available via the RIPE-NCC web pages, you are invited to use it to describe your wishes for access to data kept at the RIPE-NCC.
• RADB/Merit has a web interface for queries and updates, although this obviously works for auth: NONE or MAIL-FROM only
• proposal: put a pointer to whois "help" into ripe-104++

10.5.4. Authorization and Security

DFK reports that development work is on the action list (PGP facilities to be integrated) but there is still a severe lack of resources. Additional help is needed to make real progress, because design work is necessary first. The Key management would most probably be done according to the Merit approach. We might benefit from (Euro-)CERT activities?

In more general terms, if we want to see development progress faster than in the past, then we have to come up with clearly defined needs and a proposal for a development project with additional resources.

10.5.5. DB-SW report

David Kessens offered the traditional database software report. The slides can be obtained from:

• ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DB-REPORT.ps.gz

Another set of slides for the In-Addr-Check handling is available from

• ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DNS-INADDRCHECK.ps.gz

beta version V1.1 that allows (close to) real-time mirroring is available. At the time of writing these minutes (4-MAR-1996) the distribution is at:

• ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.1beta2.tar.gz

requests to run a mirror copy are to be sent to ripe-dbm@ripe.net

other changes include

• support for the BSD DB package
• a password controlled mechanism to overrule normal security mechanisms (e.g. for adding maintainers and the like)
• "network updates" are now fully supported by the RIPE-DB SW. Fully supported means: "If your address is in the RIPE-DB access list" However, this is a very powerful method and currently does not provide enough data for the logs to track down problems. For further study, before being made available to the community at large.
• less memory consumption

In conjunction with the mirror capability, the software has to keep track of individual object creations and updates. The mechanism that is currently used is not suitable for long-term consistency (because the sequentially increasing values are expected to suffer from wrap-around, eventually). Thus a stored: attribute was proposed and accepted.

stored: <NEW | UPD> <Date> <Time> <Serial>

Inclusion of the authorisation method used and the source of the update was then asked for. DFK is going to circulate a detailed proposal.

In general the NCC proposes to use a keyword based mechanism on the subject: line of DB update messages to request special processing. This should eventually obsolete the multiple e-mail addresses, like auto-assign@ripe.net, which are not widely known and their use is not always properly enforced.

10.5.6. Hierarchical authorization

Implementation of hierarchical authorization is initially planned for

• domain name space
• IP-Address-Ranges for registries
• origin AS for routes

Moving the description of the hierarchy and the transactions allowed at a particular level to a maintainer object was preferred over an alternate method of using a scope: attribute.

10.5.7. Handles, Object review

Eventually the assignment of NIC-Handles (more precisely: RIPE handles) is being implemented. David shall circulate a proposal about the logic and the semantics to the mailing list.

Reverse lookup (for person objects, at least) is being worked on.

The country: attribute is being redefined to allow multiple lines with multiple values, to better reflect the real scope of an entity (like address blocks from a regional registry, AS numbers, etc.)

The Role: or NOC: object needs more thought and detailed definition. There is still some uncertainty whether a fullblown new object (with a handle) is really needed, or whether the person object can be extended. Input was received from Michael H. Behringer that proposed a common format for describing contact information, coverage and emergency procedures. This object is to be re-visited on the mailing list and a decision about implementation is being sought on the list.

The proposal for an extension of the inet-rtr: object was briefly discussed. The original intent was to allow for a description of Mbone routers. However, extending the concept could be very useful for describing all sorts of peerings, like Mbone, IP-over-IP, IPnG, and the like. Due to the fact that there is already a couple of tools which read the peer: attributes, it might be wise to not change the peer: attribute as currently defined (but to eventually make it obsolete) and to invent a new attribute with the peering protocol ID as the first element, the address as the second element and then the specific information. To be discussed in more detail on the mailing list.

url: it was agreed to add a new (optional) attribute to all objects to allow for inclusion of URLs. The details to be worked out after some more tests. Format could either be plain HTML or general URI syntax.

10.5.8. Input from other WGs

Already covered (see inet-rtr: for Mbone)

10.5.9. AOB

None. Meeting closed.

List of new actions:

Action 23.8 on Daniel Karrenberg
To circulate a detailed proposal for the stored: attribute.

Action 23.9 on David Kessens
To circulate a detailed proposal for the automatic handle assignment.

Action 23.10 on Wilfried Woeber and Michael H. Behringer
To initiated discussion on the mailing list about the need and possible format for a role: or noc: object.

Action 23.11 on Wilfried Woeber
To initiate discussion on the mailing list about the extension of the inet-rtr: object.

10.6. IPv6 Working Group

Chair: Francis Dupont
Scribe: Bernard Tuy

10.6.1. Agenda (drafted during the meeting)

• Status of IPv6 standards
• Tools already available and implementation
• what about experiments running today ?
• who has (or plan to have) a testbed ?
• AOB

10.6.2. Status of IPv6 standards

10.6.2.1. RFC (PS)

• RFC 1883 IPv6 specifications
• RFC 1884 Addressing architecture
• RFC 1885 ICMPv6 specifications
• RFC 1886 DNS extensions for IPv6
• RFC 1887 IPv6 Address allocation
• RFC 1897 Test address allocation

About Security in IPv6 (and IPv4 as well) one can refer to :

• RFC 1825 Security architecture
• RFC 1826 Authentication header
• RFC 1827 Encapsulating security payload (ESP)
• RFC 1828 MD5 authentication
• RFC 1829 ESP DES-CBC transform
• RFC 1851 ESP triple DES transform
• RFC 1852 SHA authentication

10.6.2.2. Internet drafts (some of them...)

• transition mechanisms
  (draft-ietf-ngtrans-trans-mech-02.txt)
• neighbor discovery
  (draft-ietf-ipngwg-discovery-04.txt)
• dynamic host configuration
  (draft-ietf-dhc-dhcpv6-o3.txt)
• IPv6 Stateless Address Autoconfiguration
  (draft-ietf-addrconf-ipv6-auto-07.txt)
• IPv6 over Ethernet Networks
  (draft-ietf-ipngwg-ethernet-ntwrks-01.txt)
• IPv6 Packets over FDDI Networks
  (draft-ietf-ipngwg-fddi-ntwrks-01.txt)
• IPv6 over token ring
  (draft-ietf-ipng-token-ring-01.txt)
• IP Version 6 over PPP
  (draft-ietf-ipngwg-pppext-ipv6cp-00.txt)
• IPv6 Program Interfaces for BSD Systems
  (draft-ietf-ipngwg-bsd-api-03.txt)
  !attention! : a new API version is coming up.

About IPv6 and ATM relationship, one can refer to the following references:

• A Framework for IPv6 over ATM (neighbor discovery)
  (draft-schulter-ipv6atm-framework-00.txt)
• IPv6 and neighbour discovery over ATM
  (draft-ietf-ipatm-ipv6nd-00.txt)
• Support for Multicast over UNI 3.0/3.1 based ATM networks
  (MARS) (draft-ietf-ipatm-ipmc-10.txt)
• NBMA next hop resolution protocol (NHRP)
  (draft-ietf-rolc-nhrp-07.txt)
• (...)

For more information: http://playground.sun.com/pub/ipng/html/ipng-main.html

To participate in the current IETF discussions, subscribe to <ipng@sunroof.eng.sun.com>

10.6.3. Tools and implementations

10.6.3.1. Tools already available:

• tcpdump (decode IPv6 packets)
• snoop (same. for Solaris)
• BIND patches to support AAAA RR's

10.6.3.2. Implementations running:

For complete information refer to URL above.

10.6.3.2.1. for hosts with source code available:

• INRIA (F. Dupont) NetBSD + FreeBSD
  available from ftp.inria.fr/network/ipv6
• NRL (R. Atkinson) 4.4 BSD Lite + BSD OS
  available from ftp.ripe.net

10.6.3.2.2. for hosts with binary code:

• Solaris 2.5 version 3
• Digital / Unix version 3.2c
• many others are available yet but less information is known about their functionalities:
  • Hewlett Packard / UX (SICS, Sweden)
  • BULL (France)
  • FTP Software
  • (...)

10.6.3.2.3. for routers:

• Bay Networks
• Cisco Systems
• Penril
• Telebit (Denmark)
• (...)

10.6.4. Testbeds (running or planned):

• University of New Hampshire:
  interoperability experiments see Connectathon meeting (Feb. 5th to 9th)
• Grenoble and Rocquencourt (France)
  interoperability FreeBSD / NetBSD / Solaris implementation tests of INRIA source code tunneling over IPv4 WAN (Renater)
• University of Muenster (Germany)
  DFN and UNI-C tests with 3 Telebit routers
• MITRE (= US ISP)

10.6.5. AOB

10.6.5.1. Suggestions

2 suggestions came from the audience, to have

• the same Agenda at the Berlin RIPE meeting
• one hour tutorial on a major IPv6 protocol (ND, ...) and on transition mechanisms at the same meeting.

10.6.5.2. Status of the IPv6 working group

A consensus has been reached at this stage of knowledge of most of the attendees, to focus on what's going on about IPv6 standardization process and what is already running.

On a later step, we'll consider to move to a more technical group where experiences of participants can be shared.

10.7. Netnews Coordination BOF

Chair: Willi Huber
Scribe: Daniel Karrenberg

Willi called the meeting on the suggestion of Felix Kugler, the news administrator of SWITCH.

Willi gave a short presentation about the problem at hand. A full newsfeed at present uses 110kbit/s average bandwidth with peak days at 150kbit/s on average. Netnews is an overlay network much like MBONE. With such a sustained load it becomes very beneficial to prevent multiple simultaneous full feeds across many parts of the physical infrastructure. This is an inter-provider coordination problem. Today there does not seem to exist even a mailing list for European netnews administrators.

There was consensus that RIPE should coordinate this even though netnews is clearly an application and many news administrators do not usually attend RIPE meetings. There was also consensus to propose the establishment of a working group for the purpose. It was noted that working groups can easily be closed should there be no activity.

The following charter was agreed following a proposal by Willi:

• coordination of interprovider netnews flow in Europe
• coordination of intercontinental newsfeeds where necessary
• strive for efficient use of underlying infrastructure
• fair distribution of load
• as much redundancy as needed
• collect statistics
• proactive coordination ahead of topology changes
• NO work on netnews transmission technology
• NO treatment of legal issues and/or content

Pulak Rakshit reported that a similar effort has recently been successful in working around obvious problems in North American netnews distribution. A mailing list exists and is used for that purpose. George Wenzel coordinates this effort.

Several people noted that such an effort can only be successful if one or two people take the initiative to propose good topologies, modify them according to comments received and to keep track of developments.

Willi reported that Felix Kugler is prepared to chair a WG and to take the initiative in topology planning.

Creation of the working group was later approved in the plenary session. The mailing list is <netnews-wg@ripe.net>.

11. Next RIPE meetings

The scheduling of the next meetings was discussed and the following dates and locations were agreed:

• RIPE 24 - 22-24 April 1996 - Berlin, Germany
• RIPE 25 - September 1996 - Amsterdam, Netherlands
• RIPE 26 - January 1997 - Amsterdam, Netherlands

12. AOB

Geert Jan de Groot hinted on the availability of DHCP in the terminal room and the fact that nobody had used it.

13. Closing

Rob Blokzijl thanked the participants for attending and NIKHEF for providing the room facilities and lunches, and declared the meeting closed.