home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / cidrd / cidrd-minutes-95jul.txt < prev    next >
Encoding:
Text File  |  1995-10-18  |  9.1 KB  |  217 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Guy Almes/Advanced Network and Services
  5.  
  6. Minutes of the CIDR Deployment Working Group (CIDRD)
  7.  
  8.  
  9. Tony Li's Report on IP Address Space Usage and Lifetime
  10.  
  11. Tony summarised the IPv4 address space and how the InterNIC allocates
  12. large CIDR blocks.  Further, he noted how the InterNIC maintains the
  13. statistics on allocated and assigned address space used in this report.
  14.  
  15. Given this background, Tony issued the disclaimer that he could not
  16. estimate possible non-linear effects due to future developments.  He
  17. then proceeded to discuss his estimates of future Address Space Usage
  18. and the Lifetime of the IPv4 Address Space.
  19.  
  20. At the San Jose IETF (December 1994), Tony had estimated a lifetime of
  21. the year 2008 +/- three years.  By the Danvers IETF (April 1995), the
  22. growth slope appeared to drop.  The new projected lifetime is the year
  23. 2018 +/- eight years.  The statistical extrapolation technique is Tony's
  24. visible eye-balling.
  25.  
  26. Tony then presented the implications for the development and deployment
  27. of IPv6.  From his IPv4 projections, the worst-case date by which a
  28. deployed IPv6 is needed is the year 2010.  From his assumptions about
  29. IPv6 development and deployment, the latest that an intense
  30. development-and-deployment effort could begin would be seven years total
  31. (the critical path is two years for host development plus five years for
  32. host deployment).  Thus, this intense IPv6 effort would need to begin in
  33. the year 2003.
  34.  
  35. Tony's slides are included at the end of this report.
  36.  
  37.  
  38. Frank Solensky's Report on IP Address Space Usage and Lifetime
  39.  
  40. Frank presented his slides on projections similar to Tony's.  However,
  41. his techniques for statistical extrapolation was more sophisticated.
  42.  
  43. One slide showed the growth in 128/2 (i.e., Class B) allocations.  The
  44. estimate here projected that, under current allocation policies, the
  45. 128/2 space would not run out.
  46.  
  47. A second slide showed the growth in 192/3 (i.e., Class C) allocations.
  48. There were two distinct allocations here (labeled raw and smoothed).
  49. The raw estimate showed 192/3 not running out, but the smoothed estimate
  50. showed 192/3 running out by the end of the decade.
  51.  
  52. Frank's slides are included at the end of this report.
  53.  
  54.  
  55.  
  56. Erik-Jan Bos's Report on Routing Table Growth
  57.  
  58. Erik-Jan reported on the growth in the number of prefixes present in
  59. routers.  The number of total nets continues to grow, and at a higher
  60. rate than we would like.  Similarly the number of AS numbers continues
  61. to grow.
  62.  
  63. The number of CIDR routes continues its strong upward growth, as has the
  64. number of AS numbers doing CIDR. 56% of the AS numbers now advertise at
  65. least one CIDR prefix.
  66.  
  67. Erik-Jan has been maintaining a database, with entries for each hour
  68. since January 1994, of the number of BGP entries in
  69. Amsterdam1.dante.net.  This plot shows an uncomfortably high slope since
  70. Danvers (April 1995).  The proliferation of IP providers, for example,
  71. leads to the creation of holes in SURFnet's CIDR blocks.  Tony Bates
  72. stressed that we need to continue to put pressure on the `top 20'
  73. providers who need to improve their use of CIDR.
  74.  
  75. Erik-Jan's slides are included at the end of this report.
  76.  
  77.  
  78. Daniel Karrenberg's Report on Routing Table Growth
  79.  
  80. Daniel reported on the number of prefixes for each 8-bit prefix.  His
  81. table includes the number of host addresses possible (given its CIDR
  82. breakup), the number of actual current routes, and the number of hosts
  83. per route.  Daniel has done this once per month for the last two months.
  84. The value of this report will grow as he continues to produce these
  85. reports each month in the future.
  86.  
  87.  
  88. Bill Manning's Report on Class A Space Utilisation and Class A
  89. CIDRisation
  90.  
  91. Bill reported on the state of allocation of the traditional Class A
  92. space and lower (i.e., not reserved) 0/1 space.  The IANA is negotiating
  93. to recover some of the pre-CIDR allocated 0/1.  About 3% of the total
  94. IPv4 space has been recovered in the last few months.  They are
  95. continuing to review nets not visible in the global routing system, and
  96. hope to recover an additional two to four additional 0/1 prefixes.
  97.  
  98. Bill's slides are included at the end of this report.
  99.  
  100.  
  101. Classless in-addr.arpa Delegation -- Geert Jan de Groot
  102.  
  103. Geert Jan addressed the problem of maintaining the in-addr.arpa entries
  104. of the DNS when different CIDR blocks of a single class-full network
  105. number are assigned to different organizations.
  106.  
  107. After briefly discussing two non-solutions, he presented an admittedly
  108. ugly solution that works with current software.  Specifically, use CNAME
  109. RRs to alias/move authority to another zone.
  110.  
  111. This has actually been on the net for a while and seems to work well.
  112. Havard Eidnes and Geert Jan have written an Internet-Draft on this
  113. technique.  This technique is also being discussed within the DNSIND
  114. Working Group.
  115.  
  116. Geert Jan's slides are included at the end of this report.
  117.  
  118.  
  119.  
  120. Address Allocation for Private Internets -- Yakov Rekhter
  121.  
  122. Yakov noted that private internets are proliferating, and that the use
  123. of global IP addresses for these private internets depletes the address
  124. pool.  To avoid this, we need to provide an alternative addressing plan.
  125.  
  126. To further this, Yakov has drafted a successor to RFC 1597 that:
  127.  
  128.  
  129.    o Discusses those cases when non-global addresses can be used,
  130.    o Specifies three specific blocks that can be used for this,
  131.    o Notes implications for the global Internet routing system, and
  132.    o Apologises for the likely need for private internets to renumber.
  133.  
  134.  
  135. During discussion, it was noted that DNS records sometimes expose an
  136. otherwise private IP address.  In some cases, this will require two
  137. overlapping sets of DNS definitions for a company's IP domain.
  138.  
  139. As a postscript, Yakov noted the need for administrators to renumber and
  140. for tool-builders to help automate renumbering.  The key argument is
  141. that, for a site's IP addresses to be useful, it does not suffice for
  142. them to be globally unique.  Many sites are likely to have to renumber
  143. lest, for example, their old globally unique prefix be taken back by
  144. IANA (to recover a valuable and underused Class A, for example) or their
  145. old globally unique prefix be dropped from the routing tables of
  146. providers (to recover routing table memory space, for example).  During
  147. discussion, the point was made that renumbering should be applicable
  148. across the entire range, including providers and very prestigious large
  149. sites.  What is needed is routable addresses -- not merely unique
  150. addresses.
  151.  
  152. In a discussion of operational considerations, it was brought up that if
  153. a firewall tries to support proxy Web service, and if the Web browser
  154. tries to use Web authentication, then this fails.  It was judged that
  155. this is a HTTP protocol problem.
  156.  
  157. It was also brought up that Tony Bates has already written an
  158. Internet-Draft that calls for a reserved set of AS numbers that can be
  159. used for private Internets.
  160.  
  161. In discussion, Eliot Lear warned that RFC 1597bis needs to be done with
  162. care, to avoid negatively impacting users.
  163.  
  164. Yakov's slides are included at the end of this report.
  165.  
  166.  
  167. Standards-Track Actions
  168.  
  169.    o Best Current Practices
  170.  
  171.      Scott Bradner reported that Dave Crocker believes that the current
  172.      standards process supports what Best Current Practices were
  173.      intended to achieve.  Dave thus objects to the notion of Best
  174.      Current Practices.  About a dozen CIDRD members had read the
  175.      proposal for Best Current Practices, and none found it
  176.      objectionable.  The Operational Requirements Area would like to do
  177.      things such as RFC 1597bis without running it through the standards
  178.      track.  Scott advised that, if members feel that the Best Current
  179.      Practices is useful and important, then they should so advise the
  180.      IESG.
  181.  
  182.    o The Address Ownership Internet-Draft
  183.  
  184.      Yakov and Tony Li have written an Internet-Draft on address
  185.      ownership, taking the position that a notion of address ownership
  186.      has and will cause the Internet to be unroutable.  It is likely
  187.      that a working group last call on this Internet-Draft will come
  188.      soon.
  189.  
  190.    o An Appeal to Return Address Space Internet-Draft
  191.  
  192.      Phil Nesser has written a Internet-Draft urging people to return
  193.      unneeded address space, but he was not present at the meeting.
  194.      Bill Manning has agreed to help with any editorial rewrite.  Tony
  195.      needs to ping Phil on the status of this document.
  196.  
  197.    o Net 39 Experience
  198.  
  199.      Geoff Huston's document should be edited for shorter sentences, but
  200.      then sent ahead as an Informational or Best Current Practice RFC.
  201.      Barry Greene volunteered to help edit it.
  202.  
  203.    o Help in IP Space Renumbering
  204.  
  205.      There has been a request for someone to write a document on what is
  206.      involved in renumbering an IP network.  This is important in order
  207.      for people to sanely agree to ever renumber their networks.  Geert
  208.      Jan volunteered to write a draft.  Sean Doran's experience is that
  209.      most customers are happy to renumber when the importance of doing
  210.      so it pointed out to them.
  211.      There was discussion of the proliferation of IP addresses due to
  212.      the common practice of multiple Web server domain names, supported
  213.      by single server machines, requiring multiple IP addresses due to
  214.      mis-features of the HTTP protocol.  Scott Bradner reported that the
  215.      HTTP Working Group is working on this problem.
  216.  
  217.