home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 91jul / adrbof-minutes-91jul.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  6.7 KB  |  143 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Noel Chiappa
  6.  
  7. ADRBOF Minutes
  8.  
  9. IP Address Hacks BOF
  10.  
  11. This BOF discussed potential interim solutions to the near-term problem
  12. of the shortage of class B IP network numbers.  Of the three classes of
  13. IP network numbers, A, B and C, the class B numbers are being used up at
  14. the highest rate.  There are 16K (2^14) of these, and over four thousand
  15. are already allocated (although not all are being advertised in the
  16. Internet).  These are the most useful numbers, since most sites are not
  17. large enough to need a class A (24 bit rest), where most are too large
  18. to make good use of a class C (8 bit rest), particularly if subnetting
  19. is being used.
  20.  
  21. Depending on which exact model is used to predict future usage of these
  22. numbers, at the current rate of usage these will run out in several
  23. years.  A straight exponential fits the curve so far quite well; it has
  24. been argued that this is not a useful model, but rather an S-curve model
  25. should be used.  The problem is that no inflection point has yet
  26. appeared, so it is difficult to fit an S curve to the growth.  In any
  27. case, there is general agreement that the problem is severe.
  28.  
  29. The two key questions were what kind of extra network numbers to create,
  30. and what portion of the existing IP address space to devote to them.
  31. After a commendably quick discussion, consensus answers did appear to
  32. both of these.
  33.  
  34. There were several potential answers to the first question.  One option
  35. is to simply create more class B (i.e., 16 bit `rest' field) numbers.
  36. The other was to create a new class of network numbers with a different
  37. size rest field, intermediate between class B and C. It was pointed out
  38. that most sites which are getting class B numbers do not need a whole
  39. class B space, but could easily use something a little smaller; this
  40. would reduce the usage of the class B space, thereby extending the
  41. lifetime of that space.  Suggestions were made for a number of different
  42. sizes, including 14, 13 and 12 bits.
  43.  
  44. One thing going against more class B numbers was that to create a
  45. reasonable number of them would use a large chunk of the 32 bit IP
  46. address space.  The current block of 16K used one quarter of the address
  47. space; all addresses with a `10' prefix.  If another quarter were
  48. (somehow) devoted to class B, that would still only double the number.
  49. On the other hand, use of a smaller rest field would allow more network
  50. numbers to be packed into the portion of the address space allocated;
  51. since the available free (or reclaimable) spaces were mostly quite
  52. small, this weighed heavily in favor of the smaller fields.
  53.  
  54. A new class, with a 12 bit rest field (to called class `E' addresses)
  55. was finally decided on, since it maximizes the number of network numbers
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. that can be created.  While a 12 bit rest field only allows for 4K
  64. hosts, this is still significantly more than a class C, and should be
  65. more than enough for most companies.  Also, it is exactly equidistant
  66. between the class B and class C sizes.  However, this decision (for 12
  67. instead of 13 or more) needs to be reviewed carefully to make sure that
  68. a 12 bit rest field will actually be useful to a significant number of
  69. network number applicants.
  70.  
  71. This does point out the necessity of having hosts not pry into address
  72. formats.  It is plausible to deploy a new network number format if only
  73. the routers have to be changed; doing so in a world where most types of
  74. host software have to be changed as well is clearly problematic.
  75.  
  76. There are two broad classes of solution to the question of where to
  77. allocate any new network numbers.  The first is to use some or all of
  78. the currently reserved space; i.e.  prefix 1111.  The second is to
  79. recycle some of the currently ``unlikely to be used'' space; for
  80. instance the back half of the class A space (prefix 01), or the back
  81. half of class C (prefix 1101).
  82.  
  83. Considering the first, the question was whether or not to use the entire
  84. space, or to continue the practice of allocating a space whose prefix
  85. started with all 1's and ended with a 0; (i.e., allocate 11110 and
  86. reserve 11111).  It was decided not to keep a part reserved if this
  87. space were used, but to use the entire space.  The problem is that this
  88. practise is resulting in diminishing returns as far as the size of the
  89. portion of address space available to hold network numbers and the rest
  90. field; in other words, the overhead of the field dedicated to format
  91. identification was getting quite large (5 of 32 bits).
  92.  
  93. Use of the entire block would allow creation of 2^16 of these new
  94. network numbers.  (4 bits of prefix + 16 of network number + 12 of rest
  95. = 32) This number, sixteen times larger than the number of class B's,
  96. could reasonably be expected to last quite a long time.  Were this done,
  97. since it would use the last reserved space, a new reserved space should
  98. be created, consisting of the back half of the existing class A and/or C
  99. space.
  100.  
  101. Alternatively, if the back half of class C space (1101 prefix) were used
  102. to hold these new numbers, 2^16 of them could also be created here.  It
  103. was pointed out that use of class C numbers would allow routers which
  104. did not understand class E addresses to treat them as a group (2^4, or
  105. 16) of class C numbers.
  106.  
  107. No definite answer was arrived at in the BOF for the question of where
  108. to place the new numbers, although there was general consensus that
  109. using all the reserved space or the back half of class C space were the
  110. two viable options.  It was agreed that in either case the back half of
  111. the class A space should be reserved; it was felt that rather than move
  112. directly from one use to another, it would be best if a portion of the
  113. address space cycled through `reserved', to allow use of the old meaning
  114. to disappear from the net before the new use was taken up.
  115.  
  116. Discussion in the hallways after the BOF concluded that the optimal
  117.  
  118.                                    2
  119.  
  120.  
  121.  
  122.  
  123.  
  124. choice was in fact to use the reserved space.  It was felt that the
  125. ability to have older routers handle class E numbers as a group of class
  126. C numbers was not actually good, given the problems in the network with
  127. large numbers of network numbers.  Also, it was felt that the argument
  128. above about cycling through reserve should apply to the back half of
  129. class C space as well.
  130.  
  131. Finally, and most important, it was pointed out that unless the new
  132. numbers were allocated from the reserved space, there would be less
  133. impetus on people's part to change their software.  The ability to model
  134. a class E net as a group of C's would, from this viewpoint, be a
  135. problem, not an advantage.  This is a weighty point, given the necessity
  136. of the change in the network; presumably people making the change to
  137. recognize E's would also put in the change to reserve the back half of A
  138. and C space, which might well be critical in the future.
  139.  
  140.  
  141.  
  142.                                    3
  143.