背景：我正在尝试加快使用RFC7217兼容ipv6地址的速度。为此，我编写了创建有效的可路由ipv6地址（如2600:8806:2700:115:c4a3:36d8:77e2:cd1e）的代码。我知道我需要先在Windows中输入新地址，然后才能bind（）到它。我认为这两种方法可以解决问题。因此，使用我的IP地址之一，我执行了CreateUnicastIpAddressEntry中的示例代码。然后，使用相同的IP地址，执行在GetUnicastIpAddressEntry中找到的示例代码。
问题：
我希望再次获取IP地址。相反，我得到了[[ERROR_NOT_FOUND（2）。
分析：
我知道IP地址正在进入系统，因为如果我第二次使用相同的IP地址运行CreateUnicastIpAddressEntry，则会得到ERROR_OBJECT_ALREADY_EXISTS。问题：
在这两种ip方法中有经验的人在这种情况下是否知道此错误代码的含义？对于这两个Windows ip方法，输入并返回相同的IP地址是否合理？]CreateUnicastIpAddressEntry的示例代码需要做一些工作，因此，如果有人想尝试，可以将我的更改及其上载到某个地方。 GetUnicastIpAddressEntry示例代码几乎立即可用。
现在有效：
为CreateUnicastIpAddressEntry]修复了示例代码后，我能够在PC上的Windows内部IP地址表中安装生成的ipv6 slaac IP地址。然后，有两种方法可以证明其存在：运行我遇到问题的GetUnicastAddressEntry示例代码，或者仅运行应用程序以查看bind()和listen()现在是否正常工作。我做了后者，并使用netstat -a观察到，RFC7217生成的地址确实确实在监听中显示为侦听套接字。
对其他或以后的RFC7217 IPv6 SLAAC实施者的注意：
我在理解Global Routing Prefix时遇到问题，因为RFC7217并未对此进行定义。这是ipv6 slaac地址的正确图表：|<----------Global Routing Prefix---------->|<--------Interface------------------------>|
| 001 |<----45 bits---------->|<--16 bits-->|<-----------64 bits----------------------->|
|<--Internet Routing Prefix-->|<-Subnet ID->|<--------Interface ID--------------------->|
我说正确，因为找出RFC7217期望的网络ID的正确格式是一个问题。为此，我去了RFC3587。但是标准中存在格式错误，这导致了关于。但是，使用路由广告（RA）前缀的整个64位似乎很好。 7217表示您可以使用RA的前缀或“链接的本地”，具体取决于您假定的应用程序。我使用RA是因为我希望得到的ip地址可以全局路由。Global Routing Prefix图的勘误。请注意，除了实现RFC7217所涵盖的Interface ID之外，您还应该实现RFC3587对此描述的16位Subnet ID：子网字段旨在由站点管理员分层组织。
当前限制：
[当前，Microsoft要求使用CreateUnicastIpAddressEntry特权执行administrator API调用。在Microsoft's Developer Community中，我发出了以下请求：以用户身份而不是以管理员身份调用CreateUnicastIpAddressEntry函数
。我认为站点管理员一词使Microsoft误以为管理员特权是必要的。 IMO并非如此，并且给最终用户带来了不适当的笨拙负担。其他RFC7212 IPv6 SLAAC Windows C ++实现：
据我所知，这是第一个Windows实现。结论：
没有分发ip地址生成的能力（请参阅：ISP的wrest前缀委托），无法使用自有节点来实现真正的分布式分散式应用程序。利用此功能，可以实现DApps。使用私有生成的全球单播IP地址，人们将不再需要将其数据或密钥复制到集中式平台中。实施RFC7217可解决此Internet问题。最后，IPv6专家目前认为，所有IPv6地址都需要从您的ISP委派。这是一个不幸的误解，因为它固有地限制了最终下游应用程序的分布范围。该Windows实现证明不是。