Brand-new Internet Protocol "Five Fields"

T

Technologov

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

  • 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...
[attached]

With more time and polish, I plan to send it to IETF.

Best wishes,
cleardot.gif

--
-Alexey Eromenko "Technologov"
 

Attachments

Technologov said:
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.
Click to expand...

No offense meant, but, "It's too difficult to..." isn't an excuse. The answer is to learn how to operate w/IPv6 because it's what's in place right now as the path forward. The IETF is going to laugh at your submission, and even if they don't, the network vendors (Cisco, Juniper, et al) will basically tell you, "No." And if they don't want to code your new IP protocol into their respective operating systems, your protocol will go nowhere, quite quickly.
 
I won't argue, except to say my protocol is superior to whatever exists.

Things like elimination of bloatware (NDP/ARP/fragmentation/IPsec/...) worth a lot by itself.
Mobile TCP is revolutionary and ground-breaking. IP-FF VRF can work without MPLS. This already simplifies network by twice.
 
IPsec isn't bloatware. It may be complicated, but it's for securing encryptions for those who wish to do that.

The numbering could be more efficient, or clear, not just based on IP4's. I think the time for numbering a protocol after IP4 is soon to be past, if not already past, since IP6 has dominance as a new protocol.

I recognize your credit for what you did though.

jasonvp, I read that IP6 isn't meant to be regularly configured by people, it's meant to be autoconfigured. I don't know if anything has changed, in them expecting people to manually configure it, or let programs do most of the work for them.
 
sidetone said:
jasonvp, I read that IP6 isn't meant to be regularly configured by people, it's meant to be autoconfigured. I don't know if anything has changed, in them expecting people to manually configure it, or let programs do most of the work for them.
Click to expand...

SLAAC is a perfectly acceptable way to configure IPv6, and if you understand the algorithm used to determine the IPv6 address of a device, you'll always know what it'll SLAAC to. To wit: you have to at least know the /64 network that the device is sitting on. eg: dead:beef:abcd:1234::/64. Then take the device's MAC address (eg: 6E:90:98:8C:B4: d7) and flip the second bit in the second hexadecimal character. In our case, that character is 'E' or 14. Convert 14 to binary (1110) and then flip the second bit, which is a 1. You get 1100, or 12, or hex 'C'.

From there you wedge an 'fffe' into the middle of the address and you get: dead:beef:abcd:1234:6c90:98ff:fe8c:b4d7/64 as the device's IPv6 address. That's what it'll SLAAC to every time as long as A)it's on that same /64, and B)its MAC address stays consistent.

Don't like that? Well, you can *shudder* use DHCPv6 if you want. But, I'm really not a fan of that because it requires another server to be running to answer the requests (like IPv4). Any router can provide RAs to a broadcast domain so that participating hosts automatically SLAAC themselves an IPv6 address.

Finally, hand-configuring IPv6 addresses isn't difficult. There's nothing saying you have to use all sorts of hexadecimal characters in the address. For instance, if we stick with our example and we own the dead:beef:abcd::/48, then our first /64 could be: dead:beef:abcd::/64, and we can start addressing the hosts manually at dead:beef:abcd::1/64, etc.

It's not difficult. I taught myself the concepts of IPv6 in a week during Christmas break one year. And I did so with Hurricane Electric's help; they have tests you take to learn more and more about it (I'm considered an IPv6 'Sage' now). If I can do it, so can you. And everyone else.
 
While I somewhat agree that I think they tried to fix too many things directly in the IP stack and ended up making it incredibly complicated, hopefully you realise that what you are doing is purely academic. IPv6 has been around over 15 years, and has been deployed for at least 10. Billions of dollars, at least, are already behind the implementation of v6. Unless IPv6 was found to be completely broken, there's no way anyone's going to move to some new system out of the blue that drops various features and moves from 128 bit down to 50 bit (Even if 50 bit is enough).

You mention dropping ARP, but have a new 'LARP' replacement which seems very similar to IPv6 discovery. Obviously if you plan on supporting Ethernet for L2, you have to have some MAC address resolution, regardless of what you call it.

I'm also intrigued how hosts can elect to receive multicast messages without sending any sort of notification to their upstream router.

IPsec is also fairly heavily used. I doubt the Internet engineering foundations would be happy about dropping it.

I get the impression that in some cases you've altered or removed features that make sense to you, as this has been developed in house, by 1? person. The IPv6 spec was developed and evolved over years by engineers all over the world. If you actually submit it to those guys, I'd get ready to have it shot down pretty heavily.

I commend the amount of work you've put into it though.
 
I'm also intrigued how hosts can elect to receive multicast messages without sending any sort of notification to their upstream router.
Click to expand...

Same way they receive broadcasts in IPv4; Just filtering is done at layer 2 (MAC address), instead of Layer 4 (TCP/UDP).

You mention dropping ARP, but have a new 'LARP' replacement which seems very similar to IPv6 discovery.
Actually I use "LARA" - Link Address Resolution Algorithm, which resolves it all on the CPU, without sending packets.

IPsec is also fairly heavily used. I doubt the Internet engineering foundations would be happy about dropping it.
Click to expand...

I think IPsec should become an optional module, not part of core IP spec, because I think that application-level encryption is the way to go (SSL/SSH/...). If someone _really_ wants IPsec, he still can use it, just like Mobile IP (which was dropped from IPFF in favor of brand-new, in-house developed Mobile TCP spec).

I get the impression that in some cases you've altered or removed features that make sense to you, as this has been developed in house, by 1? person.
Click to expand...

Impression is correct. A 1-man project. Yet it takes some brain to do it. - And there is some innovation in IPFF - Mobile TCP, +Anycast TCP, IP-VRF, and ARP-free protocol being just a few.

Yes, features that I consider of little value were "modularized". i.e. became optional -- things like NDP Router Discovery/Advertisement/Solicitation and SLAAC -- I think this all can be served by a DHCP server, as a separate spec, and the user would get similar results.

IP-FF is about:
  • Short, human-readable addresses
  • Modularization of some perceived IPv6 bloat (NDP/IGMP/MLD/IPsec/SLAAC/Flow/...)
  • New features: IP-VRF and Mobile TCP, TCP Anycast.
  • Optimization: UDP/IPFF combo is just 26 bytes, vs UDP/IPv6 48-bytes. Almost 50% cut in overhead. And no ARP.
 
You must log in or register to reply here.
Back
Top