[governance] Uni.X to Uni.X .NETworking - The Second 32 Bits

[Jim Fleming]

As mentioned, the 160 bit Uni.X to Uni.X message can be broken down into bit
fields with many fields assigned to addressing for Source (S) and
Destination (D)
addresses. Keep in mind that historically, the DNS has been mostly used to
set
D bits, Destination bits. The assumption is that a name is used to locate a
destination
and the sender doing the name lookup sets all of the Source (S) bits.

Because the DNS has mostly been focused on 32-bit binary fields, there has
not
been much activity thinking out-side the 32-bit box. With the coming shift
to more
open-minded green-field wireless markets, the shift to LAN-based gamers and
other 48-bit devices, and more creative ways to look at the existing 160
bits, PLUS
the 128 bit AAAA records in DNS, there may be more relaxation of the DNS to
Destination mind-set. As one example, simple software can be developed that
takes
the 128 bits in an AAAA record and disperses them in some of the fields of
the
160 bit header and the Port fields for TCP and UDP. The 8-bit TTL field
could come
from the DNS AAAA record.

Some of the second group of 32 bits could also come from the 128 bit AAAA
record.
Extensive testing has shown that 14 of the bits from the ID field can be
used for addressing.
That adds a 7+7 addition to Source and Destination addressing. The other 18
bits in
the second 32 bits are less predictable across vendor's equipment and some
operating
systems do not even process them correctly, where correctly is viewed as a
"standard".
With Uni.X to Uni.X networking and a common kernel, the bits can be
processed in a
stable and consistent manner because the code defines the standard, not some
meta
document describing the code.

When placing S and D bits into legacy fields, it can be important to place D
bits into
positions that might be best set from the DNS A or AAAA records. That can
sometimes
result in less readable documents or pictures of protocol bit structures
because the D
bits may be disjoint from the S bits or on the left of the S bits and that
may appear strange
for left-to-right readers. Grouping the bits as SSDD or SDSD can also tend
to imply some
sort of preferred aggregation scheme when it is really just an attempt to be
as backward
compatible as possible. Also, SD groups can be added two bits at a time as
opposed to
SSDD groups and people looking at migration transitions may prefer SDSD over
SSDD.
That is the case with the TTL bits, where SD11GTTT may be viewed as a TTL in
the
range of 63 and later when 11 becomes SD the TTL is lowered to take
advantage of
better network technology and layers of "IP virtualization". [With IP
virtualization one
may think it is one hop to all major cities because the real transport and
hop counts are
hidden behind the scenes. A virtual view is presented to the customer. They
think their
ISP is really well-connected.]

Returning to the second 32-bits, the left-most 14 end up as 7+7 then you
have 2 bits
which can play the traditional ID function. Since fragmentation is being
phased out or
turned off completely, those two bits become wasted in the transition and
may come
back later as an SD addition.

In the second set of 16 bits, you start with the infamous 49th bit, a bit
that is defined to
be zero but has no function. That is a very useful bit to tag packets as
using the new
address space. In all of the 160 bits, it is one of the few bits that stands
alone. Most of
the other bits are in groups. [Note: Some documents attempt to claim the
49th bit either
does not exist or is used by aliens from another planet. It is there, count
the bits, there
are 160. It is like a hotel claiming there is no 13th floor.]

After the 49th bit, in legacy systems there are the D and M bits and then 13
bits rarely
used for an offset when fragmentation is not in use. When D is set,
fragmentation is turned
off, wasting the other 14 bits, not to mention the 16 ID bits. It is a very
wasteful design.

Another way to map or document the bits is as the DMZ bits, borrowing one
from the 13
and reducing that field to 12. If fragmentation is down-played, the Z bit
(zero bit) can be
assumed to be 0 for a long time. DMZ is easy to remember and the order is D
for Don't
Fragment and M for More Fragments. Yes, the bits tell a very conflicting
story, don't
fragment, and here is a bit to indicate more fragments are coming.

If D is set to 1 then M will be 0 and Z is 0, resulting in 100 for the DMZ
bits. Once those
are set, then 12 bits emerge at the right into a clean 6+6 field for
SSSSSSDDDDDD.
Because of unpredictable code in legacy systems, it is best to assume that
is a field of
6 zeroes in the each address. Some might call that "reserved". Watch out for
"reserved",
reserved for who ? Reserved for "the Right People(tm)" ?

Looking down the road as purely S and D bits, the second 32 bits may shape
up as:

SSSSSSSDDDDDDD.SD.DDSS.SSSSSSDDDDDD

The DDSS in the middle is that reversal that is not natural for some
readers.

Overall, there are 16 D bits in the second 32 that could be set from the 128
bit AAAA record.
One can begin to see what would happen if they are set in legacy stacks.
Some control
the ID field, one sets the 49th bit, one controls the Don't Fragment bit,
and some may be wasted
in the 6-bit offset field which may not be predictable on a global network.
The 128 bit AAAA
records coming from the DNS can of course be used to test what works and
does not work
and changes can be made easily and allowed to expire as TTLs come into play.

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