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.
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