Alexey,
The dropbox URL is 404 for me, so unfortunately I can't read your proposal.
However, a simple extension of the IPv4 address field was proposed in
various forms 20+ years ago, before we started on the IPv6 adventure.
My own contribution, for example, was
https://www.cs.auckland.ac.nz/~brian/draft-carpenter-aeiou-00.txt
The first problem with this approach is (as shown by the matrix in the draft)
exactly the same as with all other such proposals that we have seen over
the years: an unmodified legacy host cannot communicate with a host
using the address extension. So we need all the same tricks that we
need with IPv6 - dual stack, tunnels, and in the worst case NATs.
The second problem is that existing legacy routers will drop the packets.
That being so, and well understood since 1994, the choice was made to
develop a new protocol. We chose binary addresses for obvious reasons;
reverting to telephone-like decimal addresses was certainly not
considered.
You are correct that IPv6 addresses are hard to remember. We decided
that doesn't matter: users should never need to know about addresses
anyway.
Regards
Brian Carpenter
Regards
Brian Carpenter
On 11/12/2015 01:42, Alexey Eromenko wrote:
Hi all,
I have created a new Internet Protocol "Five Fields".
Why ?
Because IPv6 is hard to use, and I wanted to keep look & feel similar
to IPv4. Problem with IPv6, is that those addresses are very hard for
humans to remember, compare and visualize topologies in human brain.
IPv4 has great look & feel, but it is exhausted. So I wrote a new
replacement for IP.
I did it, because I don't like to work with something long like this:
2001:db8:2e1:1a73:149f:88ff:fe81:6116
And it would be better, if we work with simpler addressing:
192.168.510.971.11
10.0.0.0.1
382.201.769.25.133
Draft spec. available.
"Five Fields" offers 0...999 in each field, in dotted decimal
notation, and includes unique features not found *anywhere else*.
10-bits x 5 fields.
- x230,000 times larger address space than IPv4 (should be enough for
several hundred years, including IoT)
-Mobile TCP, allows moving Mobile Nodes between subnets, without
losing connectivity. A replacement for Mobile IP. An order of
magnitude simpler, and requires no access to routers and
configuration-free.
-IP-VRF header extension, allows doing VRF-VPN without MPLS (and
without dot1q VLANs)
-Super-lightweight, and should be faster than IPv4 or IPv6 by 1%-2%.
Small overhead.
-UDP/IP overhead is 28 bytes; UDP/IPv6 overhead is 48 bytes, but
UDP/IP-FF overhead is just 26 bytes ! Even shorter than the original,
yay !
-Simpler to implement than IPv4/v6, because no fragmentation. MTU path
discovery is the way to go.
-No broadcasts.
-No IP header checksums (done at layer 4)
-No autoconfiguration/SLAAC (this belongs to DHCP territory)
-No IGMP required (it is optional now for Multicasts)
-No Layer2 resolution. ARP-free protocol.
I believe, that it is superior to both IPv4 and IPv6, simpler than
both, and intended as a replacement for both. Substantial improvement
on both.
This draft specification describes various parts, the protocol itself,
addressing scheme, Address Resolution Algorithm (without ARP), DNS
extensions, Mobile TCP, and more...
Draft spec download here:
https://www.dropbox.com/s/mbyjo5da5zgi4kp/IP-FF-2015-12-10.zip?dl=0
IP-FF is about:
o Short, human-readable addresses
o Modularization of some perceived IPv6 bloat
(NDP/IGMP/MLD/IPsec/SLAAC/Flow/...)
o New features: IP-VRF and Mobile TCP, TCP Anycast.
o Optimization: UDP/IPFF combo is just 26 bytes. Almost 50% cut in
overhead vs IPv6. And no ARP.
Please take a look, and see how good it is.
If anybody would like to help me promoting this new protocol and
implement it in code, feel free to write to my email.
Best wishes,
--
-Alexey Eromenko "Technologov", 10.Dec.2015.
al4321(_at_)gmail(_dot_)com