Print

[nosebreaker]

Neither of our ISP's support IPv6, and we are not able to use a 6to4 tunnel.  We run private ipv6 addresses (fe00 space), and have a few different subnets internally.  On World IPv6 day, major sites switched to IPv6, and for us that caused them to become super-slow to load.  The browser tries with ipv6, then moves onto ipv4 and works fine.

I was hoping I could set an ACL on our firewall so that it would close the connection right away and it could fail back to ipv4 faster, but it didn't seem to actually do anything.

We run Cisco 5510 ASA's, does anyone have any suggestions on how to fix this?

[nosebreaker]

It is finally solved!

The solution is to define a route to nowhere (out the internet) and set an ipv6 access-list to deny it, AND use the "service resetinbound interface inside" command (resetoutbound is enabled by default).

Don't forget to enable ipv6 on your outside interface!

To sum it up I did:

Code: [Select]

interface Ethernet0/0
 ipv6 enable
 ipv6 address 2000::1/64
exit
ipv6 route outside ::/0 2000::2
ipv6 access-list deny_all deny ip any any
access-group deny_all in interface inside
service resetinbound in interface inside

I randomly chose 2000::1 as we have no ipv6 routes at all.  Ethernet0/0 is my outside interface.  I already had ipv6 defined on my inside interface.

[kasperd]

We run private ipv6 addresses (fe00 space)

FE00::/9 is reserved. You are supposed to be using RFC 4193 addresses. For example you could use fd6d:6259:b5e8::/48.

If you use proper addresses, then browsers will have a chance of realizing that IPv6 can only be used to connect to hosts on the LAN and not for hosts on the Internet. In other words, if the only (non-link-local) address a host has is an RFC 4193 address, then a sensible implementation would only default to IPv6 if the server has an address within the same /48.

There is no guarantee that switching to proper RFC 4193 addresses will help, but it is certainly better than using reserved addresses (which the browser probably treats the same way as public addresses from 2000::/3).

Using more recent browsers may also help. Supposedly recent browsers are better at dealing with broken networks, such as yours. A common strategy is to only wait a few hundred milliseconds from starting the first connection before trying the other protocol. Then the actual request is sent over the connection which first completes a handshake.

[tibordp]

While it is definitely better to use ULA addresses, it won't help. At least it shouldn't. The browsers have no way of knowing whether there is a NAT66 gateway upstream that would enable connectivity to global internet.

[snarked]

You should not be using 2000::/64 as your private network.

If you must use a network in the 2000::/3 range, use the documentation address network:  2001:DB8::/32 as it is not supposed to be routable should your packets escape.  However, I agree that the site-local range is a better choice.

[kasperd]

The browsers have no way of knowing whether there is a NAT66 gateway upstream that would enable connectivity to global internet.

No, the browser cannot know that for sure. But the probability that there is one is low enough to justify switching from preferring IPv6 to preferring IPv4. In both cases there should of cause be a fallback to the other protocol.