Answered by:

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.

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.

All replies

I generally use a randomly generated private address range (http://www.simpledns.com/private-ipv6.aspx). 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.

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?

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.

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 xxx.xxx.xxx.XXX 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:1.192.168.1.20 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.

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 http://www.simpledns.com/private-ipv6.aspx.

So, using this, my proposed approach could be made even simpler and easier to type by doing something like:

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.

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.

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.

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:
fec0:0:0:0:ffff::1%1
fec0:0:0:0:ffff::2%1
fec0:0:0:0:ffff::3%1

Looks like this was originally descibed in:
http: //tools.ietf.org/id/draft-ietf-ipngwg-dns-discovery-03.txt

And adopted by Microsoft at one point for W2K3:
http://technet.microsoft.com/en-us/library/bb727009.aspx
http://technet.microsoft.com/en-us/library/cc758118(WS.10).aspx

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.

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.

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:

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.

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.