[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv4 address length technical design

On Wed, Oct 3, 2012 at 4:15 PM, Owen DeLong <owen at delong.com> wrote:
> On Oct 3, 2012, at 3:49 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>> On 10/3/12, Jay Ashworth <jra at baylink.com> wrote:
>>> So the address space for IPv8 will be...
>>> </troll>
>> In 100 years, when we start to run out of IPv6 addresses,  possibly we
>> will have learned our lesson and done  two things:
>>  (1)   Stopped  mixing the Host identification and the Network
>> identification into the same bit field;   instead  every packet gets a
>> source network address,  destination network address, AND  an
>> additional  tuple of       Source host address,   destination host
>> address;  residing in completely separate address spaces,  with  no
>> "Netmasks",  "Prefix lengths", or other comingling of  network
>> addresses and host address spaces.
> Agreed, mostly.
> Prefix lengths can still be useful for route summarization and it would
> be useful to have separate segments of the network address, such as
> Autonomous System Number, Intra-AS Organizational Identifier, and
> Intra-Organizational Network, for example. It might be useful to use
> prefix lengths in those cases to allow for variability in the boundary
> between these identifiers.
>> And
>>  (2)  The new protocol will use  variable-length address for the Host
>> portion, such as  used in the addresses of CLNP,  with a convention of
>> a specified length,  instead of a hardwired specific limit  that comes
>> from using a permanently  fixed-width field.
> On this, I disagree? Once host identifiers are no longer dependent on or
> related to topology, there's no reason a reasonable fixed-length cannot
> suffice.
>> Need more bits?   No protocol definition change required.
> Nope, just new ASICS everywhere and no clear way to identify where they
> are or are not deployed and?

A regrettably serious response:

There are some fundamental questions about areas of computer usage,
engineering, and science that will affect what "the next protocol"
should look like.

Despite a couple of decades of frenetic work to mobility-ize our
protocols, we mostly didn't with IPv6; that may be the norm rather
than the design exception by $NEXTPROTOCOL.

Quantum computers may, or may not, be relevant to anything (including
possibly routing or switching) by $NEXTPROTOCOL days.

Supermassive parallelism may be relevant to routing or switching.

Moore's Law may peter out at some point with Silicon hitting
atom-count limits, or could continue somewhat further with nanowires
and graphene and the like, or something else completely could come

Extremely low cost concerns may collapse the number of physical
devices in a computer / computing device, as we have see many cycles
of various system controllers or video controllers migrating into CPUs
or back out again as performance or chip cost concerns / fab
technology pushed the optimization point one way or the other.  This
could affect switch and router cost optimization as well.

We can (probably safely) say that within the next decade there is no
sign of a technical or business driver for $NEXTPROTOCOL bubbling over
our feet; by the time that it becomes necessary or relevant, all the
ASICS we have out there now will be obsolete.  Whether they're just
faster smaller ASICS or some form of interface we cannot currently
accurately predict, I have no idea, but I would rather not limit our
conceptualization of 20-100 year timeframe solutions to "Today, but
faster".  If we go back to 1992, it is almost completely an accident
that winning technologies in many areas today are still recognizable
to the computer people of that era.

-george william herbert
george.herbert at gmail.com