What is the most appropriate way to generate a static IPv6 for a domain controller?

Question

DNS Role Best practives is giving errors. Looks like I need to assign ONE static IPv6 to each domain controller and use IT in DNS and DHCP. There are two routers on the network, each assigning a 2002: IP, plus a link local FE80: IP is also assigned.
Is there a way to generate a static IPv6 for domain controllers that will not change even if the network cards or routers are changed?
What is the best practice so that domain integrated DNS and DHCP with Exchange 2010 in the domain, will continue to function?
There is ambiguous information as to whether DC's should have static or dynamic IPv6 IPs. I have tried variations such as IPv4 compatible. IPv4 mapped, ISATAP, etc. but over time have gotten different errors from different sources.
It is one thing for Microsoft to give error messages about IPv6 but I cannot find any definitive recommednations on this.
Thanks if anyone finds a universal answer.
Bob.

Answer 1

Excellent and valid points, Bob. Your outlook explains in an easy way how the challenges setting up Windows Server are in a sense, self-generated, and in every sense fully avoidable.
No changes have been made to the warnings or errors in 2013 R2 despite improvements in other areas. This release mainly brought improvements to the setup in areas that were truly broken like automatic account generation for ADFS. Since that's a decade old
feature it's probably best not to wait for Microsoft to clarify, and I appreciate your recommendations.
I'm bumping this thread since it's the first result for 192.168.1.1 on ipv6 on Google right now, and since there's no way to see how often it's being referenced I wanted to add some additional information.
Multiple NIC's can be specified by using the scope ID parameter supported since Vista, that appears as a percent-sign at the end of IPv6 addresses. It uniquely identifies the network adapter even when that adapter shares the same host portion of the IPv6
address space (i.e. essentially, has the same IP, which in IPv4 is invalid.) I'll give some examples at the end of the post.
Following the recommendation to deprecate the fec0 prefix while maintaining a link-local addressing scheme is possible through the prefix length at the beginning of the IPv6 address. As
this reference at IBM explains, fe80:: maps to a link-local prefix length of 64 equivalent to the IPv4 version of 24, and anything else before the double-colon refers to the network portion of the IPv6 address.
The host portion of the IP address then _could_ be ::20, ::21, etc., as you said, but to follow
this MSDN recommendation, it would be more appropriate to use the same host portion and add a suffix for the scope ID documented on that page. The suffix may be specific to Windows
and may not work in an equivalent way in heterogeneous platform deployments. But since the effect is limited to the local machine it should help anything past XP differentiate NICs when assigned the same host portion.
The approach taken in the random IPv6 generator linked elsewhere on this page leaves open the possibility, however unlikely, that the generated IP can route to some other host on an open network that happens to have generated the same network portion of
the address (the other host would be sharing the same network.) If any part should be random, it's the host portion after the double-colon, not the network portion at the beginning, so that the possibility does not exist.
Additionally, the host portion doesn't have to be random, it's just done that way because it's usually automatically generated; a random number is safer for a computer than relying on a sequence that may not fully cover all the numbers used so far. If you're
doing a manual deployment you can combine the above information with the inline 0-supression in IPv6 to assign numbers in the following way:
fe80::1:1%1 (first computer is 1:1, first interface is %1)
fe80::1:1%2 (second interface)
fe80::1:2%1 (second computer, first interface)
Effectively here we're swapping "192.168.1" for "fe80::1" which is roughly the same length (taking into account variations like 10.0.0). The only gotcha is that _either_ the string after the double-colon can't be 1 by itself since that's
reserved for local machine loopback, _or_ that the second-to-last number after the double-colons can't be 0, since that's equivalent due to inline supression.
Other combinations are fine, like fe80::2%1 and fe80::2%2 for the first computer, then ::3 for the second, etc. I thought having a 2-index for the first machine is too uncommon to look familiar so I chose the alternative, but even something like fe80::fe%80
is perfectly fine.
If you don't need to identify individual NICs then omitting the part after the percent sign makes fe80::10, fe80::11 a valid sequence for 2 computers. For over 255 computers just add another number before the last, so that it looks like fe80::1:10, fe80::1:11,
etc. That should be easier to remember than the randomly generated numbers.
There is also another way if the preference is to use IPv4-lookalike addresses. The mapped address spec is defined in RFC 4291 and it goes along the lines of "::ffff:192.168.1.1" for a valid IPv6 address to the gateway, for example. That is a newer
recommendation than the RFC which the random-number generated linked elsewhere on this page relies on.