I would give an answer of "no, but it is remarkably similar."
Here's some history and a largely complete explanation.
Circuits 101
Information networks can route traffic, basically, in terms of circuit switching or in terms of packet switching. Circuit switching offers many more guarantees than packet switching, but this comes at a cost, and so circuit switched networks can't degrade gracefully. The classic circuit-switched network is the PSTN, and a virtual circuit would be something like a DS0 on the PSTN.
A DS0 basically works as part of a bundle of connections, usually in a DS1. In a DS1, you will have a bundle of DS0's which are transmitted together, frame-by frame in time-division manner, so each DS0 is guaranteed a specific bandwidth, timeliness, etc. by the underlying network transport.
Another way to look at this is that a physical circuit would be something like a cat6 cable running between two terminals. You can send data back and forth over the wires at guaranteed speeds, and no other communications are going to interfere with that. Indeed the early telephone networks worked by connecting physical circuits (that is copper wires) using manual or electromechanical switches. As this was computerized, the circuits were virtualized and digital (as opposed to analog) information was sent down wires on a time division basis again with a circuit reserving a slot in the time division schedule.
What this means is that circuit switching is more about bandwidth reservation than it is about routing. The former leads to the latter. I.e. a circuit reserves bandwidth for the entire connection.
Why TCP Connections are not Virtual Circuits
TCP/IP is fully packet-switched. It makes no provisions for virtual circuits. This is why things like QoS are often necessary when trunking VOIP (a virtual circuit has built-in QoS guarantees). You have no guarantee that all packets will be routed alike. They may not come through in the same order. They may not come through in a timely manner (from a connection-oriented perspective). So you can't really build virtual circuits per se on top of a packet switched protocol like IP.
TCP comes somewhat close and in fact can work as a somewhat imperfect substitute. It offers as many of the guarantees as it can. This is why, when implemented on TCP/IP, H.323 uses TCP connections instead of the virtual circuits the protocol prefers.
But TCP connections still aren't circuits, because they don't reserve bandwidth during connection on every switch between the two nodes.
Of course TCP connections are more than just datagrams. They include routing information (as does UDP) but they also include the accounting information necessary to reconstruct the stream on the other side in order.
The Answer
Both TCP and UDP are datagram protocols. They send a packet of data with routing information to routers with none of the guarantees of that a circuit offers. TCP offers a subset of guarantees on the end points of what a circuit would offer by adding accounting information to allow the end points to handle errors and a series of data in order, but it is only a subset. Of datagram protocols, TCP is the closest thing one will find to a virtual circuit but it is still conceptually and operationally very different.
Assuming you mean to protect confidentiality of the communication at IP layer with IPsec:
How would the underlying network be able to differentiate between UDP
and TCP since they're at the transport layer.
The next header field of the ESP header tells you the type of payload.
If you use tunnel mode (which is custom for VPNs), then without the necessary keys you cannot decide what's at transport layer because the next header field will tell you just that there's a whole IP packet encapsulated.
If you use transport mode, then the next header field tells you the type of payload at transport layer.
Will we still have TCP and UDP when we move the IPv6(Although I see
that IPsec has been made optional for IPv6)?
TCP and UDP are agnostic to the layer-3 protocol. In fact, TCP and UDP (and SCTP and DCCP) exist also for IPv6.
What seems to puzzle you is that in IPsec tunnel (VPN) mode there is no way to inspect the content. This is supposed to happen at the tunnel end-points. An organization that is worried by this loss of control should not allow IPsec that is not under it's own control.
Further reading: An Illustrated Guide to IPsec
Best Answer
You asked a good question. Don't let anyone tell you otherwise.
Regrettably, there is no rule of thumb for the types of protocols that use TCP verses the types of protocols that use UDP.
The decision whether a protocol uses one or the other come down to whomever wrote/created the protocol to begin with.
If they didn't want to bother with writing their own "reliable delivery" system, then they can simply use TCP which provides all the reliability innately.
If they thought (knowing their own protocol innately) that they could write a better or more appropriate "reliable delivery" system, then they can build that into the protocol itself and simply use UDP as their transport.
As an example, take a look at a UDP TFTP sample capture, you'll notice there are built in acknowledgement systems within TFTP itself -- having both those and the additional acknowledgement systems within TCP would simply be redundant.
Whereas FTP, which runs over TCP, does not have a built-in acknowlegdment system. A user simply request a file, and the sender sends it. There is a "file transfer complete" notification, but nothing that guarantees having received each bit of the file. FTP is relying on TCP's reliability to ensure the file gets all the way across.
That said, I looked through the list of ports on the wiki page you linked, and saw a surprising amount of protocols that supposedly use TCP and UDP. This was foreign to me, and I only know of very few that use both (namely, DNS). But it may be that there is a TFTP implementation that uses TCP, and if so, I'm afraid I have no exposure to it.
Domain Name System (DNS) is traditionally the protocol referred to when discussing protocols that use both TCP and UDP. It doesn't use these at the same time, mind you. But different functions within DNS might call for TCP vs UDP.
For example, when making a simple A-record resolution request, the "request" and "response" are very lightweight, both requiring a single packet. As such, this is typically done over UDP.
But if a request or response requires a larger transfer (above a certain amount of bytes), then DNS chooses to use TCP to ensure "all the bits" get there. This is common with full Zone Transfer requests.