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