home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 91jul / subnetsbof-minutes-91jul.txt < prev   
Text File  |  1993-02-17  |  9KB  |  195 lines

  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Noel Chiappa
  6.  
  7. SUBNETBOF Minutes
  8.  
  9. Variable Width Subnet Masks BOF
  10.  
  11. The Subnets BoF reviewed a number of problematical cases brought up by
  12. the use of variable width subnet masks (i.e., use of more than one
  13. subnet mask in any given IP network).  These cases all relate to the
  14. allocation of various subnetted addresses to various physical networks
  15. which are part of an IP network.  Consensus was reached on which
  16. configurations to allow and disallow.
  17.  
  18. Before reviewing the specific points, it will be useful to include some
  19. terminology.  Use of the subnet numbers ``A, B.1 and B.2'' means that A
  20. and B are differing values of a fixed part of the `rest' field, and that
  21. 1 and 2 are differing values of a different, lower, fixed part of the
  22. `rest' field.
  23.  
  24. For instance (using an 8 bit rest field), with the two masks 11100000
  25. and 11111100, `A' might be 001xxxxx, `B' might be 010xxxxx, `B.1' would
  26. be 010001xx and `B.2' would be 010010xx.  With this terminology in hand,
  27. the specific cases can now be reviewed in detail.
  28.  
  29. The first question addressed was whether or not to allow two subnets in
  30. the same part of a network's address space to be topologically separate.
  31. In other words, could subnets B.1 and B.2 be separated by subnet A?
  32. Looked at another way, if B.1 and B.2 are thought of as parts of a
  33. `subnet' B, can that subnet be partitioned?  If allowed, this would
  34. represent a divergence with the basic Internet philosophy, in which an
  35. IP network is not allowed to be partitioned.  The argument for allowing
  36. this is to get maximum use out of variable width masks.
  37.  
  38. Variable width masks were added to the architecture to allow efficient
  39. use of address space.  For example, if an enterprise, with a single IP
  40. network number, contains a single large LAN (with several thousand
  41. hosts), and a number of small LAN's (with tens of hosts), there is no
  42. single subnet mask that will efficiently use the address space of that
  43. network number.  A wide mask, necessary to handle the single large LAN
  44. as a whole, will `waste' space when used on the small LAN's.  A small
  45. mask will force the single large LAN to be trated as a collection of
  46. small LAN's, with consequent forwarding overhead.  An alternative
  47. approach would be to use a separate network number for the large LAN,
  48. but this will increase the number of network numbers in the system as a
  49. whole, with consequent global costs.  If the enterprise is only singly
  50. connected to the rest of the Internet, there is no benefit to the rest
  51. of the system of having more than one network number for the enterprise.
  52. Thus, only with use of varying width masks can efficient use be made of
  53. address space, both in the network and the Internet as a whole.
  54.  
  55. The disadvantage to allowing this is that all the routers in a network
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. must know where every subnet is (and what its mask is).  For example,
  64. suppose B.1 and B.2 are on different sides of A (connected by routers R1
  65. and R2 respectively), and a router R is attached only to subnet A and
  66. some outside network.  In the current state of affairs, R will only know
  67. the subnet mask for A, on which it has an interface.  Now, when a
  68. incoming packet for B.1 arrives at router R, knowledge of the mask for A
  69. (and thus B) is not sufficient; router R needs to be able to distinguish
  70. B.1 and B.2 as separate destinations if it is to forward the packet to
  71. the correct next hop router, R1 or R2.  It is thus seen that, to
  72. function in the general case, all routers in a subnetted network now
  73. need to know the mask for every subnet in the system.
  74.  
  75. This is a substantial cost; however, it was felt that to make the
  76. restriction that all the small subnets in one piece of the network
  77. address space (i.e., B.1 ....  B.N) must be contiguous worked against
  78. maximum utilization.  Moreover, even this restriction does not
  79. necessarily remove the necessity for a router to know all the subnet
  80. masks in use in a given network.  For example, if the router R above
  81. were connected to B.1, rather than A, it would still need the mask for
  82. A, unless it were for routing purposes to consider A as a large number
  83. of subnets of the same size as B.1.
  84.  
  85. Finally, the routing protocols which support variable length subnet
  86. masks do provide the necessary information to routers to do the
  87. forwarding correctly.  The consensus thus was that allowing this
  88. configuration was necessary.
  89.  
  90. The next question to be addressed was whether all subnet masks must be
  91. contiguous and on the high end of the `rest' field (i.e., have the form
  92. 11...1100...00).  One argument that was put forward was that
  93. non-contiguous masks allowed more flexibility in extending the subnet
  94. mask when it ran out.  It was pointed out that easy extension could be
  95. provided for by allocating subnet number bits from the high end of the
  96. rest field, and host bits from the low end, with unused space in the
  97. middle.  Whenever either field became too small, it could be extended,
  98. as long as unused bits remained.  Additionally, some versions of the
  99. Patricia tree algorithm do not work with non-contiguous masks.
  100.  
  101. While it was agreed that no good reason could be provided for not
  102. allowing other formats, no strong use could be seen for allowing them
  103. either, and in the interest of future flexibility the consensus was to
  104. not allow them.
  105.  
  106. The third question to be address was whether `subset' subnets would be
  107. allowed; i.e., could a small subnet have the same leading bits as a
  108. larger subnet.  For example, if one subnet is numbered B, could another
  109. subnet have the number B.1?  Clearly, at a minimum, no hosts on subnet B
  110. could have a address which had B.1 as a prefix (i.e., addresses on
  111. subnets B.1 ...  B.N which were in use could not appear on subnet B);
  112. this would leave routers unable to discover which subnet these hosts
  113. were on, unless each host was tracked separately.
  114.  
  115. It was initially thought that this was the only problem, which could be
  116. handled by correct configuration, and the feeling was that this should
  117.  
  118.                                    2
  119.  
  120.  
  121.  
  122.  
  123.  
  124. be allowed to optimize use of the address space.  An additional cost
  125. would be that routers would have to do a `best match' routing lookup.
  126. I.e., even after finding a mask and address that match, the router would
  127. still have to look for further potential matches that are more
  128. `complete'.  This cost exists now for routers that support host routes,
  129. however.
  130.  
  131. However, it was pointed out that a host H attached to subnet B would
  132. think that hosts attached to subnet B.1 (which host H would need to
  133. reach through a router) were in fact directly reachable by host H. No
  134. general fix (i.e., one that worked on all network technologies, not just
  135. those which used ARP) could be discovered for this problem.  In
  136. addition, the chances for misconfiguration (e.g., a host on subnet B
  137. that appears to be on subnet B.1) are manifold.  Given these points, the
  138. consensus was that this configuration should not be allowed.
  139.  
  140. Finally, ambiguous subnets were discussed briefly.  This name refers to
  141. subnets masks (and numbers) which overlap in ways such that host
  142. addresses are not unambiguously on one network or another.  For
  143. instance, consider two different subnets 5 and 6, with different subnet
  144. masks 5 and 6 (temporarily ignoring the fact that these are all 1's
  145. subnet numbers).  Next, think of an address starting with 7; it matches
  146. the 5 address and mask, but also matches the 6 address and mask.  Which
  147. one is better?
  148.  
  149. Since this case was ruled out by the fact that non-contiguous masks will
  150. not allowed, it was not discussed in detail.  However, if that
  151. restriction is relaxed in the future, this question will need to be
  152. revisited.
  153.  
  154. Attendees
  155.  
  156. Steve Alexander          stevea@i88.isc.com
  157. Philip Almquist          almquist@jessica.stanford.edu
  158. Nagaraj Arunkumar        nak@3com.com
  159. Karl Auerbach            karl@eng.sun.com
  160. Tom Benkart              teb@saturn.acc.com
  161. Arthur Berggreen         art@acc.com
  162. David Borman             dab@cray.com
  163. Scott Brim               swb@nr-tech.cit.cornell.edu
  164. Rob Coltun               rcoltun@ni.umd.edu
  165. Ralph Droms              droms@bucknell.edu
  166. Robert Elz               kre@munnari.oz.au
  167. Dino Farinacci           dino@cisco.com
  168. Dennis Ferguson          dennis@canet.ca
  169. Karen Frisa              karen.frisa@andrew.cmu.edu
  170. Jeffrey Honig            jch@nr-tech.cit.cornell.edu
  171. Phani Jujjavarapu        phani@cisco.com
  172. Douglas Kerr             dougk@mtxinu.com
  173. Nik Langrind             nik@shiva.com
  174. John Lekashman           lekash@nas.nasa.gov
  175. Tony Li                  tli@cisco.com
  176. Bill Manning             bmanning@rice.edu
  177. Matt Mathis              mathis@psc.edu
  178.  
  179.                                    3
  180.  
  181.  
  182.  
  183.  
  184.  
  185. Lars Poulsen             lars@cmc.com
  186. Gershon Schatzberg       439-3582@mcimail.com
  187. Osamu Takada             takada@sdl.hitachi.co.jp
  188. Walter Wimer             walter.wimer@andrew.cmu.edu
  189. Robert Woodburn          woody@cseic.saic.com
  190. Richard Woundy           rwoundy@ibm.com
  191.  
  192.  
  193.  
  194.                                    4
  195.