Earlier quoted context omitted.
> Even just a host identifier, in lieu of the IP address of an interface, being used in the TCP tuple would have been so much better What are you imagining as the implementation? Is it just in TCP, and IP (/ the network) is unchanged? I can see the benefit of that, but then there still needs to be some mechanism to change the binding of host->IP. And if it's not part of the core network, then it's not straightforward…
> What are you imagining as the implementation? I haven't thought about it hard enough to be doing anything besides spouting bullshit. It's one of those lazy "I don't like what we've got but I can't say what we should have" kind of complaints. The way SCTP handles multi-homing and failover with the verification tag is what I guess I'm thinking of. I'm a little enamored with SCTP, admittedly, and I'd rather we were us…
Developing on that last bit I threw out, especially since you're lamenting the non-adoption of SCTP. With the retrospective from NAT, it feels like it would have been good to factor out the "port" part of TCP/UDP and put it in the IP header instead ("flow ID" or something). Then define (saddr, daddr, protocol#, flowID) as a "flow tuple" for middle boxes to operate on. TCP/UDP/SCTP could then define and present those bits as port numbers.
This could even be size-negative if you threw out that whole fragmentation thing in favor of completely punting it to a higher layer instead.
(I realize this goes against the end to end principle and strict layer separation, but the fact is that despite the goal, middle boxes are mucking with packets, and when that mechanism cannot be prevented, facilitating it would be better for maintaining flexibility)