ASUS RT-AC68U

[mlane]

First...

I'm a first timer for IPv6.
Searched this forum for this router, didn't find anything.
I read the "Asus RT-N66U - TunnelBroker support built-in" thread.

I have:
Bright House ISP.
They don't do IPv6. (And their customer service is a joke.)
I have a static IPv4 address w/them and a cable modem. Modem connects to new RT-AC68U.
RT-AC68U is hardwired to a couple of machines (Linux, Win 7, VMware hypervisor, VMs, etc) and there are wireless connections to a variety of device types.

I want to use the Win 7 machine as the guinea pig.

Overall goal:
Get as many of these machines and devices visible to the outside world as possible. I understand the need to secure each one of them since the de facto security of NAT goes away.

During the tunnel creation, I got 'ping doesn't work' and fixed that. As far as I can tell, ping should be working for the IPv6 part of the router as well.

I've configured the router's IPv6 page per the post on the RT-N66U unit using 'Tunnel 6in4'.

(Is it a security breach to post address specifics here?)

I can't seem to verify any sort of IPv6 connectivity. Part of the problem is I'm not sure how to do that.

I also have questions about the Win 7 setup:

   world -> HE -> my router -> Win 7 machine

For IPv4, the Win 7 machine is 10.0.8.20 and it's protected by virtue of NAT with no port forwarding active.

Do I make up an arbitrary new IPv6 address for the Win 7 machine using prefix I was given and set the gateway to the router's IPv6 address? The DNS seems pretty straight forward.

Thanks for your time

[kasperd]

I've configured the router's IPv6 page per the post on the RT-N66U unit using 'Tunnel 6in4'.

That part appears to be configured correctly.

Is it a security breach to post address specifics here?

No. Often the addresses of the router can be looked up anyway. I found the v6 addresses of your router (both the tunnel interface and the LAN interface). In your case the v4 addresses of the router are not immediately visible, so those you could probably hide, if you want to.

But attempting to keep IP addresses secret is not the most efficient way to keep your network secure. That time is better spent ensuring each device is properly secured. However I didn't manage to guess any IPv6 address on your LAN other than that of the router. And scanning an entire /64 is not feasible. So a device, which has IPv6 connectivity on the LAN, but doesn't communicate externally, can remain pretty well hidden.

I can't seem to verify any sort of IPv6 connectivity. Part of the problem is I'm not sure how to do that.

There are webpages designed to help you with that. Jason Fesler has one on http://test-ipv6.com/ and I have created a different one on http://test-ipv6.netiter.dk/

Do I make up an arbitrary new IPv6 address for the Win 7 machine using prefix I was given and set the gateway to the router's IPv6 address?

If you have enabled router advertisement on the LAN interface of your Asus router, it should all happen automatically. You don't need to assign an IPv6 address to each machine manually. It is quite possible your windows machine already has an IPv6 address, we just don't know what it is. When you look on your own posts on this forum, you should be able to see which IP address you connected from. Was your previous posting send over IPv4 or IPv6?

The DNS seems pretty straight forward.

You may have been lucky. There is a lot of different ways it can be done and multiple pitfalls. But if your current settings work to your satisfaction, you don't need to change anything.

The configuration of DNS on each machine could be done manually, but it can also be done automatically. There are two competing methods for automatic configuration of DNS servers on IPv6. If a machine uses automatic configuration of DNS servers, how does it decide which to use when it has received one set of IPv4 DNS servers through DHCP and two sets of IPv6 DNS servers through RA and DHCPv6? Does it default to IPv6 and fall back to IPv4 or vice-versa? Or are there three different daemons overwriting the DNS configuration with alternating contents?

If the router advertise DNS servers to hosts on the LAN, what should it advertise? IP addresses it got from upstream? IP addresses configured manually on the router? The IP address of the router itself? If the router itself can handle DNS lookups sent to its IP, does it act as a recursive resolver, or is it simply a caching layer? If it is just caching, then the question about which upstream it is using still needs to be answered.

If hosts on the LAN send DNS queries to the IP address of the router, then it doesn't matter if that is done using IPv4 or IPv6. DNS lookups from the router can happen through either protocol and won't depend on which protocol the client on the LAN used. But the builtin DNS servers in routers are frequently found to be broken, some of them are unreliable if you use them for anything other than lookups of IPv4 addresses.

If the router automatically finds upstream DNS servers, it will be those from your ISP, since autoconfiguration of DNS doesn't happen with tunnelled IPv6. However HE does provide anycast DNS service, which you can configure manually. However, there is only one anycast IPv6 address. If the closest replica of that IPv6 address is malfunctioning, you cannot use that address for DNS lookups. So you need a secondary IP address. With a bit of luck, the IPv4 anycast address provided by HE is routed to a different replica. You could also fall back to using the DNS servers from your ISP, but those are probably not able to communicate with IPv6 only authoritative DNS servers.

Additionally the physical location of the DNS server you are using matters. Big sites will send you to a different webserver depending on which DNS server you are using. This is done to give the fastest possible replies. But if you use a DNS server far away from your own computer, you will also be directed to webservers far away.

I hope I didn't scare you by mentioning, what complications there can be in DNS configuration. If your current settings appear to work, then don't worry too much about it.

[kcochran]

The announcement of the anycast IPv4 and IPv6 addresses is tied to the DNS service being operational.  If it's down, the addresses drop off the local copy and you should wind up at a different one.

A few years ago, that may not have been always the case, but it should be as of the past year or so.

[mlane]

Thank you for the good replies. I'd like to split my comments and questions into separate messages.

I found a funny way to test IPv6 connectivity...

Take a break from IPv6, go to Win 7 machine (hardwired to router), start Thunderbird to check mail...

As soon as I did that, my cell phone went nuts with SMS messages from Google informing me of multiple gmail breakin attempts using my accounts and passwords. I got messages:

We prevented the sign-in attempt in case this was a hijacker trying to access your account. Please review the details of the sign-in attempt:

Thursday, November 21, 2013 6:57:47 PM UTC
IP Address: 2001:470:8:d72:d8d:a61c:95d3:d5e9
Location: United States

If you do not recognize this sign-in attempt, someone else might be trying to access your account. You should sign in to your account and reset your password immediately.

2001:470:8:d72 is my prefix. I don't know exactly how the interface ID came to be a61c:95d3:d5e9. Router advertisement is enabled. In Win 7, IPv6 is enabled but it is not configured with a legitimate address (IPv6 Properties).

Annoying but funny.

[kasperd]

The announcement of the anycast IPv4 and IPv6 addresses is tied to the DNS service being operational.  If it's down, the addresses drop off the local copy and you should wind up at a different one.

Any system which depends on being able to reliably find out if a component is up or down, is going to fail eventually. Being up or down is not just black or white. There are all sorts of possible intermediate states. As soon as you start making assumptions about the behaviour of failing components, you are headed for trouble.

In this particular case, what one should expect to happen sooner or later is that the health checks driving the announcement comes out as good, but in reality the DNS lookups from the client are failing somehow. DNS clients know how to deal with that. They retransmit the DNS lookup to another IP. But they can only do so, if there is another IP to send the request to. Two different anycast addresses with each DNS server being in only one of the two pools is one way to achieve that.

But clients can also just use two independent operators of DNS servers. There is less risk of shared fate in such a configuration. Google has a DNS service with four anycast IP addresses (two IPv4 and two IPv6 addresses), using one of those can work just fine. Before Google got IPv6 support on their public DNS service I was using the HE DNS anycast address and one of the HE DNS unicast addresses as primary and secondary DNS resolver. On at least one of my machines I actually needed to use a unicast address as primary and anycast only as secondary, because the anycast address was unreliable enough to frequently slow down lookups.

The reliability of the anycast address might have improved since then. I didn't change my configuration, once it was working. But I wouldn't recommend on using just one anycast address if you want reliable service regardless of what the track record may look like.

[kasperd]

We prevented the sign-in attempt in case this was a hijacker trying to access your account. Please review the details of the sign-in attempt:

Thursday, November 21, 2013 6:57:47 PM UTC
IP Address: 2001:470:8:d72:d8d:a61c:95d3:d5e9
Location: United States

If you do not recognize this sign-in attempt, someone else might be trying to access your account. You should sign in to your account and reset your password immediately.

Did they remember to tell you how to let them know, that the access was legitimate? The wording seems to imply they didn't think about he possibility that it could be legitimate, and how to deal with that.

I don't know exactly how the interface ID came to be a61c:95d3:d5e9.

Pseudorandom. I recall reading about one system, which constructs the interface ID by hashing the prefix along with a secret value chosen at install time. That way the IP is static as long as the host stays on the same network, but if it moves to a different network, an outsider cannot tell that it is the same host from the interface ID. I am not sure if it was Windows, which used that strategy. There are also systems which chose a new random interface ID every 24-48 hours and keep the old ID alive until all connections opened before the change have eventually been closed.