Enabling IPv6 On My Home Network Part 2 AT&T

I originally setup IPv6 on my home network using Hurricane Electric’s tunnelbroker.net service. This worked okay for some time, until late summer of 2013 when my provider, AT&T, decided to rollout a firmware update to their 2Wire/Pace residential gateway devices which broke the ability to forward the 6in4 tunnel encapsulated traffic. That is another long story in itself. So, needless to say, I was unable to run IPv6 publicly for quite some time, due to this issue.

I upgraded my service to the new AT&T U-verse Power Tier back in October which replaced my old 2Wire 3801 residential gateway with the brand new Motorola NVG589 unit. This unit was deployed with AT&T’s IPv6 6rd tunnel solution enabled out of the box. This provided IPv6 access to the segment directly attached to my residential gateway with a /60 netblock assignment. It’s a pretty generous assignment, aside from the fact that it only assigned a single /64 to the local LAN and there was no obvious way to delegate the 15 other /64 networks to a downstream router.

Well, that appears to have finally changed. You are now able to use DHCP-PD to request a prefix assignment from the NVG589 to a downstream router. The downside is that it seems you can only make a generic request and it automatically assigns you a single /64 prefix per DHCP-PD client. I have 3 separate segments behind my internal router that I would like to enable IPv6 on. So, that is limiting at the moment. However, at least I am now able to obtain IPv6 connectivity on my primary LAN segment.

Following are the IPv6 configuration details regarding my setup with AT&T U-verse for your reference.

On the NVG589 residential gateway supplied by AT&T, you need to ensure that IPv6 is enabled on the Home Network::Configure tab. If the IPv6 option is greyed out on the configuration screen, then AT&T has not enabled your gateway profile for IPv6 6rd tunneling. There is another long story about the situation with AT&T’s IPv6 rollouts. I’m pretty sure that the NVG589’s should be activated by default for IPv6. If not, you have a couple of options:

1. You can visit the following link to run a compatibility test that should prompt you to enable it, if possible.»www.att.com/esupport/ipv6.jspClick the IPv6 Compatibility menu option in the middle of the screen and then click the “Start Test” button.
   If you are already enabled, you should see green checkmarks for each of the tests in the middle column. You should see a message that says “Your system is IPv6 compatible” in the top right.If IPv6 is not enabled on your gateway and/or the firmware is not the right version for support there will be an option presented toward the right hand side to request having it enabled. AT&T will then execute the necessary changes to enable IPv6 on your gateway and/or upgrade the gateway firmware.
2. You can submit a really nice request to AT&T’s social media Customer Care group and they will route you to someone who will update the profile and let you know when to reboot your device to pick up the update.

Once IPv6 has been enabled on your RG, you should see the following:

The 6rd tunnel will automatically be setup and assign you a unique /60 prefix based upon your IPv4 address assigned. You can verify this information on the Home Network::Status tab.

On my Cisco 3825 router running IOS 15.1(4)M6 Advanced IP Services I’ve configured the following:

Global Config

ipv6 unicast-routing
ipv6 cef
ipv6 cef accounting prefix-length
ipv6 inspect max-incomplete low 100
ipv6 inspect max-incomplete high 300
ipv6 inspect udp idle-time 60
ipv6 inspect tcp idle-time 7200
ipv6 inspect tcp finwait-time 8
ipv6 inspect tcp max-incomplete host 100 block-time 1
ipv6 dhcp pool Home
 dns-server 2001:4860:4860::8888
 dns-server 2001:4860:4860::8844
 domain-name domain.net
 sntp address xxxx:xxx:xxxx:xxxx::1

Outside Interface

interface Gi0/0
  ipv6 address autoconfig default
  ipv6 mtu 1480
  no ipv6 redirects
  no ipv6 unreachables
  ipv6 dhcp client pd Uverse
  ipv6 virtual-reassembly in

Inside Interface

interface Gi0/1.961
  ipv6 address Uverse ::1/64
  ipv6 mtu 1480
  ipv6 nd other-config-flag
  ipv6 virtual-reassembly in

 

The Cisco router obtains the delegated IPv6 /64 prefix from the NVG589 using the ‘ipv6 dhcp client pd Uverse’ command and assigns it to the arbitrary prefix name “Uverse”. I then apply the IPv6 address to my internal interface using ‘ipv6 address Uverse ::1/64’ which assigns the ::1 address within the netblock. The command ‘ipv6 address autoconfig default’ automatically assigns a default route pointing to the link-local address of the NVG589 to provide access to the IPv6 Internet.

Set Your MTU

In IPv6, fragmentation is only done by the end-hosts, which means that end-hosts should be able to run PMTU to a destination and adjust the size of IP packets accordingly. If PMTU is failing under IPv6, which typically occurs when ICMP messages are filtered (PMTU black holes), you are about to enter a world of pain, since your IPv6 traffic will be dropped on the floor without further notice. Therefore, failed PMTU is a big problem in IPv6 connections. In IPv4 a similar problem happens if the Don’t Fragment flag is set (default in Linux).

Ref: https://blog.thousandeyes.com/troubleshooting-path-mtu-tcp-mss-problems/

IPv6 routers, as defined by the standard, do not perform packet fragmentation. Only IPv6 endpoint hosts can fragment packets. This can be a problem if you send packets that are bigger than the MTU of any particular hop on the path to your destination. The typical default MTU for an interface is 1500 bytes. I’ve set my router interfaces to use an IPv6 MTU of 1480 bytes, as my IPv6 connection is tunneled using 6rd to AT&T’s Border Relay router. The 6rd tunnel adds 20 bytes of encapsulation overhead to every packet which reduces the effective MTU to 1480. If my machines were set to the default MTU of 1500 and unable to perform PMTUD, most of their IPv6 communication could be blackholed. Local clients are supposed to learn the link MTU from the IPv6 Router Advertisement (RA) as the MTU value is included, as part of that message. If that fails for some reason, local clients should learn the MTU through Path MTU Discovery (PMTUD). This requires ICMPv6 Packet Too Big responses to be permitted inbound towards any client machine. When an IPv6 packet is sent that is larger than the MTU of a receiving or sending router interface, the packet will be dropped and the router should transmit an ICMPv6 response to the sender identifying the max MTU value. If there is a firewall or filter in the path back to the sender that blocks ICMPv6 packets, this would fundamentally disable PMTUD, since the ICMPv6 response could not be received by the client and it would potentially break the majority of their communications.

The best practice is to permit the ICMPv6 response traffic to allow PMTUD to function as it was designed and intended. However, there is a known Denial of Service (DoS) attack that can be caused by Packet too Big responses with particular host types that causes atomic fragments that will hang the system. Another alternative and probably the second best option is to configure your router interfaces to use an MTU of 1480 bytes for IPv6 and/or you can configure each of the client machines to use an MTU of 1480. There are definitely problems with this IPv6 MTU issue on AT&T’s network, due to the 6rd tunneling they are currently using. If you run into issues with connectivity when you have IPv6 enabled on your RG, it is likely related to this PMTUD problem. Try adjusting the IPv6 MTU to 1480 on the client machine and see if that resolves the problem. If you are directly connected to the AT&T RG things should work with PMTUD. But, for machines that sit behind your own personal router, if it is blocking ICMPv6 responses, they will require the router’s interfaces to be configured with the proper MTU of 1480 or each client will have to have its MTU modified to support IPv6.

In addition to setting the MTU, you can also adjust the TCP Maximum Segment Size (MSS). If you are able to adjust the MSS properly on the clients and/or the router interfaces in between, this avoids the hassle of PMTUD from occurring and speeds up the initial connection establishment. MSS is proactively advertised by the endpoints during a TCP handshake. Both endpoints will select the lower of the two values offered, thus avoiding sending initial packets that may be too big and waiting to receive an ICMPv6 Packet Too Big response for PMTUD. With IPv6 the normal MSS is the default MTU of 1500 minus the 40 byte IPv6 header minus the 20 byte TCP header or 1440 bytes. If the connection is tunneling via 6rd or using PPPoE there is another 20 bytes of overhead which reduces the MSS down further to 1420 bytes. Adjusting the IPv6 TCP MSS on router interfaces was initially an unsupported configuration option on Cisco IOS. It has since been introduced in the 15.2(4)M release train, as part of the more generic ip tcp adjust-mss command. This thoughtlessly combines the MSS adjustment function for both IPv4 and IPv6 forcing them to be the same value, even though IPv6 has an additional 20 bytes of overhead for its header. Unfortunately, it is doubtful if any consumer routers will support tuning this configuration option in either case for IPv4 or IPv6. In that case, your only option is to manually tune this configuration option individually on the endpoint clients.

I’ve configured an IPv6 DHCP server to supply Google’s IPv6 nameservers and my local NTP server address. The clients should use the ‘ipv6 nd other-config-flag’ option on the autoconfig neighbor discovery process to trigger a DHCP query to receive the additional options. I haven’t tested how well baked this functionality is but eveyrthing I’ve read has indicated this is how you handle additional config options for IPv6 Autoconfig.

Please Note: This configuration does not address IPv6 Security. The NVG589 will provide some basic IPv6 security features. However, I am working on a supplemental post that will detail a reference config for baseline IPv6 security on a Cisco router directly exposed to the IPv6 Internet.