Posted by: rolande | May 16, 2014

Enabling IPv6 On My Home Network Part 2 AT&T

IPv6 ReadyI 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:

nvg589homenetconfig

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.

Advertisements

Responses

  1. […] See my latest post on my IPv6 setup with AT&T U-verse. […]

    Like

    • You forgot part of the configuration. Without this clients will not be able to get internet access.

      interface Gi0/1.961
      ipv6 dhcp server home

      Like

  2. Thank you for the link at Uverse! Awesome information. The only thing I would change in your config is to allow unreachables. You will break PMTUD in IPv6 if that is disabled, and since packet fragmentation is no longer supported in IPv6, you will definitely want that to get maximum throughput.

    Like

    • Thanks for the feedback. I am aware of the change with fragmentation support in IPv6. Can you point to documentation that shows ipv6 Unreachables on IOS covers Packet Too Big responses? I haven’t seen that anywhere. I actually disabled Unreachables on purpose due to the known DoS with Atomic fragments. I’ve hard coded my MTU to 1480 on my router interfaces and that appears to avoid PMTUD issues, at least with the 6rd tunnel to AT&T’s border relay. Regardless, according to some reports, it appears that AT&T is breaking PMTUD anyway. So, not sure it would actually make any difference, other than open a vulnerability. I appreciate the heads up. I’ll have to read some more and test it out and see first hand.

      Like

      • You should read RFC 6946 which is all about IPv6 atomic fragments. It also covers how to eliminate the known issues (for now); whether it is implemented across all devices is another issue entirely (I highly suspect the answer is ‘no’, even after the RFC has been around a while).

        “The best practice is to permit the ICMPv6 response traffic to allow PMTUD to function as it was designed and intended. ”

        True. Of course, you can argue that it is more like the ‘correct’ way but ‘correct’ does not always mean best practise. I would go that way because it is never so easy as it is claimed.

        “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.”

        See the RFC I refer to for this subject.

        “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.”

        Indeed. I actually have my MTU lower because of it (lower than 1480 and for specific yet similar reasons – something over IPv6 very broken). But when you consider that 6rd is IPv6 to IPv4 (6to4 at the provider, essentially)… it sort of adds up. If they could actually move to native IPv6…alas. My understanding is some of their customers do have this but those would be managed services. In any case, to be strictly technical, there isn’t really anything wrong with setting your MTU; that’s why it is configurable (I somehow suspect even Windows allows it although I don’t know for sure nor do I really care).

        Otherwise, while I somehow suspect I’m not as fortunate with your subject (making use of static iP blocks for IPv6), given that I’m stuck at 3.0Mbps (and lucky to have that), the link you offer is potentially of value at some point. Appreciate it.

        Cheers.

        Like

  3. I need the firmware update for a Pace 5031NV provided by ATT. Option 1 no longer has a request feature. Option 2 led to a chat that boils down to “when it becomes available it will be automatically updated; you do not need to request it.” Not even an attempt to up-sell me on equipment or service. Requests for firmware updates appear to be unwelcome.

    Like

  4. How to use the 15 other /64 segments of the 16 provided /64 networks
    https://forums.att.com/t5/Features-and-How-To/ATT-IPV6-tunnel-issue-solved-Cisco-router-only/m-p/4182159#M43321

    Like

  5. You could just root it and enable bridge mode.

    nvg589.tk

    Like

    • Last time I checked, the 589 had not been successfully rooted.

      Like


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: