Main menu

Post navigation

About Alex Broque

Alex Broque is an experienced Network Engineer, and got all of his IPv6 experience by working at Hurricane Electric. He was responsible for co-authoring the HE.NET IPv6 Certification Program. Also managed the day-to-day operations of both tunnelbroker.net and the globally deployed nodes and tunnels, as well as the 200,000sqft FMT2 facility owned by Hurricane Electric. This blog is a dumping ground for what he has learned over the years about IPv6 implementation and deployment.

After the success of last year’s World IPv6 Day, where success was measured with little to no problems reported, World IPv6 Launch Day has arrived! For a while major players like Google and Facebook had been white-listing their AAAA records to specific ISP recursive nameservers. This meant you had to query one of those in order to see IPv6 entries for their websites. Now that white-listing has been removed and all properly operating recursive nameservers will now serve up these records. They aren’t the only companies participating of course! Take a look at this list to see whom else signed up to promote their enabling of IPv6. Want some stats, take a look at the following:

But what does this mean to the non-techies out there? It is meant to be a passive change. You shouldn’t notice much in the way of interruptions. Perhaps your ISP will have a shorter route to a destination over IPv6, and you might get what you are trying to access a tiny bit quicker. If you like video/chat applications, this will soon mean that you’ll be able to have proper end-to-end communication between your machine/application and someone remotely. No more NAT to muddle connections. If XBOX and similar console devices migrate, you could actually have more than one in the household online at the same time and not get mangled because of IPv4 NAT!

With all my servers and services IPv6 enabled remotely, it was time to check out how well Comcast is doing with their residential IPv6 rollout. First thing I did was check out their listed compatible DOCSIS 3.x modems that had IPv6 support. Saw the Motorola SB6120 listed, and having used their ISDN products in mid-90s, figured it would be a good investment. Hunted around and found that the nearby Fry’s Electronics had the SB6121. Picked it up for $100. They also had Zoom modems that stated they supported IPv6. But after dealing with their Rockwell chipset modems in the early 90s, I’ll pass.

Got home, swapped out the old RCA rental from Comcast, and plugged in the new one. Called them up, got them the HFC MAC and had them provision it. Took them a bit to do, but finally my laptop was getting a Comcast IP, and that was a good start. Plugged in the D-Link DIR-825, it got its old IP back (since its MAC hadn’t changed). Went into the IPv6 WAN Configuration, and initially picked “Autoconfiguration (SLAAC/DHCPv6)”, but decided that since we live in the FUTURE, I’d let the D-Link try “Auto” and sort it out. Well it worked, and I had IPv6 on the D-Link’s WAN interface, and my laptop was autoconfiguring out of Comcast space.

But there was one last hurdle: Comcast. While IPs had configured fine, I couldn’t reach anywhere. I spent roughly 30 minutes reviewing all configuration settings, making sure I had routes, and rebooting everything a few times to no avail. Finally gave in, called back Comcast, and the tech was like “oh, let me disable the firewall on our side.” POOF! Everything worked. So Comcast residential IPv6 is definitely live in my area, and just needed a new shiny DOCSIS 3.x modem.

Helping out someone in #ipv6 on FreeNode today, they had issues with getting ospf6d to redistribute the default IPv6 route. They were configured to redistribute static, connected and kernel, but for one reason or another the default route wasn’t getting picked up and shared. Luckily they were also running the zebra daemon, so I recommended that they manually configure the default route in the zebra config, and lo’ everything magically worked! So if you are running into the same issue with Quagga’s OPSFv3 and getting a default IPv6 route redistributed, make sure you’ve added the route within Zebra.

Being in the SFBA has its quirks at time 🙂 Stopped in a 7-11 to get something to drink while driving around. Got up to the register and the clerk asked ‘Is that your IPv6 address?’ I was wearing a Cisco shirt with 2001:420::c15c:0 on the front, which I got at last years World IPv6 Day post-celebration at Tied House. I explained what it was and from, and he laughed. He said he recognized it as being IPv6 because he was studying for his CCNA. So yay SFBA nerds, and yay IPv6 getting into more people’s minds 😀

This is going to be based on a bit of both practical deployment experience and opinion. Let us start with what is acceptable for BGP announcements. RIRs hand out /48s as the smallest allocation. This is perfectly fine for BGP announcements. If you got a larger allocation, say a /32, you should be announcing that master prefix. This will help curb de-aggregation of routes and keep the IPv6 routing table smaller. Is anyone going to tar and feather you for announcing a few specifics? Most likely not, especially if you are providing some sort of anycasted service. Otherwise, until an RIR starts allocating and handing out something more specific than a /48, put in some global filters to make sure nothing gets leaked like /64s.

When providing someone with an abundance of IPv6 subnets (/48, /56, multiple /64s, etc.), make certain that you aren’t putting them ON-LINK, and instead are routing them to a destination IPv6 address on a downstream router. Either by static routes or accepting and properly filtering BGP advertised routes. If you allocate someone a /48 and configure 2001:db8:1::1/48 on the interface facing their router, you basically do a disservice to them. They would need to hack around with proxy NDP and other headaches, rather than have something straight forward and working in seconds.

As far as I’m aware, only 2 popular providers out there seem incompetent regarding this: OVH and FDC. Either they don’t understand how to set static routes on their routers, or don’t want to learn. Seriously, what is so hard about typing in:

conf t
ipv6 route 2001:db8:2::/48 2001:db8:1:2::2
end
wr mem

With RA, a host will usually configure their default gateway as the link-local address based on the upstream router’s interface, facing that host. For static IPv6 configurations, the 2001:db8:1:2::/64 network address tends to be reserved for just that purpose, being the network address. Some software out there might not like trying to bind on this address, or perhaps there are some older and possibly poorly designed and deployed networking code that won’t like treating that as a host’s address. My recommendation is just use the first “usable” address out of an allocation as the gateway address for hosts, like 2001:db8:1:2::1/64. However any address will work, as with a /64 you get 18+ quintillion of them to pick from (as long as it doesn’t conflict with the host).

Another thing to consider is using /126 allocations for links between routers. This gives a few IPs to use on the link which can be good for multiple BGP sessions, etc. It will also limit the possibility for a ND table overload by someone trying to hit all possible addresses in a larger range, if the link is configured with something smaller (I’ve oversimplified this explanation).

Sure some players like Sprint will plop down 2600:: as that host’s AAAA record and address. Maybe it is a /127 with 2600::1/127 set as gateway; who knows other than Sprint. Point is, to avoid any potential issues, you are better served treating it as the reserved network address for the allocation.

One of the things learned in my time at previous job, was the interoperability between IPv6 routing protocols and platforms. I ran into a quirk when deploying some Quagga boxes (0.99.x version) talking OSPFv3 with some Brocade routers running NetIron 5.x. The issue was that if MTU wasn’t specifically configured on the Brocade interface facing the Quagga box, OSPFv3 wouldn’t properly negotiate and was pretty much useless. However setting the MTU on the Brocade interface to 1500 fixed this. It is possible that this would also work with jumbo frame MTU settings, however the machines weren’t getting configured or deployed for that. Just something to look out for in the lab or production, if OSPFv3 appears configured correctly everywhere, but won’t establish. Quagga’s BGP had no issue with communicating properly with a Brocade router that didn’t specify MTU on its interface, it was only OSPFv3 that appeared to be affected.

So you have your ASN and just got your PI (Provider-Independent Address Allocation) straight from an RIR, or perhaps a LoA (Letter of Authority) to announce some PA (Provider-Assigned Address Allocation) space from your ISP. You’ll need to start getting that announced out there to your peers, customers and transits. So lets use some documentation prefixes and ASNs and sort out a basic working config. I’ll base the examples on my experience with Brocade NetIron software on XMRs, which can translate over to Quagga or Cisco IOS with a few tweaks.

Assuming you are familiar with BGP4+ with IPv4, IPv6 is not so different or any more complex when getting started. Lets start off with some numbers:

Start off with making certain that you’ve configured IPv6 on your upstream facing interface, and they’ve configured your side, and you can ping each other over the link. The upstream provider’s configuration can be done as so:

The differences being:
1) outbound filter list on your session to the ISP
2) network statement for the allocation to be announced by BGP

You’ll also need some sort of anchor route so BGP knows to announce the route. This can be either a local null-route or static-route for the covering prefix, or an IP out of the prefix configured on an interface. So once BGP is configured, and establishes between both routers, the ISP side should see something similar to:

And that should be it. You can obviously play around with peer-groups, route-maps, etc. Communities should work as long as your ISP offers them, so be sure to ask. Ideally there is at least a blackhole community in place. That should allow you to announce a specific range or IP that you want to have null-routed upstream in cases of abuse or attacks. That filter could look like either of the following, depending on how specific they allow you to announce:

OSS projects and authors are just making it too easy to enable IPv6! Not that this is a bad thing mind you, because it means there is even less reason to NOT have your services available on IPv6. We’ll take a speedy look at configuring Dovecot.

dovecot.conf#listen = *, ::
This line lets you configure what addresses Dovecot will listen on.
* = All IPv4
:: = All IPv6
If you have specific IPs you only want Dovecot listening on, you would specify a listen = line with comma delimited addresses for those IPs. By default Dovecot will listen on all available IPs configured on the server, as will the services you’ve decided to provide (POP3, POP3S, IMAP, IMAPS, etc.).