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


  • 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.


    • Edited by BobH2 Monday, February 13, 2012 11:43 PM
    Monday, February 13, 2012 11:42 PM


  • After a few hours of reading through more RFCs and scouring the Internet:

    Both Microsoft and Cisco seem to still support Site-Local addresses (FEC0).

    Two excellent pieces I found are:

    It looks like self-assigned Unique Local IPv6 Unicast addresses are preferred (FD00)  for what I am aiming for. If I can get this implemented with some sort of NAT for IPv6 or Proxy to keep the internal network IPs private, then that might be a solution.



    is a download document entitled: Windows Server 2008 Introduction to IP Version 6. It states
    "Note  RFC 3879 formally deprecates the use of site-local addresses for future IPv6 implementations. Existing implementations of IPv6 can continue to use site-local addresses."

    Sounds vague, and has no time limit, so new installations could probably use it, but we do not know for how long. Probably no one does. To kill it, support would have to be removed from routers.


    Tuesday, February 21, 2012 12:35 AM

All replies

  • I generally use a randomly generated private address range ( You can always change it later. If the server's are all on the same vlan, then you won't have to worry about anything.

    Jason | | Twitter @JasonSandys

    Tuesday, February 14, 2012 1:53 AM
  • Jason,

    Thank you for the reply.

    That site and page generates a global IPv6. My understanding is that would make the IP routable to the open Internet. Would we not want Domain Controllers to ONLY be accessible in private LANS and VPNs, or am I missing something?



    Tuesday, February 14, 2012 5:20 PM
  • No, it generates a random private IP range. The bottom of that page explains it and gives links for further reading.

    Also note, even if you give give them a public range, they wouldn't be accessible to the Internet unless the routing was in place to route to them and you allowed them through the firewall. Not that I recommend you do this though.

    Jason | | Twitter @JasonSandys

    Tuesday, February 14, 2012 7:03 PM
  • Jason,

    I agree about the firewall. Unfortunately with this customer, one of the local staff has control over their routers. Their current routers don't support IPv6 but it looks like they are providing basic stateless stuff. Does Microsoft have a recommended IPv6 suggestion that uses only Link Local or Site Local static IPs?

    In the meantime, I've scratched my head, read a lot of the parrots' brains on the 'net and worked out my own "IP4 Lookalike Approach". (I apologize if anyone else thought if this first but I haven't been able to find anything covering this problem.)

    Basically, since FE8x: to FFxx: addresses can't make it to the public net, its safer to use these instead of 2xxx: IPs.

    If subnets are going to be used, or if they might be in the future, we need to choose a FEC0: to FEFF: IP and specifiy a subnet. I chose a global prefix of FEC0:0:0:1. This will correspond to a typical 192.168.1 subnet. FEC0:0:0:2 would be equivalent to 192.168.2 and so on.

    For the local net IP for an individual adaptor, we could convert to hex but that's just silly. Its too hard when you have do test pings all over the place. Since the entire range of 0 through 255 can be stated as hex anyway, then we just need to use the same text value. Using FEC0:0:0: just gets displayed as FEC0:0:0:1:C0A8:114 anyhow, which just simply requires too much head calculations to use practically (other brains may differ). This also make it easier to check IP network documentation, verify hosts files, etc.

    The following IPs demonstrate my point: -> :: (Don't know what the router's IPv6 IP is). -> FEC0:0:0:1::20 -> FEC0:0:0:1::200 -> FEC0:0:0:15::30

    Basic testing shows this is working ok with dual domain controllers. If I discover problems, I'll add comments.

    If anyone else can add some insights, it would be appreciated.



    • Edited by BobH2 Wednesday, February 15, 2012 11:23 AM
    Wednesday, February 15, 2012 4:01 AM
  • I thought FEC0 was depracated now and not recommended for use???



    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: and

    Wednesday, February 15, 2012 10:52 AM
  • Jason,

    Yep - Thanks for reminding me. I remember coming across that some time ago. But then I started going through Microsoft and other documentation that still lists it. Even Wikipedia still describes a subnet field.

    There is so much stuff out there now. All I want is a nice, simple way to set small networks up, be able to diagnose networks without long hex strings, be able to double check static IPs and find errors quickly, etc. For me, using long hex strings does not seem necessary.

    We don't have anyone with IPv6 routers/VPNs at this point, and the servers are always in the main office (except for some DCs), But I don't want to have to change this later.

    Came across RFC 4193 which replaces RFC 3879. It suggests using FC00::/7  instead and looks like it does subnetting similarly to IPv4. FCxx: is not yet deifned according to Wikipedia, but it looks like FDxx: is, thus the IPs from

    So, using this, my proposed approach could be made even simpler and easier to type by doing something like: -> :: (Don't know what the router's IPv6 IP is). -> FDDD:1::20 -> FDDD:1::200 -> FDDD::15::30

    I imagine subnetting would be accomplished by setting the prefix length to 16 in the router and the router would be able to route based on the second hextet.

    The only use for long, random hex strings that I can see would be in case two intranets were merged in the future. If this were a concern, then perhaps, subnetting using the 4th hextet should be used (FDDD:0:0:1::20) with a standard prefix length of 64.

    Any comments?



    • Edited by BobH2 Wednesday, February 15, 2012 1:17 PM
    Wednesday, February 15, 2012 12:40 PM
  • You are certainly free to use use whatever address range you want. As to not wanting to remember hex strings: don't. That's what DNS is for. Only crusty old *nix admins use IP addresses directly.

    And for subnetting, there's really no need with IPv6. It was designed so you don't have to subnet even the largest networks -- thus the normal use of /64 for the private ranges. As for possibly merging networks, yes, why wouldn't you do what you can now to avoid any issues in the future -- just use a random private address range and DNS.

    Jason | | Twitter @JasonSandys

    Wednesday, February 15, 2012 3:38 PM
  • Jason,
    I guess everyone comes at this from different points of view. And I guess, yes I do get crusty, and I could be considered "old". I never did like Unix, even when all the geeks were wearing "Sex, Drugs, and Unix" buttons on their lapels. I've had experience cutting and pasting software code the "real way" on paper tape using scissors and scotch tape (that was actually after pasting) generated by teletype machines; and Fortran on DG minicomputers, etc. I prefer GUI interfaces and consider this stupid trend to Powershell as retrogradely dumb.
    When you have branch offices with crappy Internet connections, it is not uncommon to NOT have DNS at the branches. I guess one way or the other, hosts might be registered. But when you are diagnosing things, you may not be able to rely on DNS or you may even suspect DNS, so going down to the lowest levels is necessary. Since it is so easy to make mistakes typing long hex strings, a short one is obviously preferable.
    Another one: the only way I can find to guarantee the use of a virtual NIC by a VM when a host has two NICs on the same subnet is by adding IPs to the hosts file. (I'm sure you know the two reasons why this is preferable.) Not sure how that's going to work with IPv6. Again, long hex strings are a nuisance to type and to check and to record in network documentation, or to tell someone over the telephone if they are onsite.
    I've done my share of reading on IPv6 and I must admit I am no expert. On the other hand, it is quite clear to me now, that a lot of the posts I've read recently are not written by experts either. I don't have time to become expert on IPv6 right now, and don't even want to. I just need some advice by someone that already knows.
    I guess IPv6 is still new, the technoclogies are not completely in place yet, and very few have real, full experience with it. And those that do are coming at it with their own point of view too.
    What I need is as follows:
    Microsoft DNS is giving me errors and insisting that I provide a static IPv6 address. My simple question is which IP do I use? How do I generate it? Can I design one that I can use easily for troubleshooting? Has anyone ever cared about it from that point of view?
    You know, years ago, there were a couple of golden rules in software development:
    1. Do not write or distribute anything that installs without having an uninstall program that works to go with it.
    2. Provide error messages that provide the action that was occuring at the time, and the reason (error code) for the error. If the message can not fully describe the error, add additional information in a help file.
    Microsoft is really not doing that these days and is wasting so much administrator time its ridiculous. We would not be able to get away with that with our customers, and its amazing to me that Microsoft still can.
    I'm starting to ramble a bit. If Microsoft says there's something wrong with their default setup of IPv6, then Microsoft should provide an explanation of what the problem is, and documentation on how to fix it. Microsoft is not doing that these days, and instead, is making us go through support sites with really crappy search engines to find answers. And that is precisely why you are answering questions, and I was hoping, as the substitute for proper Microsoft documentation, that you, or someone there, CAN provide a reasonable, well thought out, practical solution. If not, there has to be someone at Microsoft that understands this stuff, and understands why simple is better than complex, and could spend a day or so to write up a comtempoary, practical way of doing this, using current thoughts on how IPv6 is going to progress, even if he/she has to include some caveats about what might change in the future. Discussing the pros and cons of simple vs. complex IPv6 IPs would be fantastic. Then publish it in an easy to find place as an "official" Microsoft suggestion, so all of us can implement a quick solution that might stand the test of time, rather than spend several days trying to figure out which "expert" to believe.
    If you can see it from my point of view, and suggest an alternative, great. Otherwise, I will experiment a little more with my approach and probably your suggestion.

    Wednesday, February 15, 2012 11:11 PM
  • I am still looking at this when I have some moments. Still can't find anything definitive.

    On one of my customer's machines, with dual NIC, I only have DNS defined (using IPv4) on one NIC. On the other, it looks like something has automagically added:

    Looks like this was originally descibed in:
      http: //

    And adopted by Microsoft at one point for W2K3:

    My asumption is that this has remained as part of W2k8-R2. If so, then at some point in Microsoft, someone was thinking about using a subnet of "0000" as the main, default, IPv6 IP for a DNS. This is starting to look like a recommendation - one that is a little old and not fully documented.


    Sunday, February 19, 2012 5:32 PM
  • After a few hours of reading through more RFCs and scouring the Internet:

    Both Microsoft and Cisco seem to still support Site-Local addresses (FEC0).

    Two excellent pieces I found are:

    It looks like self-assigned Unique Local IPv6 Unicast addresses are preferred (FD00)  for what I am aiming for. If I can get this implemented with some sort of NAT for IPv6 or Proxy to keep the internal network IPs private, then that might be a solution.



    is a download document entitled: Windows Server 2008 Introduction to IP Version 6. It states
    "Note  RFC 3879 formally deprecates the use of site-local addresses for future IPv6 implementations. Existing implementations of IPv6 can continue to use site-local addresses."

    Sounds vague, and has no time limit, so new installations could probably use it, but we do not know for how long. Probably no one does. To kill it, support would have to be removed from routers.


    Tuesday, February 21, 2012 12:35 AM
  • 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 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:" 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.

    • Proposed as answer by Inkreel LLC Saturday, August 30, 2014 2:52 AM
    • Unproposed as answer by Inkreel LLC Saturday, August 30, 2014 2:52 AM
    • Proposed as answer by Inkreel LLC Saturday, August 30, 2014 2:54 AM
    • Edited by Inkreel LLC Saturday, August 30, 2014 3:31 AM
    Saturday, August 30, 2014 1:31 AM
  • Hi BobH2,

    I administer several Windows networks throughout Florida for various businesses.  Some networks are larger AD networks with multiple DCs and DNS servers in Sites with unique subnets distributed across multiple satellite networks throughout the state, connected with IPSEC tunnels to each location, and other networks as simple as a Single Site AD Domain with all computers connected to the same local network.  I have a firm understanding of the workings of Active Directory and DNS utilizing IPv4 addressing, and up to now have been muddling my way through the addition of IPv6 and working my way around it to keep my distributed networks communicating, DNS servers updating and DC's replicating from site-to-site.  But as IPv6 becomes the more dominant protocol specification, I am starting to devote my time attempting to understand how to specify a non-random IPv6 implementation to not only make it work correctly, but to indeed take advantage of the benefits of this newer specification.  My quest started fairly recently, and I used to disable IPv6 on my networks to keep DNS and AD replication tied to IPv4 specifications, which was always easy to design and keep running efficiently.  But now it seems that regardless of whether I have static IPv4 settings with hard-coded DNS specifications on an Ethernet adapter, the IPv6 settings obtained by DHCP on that same adapter supersede all else when resolving DNS on the network.  Like you, I am looking for an easy, correct way to implement and specify IPv6 across my Windows Domains so that when computers attempt to resolve my domain resources in DNS via their IPv6 specifications, they don't receive incorrect or unusable IPv6 information that kills the performance of my network.  And forget about Reverse Lookup Zones resolving IPv6 addresses correctly in Windows DNS Servers...  

    I know this post is several years old at this point, but I found your posts and questions well thought out (Inkreel LLC's post too), and nearly identical to my own questions.  I have made note of every linked resource in the posts on this page, and plan to continue my education by investigating each of them.  But I had to attempt to reach out to you to ask if you had found an acceptable approach to implementing IPv6 in Windows Domains, and if you would kindly share that information with the rest of us who find this page still relatively high in our Google searches.  I am starting to implement and migrate my AD Domains to virtualized environments, and I feel that IPv6 should be as familiar and welcome as IPv4 by now, and I am trying to find a concise, logical way to deal with IPv6 in order to make it as reliable as IPv4.  I would appreciate any guidance you or anyone reading this could give me, whether it is pointing me in the direction of official recommendations, or sharing their experience of how they made sense of IPv6, and what was done to make it play nice with Active Directory and DNS.

    Thanking you in advance, and hoping to get some kind of response that is as intelligible as BobH2's previous inquiries..

    - Jim - BuckeyeNut74 - BuckeyeTek

    Sunday, September 4, 2016 10:24 AM
  • This is a very old post, but I have just found it while searching for the same issue.

    In the end, I designed my own scheme which is like:   --> fd00::192:168:12:1 --> fd00::192:168:12:33

    This is current standards compliant, using ULA private addresses and not site-local deprecated addresses.

    It can be easily read and remembered by those with IPv4 experience.

    For a simple network this should do the job, while for more complex internal networks, the ULA address ranges could be generated at or

    On a related note, I had a  hard time figuring out why Windows DHCPv6 Server configured as stateless would not provide options 0023 DNS Recursive Name Server IPv6 Address List and 0024 Domain Search List.

    The trick is to set static IPv6 address different than the SLAAC generated IPv6 addresses on the DHCP server. It can be checked if the static IPv6 configuration is correct by looking at the Connection and server bindings for IPv4 and IPv6 on the DHCP server.

    Sunday, June 4, 2017 1:08 AM