I do not want to seem to be ganging up on you, but your reply to Mr. Hain just prompts more questions.
You might have to explain this really often and in simple language too. But why do you assert that it will take lots of complexity and overhead? Can you point to some code where they tried this? As far as I know, nobody has really given this an earnest try as yet. At least not with any IP protocols.
You are missing something fundamental here - if a TCP connection breaks (isn't closed cleanly) then the two endpoints can get out of sync regarding how much data was delivered. You can't fix this at higher layers without an unacceptable amount of complexity and overhead. This has nothing to do with the app/transport interface being a sacred invariant - it happens any time you try to layer something on top of transport that has to survive breakage of the transport layer.
(how many ways do I have to explain this?)
It's a lot less glue than the L4-L7 approach, and most of it has to deal with authentication that would be needed for any kind of remotely-originated routing update anyway, regardless of what layer it lived at.
What specific glue do you believe it requires for the L4 to L7 approach? How does that compare to what is needed in an L3 solution?
Yes you can do that but it presumes that the host knows a priori whether or not it needs the stabilization layer. I would make the mechanism used to provide stable addresses a property of the network- either the network provides "reasonably" stable addresses (i.e. plenty of prior notice before changing them) or it provides a stabilization layer. That way, networks that don't need it don't pay the overhead.
But I would argue that the host or at least the application's designer knows whether it will need the stabilisation layer. Making the mechanism that provides the stable network addresses a property of the network leaves the question of how. Even if that were achieved though, that still does not completely or effectively address the problem of one application process identifying its peer across the network.
Yours sincerely, Robert Honore.
