请去掉‘身份验证’部分，只讨论加密部分！（身份验证是另一个问题。）
例如：连接到http://ipv6.google.com可以通过 HTTPS 加密，如下所示：https://ipv6.google.com/（如果您没有 IPv6，您可以尝试 IPv4：https://www.google.com）
是否有可能对网络服务器和浏览器进行编程以支持例如
http-over-ipsec://ipv6.google.com
作为 https 的更好、更安全的替代品？
答案1
加密的问题不在于协议（无论是 SSL、TLS 还是 IPSec），而在于引导。SSL 和 TLS 依赖于可信的（对于“可信”的某个值）第三方，这些第三方会证明某个加密密钥属于某个网站。否则，我们如何知道我们是否真的在与正确的服务器通信？连接可能会被劫持。身份验证始终很重要（对于客户端验证服务器而言，有时对于服务器验证客户端而言也是如此）。没有身份验证任何人可以声称是 ipv6.google.com。
随着 DNSSEC 支持的不断增加，我们获得了更好的引导选项：DANE（RFC 6698）和 DNS 中的 IPSec 密钥（RFC 4025）。它们都使得使用 DNS（必须使用 DNSSEC 确保安全）来引导加密成为可能。DNS 会告知客户端将要使用的证书，我们不再需要依赖第三方。
确保 DNSSEC 得到广泛部署，这才有可能。否则，我们将陷入当前复杂且昂贵的第三方证书颁发机构系统……
答案2
不，IPsec 不能也不会取代 HTTPS，因为它们实际上是苹果和橘子，原因如下：
IPsec 在网络层运行，并通过 IKE 明确协商 - 两个端点必须就密钥方案、操作模式和许多其他参数达成一致，然后将这些参数安装到负责 IP（v6）堆栈的任何内容（通常是操作系统的内核）中。
*IPsec 旨在长期保护整个通信渠道（或多个通信渠道），而不是简单地建立一个简短的会话、交换数据然后拆除它。
因此，IPsec 根本无法很好地适应 HTTPS 通常经历的那种生命周期（即重复的、短暂的连接），更不用说它明确依赖于 IP 堆栈本身这一事实，这使得在应用程序内实现它既有问题又存在安全问题，因为 IPsec 参数的配置通常是需要 root/管理员访问的特权操作。
另一方面，HTTPS，更具体地说，SSL/TLS 在应用程序（例如您的 Web 浏览器）具有预定义的授权机构列表的基础上运行，它信任这些授权机构来签署服务器加密证书。
正如另一个答案中提到的，虽然 DNSSEC 可以很好地用于引导 IPsec，但这已经完全可以用于 TLS，并且确实已在 IETF 中编纂为RFC6698。