[governance] Uni.X to Uni.X .NETworking - Where do the new bits go ?

[Jim Fleming]

Uni.X to Uni.X .NETworking - Where do the new bits go ?

With an existing 160 bit message foot-print, you can expand the addressing
from 32 bits to 64 bits and even add a new micro-UDP protocol that carries
data.

The existing 32 bit addressing is not changed. Routing policies determine
which
bits are PREFIX bits and which bits are SUFFIX bits. [Note, the 16 extension
bits in the Port fields for UDP and TCP are not mentioned. Some people do
not
view those as real address bits. They certainly are lightly used in an age
where
people claim to be running out of address space. One of the negatives of
considering
them as address bits is that they assume UDP and TCP. The NOP protocol would
not have those bits, or ICMP.]

Reviewing all of the new found bits we have:
0101.0101.SSSSDDDD.000000.LLLLLLLLLL
SSSSSSSDDDDDDD.SD.DDSS.SSSSSSDDDDDD
SD11GTTT.PPSSSDDD.CCCCCCCCCCCCCCCC
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD

The 0101.0101 can evolve to SSDD.SSDD but is likely a good PREFIX for a long
time.
The 000000 can also evolve to SSSDDD but is also likely a good PREFIX.
The SSSSDDDD in the first 32 bits comes from legacy QOS research and likely
also falls into
the PREFIX category because messages are often sorted first based on PREFIX.
Another likely set of PREFIX bits is the SD11 group which evolves to SDSD.
The SSSDDD in evolved from the Protocol Field may be better as SUFFIX bits.
The bits in the second 32 bit group could then be divided evenly between
PREFIX and SUFFIX.

What this means is that if we were dealing with phone numbers (in the old
days) and you had
a number like 555-1212 and area codes were added they would be on the left
and considered a
PREFIX. Country codes are also added on the left. Extensions behind PBXs are
normally
shown on the right as a SUFFIX.

>From a global governance and routing policy point of view, some may argue
that they should
all be PREFIX bits in order to dillute the current corrupt regime that lords
over 32 bit allocations.
IF one assumes that there will be FIRST a major migration in the market to
ONE new
32-bit space behind the NATs, before moving to 64-bit addressing, then there
is less concern
about the current corrupt regime because it will be de-peered from the telco
core as we see
happening in the current markets. As the de-peering occurs, the new 32-bit
space managed in
a fair and impartial manner emerges from behind the NAT (PE - Provider Edge)
devices.
The CE (Customer Edge) devices only see the new addresses and are not
impacted by the
current corrupt regime.

>From a global governance and routing policy point of view, some may also
argue that FIRST
people should migrate to the space behind the NATs and then work out the
governance.
This is like people in Europe first moving to America and then working out
their governance.
Attempting to do it in Europe would likely cause the trip (migration) to
never occur. It is ironic
that with cyberspace, people in America appear to be going to Europe and
other regions to
free themselves from the corrupt 32-bit address regime and protocol
engineering regime which
go hand in hand. It is even more ironic that the solution for many people
has been sitting right
in front of them in the form of cyberspace governance but these choose to
handicap themselves
via meat-space meetings, and to be co-opted by meat-space people who could
not care less
about cyberspace.

_______________________________________________
governance mailing list
governance at lists.cpsr.org
https://ssl.cpsr.org/mailman/listinfo/governance