IPv6 - Technical Information

This page provides more technical information about IPv6 connectivity for Stargate customers. If you are looking for general or introductory information about IPv6, please see the IPv6 General Information page.

Will my customer's router or firewall support IPv6?

The answer here is generally "it depends". Most reasonably modern routers, firewalls, and switches have at least basic IPv6 support. However, in our experience, customers frequently need to upgrade firmware on their equipment in order to ensure proper functionality; basic IPv6 connectivity may work, for instance, but management interfaces may often not expose relevant IPv6 options, or some features like DHCPv6 client or server functionality, IPv6 connectivity through IPSEC tunnels, etc., may not work in older firmware releases.

We do also find that, especially at smaller offices, customer firewalls are often deployed for very long service lifetimes ("If it ain't broke, don't fix it!"), meaning equipment that is several years old is still in production. Older equipment may no longer be supported by the vendor and may not have any IPv6 capability, and would need to be replaced entirely in order to get IPv6 connectivity at the site.

How do I get IPv6 connectivity from Stargate?

Ask :-)

But seriously, contact support or sales and ask about getting IPv6 connectivity. At the time of this writing, Stargate is in a pilot phase for turning up IPv6 for customer connections, and our support and engineering teams would love to hear from you.

How many IPv6 addresses will Stargate allocate to customers?

In cases where customers provide their own firewall, Stargate will configure a ::/64 network between the Stargate demarc router and the customer firewall. This means that customers can easily connect multiple discrete firewalls or network gateways if that is their preference.

Each customer site is also allocated a ::/48 prefix by default. This allows plenty of room for hierarchical addressing/subnetting schemes, and for a theoretical maximum of 65,565 networks per site, assuming default network masks of /64.

How should I configure my firewall for IPv6 connectivity?

Stargate's preferred configuration option for customer equipment is SLAAC for interface addressing and DHCPv6 Prefix Delegation (IA_PD) for prefix delegation. Our demarc equipment will also be configured by default to support stateful DHCPv6 addressing (IA_NA), should customers prefer that option. Static IPv6 addressing for WAN interfaces and static routing for customer prefixes is also supported if needed, though DHCPv6-PD is preferred.

Other configuration options (recursive resolvers / DNS servers) are available through stateless DHCPv6. RDNSS is not currently supported.

Does Stargate support DHCPv6-PD?

Yes; DHCPv6-PD is the preferred method for customer prefix delegation.

Will Stargate provide IPv6 SMTP relays / smarthosts?

Yes. Our SMTP relays at smtp.stargate.ca do have AAAA records and will relay mail from Stargate IPv6 address space.

Will Stargate provide IPv6 name servers (recursive resolvers)?

Yes. Anycasted recursive resolvers are available at 2607:4100:ffff::3 and2607:4100:ffff::4.

How do I protect/firewall my IPv6 network?

We also call this "The NAT question".

Many systems administrators have "grown up" in an Internet dominated by NAT and have likely never administered a network that did not use overloaded NAT (aka NAPT, IP masquerade, etc.) for Internet connectivity. However, NAT was created to address IPv4 address exhaustion, and since address exhaustion is not a concern in IPv6, IPv6 does not provide support for overloaded NAT. Because the idea of a firewall is so closely tied to NAT for a lot of IT professionals, this immediately brings up the question of how they can secure their IPv6 networks as there is no way to NAT their "internal" networks.

The key thing to realize is that NAT is not a firewall.

In a typical "port forward" setup (destination NAT or static NAT), two things actually need to happen:

A NAT rule needs to translate the destination address and/or port of a packet from the original public destination IP to the private (RFC1918) IP.
A firewall rule needs to allow that traffic.

Most GUI-managed firewalls just bundle the creation of the needed NAT and firewall rules together in a single wizard or configuration page, but both do still exist "under the hood". If we move to a basic IPv6 scenario with an Internet connection, a server on a LAN, and a firewall between the LAN and the Internet, we've removed the need for NAT rule as we would talk to the server's IPv6 address directly, but we still need a firewall rule to allow that traffic.

A scenario for a standard stateful firewall with a "Default Deny" inbound policy looks like this:

An IPv6-capable user on the Internet wants to connect to a server on your network via IPv6.
The user's request reaches your firewall's WAN/outside interface.
The firewall compares the packet's source address, source port, destination address, destination port, protocol (TCP, UDP, etc.) and other characteristics (e.g. ingress and egress interfaces) to its list of firewall rules.
If a matching firewall rule is found (e.g. you have a web server on your network, the user is trying to connect to port 80 on that web server, and you've configured a firewall rule to allow that traffic), the firewall accepts the packet and forwards it to the web server.
If no matching firewall rule is found, the firewall drops the packet because of its "default deny" configuration for traffic from the WAN/outside to your networks.

No NAT occurred in that scenario.

Some may ask at this point that if we use a "Default Deny" policy for traffic from the Internet, how replies for legitimate user traffic will get back into our network. In other words: If our firewall drops any traffic from the Internet by default, won't we need firewall rules for every single user's regular web traffic? This is handled by stateful firewalling.

A stateful firewall keeps track of active sessions. Assuming a very simple scenario of permitting all traffic from the local network to the Internet, but denying all traffic from the Internet to the local network, an example browsing session for a local user looks like this:

A local user opens their browser and navigates to a web page.
The user's PC (or phone / other device) sends a request to the web server on the Internet.
The user's request reaches your firewall's inside/LAN interface.
The firewall compares the packet's source address, source port, destination address, destination port, protocol (TCP, UDP, etc.) and other characteristics (e.g. ingress and egress interfaces) to its list of firewall rules.
As you have a default rule permitting all traffic from the local network to the Internet, the firewall permits the packet.
The firewall creates a session entry that lists identifying information about the traffic, generally the source address, source port, destination address, destination port, protocol (TCP, UDP, etc.), ingress interface, egress interface, TCP sequence numbers, etc.
The web server receives the user's request and replies.
The reply packet reaches your firewall's WAN/outside interface.
The local firewall compares the packet to existing sessions and finds that it matches the user's existing session with the web server (created in step 6).
Because an existing session was found and matched, the firewall permits the packet and forwards it to the user.

So, although any traffic that is initiated on the public Internet outside of the firewall is dropped by default, the firewall's stateful nature allows it to identify which traffic received on its "outside" interfaces is a reply to traffic that was initiated on the local network and should be permitted.

If you still have concerns about security and firewall configuration in IPv6, give us a shout about IPv6 training and workshops. Also, some further reading:

No NAT in IPv6?
IPv6 Philosophy: To NAT or not to NAT – that's the question

Are there any "gotchas" that Stargate can recommend to watch out for when deploying IPv6?

Yes. Stargate is keeping a knowledge base of known caveats or odd behaviour with common customer firewalls. That list is likely to grow a bit too long to include here, but please feel free to ask support (contact us) if we are aware of any issues to watch for with your preferred equipment. Note that this is "best effort" information based on issues we may have come across in regular customer support, and should not be considered an exhaustive list, as we cannot vet all possible customer equipment and configuration options.

General best practices and tips & tricks to use or "gotchas" to look out for, though:

Initial turn-up & testing:
If you are new to IPv6, consider leaving dynamic IPv6 addressing (through DHCPv6 or SLAAC) disabled when you first enable IPv6 on your network. Configure static IPv6 addresses on some test workstations and servers to "get your feet wet" and become more comfortable supporting or troubleshooting IPv6 connectivity. Turn up dynamic addressing when you're ready to support IPv6 connectivity at your site.
Dynamic addressing protocols:
Pick your addressing protocol, either stateful DHCPv6 or SLAAC, depending on your needs. Understand why you would use one or the other or both, and why you may still need stateless DHCPv6 even if you use SLAAC for addressing.
ICMPv6, Path MTU Discovery, and firewall policy:
Routers will not fragment IPv6 packets like they will do for IPv4, meaning that Path MTU Discovery (PMTUD) must work for proper IPv6 connectivity. Ensure that your firewalls allow at least ICMPv6 Type 2 (Packet Too Big) messages from WAN interfaces to LANs, and consider allowing all ICMPv6 from WAN interfaces to LANs. Security by obscurity isn't; ICMPv6 is an important if not critical part of IPv6 and should be permitted from "untrusted" zones (e.g. the Internet) to "trusted" zones (e.g. the local network). If your organization still has lingering concerns about allowing all ICMPv6 into your network, Stargate recommends that at least the following ICMPv6 message types should be permitted:

- Required:
- Type 1 (Destination Unreachable)
- Type 2 (Packet Too Big)
- Type 3 (Time Exceeded)
- Type 4 (Parameter Problem)

- Recommended:
- Type 128 (Echo Request)
- Type 129 (Echo Reply)
Default firewall rules:
Though a lot of small business firewalls will allow all IPv4 traffic out from LAN zones to WAN zones by default, many do not set up default rules to allow IPv6 traffic from LAN to WAN. If you have no IPv6 connectivity after enabling IPv6 on your firewall, check if you need to set up explicit firewall rules for LAN to WAN IPv6 traffic.
Browser extensions for visibility:
Once you have IPv6 connectivity, consider using an IP address information browser extension, e.g. IPvFox for Firefox or IPvFoo for Chrome/Chromium, to provide feedback as to whether you are connecting to websites over IPv4 or IPv6. At the least, this provides some insight as to which websites have deployed IPv6.

Can Stargate assist me in rolling out IPv6 connectivity to my networks or customers?

Absolutely. Stargate is developing IPv6 support and consulting services to help our customers and network partners in their IPv6 deployments. This can take the form of basic "IPv6 Bootcamps" and workshops for senior support staff or whole IT support teams, support in developing IPv6 addressing schemes, or more intensive IPv6 consulting to help evaluate the entirety of a customer's network and provide a full IPv6 deployment plan.

Our customers and network partners depend on Stargate for networking expertise, and we are extending that expertise and support into this next phase in the evolution of our customers' networks. Contact us to learn more about how Stargate can help you step into IPv6.