Unable to GetUnicastIpAddressEntry after CreateUnicastIpAddressEntry

Question

Background: I am trying to get up to speed on using RFC7217 compliant ipv6 addresses. To that end I have written code that creates a valid route-able ipv6 addre

Answer 1

What Works Now:

After fixing the sample code for CreateUnicastIpAddressEntry I was able to install a generated ipv6 slaac ip address in the windows internal ip addresses table on a PC. There were then two ways to prove its existence: run the GetUnicastAddressEntry sample code which I was having problems with, or simply run the application to see if the bind() and listen() now worked. I did the latter and observed, using netstat -a, that the RFC7217 generated address did indeed appear in the readout as a listening socket.

Note To Other or Future RFC7217 IPv6 SLAAC Implementers:

I had a problem with understanding what the Global Routing Prefix was, since RFC7217 did not define this. Here is the correct diagram for an ipv6 slaac address:

|<----------Global Routing Prefix---------->|<--------Interface------------------------>|
| 001 |<----45 bits---------->|<--16 bits-->|<-----------64 bits----------------------->|
|<--Internet Routing Prefix-->|<-Subnet ID->|<--------Interface ID--------------------->| 

I say correct because finding out what the correct format of the Network ID that RFC7217 expected, was a problem. For that, I went to RFC3587. But there was a format error in the standard, which lead to an errata concerning the Global Routing Prefix diagram. Note that in addition to implementing the Interface ID which RFC7217 covers, you also ought to implement the 16-bit Subnet ID which RFC3587 describes as this: The subnet field is designed to be structured hierarchically by site administrators. However, using the entire 64 bits of the Routing Advertisement's (RA) prefix seems to work just fine. 7217 says you can either use an RA's prefix or Linked Local, depending on your app I presume. I used the RA because I wanted my resulting ip addresses to be globally routable.

Current Limitation:

Currently, Microsoft requires that the CreateUnicastIpAddressEntry API call be executed with administrator privileges. In the Microsoft's Developer Community I have made this request: Call the CreateUnicastIpAddressEntry function as user instead of as administrator. I think the words site administrator have confused Microsoft into thinking that the administrator privilege is necessary. IMO it is not and presents an undue and clumsy burden on the end user.

Other RFC7212 IPv6 SLAAC Windows C++ Implementations:

To my knowledge this is the first windows implementation.

Conclusion:

Without an ability to distribute ip address generation (read: wrest prefix delegation from the ISPs), there is no way to implement real distributed decentralized applications with self-owned nodes. With this capability implementing DApps becomes possible. With privately generated Global Unicast IP Addresses one will no longer have to let his or her data or keys of any kind be copied into centralized platforms. Implementing RFC7217 fixes this internet issue.

Lastly, IPv6 pundits currently believe all IPv6 addresses need to be delegated from your ISP. This is an unfortunate misconception since it inherently limits the distributed-ness of resulting downstream applications. This windows implementation proves otherwise.