I should write up my concept for IP. This is literally stuff I dream of!
This is totally "if I had a time machine and could fix IP at the start" and very much not a "this is what we should move to". The time taken to get IPv6 deployed (over 50% in US now) shows this would never fly.
So my ideas is this...
IP addresses would have multiple levels, tagged at the binary level in some way to allow each level to be different number of bytes, and allow for multiple levels - perhaps top two bits say length of each level. The exact detail on this is not that important other than the fact it is "variable" in some way and a fixed pattern for any IP address to allow hardware to cope. The displayed format is not that important either, but probably a series of decimal numbers with a separator.
The top level of any target IP would be AS number. This is still routing packet by packet, not session routing. So an ISP level core router needs a simple top level binary decisions, is target outside our AS (so send to target AS) or within (so send to next level at byte X in packet). Yes, a router could have more than one role as more than one AS maybe, but in general it is simple. This is the sort of thing that can work at a hardware level in ASICs without too much issue. A CAM at top level for sending to AS and a CAM for "within my network (AS)" level.
Routers below this level are similar - "is it my network" do routing to "next level", or I send "upstream".
The basic idea is that you have a simple routing decision at any "level" and when it gets to that party, an AS, and end user, etc, they have choice how they want to route and assign addresses.
The concept is that the IP would actually go in levels from AS, to areas within an AS (if needed), to customers, to devices on customer networks, and even include "port" within the device. No need for NAT ever. Ultimately extensible at ISP or customer or network level and even within device to allow more ports (which can be an issue). Some limit on levels, and bits at each level, but more than enough.
Yes, TCP and UDP would change to not have a port where it is now, but part of the IP addressing.
As for allocation and RIRs, the allocation would be AS, and anyone with an AS controls as many IPs within that as they need.
Also, the session connection to a device would be a protocol in itself, for things like TCP (maybe even UDP and others), where the connection is to the device IP address (not a port level) but the payload includes a text port name. So https would be to port "https" not port 443. The reply would confirm the actual target IP (which includes port ID) to use for that connection. This allows target port to be unique without mapping the source IP/port and target IP/port normally needed to identify TCP socket within a device, even as a server. So simpler code (yes, check the IP/ports are right when you match it).
I also think that, unlike IPv6 which has a separate standard header for encryption (which therefore does not actually work for TLS we have now) I think TLS would be an option in the that SYN, along with port name. So port "http" can request TLS or not as a standard start of that session, with things like "use previous authentication session" as an option at the SYN level for faster connections. Ideally the application calls for TCP would make it very simple for any stream to be TLS or not with minimal coding overhead.
Multihoming at TCP level
Also, you need protocols like TCP to be multi-homed at the TCP level. Mobile phones can already do this to some extent. Connect to a name, not an IP, and it has multiple IPs, but allow the IPs to change during the session if needed, either end, as part of the connection protocol. This avoids the need for multihoming at the BGP level, and IPs can start with AS at a top level regardless.
No, not "IP is the route" - still routing path redundancy
Just to be clear, this is not saying the IP is the route to the end point, either. The route taken would be determined by routing protocols like BGP, and still have the alternative paths and redundancy that exists now to get to an AS, and within an AS. The only really difference is that core routing policy would almost certainly not allow announcements below the AS level, and hence keeping routing tables smaller. At present IPv4 does not work (by policy) smaller than a /24, for the same reasons. This just makes a really simple and obvious policy as the inter-AS level. It also means each AS only needs to originate one prefix (their AS) where as now they originate loads of separate blocks. That one prefix is extensible as much as they like. Indeed, the role of RIRs for IP management would pretty much vanish as having an AS would entitle you to allocate IPs under that AS, and originate routing for those IPs from that AS.
Comments and discussion welcome - but remember this is essentially just a thought exercise.
This idea is still per packet - a totally different approach involves a connection based system. Establish a route over the internet as you connect and each point reports the connection id, and at the start you send to the local connection ID which is mapped to next hop connection ID. It could work but is a massive amount of "state" in the core, and I don't think a viable approach. Sorry.