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.
More ports
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.
Alternatives rejected
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.
So the IP address would be formed by the route to get to the host?
ReplyDeleteNo, not really. This would not tell you how to get to an AS. That would still be by BGP. And the routing within an AS is up to the AS to manage, probably using routing protocols as now. No real change at all. I suspect transit providers would have policy of AS announcing only at the AS level much like they don't allow IPv4 smaller than /24 now, though routing protocols would allow it. Where an IP to an end user is dynamic, then within an AS the routing could literally be to which endpoint and have a section of the IP that identifies the port directly, but that has been done with IPv4 as well. So not a real change to how that all works apart from possibly simpler policy to keep core routing tables sensible (as now).
DeleteHow would multi-homing work, if the IPv8 address embeds the AS in it?
ReplyDeleteThat's the point at the end - it would allow multiple routing and redundancy to an AS and within an AS, but not multiple AS multi-homing. The idea being that instead of IP/AS level multihoming you have TCP/DNS level with seamlessly handling talking to multiple IPs on each end of a connection, which can be different AS/IP routes to same machine.
DeleteHow would Anycast and Multicast work in this structure?
ReplyDeleteWell, the BGP level can work the same as now. I suspect some special any cast such as root servers would be their own AS, injected in BGP in multiple places. But even lower levels than AS could be accepted in core routing for special cases anyway. This does not fundamentally change the logic of BGP, just steers policy so most ASs announce that one prefix only.
DeleteIf you moved your independent IP addresses to a different AS, would that ultimately change the addresses themselves?
DeleteBit of an arse for DNS.
PI would not exist like it does now, but you could have independent (and movable) addresses if you had an AS. Indeed, that was be a way to be multi-homed in much like the current sense. But DNS and DHCP remove the need for portable addresses mostly.
Delete