September 1993 - ripe-list - mailman.ripe.net

RIPE DNS Hostcount September 1993
by Marten Terpstra 28 Sep '93

28 Sep '93

Dear all, Please find below another RIPE DNS Hostcount. - some countries went down a little, I did not retry any of them, sorry. - Germany makes another big step with over 4,000 extra hosts - Poland steams up with more than double their previous figure ... - Just as a reminder, a short explanation of what is displayed: CY = country SOA = number of different SOAs found in the Top level domain COUNTED = number of hosts found DUPL = number of hosts found more than once (multiple A records with the same address) REAL = COUNTED - DUPL, the real number of machines found CHANGE = change since last time. - All output again available from ftp.ripe.net:ripe/hostcount - A rather detailes history appended again below. Enjoy, -Marten RIPE DNS Hostcount Previous Count : Tue Aug 31 This Count : Sat Sep 25 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 1 0 0 0 0 at 247 12324 80 12244 - 648 be 63 5528 89 5439 + 397 bg 1 0 0 0 - 16 by 0 0 0 0 0 ch 176 33334 707 32627 + 863 cs 95 2722 49 2673 - 80 cy 5 32 2 30 0 cz 93 3480 79 3401 + 47 de 1478 99569 3291 96278 + 4258 dk 118 7158 97 7061 + 331 dz 0 0 0 0 0 ee 18 271 0 271 + 63 eg 1 0 0 0 0 es 272 11175 83 11092 + 734 fi 278 28924 695 28229 + 733 fo 1 0 0 0 0 fr 590 47261 633 46628 + 2990 gb 1 16 0 16 + 1 ge 1 0 0 0 0 gr 88 1329 237 1092 - 20 hr 12 193 0 193 - 225 hu 34 1836 11 1825 + 153 ie 45 2015 48 1967 + 78 is 38 1427 13 1414 + 122 it 366 14787 305 14482 + 639 il 88 5796 68 5728 + 121 li 2 17 0 17 0 lt 1 0 0 0 0 lu 12 252 1 251 + 22 lv 1 38 0 38 + 23 mt 1 0 0 0 0 nl 394 38042 386 37656 + 1422 no 420 26508 241 26267 + 622 pl 190 3947 57 3890 + 2683 pt 97 3082 64 3018 + 371 ro 2 17 0 17 + 3 se 460 36015 319 35696 + 474 si 11 484 3 481 + 16 sk 28 475 11 464 + 3 su 146 1009 61 948 + 235 tn 0 0 0 0 0 tr 19 478 2 476 + 29 ua 34 155 10 145 + 16 uk 659 96558 9257 87301 + 1781 va 0 0 0 0 0 yu 1 1 0 1 - 1 ============================================================ 6588 486255 16899 469356 +18240 This is an overview of the History of the RIPE hostcounts. It only contains the totals. The totals for 1990-1991 should be considered rather unstable and unreliable because the program used then was not really tuned, plus the count was not done as regular as it is now. Count : total hostcount for all European top level domains Delta : delta since previous count Delta % : delta as percentage of previous count Q Delta : delta over the past quarter Q Delta%: delta over last quarter as percentage of end of last quarter count For the Q Deltas I have not calculated those back before 1992, because the figures for 1990-1991 are not too reliable. *) Dec 1991 hostcount estimated at 135,000. Count Delta Delta % Q Delta Q Delta % ------------------------------------------------------------------- Oct 1990 31724 Nov 1990 33665 + 1941 + 6.1% Dec 1990 29230 - 4435 - 13.2% Jan 1991 43832 + 14602 + 50.0% Feb 1991 - Mar 1991 44506 + 674 + 1.5% Apr 1991 46948 + 2442 + 5.5% May 1991 - Jun 1991 63267 + 16319 + 34.8% Jul 1991 - Aug 1991 73069 + 9802 + 15.5% Sep 1991 92834 + 19765 + 27.0% Oct 1991 104824 + 11990 + 12.9% Nov 1991 129652 + 24828 + 23.7% Dec 1991 - Jan 1992 141308 + 11656 + 9.0% Feb 1992 161434 + 20126 + 14.2% Mar 1992 167939 + 6505 + 4.0% + 32939 *) + 24.4% *) Apr 1992 170050 + 2111 + 1.3% May 1992 182528 + 12478 + 7.3% Jun 1992 196758 + 14230 + 7.8% + 28819 + 17.2% Jul 1992 213017 + 16259 + 8.3% Aug 1992 221951 + 8934 + 4.2% Sep 1992 232522 + 10571 + 4.8% + 35764 + 18.2% Oct 1992 254585 + 22063 + 9.5% Nov 1992 271795 + 17210 + 6.8% Dec 1992 284374 + 12579 + 4.6% + 51852 + 22.3% Jan 1993 303828 + 19454 + 6.8% Feb 1993 322902 + 19074 + 6.3% Mar 1993 355140 + 32238 + 10.0% + 70766 + 24.9% Apr 1993 366164 + 11024 + 3.1% May 1993 385522 + 19358 + 5.3% Jun 1993 404930 + 19408 + 5.0% + 49790 + 14.0% Jul 1993 426827 + 21897 + 5.4% Aug 1993 451116 + 24289 + 5.7% Sep 1993 469356 + 18240 + 4.0% + 64424 + 15.9%

1 0

RIPE NCC Review - Draft
by k13＠nikhef.nl 14 Sep '93

14 Sep '93

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT RIPE NCC Review R.Blokzijl M.Sterba W.Woeber 7 September 1993 Version 1 1. Background The current activities of the RIPE NCC are guided by, and based upon, the document "RIPE NCC Activity Plan" [ref.: ripe-035]. This document was accepted by the RIPE community in May 1991 as the bases for a future RIPE NCC. Since April 1992 the RIPE NCC has been operational on the basis of the set of activities as described in ripe-035. At the RIPE meeting of April 1993 it was decided that a review of the first year of operations would be a needed in order to determine whether a. the goals as put down in the Activity Plan have been met b. an update of said activity plan is needed This document gives a review of current operations of the RIPE NCC. An updated activity plan will be presented in a separate document. The document is structured in two parts. The first part gives a detailed evaluation of the individual activities, as defined in the Activity Plan. The second part contains remarks of a more general nature. 2. Evaluation of Technical Activities 2.1 Technical -- Coordination Activities 2.1.1 The RIPE Database This task is performed by the NCC according to the Activity plan. New objects and attributes have been added as agreed by the RIPE community. New tools for checking, maintaining and distributing the database are being implemented. Reports are handled through the Quarterly Reports in an excellent way. 2.1.2 Distribution of the Database The distribution of the database is handled well. The newly developed software will support consistency between primary and secondary copies better. 2.1.3 Coordination of Database exchange with other Organisations This is permanently pursued. In cooperation with the Internic and Merit an exchange format has been defined. Good progress has been made, the delay in implementation of the actual exchanges is not attributable to the RIPE NCC. 2.1.4 Keep a record of IP connectivity in Europe This is progressing, albeit slowly. However we think this activity could be reviewed in the light of recent developments on the organisational background of networking in Europe. A more distributed approach could be advisable. 2.1.5 Keep an inventory of IP infrastructures not yet interconnected Basically this is done via the RIPE DB, though this could be only up to date from the moment the NCC started registering IP networks for Europe. 2.1.6 Keep a record of operational contact points This has been implemented by way of mailing distribution lists that enable subscribed networks to keep in contact. 2.1.7 DNS Software Operational issues are coordinated by the RIPE DNS WG. The NCC maintains an archive of relevant software and documentation. 2.1.8 Placement of name servers and backup servers in Europe, and beyond From our experience, this currently appears to be a non-issue. At least down to the level where central coordination and checking can be done, there seem to be no major problems that would call for allocation of NCC manpower. 2.1.9 Gather traffic statistics and network performance data Basically no progress has been made in these fields. It is our opinion that these activities belong to various network operators, not a central organisation such as the RIPE NCC. The RIPE NCC could provide a store facility for those providers who wish to publish their statistical data on neutral ground. However, the role of the RIPE NCC in gathering quality of service data needs to be discussed by RIPE. 2.2 Technical -- Development Activities 2.2.1 DB Management Tools The development of more sophisticated DB management tools has been an ongoing activity, resulting in a very stable and able database service. The definition of new tools has been done in close cooperation with the RIPE Working groups on Routing, Local-IR and DB, thus ensuring the fulfillment of user needs. 2.2.2 DB Querying Tools This has resulted in improved versions of client software that are being used widely. Also the integration with most commonly used information retrieval tools is excellent. 2.2.3 Network Statistics and Performance gathering and presentation tools Not much progress has been achieved. The need for these tools is clear, but a more precise definition of the role, and the amount of resources, of the RIPE NCC is needed. 2.2.4 DNS Quality Control Tools Tools are available from the RIPE NCC server. The NCC itself does a monthly analysis of the European DNS space, resulting in the famous hostcounts, and a set of comprehensive error reports for all European domains. It is our opinion that further quality control of the DNS space, is up to the responsible organisations on a top level basis. 2.2.5 Tools for drawing network diagrams Basically no progress has been made in this area. A repository and a common naming scheme for network maps have been implemented. We do feel that the work should have some priority, but whether it should be done by the RIPE NCC is debatable. A special project might be more appropriate. 2.3 Administrative -- RIPE Activity Support 2.3.1 Keeping the RIPE document store This has been implemented in an extremely friendly way for the end users: all commonly available information retrieval tools give access to the document store. The documentstore itself is kept up to date, and has been implemented in a well structured way. 2.3.2 Technical and secretarial support for studies undertaken by RIPE This has been working quite well. We should probably try to put in place a chasing mechanism for work items issued from RIPE meetings i.e. more follow-up on the WG's and WG chairs. 2.3.3 Organisational support for RIPE meetings This works extremely well, and has substantially augmented the productivity of the RIPE meetings. 2.4 Administrative - Reporting 2.4.1 Quarterly reports on all activities will be produced for the RIPE participating organisations and the RARE CoA 2.4.2 Quarterly reports on outstanding problems will be produced for the RIPE participating organisations and the RARE CoA We conclude that excellent quarterly reports have been produced in a timely fashion. They consist of detailed descriptions of the accomplishments of the RIPE NCC, a discussion of outstanding problems, and excellent overviews of the state of the Internet in Europe. They not only serve as administrative reportings, but also as reference material for network administrators and operators. 2.4.3 the NCC reports on its ongoing work and outstanding problems also to each RIPE meeting. This has been done at each RIPE meeting. Especially presentation of outstanding problems is of importance, since in most cases participation and decision by RIPE is needed to resolve them. 2.4.4 The NCC will produce annual reports At the time of writing of this report, the first RIPE NCC annual report has just been produced. 3. General comments We have concluded that the RIPE NCC has in its first year of operations achieved the goals that were aimed at back in 1991. The flying start of most of the activities within the first few weeks of operations has been extremely impressive. Even more impressive has been the way the RIPE NCC staff has been able to keep up the momentum. A careful analysis of the original Activity Plan has shown that in a few areas the progress has not been as was foreseen. We recommend that RIPE has a careful look at these areas and decides on their relative importance for the near future. On the other hand, we have found that certain areas of activity have taken much more resources then was originally foreseen. The activities concern mainly the IP Registry function of the RIPE NCC. It is interesting to notice that this activity is not even explicitly mentioned in the Activity Plan! Another area that the current activity plan has not foreseen is the involvement of the RIPE NCC in special projects. This requires resources on the management level and on the technical level. Though the projects are formally separately staffed and funded, the fact that they are housed in the RIPE NCC automatically means that some NCC resources go into these projects. This has been intentional, but it is not covered by the Activity Plan. We conclude that the RIPE NCC has become a focal point for development activities in many areas of Internet technology. We therefore strongly recommend that RIPE defines a new Activity Plan for the RIPE NCC, taking into account the analysis above, and the actual set of activities of the RIPE NCC as they have developed over the first year of operations. 4. Acknowledgements We would like to thank the following persons for their involvement in preparing this report: Daniel Karrenberg <dfk(a)ripe.net> Tony Bates <tony(a)ripe.net> Anne Lord <anne(a)ripe.net> Marten Terpstra <marten(a)ripe.net> Daniele Bovio <hi(a)frors12.bitnet> Nandor Horvath <horvath(a)sztaki.hu> Francis Dupont <francis.dupont(a)inria.fr> Jean-Michel Jouanigot <jimi(a)dxcoms.cern.ch> Bernhard Stockman <boss(a)sunet.se> Blasco Bonito <bonito(a)nis.garr.it> Vladimir Vrabec <vrabec(a)cs.felk.cvut.cs> Geza Turchanyi <turchanyi(a)fserv.kfki.hu> Ruediger Volk <rv(a)Informatik.Uni-Dortmund.DE> Roland Acra <acra(a)cisco.com>

1 0

Re: Deadline for Canal Cruise dinner
by Robert D. Collet Sprint GSD 13 Sep '93

13 Sep '93

Anne: It looks like I'll need to be in Kansas City the following week fighting for 1994 capital dollars, so I'm going to bow-out of this week's meeting. I've asked Peter Lothberg to present our construction efforts. Please accept my regrets. Bob > Message-Id: <9309130907.AA23322(a)ncc.ripe.net> > To: ripe-list(a)ripe.net > Subject: Deadline for Canal Cruise dinner > From: Anne Lord <Anne.Lord(a)ripe.net> > X-Organization: RIPE Network Coordination Centre > X-Phone: +31 20 592 5065 > Date: Mon, 13 Sep 1993 11:07:38 +0200 > Sender: anne(a)ripe.net > > > Dear All, > > *** RIPE Dinner reservation deadline : Tuesday 14th September 4pm.*** > > If you are planning to come to the RIPE Evening Dinner, please dont > forget that the deadline for reserving a place is tomorrow (the > caterers need to know exact numbers in advance). > > Send a mail to <meeting(a)ripe.net> if you would like to reserve a place. > > Anne > >

1 0

MAPS to be stored ?
by Anne Lord 13 Sep '93

13 Sep '93

Dear All, There has been some confusion where to send your maps to for storing..so to clarify - if you would like your map(s) stored in the RIPE Map repository, please send your map to the RIPE NCC <ncc(a)ripe.net> with the accompanying information which will be put in the index: name: the filename of the map. maintainer: the name and e-mail address of the maintainer of the map descr: a short description of the content of the map descr-as: the AS numbers that the map encompasses, both totally or in part. source: the original source of the file, where the map can also be retrieved, if available. The filenames must follow the convention: cc-name-ty-yymmdd.ext Where: cc - Two letters ISO country code, or, for large maps, geographical area covered. name - Short Name of the network ty - Type of map, could be: ge - geographical tp - network topological yymmdd - Year, month, and day of creation. ext - Extension giving file type (encoding): ps - PostScript ps.Z - compressed PostScript Anne

1 0

Deadline for Canal Cruise dinner
by Anne Lord 13 Sep '93

13 Sep '93

Dear All, *** RIPE Dinner reservation deadline : Tuesday 14th September 4pm.*** If you are planning to come to the RIPE Evening Dinner, please dont forget that the deadline for reserving a place is tomorrow (the caterers need to know exact numbers in advance). Send a mail to <meeting(a)ripe.net> if you would like to reserve a place. Anne

1 0

NIDUS-WG draft agenda
by Nandor Horvath 13 Sep '93

13 Sep '93

Please find attached the draft agenda for the comming RIPE NIDUS-WG. See you in Amsterdam, Nandor -=-=--=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- RIPE NIDUS-WG Draft Agenda 1. Report about the User Services WG sessions of the Amsterdam IETF meeting 2. Antonio Blasco's project +--- Start of included message from: Antonio_Blasco Bonito ----- | | | the GARR-NIS has started some months ago a small project to collect | information about network resources available on GARR network nodes. | We call it GARR online network resource guide. | The format of the information has been defined and client-servers | architectures have been identified to support easy retrieval of | the information via keyed requests over the network. | A limited number of resource descriptions have already been loaded | to test the system and the approach taken looks reasonable. | The client-server architecture is a mix of gopher, Wais and X500, each | one is used where it gives its best features. WAIS functionalities have | been modified/extended to achieve our goals. | | I think it could be a good idea to present this work at the next RIPE | meeting: if there is consensus we can start a project aiming at | making available information on RIPE network resources. | | ---------- ---------- | Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it | GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito | c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 | Via S. Maria, 36 Telex: 500371 CNUCE I | 56126 PISA Italy Fax: +39 (50) 904052 | ---------- ---------- | +--- End of included message from: Antonio_Blasco Bonito -----

1 0

RIPE 16 - Proposed European Internet Architecture WG
by k13＠nikhef.nl 10 Sep '93

10 Sep '93

Dear all, please find below a document produced by Bernhard Stockman as background material for the proposed EIA WG. See you all in Amsterdam, Rob +--- Start of included message from: boss(a)sunet.se ----- | | | Here is the draft version of the EIA charter as discussed | out in nowhere in California. | | Regards, | | Bernhard. | | =============================================================== | | European Internet Architecture (EIA) WG | | | | Introduction | | During the course of Internet based networks in Europe an intensive | developments has been observered. The number of connected hosts has | increased exponential from around 30000 in October 1990 to 450000 at | the latest count in August 1993. (See RIPE DNS Host Count Reports). | Together with these massive increase in Internet connected hosts | comes a corresponding increase in the number and size of Internet | regional, national and international networks within Europe. | | As a result of this growth a need for coordination of networking | between Internet networks in Europe was early observed which was one | of the main reasons for the formation of the RIPE organization and | the installation of the RIPE NCC. An important outcome was the | specification of a RIPE database today containing information of | various aspects of the European Internets. One aspect of this | database was the ability to describe routing policies via a | dedicated routing database. (The actual format of this database is | described in the ripe-81 document). | | The need for routing stability has been seen as one of the most | important aspects of today Internet networking and several efforts | are today ongoing aiming to define and implement means and methods | to guarantee routing stability. In Europe this has been provided | via the RIPE routing database in conjunction with the European Route | Server implementation. This is today fully covered within the PRIDE | project managed by the RIPE NCC. (See the project specification for | the PRIDE project for further details). | | Although the today routing technology offers a variety of tools for | different requirements based on technical and political needs there | are certainly limitation to what this technology can provide. For | this reason there is a need to further investigate interconnectivity | and topology developments within Europe and between Europe and the | Global Internet with the ambition of provide recommendations for the | maintenance and improvement of the European routing stability. | | As a first step towards an open and fully interconnected European | Internet the European Internet Architecture WGs aims at an initial | review of possible developments within Europe and by this produce | document(s) describing the observed possible paths that can be taken | and the consequences for the European Internet connectivity. | | As this effort concentrates on the European part of the Internet it | is natural that it takes the form of a RIPE WG. However, as some | aspects in this effort will have to do with the European Internet | connectivity towards the Global Internet it is also seen as | necessary that part of this work is done in close collaboration with | the Global Internet engineering and operations especially as | represented by IEPG. | | Goals and Milestones: | | September 1993 | First review of charter, definition level of ambition. Drafting of | the main topics to be covered | | January 1993 | Fist draft ready to be discussed and further improved. | | May 1994 | Final version ready to be submitted to RIPE and other interested | organizations. | +--- End of included message from: boss(a)sunet.se -----

1 0

MAPS|
by Daniele Bovio 09 Sep '93

09 Sep '93

Friends, (Romans, Countrymen) this message is to remind you that you have the great opportunity, during the coming week, to store your map at ftp.ripe.net directory ripe/maps. If you do so you'll feel less guilty when, during the meeting, I will ask to everybody: "did you store your map?" See you in Amsterdam d.

2 1

RIPE 16 - Agenda (version 2)
by k13＠nikhef.nl 09 Sep '93

09 Sep '93

R I P E 1 6 ------------- draft Agenda - version 2 ======== Wednesday 15 September 14:00 h ========================== 1. Opening 2. Minutes previous meeting 3. Action items 4. RIPE NCC report (Daniel Karrenberg) 5. Joint Projects progress (Tony Bates) - RS - GISS - PRIDE 6. RIPE NCC Review (Rob Blokzijl) 7. RIPE NCC Activity Plan (Rob Blokzijl) 8. RIPE & RARE (Rob Blokzijl) 9. Network Resource Discovery - GARR on-line network resource guide (Giuseppe Romano) - Guide To Network Resource Tools (Daniele Bovio) ======== Thursday 16 September 09:00 h ============================ During this day Working Group and BOF sessions will take place. A scheduling of these meetings will be distributed later. ======== Friday 17 September 09:00 h ============================== 10. Update on the new JIPS services (Phil Jones) 11. Update on EMPB services - status EUROPAnet (Svend Moeller Nielsen) - status EUROPAnet/EBONE gateways (Erik-Jan Bos) 12. Update on EBONE (Bernhard Stockman) 13. Update on SPRINT infrastrucure support (Bob Collet) 14. RIPE European Internet Architecture WG (Bernhard Stockman) 15. Introduction of DANTE (Howard Davies) 16. Update on networking with Russia (Rob Blokzijl) 17. Reports from the Working Groups and BOFs. 18. Next meetings 19. A.O.B. 20. Closing ======== End of Meeting Friday 17 September 16:00 h ============================

1 0

Fwd: A Direction for IPng
by IESG Secretary 09 Sep '93

09 Sep '93

Folks, Phill Gross asked me to forward this to you all FYI. /jws ------- Forwarded Message Date: Tue, 07 Sep 1993 14:02:30 -0400 From: Phill Gross <pgross(a)ans.net> To: IETF-Announce :; Subject: A Direction for IPng A Direction for IPng At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide BOF", on the process and progress of the IPng activities. ("IPng" stands for "IP, the next generation". The IPDecide BOF was chaired by Brian Carpenter. Minutes are available in the IETF directories, with the file name </ietf/93jul/ipdecide-minutes-93jul.txt>.) The IPDecide BOF explored several facets of the IPng process, such as - "What is the basis for choosing the next generation IP (i.e., what are the technical requirements and decision criteria)." - "With the advent of CIDR and new, more stringent address assignment policies, are we comfortable that we truly understand the level of urgency?" - "Should the IETF or the marketplace make the final IPng decision". The BOF was held in a productive atmosphere, but did not achieve what could be called a clear consensus among the assembled attendees. In fact, despite its generally productive spirit, it did more to highlight the lack of a firm direction than to create it. The IPDecide BOF was followed the next evening by the open IESG plenary. During this session, the IESG and the assembled attendees discussed the IPng issues and seemed to arrive at a consensus based on the following set of bullets presented by the IETF chair: - "The IETF needs to move toward closure on IPng." That is, the IETF should take active steps toward a technical decision, rather than waiting for the "marketplace" to decide. - "The IESG has the responsibility for developing an IPng recommendation for the Internet community." That is, the IESG should provide leadership and take specific actions to help move the IETF toward a technical decision. - "The procedures of the recommendation-making process should be open and published well in advance by the IESG." - "As a part of the process, the IPng WGs may be given new milestones and other guidance to aid the IESG." - "There should be ample opportunity for community comment prior to final IESG recommendation (e.g., there will be an extended Last Call)." A Direction For IPng Building on this consensus, I'd like to announce a set of specific directions in the IESG that I hope will move us toward timely resolution of many of the key IPng issues. The IESG will establish a temporary, ad hoc, "area" to deal specifically with IPng issues. The charter for this new IESG area is to develop a recommendation on which, if any, of the current proposals should be adopted as the "next IP". This recommendation will be submitted to the IESG and to the Internet community for review. Following an adequate period of review to surface any community concerns, the IESG will issue a final IPng recommendation. All of the current IPng-related working groups will be moved immediately into this new area. This new area will be headed by two co-Area Directors from within the IESG. I have asked Allison Mankin (NRL), current Transport Services AD, and Scott Bradner (Harvard), current Operational Requirements AD, to serve as co-AD's for this temporary area. I am very pleased to report that they have agreed to take this important assignment. (Because this is expected to be a temporary assignment, Scott and Allison will also continue to serve in their current IESG positions during this period.) All IETF Areas are now expected to have Area Directorates. For the IPng Area, a Directorate will be especially important to bring additional viewpoints into the process. Therefore, I am asking that, as their first action, Scott and Allison form a specific IPng Directorate to act as a direction-setting and preliminary review body. The IPng process will continue to be completely open, and therefore reports and meeting notes from any IPng Directorate meetings will be published in timely fashion. Issues Toward IPng Resolution Two important issues need resolution immediately before we can expect progress toward an IPng recommendation: - What is the scope of the effort? That is, should IPng be limited to solving the well known scaling and address exhaustion issues; or should IPng also include advanced features such as resource reservation for real-time traffic? The argument in favor of considering advanced features is that migration to a new IP is (hopefully, only!) a once-in-a-generation occurance, and therefore all advanced features should at least be considered. Arguments opposed to considering advanced features include the fact that we may not have time for this level of effort before the scaling and address exhaustion problems confront us, and that we may not have the necessary understanding and experience to make all the correct choices at this time. - What is the available timeframe? That is, before we can even begin to make an informed decision about the scope, we need a better understanding of the urgency and time constraints facing us. Factors that affect the available time include the current rate of address assignments (which can give us an estimate of when we are currently projected to run out of addresses), the current policies governing address assignment (which can give us an understanding of how policies affect the assignment and utilization rates), the impact of CIDR aggregation, the development time for IPng, and the time needed to field and migrate to the new IPng. Therefore, I am asking the new AD's and the Directorate to start immediately the following specific activities to help guide their ultimate IPng recommendation: 1. Develop an understanding of the available timeframe, covering at least the following issues: - Review Internet growth metrics, such as the current address assignment and utilization rates. Develop an understanding of how the new address assignment policies impact the assignment and utilization rates. - Review the expected impact of CIDR address aggregation. Develop an understanding of the expected savings due to CIDR aggregation. - Develop new technical guidelines for classless Internet addressing. Specific examples include guidelines for how to utilize variable length subnet masks, and how to utilize currently unused Class A and B addresses in a classless fashion in hosts and routers. - Develop a strong understanding of the time required for the development, fielding, and migration for a new IP. - Based on all the above issues, (a) develop an estimate for how long we have to to develop and deploy an IPng. This could be a set of estimates based on best/worst case estimates for how each of the above factors will affect the available timeframe. (b) Consider whether more stringent assignment policies might provide additional time. If so, recommend such policies. (c) make a recommendation on whether it is worthwhile to mount a serious effort to reclaim addresses and/or to renumber significant portions of the Internet. 2. Based on an informed judgement of the time constraints above, make a recommendation regarding the scope for IPng, i.e., should IPng consider scaling issues only or advanced topics also. 3. Based on the scope and time constraints, develop a clear and concise set of technical requirements and decision criteria for IPng. These should include, but not be limited to, the criteria outlined in the IESG statement (RFC1380). 4. Based on the decision criteria, scope, and time constraints, make a recommendation on which of the current IPng candidates to accept, if any. Finally, I am asking Scott and Allison to make a detailed report at the opening plenary of the next IETF meeting in November on the status of setting up their new area, and on their progress toward organizing the above work items. In particular, the status of the work items on timeframe should be fully reported. This will be followed by regular progress reports to the Internet community, at IETF meetings and in other appropriate forums. Please join me in giving Scott and Allison our full cooperation, and in thanking them for accepting this daunting assignment. I feel confident that we will now make significant progress on the important IPng issues facing the Internet community. Phill Gross IETF/IESG Chair P.S. All follow-up discussion of this message should be on the main IETF mailing list ietf(a)cnri.reston.va.us. ------- End of Forwarded Message

1 0