CURRENT_MEETING_REPORT_


Reported by Noel Chiappa

ADRBOF Minutes

IP Address Hacks BOF

This BOF discussed potential interim solutions to the near-term problem
of the shortage of class B IP network numbers.  Of the three classes of
IP network numbers, A, B and C, the class B numbers are being used up at
the highest rate.  There are 16K (2^14) of these, and over four thousand
are already allocated (although not all are being advertised in the
Internet).  These are the most useful numbers, since most sites are not
large enough to need a class A (24 bit rest), where most are too large
to make good use of a class C (8 bit rest), particularly if subnetting
is being used.

Depending on which exact model is used to predict future usage of these
numbers, at the current rate of usage these will run out in several
years.  A straight exponential fits the curve so far quite well; it has
been argued that this is not a useful model, but rather an S-curve model
should be used.  The problem is that no inflection point has yet
appeared, so it is difficult to fit an S curve to the growth.  In any
case, there is general agreement that the problem is severe.

The two key questions were what kind of extra network numbers to create,
and what portion of the existing IP address space to devote to them.
After a commendably quick discussion, consensus answers did appear to
both of these.

There were several potential answers to the first question.  One option
is to simply create more class B (i.e., 16 bit `rest' field) numbers.
The other was to create a new class of network numbers with a different
size rest field, intermediate between class B and C. It was pointed out
that most sites which are getting class B numbers do not need a whole
class B space, but could easily use something a little smaller; this
would reduce the usage of the class B space, thereby extending the
lifetime of that space.  Suggestions were made for a number of different
sizes, including 14, 13 and 12 bits.

One thing going against more class B numbers was that to create a
reasonable number of them would use a large chunk of the 32 bit IP
address space.  The current block of 16K used one quarter of the address
space; all addresses with a `10' prefix.  If another quarter were
(somehow) devoted to class B, that would still only double the number.
On the other hand, use of a smaller rest field would allow more network
numbers to be packed into the portion of the address space allocated;
since the available free (or reclaimable) spaces were mostly quite
small, this weighed heavily in favor of the smaller fields.

A new class, with a 12 bit rest field (to called class `E' addresses)
was finally decided on, since it maximizes the number of network numbers

                                   1





that can be created.  While a 12 bit rest field only allows for 4K
hosts, this is still significantly more than a class C, and should be
more than enough for most companies.  Also, it is exactly equidistant
between the class B and class C sizes.  However, this decision (for 12
instead of 13 or more) needs to be reviewed carefully to make sure that
a 12 bit rest field will actually be useful to a significant number of
network number applicants.

This does point out the necessity of having hosts not pry into address
formats.  It is plausible to deploy a new network number format if only
the routers have to be changed; doing so in a world where most types of
host software have to be changed as well is clearly problematic.

There are two broad classes of solution to the question of where to
allocate any new network numbers.  The first is to use some or all of
the currently reserved space; i.e.  prefix 1111.  The second is to
recycle some of the currently ``unlikely to be used'' space; for
instance the back half of the class A space (prefix 01), or the back
half of class C (prefix 1101).

Considering the first, the question was whether or not to use the entire
space, or to continue the practice of allocating a space whose prefix
started with all 1's and ended with a 0; (i.e., allocate 11110 and
reserve 11111).  It was decided not to keep a part reserved if this
space were used, but to use the entire space.  The problem is that this
practise is resulting in diminishing returns as far as the size of the
portion of address space available to hold network numbers and the rest
field; in other words, the overhead of the field dedicated to format
identification was getting quite large (5 of 32 bits).

Use of the entire block would allow creation of 2^16 of these new
network numbers.  (4 bits of prefix + 16 of network number + 12 of rest
= 32) This number, sixteen times larger than the number of class B's,
could reasonably be expected to last quite a long time.  Were this done,
since it would use the last reserved space, a new reserved space should
be created, consisting of the back half of the existing class A and/or C
space.

Alternatively, if the back half of class C space (1101 prefix) were used
to hold these new numbers, 2^16 of them could also be created here.  It
was pointed out that use of class C numbers would allow routers which
did not understand class E addresses to treat them as a group (2^4, or
16) of class C numbers.

No definite answer was arrived at in the BOF for the question of where
to place the new numbers, although there was general consensus that
using all the reserved space or the back half of class C space were the
two viable options.  It was agreed that in either case the back half of
the class A space should be reserved; it was felt that rather than move
directly from one use to another, it would be best if a portion of the
address space cycled through `reserved', to allow use of the old meaning
to disappear from the net before the new use was taken up.

Discussion in the hallways after the BOF concluded that the optimal

                                   2





choice was in fact to use the reserved space.  It was felt that the
ability to have older routers handle class E numbers as a group of class
C numbers was not actually good, given the problems in the network with
large numbers of network numbers.  Also, it was felt that the argument
above about cycling through reserve should apply to the back half of
class C space as well.

Finally, and most important, it was pointed out that unless the new
numbers were allocated from the reserved space, there would be less
impetus on people's part to change their software.  The ability to model
a class E net as a group of C's would, from this viewpoint, be a
problem, not an advantage.  This is a weighty point, given the necessity
of the change in the network; presumably people making the change to
recognize E's would also put in the change to reserve the back half of A
and C space, which might well be critical in the future.



                                   3