Rob Blokzijl welcomed the participants to the 23rd RIPE meeting hosted by NIKHEF in Amsterdam, The Netherlands.
The agenda was approved. Note: some of the agenda items were rescheduled during the meeting but they are minuted as originally scheduled.
The minutes of the 22nd RIPE meeting were approved with no changes.
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.
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:
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.
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 '[email protected]' would soon be announced at the 'ripe-list' mailinglist.
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:
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.
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.
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:
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.
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.
Chair: Peter Lothberg
Scribe: Havard Eidnes
Peter Lothberg (PL) welcomed everyone to the meeting.
No additions to the agenda were proposed.
HE volunteered.
None received.
No comments were presented. The previous minutes were approved.
PL invited updates on
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:
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.
PL would attend NANOG in San Diego 15-16 February, and solicited input. No input appeared.
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]
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.]
This was merely briefly mentioned as a possibility, and that it "may be possible". [This remains to be seen, though.]
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/
None.
In conjunction with the next RIPE meeting, i.e. 22 April in Berlin.
Meeting adjourned.
Chair: Antonio-Blasco Bonito
Scribe: Carol Orange
Carol Orange took notes.
The agenda was agreed to without changes.
Rob Blokzijl:
Hopefully a new chair will be appointed during the next RIPE meeting.
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:
The tool will:
The tool will *not*:
The latest version has several software improvements including:
Currently under development:
Plans to integrate the tool in RIPE database will mean:
The tool is available in:
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.
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.
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.
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
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.
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.
Chair: Magnus Danielson (KTH/IT)
Scribe: Kurt Kayser (ECRC)
Magnus Danielson, Chair of the MBone WG welcomed everybody.
No apologies were received
Kurt Kayser volunteered for the scribe of the meeting minutes
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?)
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.
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.
+----------+-------+---------+
| Version | hosts | percent |
+----------+-------+---------+
| 3.8PGM | 160 | 38.5% |
+----------+-------+---------+
| 11.0PM | 38 | 9.1% |
+----------+-------+---------+
| 3.8PGMS | 14 | 3.4% |
+----------+-------+---------+
| 11.0PMS | 11 | 2.6% |
+----------+-------+---------+
| 11.1PMS | 4 | 1.0% |
+----------+-------+---------+
| 3.6PGM | 42 | 10.1% |
+----------+-------+---------+
| 11.0Mpim | 13 | 3.1% | <- 54.6% so far
+----------+-------+---------+
| 10.3pim | 12 | 2.9% |
+----------+-------+---------+
| 10.2pim | 6 | 1.4% | <- 72.1% so far
+----------+-------+---------+
| 3.3 | 27 | 6.5% |
+----------+-------+---------+
| 3.4 | 21 | 5.0% |
+----------+-------+---------+
| 2.2 | 20 | 4.8% |
+----------+-------+---------+
| 3.2 | 15 | 3.6% |
+----------+-------+---------+
| 10.3 | 8 | 1.9% |
+----------+-------+---------+
| 10.2 | 8 | 1.9% |
+----------+-------+---------+
| 3.1 | 7 | 1.7% |
+----------+-------+---------+
| 3.5PGM | 6 | 1.4% |
+----------+-------+---------+
| 3.7PGM | 2 | 0.5% |
+----------+-------+---------+
| 2.0 | 2 | 0.5% |
+----------+-------+---------+
| Total | 416 | |
+----------+-------+---------+
League Table for Europe
+--------+-------+-------+--------+--------+--------+
| Domain | Hosts | Score | New | OK | Old |
+--------+-------+-------+--------+--------+--------+
| ru | 3 | 100.0 | 100.0% | 0.0% | 0.0% |
+--------+-------+-------+--------+--------+--------+
| pl | 5 | 80.0 | 60.0% | 40.0% | 0.0% |
+--------+-------+-------+--------+--------+--------+
| no | 28 | 76.8 | 67.9% | 17.9% | 14.3% |
+--------+-------+-------+--------+--------+--------+
| de | 104 | 73.6 | 64.4% | 18.3% | 17.3% |
+--------+-------+-------+--------+--------+--------+
| fi | 45 | 72.2 | 64.4% | 15.6% | 20.0% |
+--------+-------+-------+--------+--------+--------+
| se | 46 | 69.6 | 56.5% | 26.1% | 17.4% |
+--------+-------+-------+--------+--------+--------+
| uk | 85 | 63.5 | 58.8% | 9.4% | 31.8% |
+--------+-------+-------+--------+--------+--------+
| EU | 416 | 63.3 | 54.6% | 17.5% | 27.9% |
+--------+-------+-------+--------+--------+--------+
| be | 4 | 62.5 | 50.0% | 25.0% | 25.0% |
+--------+-------+-------+--------+--------+--------+
| it | 18 | 58.3 | 50.0% | 16.7% | 33.3% |
+--------+-------+-------+--------+--------+--------+
| si | 2 | 50.0 | 0.0% | 100.0% | 0.0% |
+--------+-------+-------+--------+--------+--------+
| pt | 2 | 50.0 | 50.0% | 0.0% | 50.0% |
+--------+-------+-------+--------+--------+--------+
| cz | 10 | 45.0 | 10.0% | 70.0% | 20.0% |
+--------+-------+-------+--------+--------+--------+
| es | 6 | 41.7 | 16.7% | 50.0% | 33.3% |
+--------+-------+-------+--------+--------+--------+
| nl | 14 | 35.7 | 35.7% | 0.0% | 64.3% |
+--------+-------+-------+--------+--------+--------+
| fr | 35 | 34.3 | 28.6% | 11.4% | 60.0% |
+--------+-------+-------+--------+--------+--------+
| at | 5 | 20.0 | 20.0% | 0.0% | 80.0% |
+--------+-------+-------+--------+--------+--------+
| su | 3 | 0.0 | 0.0% | 0.0% | 100.0% |
+--------+-------+-------+--------+--------+--------+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
+----------+-------+---------+
| Version | hosts | percent |
+----------+-------+---------+
| 3.8PGM | 479 | 28.3% |
+----------+-------+---------+
| 11.0PM | 120 | 7.1% |
+----------+-------+---------+
| 11.0PMS | 31 | 1.8% |
+----------+-------+---------+
| 3.8PGMS | 25 | 1.5% |
+----------+-------+---------+
| 11.1PMS | 16 | 0.9% |
+----------+-------+---------+
| 11.1PM | 9 | 0.5% | <- 40.2% so far
+----------+-------+---------+
| 10.3pim | 171 | 10.1% |
+----------+-------+---------+
| 3.6PGM | 161 | 9.5% |
+----------+-------+---------+
| 10.2pim | 46 | 2.7% |
+----------+-------+---------+
| 11.0Mpim | 45 | 2.7% | <- 65.2% so far
+----------+-------+---------+
| 2.2 | 148 | 8.7% |
+----------+-------+---------+
| 3.3 | 83 | 4.9% |
+----------+-------+---------+
| 3.4 | 83 | 4.9% |
+----------+-------+---------+
| 10.3 | 78 | 4.6% |
+----------+-------+---------+
| 2.0 | 54 | 3.2% |
+----------+-------+---------+
| 10.2 | 49 | 2.9% |
+----------+-------+---------+
| 3.5PGM | 21 | 1.2% |
+----------+-------+---------+
| 1.0 | 20 | 1.2% |
+----------+-------+---------+
| 3.2 | 18 | 1.1% |
+----------+-------+---------+
| 3.7PGM | 18 | 1.1% |
+----------+-------+---------+
| 3.1 | 9 | 0.5% |
+----------+-------+---------+
| OLD | 5 | 0.3% |
+----------+-------+---------+
| 11.0M | 4 | 0.2% |
+----------+-------+---------+
| Total | 1693 | |
+----------+-------+---------+
League Table for Europe
+----------+-------+-------+-------+-------+-------+
| Domain | Hosts | Score | New | OK | Old |
+----------+-------+-------+-------+-------+-------+
| EU | 416 | 63.3 | 54.6% | 17.5% | 27.9% |
+----------+-------+-------+-------+-------+-------+
| World | 1693 | 52.7 | 40.2% | 25.0% | 34.8% |
+----------+-------+-------+-------+-------+-------+
| World-EU | 1277 | 49.2 | 35.5% | 27.4% | 37.1% |
+----------+-------+-------+-------+-------+-------+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.
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.
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:
The EU-Mbone-FAQ was moved to:
Action 23.5 on RIPE NCC
To include a pointer to the EU-Mbone-FAQ in the RIPE WWW-server.
Thanks to Victor Reijs for his presentation and Kurt Kayser for scribe.
Chair: Mike Norris
Scribe: Anne Lord
At the working group meeting there were 111 attenders.
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.
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.
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:
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 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.
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
PI/PA address space issues
Renumbering
Reservations Policy
Static assignments for dial up
Assignment window anomaly
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.
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:
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.
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.
Ripe-105 will be incorporated into ripe-104++.
A proposal was made to the Database WG mailing list to incorporate the functionality of <[email protected]> into the general database update procedure. In future, it was pro-
posed that in-addr updates could be sent to <[email protected]> with a special tag which could be something like "INADDRREQUEST".
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.
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 <[email protected]>.
Chair: Wilfried Woeber
Scribe: Kurt Kayser
Kurt Kayser, ECRC, volunteered to take notes.
The WG meeting was split into two sessions
The proposed WG-agenda was accepted.
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:
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.
David Kessens offered the traditional database software report. The slides can be obtained from:
Another set of slides for the In-Addr-Check handling is available from
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:
requests to run a mirror copy are to be sent to [email protected]
other changes include
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 [email protected], which are not widely known and their use is not always properly enforced.
Implementation of hierarchical authorization is initially planned for
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.
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.
Already covered (see inet-rtr: for Mbone)
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.
Chair: Francis Dupont
Scribe: Bernard Tuy
About Security in IPv6 (and IPv4 as well) one can refer to :
About IPv6 and ATM relationship, one can refer to the following references:
For more information: http://playground.sun.com/pub/ipng/html/ipng-main.html
To participate in the current IETF discussions, subscribe to <[email protected]>
For complete information refer to URL above.
2 suggestions came from the audience, to have
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.
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:
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 <[email protected]>.
The scheduling of the next meetings was discussed and the following dates and locations were agreed:
Geert Jan de Groot hinted on the availability of DHCP in the terminal room and the fact that nobody had used it.
Rob Blokzijl thanked the participants for attending and NIKHEF for providing the room facilities and lunches, and declared the meeting closed.