home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ale / ale-minutes-94mar.txt < prev   
Text File  |  1994-05-13  |  8KB  |  215 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Erik-Jan Bos/SURFnet
  5.  
  6. Minutes of the Address Lifetime Expectations Working Group (ALE)
  7.  
  8.  
  9. Agenda Bashing
  10.  
  11. Tony Li added one item to the agenda, IPng Timetable, at the request of
  12. the area director.
  13.  
  14.  
  15. Corrections to Models
  16.  
  17. During the ALE BOF at the Houston IETF, models were presented to look at
  18. the expected lifetime of IPv4.  The intention of this agenda item is to
  19. review the models currently used and make corrections if and when
  20. needed.
  21.  
  22. The volume of the routing tables is still increasing.  Lines on the
  23. graph show a million routes in several years time (Tony Li:  ``This is
  24. scary'').  The question is, what will the effect of CIDR be?  Some
  25. curves are trying to show the effect of CIDR, but it is only guessing
  26. since no real data is available.  The current curves are based on data
  27. beginning in September 1992.  The coming weeks and months will be
  28. interesting starting points for new curves.
  29.  
  30. Most of today's CIDR announcements are blocks of class C addresses,
  31. however, some blocks of Bs are already announced from Europe.
  32.  
  33. Curtis Villamizar did a dump of his routing tables and analyzed the
  34. data.  Tony Bates and Curtis will be looking into the routing table
  35. dump.  The dumps will be made on a weekly basis.  Regionals that are
  36. willing to make their dumps available should provide pointers to the
  37. appropriate FTP directory.  Other people are encouraged to dump their
  38. routing tables and analyze the data.
  39.  
  40.  
  41. Efficiency
  42.  
  43. Tony Bates reported that a look into the DNS was done for Europe to
  44. determine the efficiency (percentage of usage) of the assigned address
  45. space.  There are good reasons why this is not accurate (e.g.
  46. firewalls, just not registering in DNS and other usage of IP like
  47. NetBIOS add to the inaccuracy).  It is clear, however, that this is the
  48. only source available.
  49.  
  50. Looking at improving efficiency is relatively easy for networks that are
  51. new, but ``renumbering'' is not a lost battle.  Tools need to be
  52. developed so that organizations can grow their networks without needing
  53. more address space.  People should be given the means to be efficient.
  54. Furthermore, there should be documents to help people.  Currently there
  55. is no pointer to give to people.
  56.  
  57. Havard Eidnes volunteered to start this effort from a draft document he
  58. wrote.  There is software that Charley Kline wrote that allowed him to
  59. get approximately 30% efficiency in the assignment of host numbers at
  60. the University of Illinois.  This should be made available at some
  61. common location (e.g., Merit) after some restyling for portability.
  62. Frank Solensky spoke with Charley a few minutes after the meeting.
  63. Charley had just completed some of the finishing touches on his software
  64. the previous week and was happy to make it available.
  65.  
  66.  
  67. RFC 1597
  68.  
  69. Marten Terpstra reported on RFC 1597, an Informational RFC. Although
  70. this is not a standards-track RFC, it is considered important because
  71. the numbers are now available and the issue is being discussed.  It is
  72. now possible to use address space inside a company, without needing a
  73. review by another company to judge your efficiency.
  74.  
  75. The basic idea is simple:  assign network numbers that are non-unique,
  76. but that are never going to be connected to the Internet.
  77.  
  78. The numbers are:
  79.  
  80.  
  81.    o 10.0.0.0 - 10.255.255.255
  82.    o 172.16.0.0 - 172.31.255.255
  83.    o 192.168.0.0 - 192.168.255.255
  84.  
  85.  
  86. Pros:
  87.  
  88.  
  89.    o Save address space for the Internet
  90.    o Use as much as you like
  91.    o Perhaps some security advantage
  92.  
  93.  
  94. Cons:
  95.  
  96.  
  97.    o Connecting to the Internet or other private Internet needs
  98.      renumbering
  99.  
  100.    o Traffic becomes untraceable when leaking
  101.  
  102.    o DNS and other things need more thinking
  103.  
  104.    o Generally something for an ``experienced'' network manager
  105.  
  106.  
  107. If Network Address Translators (NAT boxes) are being used, this RFC
  108. might have a large beneficial impact on the Internet.  This RFC is also
  109. useful for sites that are definitely not going to connect.
  110.  
  111. The DNS consequences for deploying this RFC are not clear yet.  There
  112. should be an additional RFC describing DNS consideration for RFC 1597.
  113.  
  114.  
  115. IPng Timetable
  116.  
  117. The area director asked the working group to come up with a
  118. ``guesstimate of'' how long IPv4 will last.  Hand grenade tossing:
  119.  
  120.  
  121.    o IP addresses will be available until 2008 plus or minus three
  122.      years.  The assumptions should be clear, e.g., there are users out
  123.      there that cannot be served right now.  If they are connecting this
  124.      will become different.
  125.  
  126.    o Core routers are already running out of memory.  64Meg routers will
  127.      buy another two years (plus or minus six months).  In an optimal
  128.      CIDR world, there would probably be more time.
  129.  
  130.  
  131. From this, no firm date can possibly be given, it all depends on the
  132. success of CIDR and the cooperation of all service providers.
  133.  
  134. NAT boxes might also help CIDR, since a service provider is then able to
  135. announce a non-CIDR-isable customer inside his own CIDR block.  This
  136. will be studied further.
  137.  
  138.  
  139. Action Items
  140.  
  141. Tony Bates and Curtis Villamizar  Conduct and analyze routing table
  142.                                   dumps.
  143.  
  144. Havard Eidnes                     Brush up the document on improving
  145.                                   efficiency.
  146.  
  147.  
  148. Attendees
  149.  
  150. Juha-Pekka Ahopelto      juha-pekka.ahopelto@ntc.nokia.com
  151. Mark Allyn               allyn@netcom.com
  152. Susie Armstrong          susie@mentat.com
  153. Bashir Ashrafi           bashraf@chipcom.com
  154. Dennis Baker             dbaker@wellfleet.com
  155. Fred Baker               fbaker@acc.com
  156. Tony Bates               tony@ripe.net
  157. Jim Beers                Jim.Beers@cornell.edu
  158. Nutan Behki              nebhki@newbridge.com
  159. Erik-Jan Bos             erik-jan.bos@surfnet.nl
  160. Brad Burdick             bburdick@radio.com
  161. Joesph Burrescia         burrescia@es.net
  162. Frank Cannata            cannata@cabletron.com
  163. Greg Celmainis           gregc@newbridge.com
  164. Brett Chappell           bchappe@relay.nswc.navy.mil
  165. Robert Christ            rchrist@fhcrc.org
  166. Michael Collins          collins@es.net
  167. Matt Crawford            crawdad@fncent.fnal.gov
  168. John Curran              jcurran@nic.near.net
  169. Sean Doran               smd@use.net
  170. Kjeld Borch Egevang      kbe@craycom.dk
  171. Havard Eidnes            havard.eidnes@runit.sintef.no
  172. Nasser El-Aawar          nna@ans.net
  173. H. Tom Fitzpatrick       fitz@ddn.af.mil
  174. Vince Fuller             vaf@barrnet.net
  175. Steve Fulling            fulling@cs.orst.edu
  176. Eugene Hastings          hastings@psc.edu
  177. Ian Heavens              ian@spider.co.uk
  178. Jeff Hodges              hodges@jessica.stanford.edu
  179. Matthew Jonson           jonson@ddn.af.mil
  180. Sean Kennedy             liam@nic.near.net
  181. Edwin King               eek@atc.boeing.com
  182. So Young Lee             sylee@hen.nca.go.kr
  183. Tony Li                  tli@cisco.com
  184. Kim Long                 klong@nysernet.org
  185. Jun Matsukata            jm@eng.isas.ac.jp
  186. Gerry Meyer              gerry@spider.co.uk
  187. Keith Mitchell           keith@pipex.net
  188. Pushpendra Mohta         pushp@cerf.net
  189. Dennis Morris            morrisd@cc.ims.disa.mil
  190. Rina Nathaniel           rina@rnd-gate.rad.co.il
  191. Phil Nesser              pjnesser@rocket.com
  192. Ngoc-Lan Nguyen          lnguyen@icp.net
  193. Michael O'Dell           mo@uunet.uu.net
  194. Andrew Partan            asp@uunet.uu.net
  195. Michael Patton           map@bbn.com
  196. Rex Pugh                 pugh@hprnd.rose.hp.com
  197. Ron Roberts              rgr@stanford.edu
  198. Robert Roden             roden@roden.enet.dec.com
  199. Duncan Rogerson          d.rogerson@nosc.ja.net
  200. Michal Rozenthal         michal@fibronics.co.il
  201. Steven Schnell           schnell@sprintlink.net
  202. Tim Seaver               tas@concert.net
  203. Frank Solensky           solensky@ftp.com
  204. John Tavs                tavs@vnet.ibm.com
  205. Marten Terpstra          marten@ripe.net
  206. Jerry Toporek            jt@mentat.com
  207. Paul Traina              pst@cisco.com
  208. Wendell Turner           wt@arinc.com
  209. Gary Veum                veum@boa.gsfc.nasa.gov
  210. Maria Vistoli            vistoli@infn.it
  211. Justin Walker            justin@apple.com
  212. Geoff White              geoff@nexsys.net
  213. Jane Wojcik              jwojcik@bbn.com
  214.  
  215.