Chair: Rob Blokzijl
Scribe: Sylvana Wenderhold
1. Opening and Welcome
2. The Agenda
3. Minutes from RIPE 36
4. From the Chair
5. Report from the RIPE NCC
6. News from ICANN
- Louis Touton
7. IPv6 Address Allocation Policies
- Bob Hinden
8. ETSI and its Role in Developing Standards for the Internet
-Christopher Corbett
9. Reports from the Working Groups
10. Next RIPE Meetings
11. AOB
12. Close
1. Opening and Welcome
RIPE Chair Rob Blokzijl welcomed the participants to the RIPE 37 meeting.
2. The Agenda
The RIPE meeting participants approved the agenda.
3. Minutes from RIPE 36
The minutes were approved.
4. From the Chair
Rob thanked the sponsors of the social events:
- GTS (opening reception)
- Band-X (social gathering)
- AMS-IX (party).
He also gave a warm thank you to Patrick de Muynck (also on behalf of Lars Johann Liman) for all hard work he put into preparing the Multicast Tutorial. He thanked Cisco for providing the equipment.
5. Report from the RIPE NCC
Axel Pawlik, Managing Director, RIPE NCC introduced himself.
LIRs: There continues to be a rapid growth of LIRs. The number of LIRs in Africa is growing.
Address space usage: The number of request is still going up.
IPv6: The RIPE NCC continues to receive requests for IPv6. It is overall relatively quiet in the day-to-day business, but as seen in the working groups there is a lot of work to be done in setting the policies. The RIPE NCC closely co-operates with the other RIRs and the IETF on IPv6 issues.
Achievements: Unfortunately, the wait queue has not gone down. After RIPE 36 in Budapest the wait queue went done for a short time period. However, it has gone back up. Axel explained the emergency short-term measures that were used to combat the wait queue.
- RIPE NCC ex-hostmasters were recruited to bring the wait queue down.
- Overtime work was done by hostmasters. Unfortunately, staff can only work under those measures for a short period. To avoid burn out, the hostmasters are now back to their regular schedule.
- Another solution was to ask fellow RIRs to support us and send one or two hostmasters. APNIC sent us Son Thanh Tran and Anne Lord. The RIPE NCC also approached ARIN. They had to decline as they are dealing with a similar
situation.
As a long-term solution the RIPE NCC is hiring a sufficient number of hostmasters to deal with the peaks periods. In addition, the RIPE NCC is working on the development of tools to automate and streamline the process of registration services.
Special attention has been given to improving our documentation, making it easier for LIRs to fill in the required forms:
- An RIPE NCC Reference Guide booklet has been developed
- The FAQ page has been drastically improved
- There is a 'tips' page available to help LIRs with requests
- The number of LIR courses has been increased (41 courses for 2000).
A closer look is taken into dealing with the responsibilities of documenting past address usage. The May 17 Task Force suggests that part of this responsibility will be on the part of the LIRs. This way they can provide RIPE NCC with accurate information and as a result their request will be easier and quicker to process.
The May 17 Task Force had been formed in Budapest to find solutions for the wait queue problem. They will present their findings in Friday's Plenary. Axel informed the attendees that the results offered by the Task Force are
interesting and in some cases extreme. The RIPE NCC board supports measures to bring the wait queue down.
Axel expressed his contentment about the overwhelming interest in the Tools BoF meeting that was given earlier in the week.
RIPE Database: Top-level domain data has gone from the database. In Budapest 57 percent were domain-related objects. This has decreased to below 20 percent.
Data Protection: Non-PGP maintainers protect about half of the objects, whereas a tiny amount of data is protected by PGP. RIPE NCC has licenses and Axel urged the attendees to obtain a license.
Database re-implementation is practically done. The database is functional. The RIPE NCC is now looking for volunteers to test it. The information about the project can be found at:
- http://www.ripe.net/ripencc/pub-services/db/reimp
- mailing list [email protected]
- project development team [email protected]
Three million objects are left after the domains went out at the end of June. Queries have levelled off a bit. There are still approximately seven queries per second. Updates have gone up dramatically.
External Communications: As Axel had explained in Budapest, the main objective of the external communications is to increase awareness about RIPE and the RIPE NCC:
- RIPE NCC staff visited the ETSI offices
- RIPE NCC produced a joint press release with the GSM clarifying address space policies resolving any uncertainty regarding the availability of IP address space to support the infrastructure of GPRS roaming services.
- RIPE NCC visited some representatives of the french government, one of which is also a member of the Government Advisory Council (GAC) for ICANN. She
raised the concern that some countries are having difficulties getting addresses. As a result, the RIRs and Address Council will deliver a presentation at the next GAC meeting.
LIR courses: The number of classes will be increased to 41 per year. In the short term to deal with the increase in LIRs the number of participants will increase to 30 per course.
New projects:
Test Traffic Measurements (TTM): The analysis code has been improved. The RIPE NCC continues to produce new test boxes. There is a draft for the service contract. There are two issues:
- As the RIPE NCC is a non-profit organisation, there may be tax implications.
- Dealing with the issue of whether TTM users need to be members.
The schedule will, nevertheless remain unaltered and the new test boxes will go out in late September.
PAM2001: The RIPE NCC staff members have attended PAM2000 in New Zealand. This was the first workshop about Passive and Active Measurement. The next PAM
workshop will be held in Amsterdam. There is currently a call for papers. The deadline is mid-November. Please see: http://www.ripe.net/pam2001 if you are interested in participating.
Routing Information Service (RIS): There is a new collection point at the LINX. In addition, there is a new database machine. The software has been improved. A nice outcome of this project is that the data is used with the asused tool.
Plans for 2001:
- Move to a regular service
- Add more route collectors
- Produce daily reports
Routing Registry Consistency Check (RRC): This is a new service. Work has started in August. However, due to the lack of manpower it is not fully launched. The idea is to check the Routing Registry for inconsistencies and to
compare the Routing Registry data with the RIS data.
DASIST - Deployment Assistance and Support for Internet Security Technology is a mouthful and Axel will be glad to hear suggestions for a better name. The issue is that there are varying and new standards when new products are
developed and people don't know what to think of these products. The RIPE NCC wants to be a central point to provide assistance for LIRs. The long-term goal
is to offer service through:
- Training courses
- "how to", FAQ
- Evaluate products
- Produce tools
RIR Co-ordination: There is excellent day-to-day contact with the other RIRs.
The topics usually include policy co-ordination and IPv6. Together the RIRs evaluate interesting new requests, such as GPRS and IPv6.
ICANN/ASO:
- Attended ICANN meeting in Yokohama, Japan.
- ASO Address Council Selection (to take place at RIPE 38) in the LIR WG
- See http://www.aso.icann.org
- New ICANN Director (ASO) Dr. Sang Hyun Kyong (for APNIC region)
- New contract draft received from ICANN
- MoU Amendment - that aligns terms of office of AC members
- working on agreement between ICANN and the root server operators
RIPE NCC priorities:
- Ensure and further improve stable, reliable and high quality services
- Respond to members' needs and develop and propose services as needed
- Further increase RIPE NCC and RIPE awareness
RIPE NCC next steps:
- Further automate internal tools and processes
- Complete infrastructure overhaul
- Extend tools for members
- Update and improve external documentation
- Migrate to new DB software
- Introduce TTM as service
- Further formalise ICANN relations
Questions:
Rob: Tell us about your report on the input of the activity plan.
Axel: At the last RIPE meeting I had asked all working group chairs to provide input. This information has been included in the activity plan and is currently on the website. Please have a look and give me your comments.
Rob: The activity plan is a document that will be formally approved by the RIPE community at the Annual General Meeting on October 24, 2000. This meeting
is only open for members. In order to participate, you need to register before October 9, 2000. Among the items on the agenda are the approval of the activity plan, the budget and the election of another board member.
There were no more questions.
Report from Randy Bush:
Randy ran a security test during the RIPE meeting; the results were alarming, especially with wireless access. He urges all people to use Secure Shell (SSH), so that login names and passwords do not get exposed to the world.
6. News from ICANN
Louis Touton, Vice-President of ICANN, began his presentation by explaining the roles of ICANN. ICANN co-ordinates policies relating to the unique assignment of:
- Internet Domain Names
- Numerical IP Addresses
- Protocol Port and Parameter Numbers
And also
- Co-ordinates the DNS Root Server System
Louis explained the philosophy and goals of the Address Supporting Organisation (ASO).
- Address Council (three members from each RIR elected by community)
- Responsible for recommendations on global addressing policies
- Most issues handled in RIR open policy processes
- Keeps alert for situations where a segment of overall Internet community is not being heard
- Promotes global consistency where appropriate
Some of the issues that the ASO deals with are:
- Global vs. Local Addressing Policies
- Procedures to be followed in IANA Allocations to RIRs
- Net 24 Cable-System Assignment Procedures
- IPv6 Allocation Guidelines (IETF Papers) - also at RIPE 37
- Recommendations to ICANN on emerging RIRs
- Future IP address needs
Following an overview of ICANN/ASO Louis gave the microphone to Hans Petter Holen.
Hans Petter urged the RIPE community to give input as it is the community that the Address Council members represent. The current Address Council members
from the RIPE NCC region are Sabine Jaume, Wilfried Wöber and Hans Petter Holen. Hans Petter told the audience that the three Address Council members
need to know what policies are most important for them to focus on. What kinds of policies does the RIPE community want? He urged the audience to approach
them, or post issues to the LIR-WG list (to subscribe, send a mail to [email protected]).
Saubine Jaume took the microphone next. She provided an update from the Address Council.
Sabine described the policy development process and the operations of the Address Council.
Louis gave a review on the activities of IANA. These figures are also included in his presentation. He concluded by informing the audience of other ICANN activities:
- New TLDs
- At-Large Membership
- Root server system enhancements
- Operational Transition (root maintenance, Blackhole, InterNIC, .arpa)
- Transition extended for up to one year
There were no questions.
7. IPv6 Address Allocation Policies - Bob Hinden
Bob introduced himself as the co-chair of the IPng working group at the IEPG and is employed at Nokia.
The enormous success of the Internet has created a lot of problems.
The problem is that the allocation of IPv4 address is controlled. Customers cannot always be provided with the number of addresses they ask for. This is the main thing IPv6 focuses on.
NAT has extended the life of IPv4. Yet there are still problems:
- Breaks IP end-to-end problem
- Especially Security
- Inhibits the creation of new applications
- Barrier to mobile IP communications
- Mobile phones without phone numbers?
Main features of IPv6:
- Larger 128-bit Hierarchical Addresses
- Supports much larger Internet (it is four times bigger than IPv4)
- Allows Embedded IEEE 802 MAC Address for Auto-Configuration
- Plug and Play-Auto Configuration
- Other
- Enables end-to-end security (IPSEC) via Global Addresses
- Efficient general header compression
- Incremental Deployment
IPv6 Addressing:
- It is likely that the address space will never be used up
- Currently only 15% is initially assigned, 85% is reserved for future growth (this is especially useful for new technology that may be invented)
There are different IPv6 Address Types:
- Unicast (one-to-one)
- Global
- Link-Local
- Site-Local (for local communications)
- Compatible (IPv4, NSAP)
- Multicast (one to many)
- Anycast (one of a set, but to the nearest)
Routing is essentially the same as IPv6:
- Uses same "longest-prefix match" routing as IPv4 CIDR
- Straightforward changes to existing IPv4 routing protocols to handle bigger addresses
News and status:
- Many companies are now using and supporting IPv6 (e.g. BSD, Linux, Solaris 8, and Microsoft and others).
- Cisco has announced fall 2000 IOS release with IPv6.
- Also, the Third Generation Mobile Protocols (3GPP) requires that now all mobile devices that meet the standard now use IPv6.
- Finally, three ISPs have announced commercial IPv6 service trials (NTT, IIJ
and SURFnet)
- IPv6 included in IPSO (Nokia) 3.3 release
Bob showed a list of current IPv6 implementation and IPng standards status. Bob reiterated that there is still a lot of work to be done on IPv6.
Approximately six months ago, the RIRs asked the IETF for advice on IPv6 prefix assignment. The IPng working group has discussed this issue in July. The IPv6 directorate has developed a recommendation. This recommendation was
approved by the IAB and the IESG and sent to the registries as official comments.
The IPng working group in the addressing specification (RFC2374 and RSF 2450) specified that sites that have subnetting should be allocated a /48 prefix:
- allows 2(16) subnets
- most sites, subscribers this should be enough for all time
Issue is size of prefix for smaller sites:
- /64 for single subnet sites?
- Single host? Mobile phones?
- Temporary vs. permanent usage?
- How to judge usage?
IAB - IESG recommendation:
- Recommend /48 fixed boundary for all subscribers
- Except:
- Very large subscribers (receive multiple /48 allocations)
- Transient nodes (receive /64)
- No interest in subnetting (receive /64)
- Consistent with responsible stewardship of the IPv6 address space
The main question: is giving a /48 prefix to every subscriber good utilisation of the IPv6 address space? Is this wasteful?
No, because IPv6 has a very large address space:
- Aggregatable Unicast Address format supports 45 variable bits
- Assuming one /48 prefix per person (utilisation is 0.03%)
Please see the presentation for the analysis.
We are using only one format prefix of IPv6. The other 84% of the address space in unassigned. If in the future the analysis proves to be wrong, there is the option of imposing more restrictive allocation policies.
Transient usage (when you are not connected all the time)
- Single dialup nodes that prefer transient addresses
- /64 prefix is okay
- Subscriber who wants static assignment or plans multiple subnet
- /48 even if dialup
This has also been discussed in the joint session of the
IPv6/LIR. The WG agreed with Bob's analysis and the suggestion to assign a /48 to end sites except in the cases listed above.
For more information:
http://playground.sun.com/ipng
http://www.IPv6forum.com
http://IPv6.org
There were no questions.
8. ETSI and its role in developing standards for the Internet - Christopher Corbett
9. Reports from the Working Groups
Anti-Spam Working Group:
60 participants
Scribe: Marcel Duran
Chair: Rodney Tillotson
Update on spam
- more collateral spam
- more hiding of websites
Update on anti-spam
- ORBS disrupted
Opt-In Lists
- EU endorses Opt-In
- Document for marketers
Reporting spam
- SpamCop not focused enough
- Directions to end users
Reading mail headers
- existing documents gathered
Future (& next agenda)
- SMS, WAP, cell broadcast, real-time spam
Question from the audience: How many ISPs want to do something about spam?
Rodney: I have not done research on this, but it is my impression that many
ISPs want to do the right thing and battle spam.
Question from Wilfried Wöber: Are you aware of any activities to make mail
headers more creditable, like signing them?
Rodney: I am not aware of people signing them.
Routing Working Group / Multicast Application Workshop
Joachim began with a short report of the Multicast Workshop.
He gave a special thank you to Patrick de Muynck. Patrick took the microphone
and said that he enjoyed working on this tutorial. He felt full satisfaction
because of the participants' enthusiastic reactions. He enjoyed building more
multicast awareness. He thanked RIPE in return, as he had been looking for a
platform to promote multicast for a while. He enjoyed working at the offices
of the RIPE NCC and its staff; in particular Monica Cortes Sack who had really
did a great job.
Joachim also thanked Cisco for the equipment they had provided. There were 70
participant and it was very much appreciated.
Routing WG:
97 participants
Scribe: Marek Bukowy
Chair: Joachim Schmitz
Slot 1
A. Preliminaries
C. RADB Update (G.Winters)
E. RIS, Status and Plans (A.Antony, H.Uijterwaal)
F. Routing Registry Consistency Project (S.Kerr)
G. Study of BGP Convergence (A.Ahuja)
H. Internet Routing Table Analysis Update (P.Smith)
I. RIPE-210 - Updates with contributions from the audience (C.Panigl,
P.Smith)
J. Promoting European IP Multicast deployment - Introducing the European IP
Multicast Initiative (EuMI) (T.Ballardie)
RIPE 37: Routing Working Group
Slot 2
Notice: joint session with Database WG!
B. RIPE Database Software Re-Implementation and Transition to RPSL
(A.Robachevski, J.L.S.Damas)
Y. Transition Taskforce: RIPE-181 to new RPSL database
- what does it mean
- intentions
- progress
A. Preliminaries
- introduction
- participants' list
- volunteering of scribe
- RIPE 36 minutes
- agenda bashing
- actions from earlier meetings
Current Actions
31.R1 on RIPE NCC, D.Kessens, J.Schmitz
Basic design for an IPv6 IRR project in RIPE NCC activity plan
- done -
32.R1 on RIPE NCC, JLS.Damas
Prepare draft document on issues of RIPE-181 to RPSL transition
http://www.ripe.net/ripencc/pub-services/db/reimp/new-transition-v3.ps
- done -
34.R1 on C.Panigl
Provide updates to RIPE-178
RIPE-210
- done -
but triggered additional discussion
36.R1 on RIPE NCC
During the transition phase to the RPSL software
- verify with RADB on their test suites for RPSL implementations
- co-ordinate with RADB on consistent mirroring of databases (NRTM)
- co-ordinate with RADB on consistent whois interface of databases including
irrd
- ongoing -
There were no questions.
Netnews Working Group:
18 participants
Scribe: Fotis Georgatos
Chair: Dave Wilson
1. Admin
- Agenda agreed without changes
2. Review of minutes last meeting
- Accepted without changes
3. Flowmaps
Presentation by Kai Siering of Mediaways
- Geographical maps (2D and 3D) are not helpful
- Considered other 2D mappings
- newsdist, makefeedmap
- Now using Cichlid 3D client-server visualisation package
- Data is from Innstats based on article count rather than volume
- Appearance depends on thresholds below which feeds are ignored
http://newsbone.uu.org/RIPE-37/
4. NHNS
Presentation by Daniel Diaz of Satec
http://nh.nhns.net/
- Reflecting Usenet hierarchy in DNS
- Now in production under usenet.nhns.net
- 472 TLHs included
To do:
- mechanism to check freshness
- port sync to Diablo
- delegate!
- Promote now, report at RIPE 38 with a view to moving toward standardisation
Details:
http://www.ripe.net/ripe/wg/netnews/
Mailing list: [email protected]
Chair: [email protected]
There were no questions.
LIR Working Group:
Approximately 100 participants
Scribe: Roger Arcilla
Chair: Hans Petter Holen
Hans Petter Holen gave Stephen Burley the opportunity to report the findings
of the May 17 Task Force, because these findings are the most important issues
the LIR working group is currently dealing with.
The findings and recommendations can be found in the May 17 Task Force Report:
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/
Stephen stated that the proposed goal of the task force was to propose changes
to the policies and procedures for address assignments to ultimately be
submitted to LIR working group, with the clarification of best practices and
tangible steps to achieving those goals.
Stephen gave a detailed explanation of the proposed changes and he requested
the consensus of the audience. This resulted in a lively discussion.
Stephen asked the attendees for their opinion about creating assignment window
and no assignment window differentiation.
Comment from the audience: Are you proposing to improve service for the big
boys on the back of the new LIRs?
Stephen: No, that is not the intention at all. As soon as you get any
assignment windows you go to the other queue.
Hans Petter: It opens up the possibility of specialisation.
Axel: I personally endorse the general outlook. I am prepared to find ways of
implement the recommendations. If the audience gives its consensus, I am
prepared to take more extreme measure to bring down the wait queue. However,
some ideas concern policy changes, which I am uncomfortable to change on my
own. So we need consensus. I would like to thank the Task Force for their
efforts and for the proposed recommendations.
Rob: It looks like these are fire-fighting measures. I hope people are working
on a more structural solution.
Axel: Once the wait queue is down, I think we have measures to keep it down.
Wilfried Wöber (Task Force member): There have been lively discussions within
the Task Force about before mentioned objections. I like the idea of
hostmaster specialisation. It will improve the efficiency of the whole process.
Daniel Karrenberg: Have you considered that these recommendations could
endanger the industry's self-regulation? If you propose to change a process
that has been established for a purpose in the first place. These measures
should indeed be only implemented in extreme situation, or else it will affect
the industry's self-regulation.
Hans Petter: Let's look at this in a historical perspective. I have the
feeling that in the past the assignment window was raised a lot quicker. We
have consciously lowered the assignment window over the years, but we have not
seen the additional resources that are needed.
Daniel: I was making the argument from the appearance. We do not want to give
people outside the community the impression that we are very light-hearted
about this.
Stephen: Our proposed measures are a test. If they don't work we will look at
other options.
Rob: I suggest that the NCC management take this input into consideration. The
final decision is the RIPE NCC's, not of this community. I am looking froward
to Axel's report in January.
Daniele Bovio (Task Force member): I don't think the NCC can start applying
these measures without the backing of this community, because it may create
problems with the LIRs that are not as involved.
Rob: We need more permanent solutions. We will discuss this further at RIPE 38.
Joao Silva Damas suggests as an additional measure to delegate more
responsibility to the LIRs, for instance for their records in the RIPE DB.
Rob: The message is clear. The Task Force has produced a tool kit and it is up
to the RIPE NCC to make sensible use of it.
Stephen: The Task Force will meet again before the next RIPE meeting with the
NCC to see if these measurements are effective. The Task Force is open to any
suggestions from the community.
Nurani Nimpuno: A lot of the measures have been taken already. You will not
yet see the effect, because they are long-term measures. The task Force was
set up to come up with solutions for a radical situation.
Hans Petter further discussed the ASO nominations. Voting will take place at
the next meeting.
Due to time constraints, Hans Petter did not get the opportunity to give a
report of the other issues the LIR working group is concerned with. However, a
detailed presentation is available:
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/
There were no further questions.
EIX Working Group:
90 participants
Scribe: David Knight
Chair: Fearghas McKay
1: IX Reports
INEX - Irish Neutral IX
INXS - Munich IX
CIXP - Geneva IX
AMSIX - Amsterdam IX
LINX - London INX
SFINX - French IX
VIX - Vienna IX
For the next meeting we hope to have Athens & DecIX presenting as well. More
IXs are always welcome.
2: IXP switching wish list - Mike Hughes
3: IX Best Current Practices - Nic Lewis
4: Change in WG Charter
"To provide a means for the RIPE ISP community to find out about the status
and activities of Internet Exchange Points within the RIPE geographical area"
This was changed to:
"To provide a means for the RIPE ISP community to:
- find out about the status and activities of Internet Exchange
Points within the RIPE geographical area
- develop Best Current Practice documents
- provide operational feedback and guidance to vendors of IX related products
and services"
5: I-Point Europe - presentation by Annette Nabavi, CEO.
This was followed by a lively and wide-ranging community discussion on their
plans for a Europe wide network of IXs.
The discussion can be continued on the WG mailing list:
Question from the audience: there was a comment of developing an exchange
object in the database.
Fearghas: We are looking at developing this and working on it. We are building
a list of the IXs, as to compare what they do.
Test traffic Working Group:
40 participants
Scribe: Mark Santcroos
Chair: Matthew Robinson
Agenda
A. Administrative stuff
B. Presentation by Henk Uijterwaal on current project and future plans.
C. Entries for the competition
D. AOB
C. Entries for the competition
- a staggering number of entries
- two entries (from the same person)
Entry one:
TEMPI - Timing and Exact
Measurements of the Performance of the Internet
Entry two:
TRIPS - Time-Related Internet Performance Service
Mottos:
1. "The fundamental things apply / As time goes by" (H. Hupfeld from the movie
'Casablanca')
2. "Sum loquimur, fugit invida Aetas" ("While we speak, envious time flies")
(Horace)
3. "O temps! Suspend ton vol." ("Oh time! Halt your flight.") ( A. de
Lamartine)
Options
1. If we like either of the options we can adopt it.
2. Leave the competition open longer.
3. Change nothing
AOB
- I would like to stand down as chair
- One of my colleagues has agreed to take over
- Any offers from the working group?
There were no questions.
IPv6 Working Group:
106 participants
Scribe: Vesna Manojlovic
Chair: David Kessens
Report of the Joint Session
Agenda
1 Statement of current policy draft
2. IAB/IESG recommendations
3. Panel discussion
4. AOB
Presentation João
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/
Presentation Bob Hinden
IAB/IESG Recommendations on IPv6 Address Allocation - Bob Hinden
http://www/ripe/meetings/archive/ripe-37/presentations/ripe-ipv6-hinden/
We do not have real issue on service provider allocation size.
Our recommendation is: /48 fixed boundary for all subscribers.
This is consistent with responsible stewardship of the IPv6 Address space.
Reasoning:
- allocation policies influence the deployment; policies should make
deployment easy, not slow
- renumbering is (still) not painless or automatic
Exceptions:
- very large subscribers should get multiple /48:s, or /47
- transient nodes (roaming, dial-up) (/64)
- explicitly no interest in subnetting
Justifications for fixed boundary:
- easy to change ISP:s (does not require restructuring of subnets)
- straightforward renumbering
- compatible with current multihoming proposals
- allows easy growth of subscribers
- reduces burden of ISP:s and RIR:s to judge customers' needs
- no need for details of customers' networks
- no need to judge rates of consumption
- no scarcity of subscriber's space: no need for NAT
- allows single reverse DNS zone (for all prefixes)
Conservation:
- does this waste IPv6 address space? No.
- this distribution had better H ratio (RFC1715) then many others today
- still, only one of the Format Prefixes (001) is going to be used; it leaves
85% of total IPv6 space for future usage and possible stricter policy
IPv6 Report
Agenda:
A - Administrative stuff
- - appointment of scribe
- - list of attendees
- - agenda bashing
Chair: David Kessens
B - Status of 6bone
(David Kessens)
C - RPSL & IPv6
D - Transition mechanisms
E - News from IPv6 Forum
(Juergen Rauschenbach)
F - Addressing plan of the real world
(Juergen Rauschenbach)
G - IPv6 connectivity in the terminal room
(Monica Cortes)
H - IPv6 native exchange points
- - INXS (Munich)
I - European developments
(input from the audience)
J - Future plans for the working group
(input from the audience)
Z - AOB
============
B - Status of 6bone
More than 600 sites connected on the 6Bone with 48 countries
(David Kessens)
C - RPSL & IPv6
(Joachim Schmitz, routing-wg chair)
Joachim announced that project proposal has been submitted for the RIPE
activity plan for RPSL extensions with multicast and also IPv6.
D - IP Transition Strategies
Presented by: Alain Durand
Co-chair of the IETF NGtrans WG
URL:
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37/
E - News from IPv6 Forum
(Juergen Rauschenbach)
[presentation]
F - Addressing plan of the real world
By Bernard Tuy and Juergen Rauschenbach
G - IPv6 connectivity in the terminal room
(Monica Cortes, RIPE NCC)
If you have IPv6 configured on your laptop, and are connected to LAN here, you
can use IPv6.
H - v6 native exchange points
The list is getting longer
There were no questions.
DNS Working Group
There was report from the DNS working group.
Database Working Group:
Approximately 50 participants
Scribe: Nigel Titley
Chair: Wilfried Wöber
Logistics:
- scheduling problems => joint session with routing
- agenda
- thanks you to Nigel for scribing
Results:
Gerald Winters on IRRD/RPS-Dist
=>RFC could benefit from revision
Randy Bush on globally unique handles
=>action on three RIRs to come up with a proposal
RIPE does support this activity
=>have to work with ARIN, APNIC
on CERT/IRT pointer proposal
=>propose object to list and deployment scenarios
RIPE NCC on RIP
=>status and changes
=>Task Force proposed and agreed
RIP/Migration TF
- co-ordinator: Ulf Kieber
- find name, a home, members
- define mandate
- work with the NCC
Input from other working groups:
CENTR Tech:
Review situation with regard to domain 'exodus' and referral
=>maintenance of objects is owners' responsibility (confirmed)
=>you have to deal with clean-up anyway
There were no questions.
CENTR/DNR Working Group
There was no report from the CENTR/DNR working group.
Tools BoF:
106 participants
Scribe: Guy Vegoda
Chair: Maldwyn Morris
Summary:
Scope: Tools for Members' use specifically related to RIPE Local IR activities
1. Existing Tools
- Asused* - allocation and assignment usage and consistency
- Web141/ip-req-robot* - IP Address request check
- ASinuse - AS number lookup
- Web147 - AS Number request check
- Stt* - mail reply template tool
* Sources linked from:
http://www.ripe.net/ripencc/mem-services/tools/tools.html
2. Future Tools
- Secure Web Page: Reg info edit, 141/147 submit, gandalf
- PGP for mails to & from [email protected]
- as-req-robot
- public version of RIPE NCC ticketing system
Proposed:
- Allocation & Assignment Management Tool?
- Easier Member access to RIPE Databases?
- Scripts to work with proprietary Address Management Systems?
3. Member Tools
- Holger Münzof of UUNET gave a talk on RICE, their ASNumber/ASMacro Management
Tool
4. Whither the BOF?
- Discuss requirements on mailing list: [email protected]
Tools BOFs if a lot to discuss, otherwise RIPE NCC to report in LIR working
group.
10. - Next RIPE meetings:
RIPE 38 Amsterdam 23-26 January, 2001
RIPE 39 Bologna 30 April - 4 May, 2001
11. - AOB
There was no other business to discuss.
12. - Close
Rob thanked everyone for attending and hopes to meet all the participants
again at the next RIPE meeting in Amsterdam on 23-26 January, 2001.