Date: Tue, 5 Jul 2005 00:58:36 -0700
From: "Christian Huitema"
| The problem is the really small size of the option type field in IPv6.
| There really only are 5 bits available for numbering both the hop by hop
| and the end to end options. That makes for a grand total of 32, of which
| three are assigned by basic IPv6 specs. So, there really are good
| reasons to be somewhat conservative with the assignments.
It isn't really that bad, the option with 17 in the low 5 bits and 0 in
the upper 3 is a different option than the one with 17 in the low 5 bits and
7 in the upper 3.
So, really there are 8 distint groups of 32 options each.
Certainly it is possible (even likely) that those groups won't be filled
at the same rate, and that one will run out before the others (most likely
the one with 0's in the upper 3 bits), but pretending there are only 32
options available is taking it too far.
Beyond that, we need to consider the rate of allocation. If IPv4 address
space was being used at the same rate as IPv6 options, even allowing for the
differences in the allocation spaces, we wouldn't have IPv6 today, we wouldn't
even be thinking about it.
This request is (or seems to be) the first new request for a v6 option
since options were invented. At this rate it will be another couple of
hundred years before we have a problem (even if all the options were 000
options, which I think, this one was not).
When we get to about half full, which should be in another hundred years
or so, unless someone finds a sudden use for lots of IP level options that
has been eluding us for the past 20 years, we will need to extend the
option numbering space. Methods to do that are trivial to design. If
anything, the problem is that there are so many different reasonable ways.
Being all that ultra careful with this number space just isn't a requirement.
Ietf mailing list