On 12/14/2015 02:24 AM, Masataka Ohta wrote:
Alexey Eromenko wrote:
So, use NAT to enjoy 48 bit addressing, may be with class E.
You can still enjoy full end to end transparency for applications
over TCP/UDP through UPnP capable NAT boxes.
I thought about extending port ranges to 32-bit,
For the time being, 16bit is good enough.
This NAT within 16bit architectures is mystical to me. That is always a
caution and a calling, may you imagine, Ohta-san.
It pleases that you may receive merriment at my sharing that I have
always tried to approach new domains and challenges by inquiring into
how new principles may shape new understandings of a tradional state of
affairs.
Alright, as usual, new principles to the domaing of broadcast, let us
raise the trinity, imperfection, eventually consistent, redundancy,
host and meta-principlse by building a superstructure and see how big it
is, just for fun.
In bytes
48 = 3 X 16bit port redundency.
50 = global address
98 = 48bit + 50bit slice
294 = 3 X 98bit packet redundancy
320 = 294bit + 26bit sanguinity mysticly measured,
320bits is Five 64bit registers.
5 64bit registers to hold the Five Fields. That's lovely.
best regards,
robert
but it invites a massive
Carrier-Grade NATs. Lets call it Large variants of TCP and UDP. TCP.L and
UDP.L.
32bit port number, if any, is a long term goal and, unlike home
routers, you can expect carriers upgrade their equipments
regularly.
-Simpler to implement than IPv4/v6, because no fragmentation. MTU path
discovery is the way to go.
That's as bad as IPv6.
Look, for most links, fragmentation and checksums slow down Core Router
processing (those big boxes doing 100 Gigs per port).
Wrong. Within the core, MTU is 1500. Hardware computation of
checksums are done at wire speed with small amount of hardware
(much smaller than additional hardware to support IPFF in
addition to IPv4).
Even edges, to make PMTU discovery quickly react against
PMTU increase, packets a little larger than the current
PMTU must be sent frequently, which burdens devices
at the edges.
Do you suggest supporting links with 30% overhead ?
No, requiring 1280 or 9000 should be fine.
IPv4 doesn't do it either, defining minimum MTU at 576 bytes
FYI, it is 68, not 576.
-No broadcasts.
That's as bad as IPv6.
Why is it bad ?
Because broadcast is useful and IPv6 foolishly abandoned it
because of the wrong understanding that some architecture
of IP over ATM was broadcast incapable.
IPFF defines a new mode: "silent multicast", which is
somewhere between tradional Multicast and Broadcast.
No complication, please. Just say "broadcast".
Masataka Ohta