I have uploaded to Internet-draft repository.
On Dec 10, 2015 9:42 PM, "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx> wrote:
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@xxxxxxxxx
>
>