While I’m not on a carrier that hands out IPv6 over the radio (4g/LTE/etc), at least the WiFi support for IPv6 remains working 🙂
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:
ipv6 route 2001:db8:2::/48 2001:db8:1:2::2
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:
Upstream ISP ASN: 64500
Your ASN: 64501
Specific /126 configured on interfaces out of allocated /64: 2001:db8:0:1::/126
PA allocation to announce: 2001:db8:1234::/48
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:
isp#conf t isp#(config)ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48 isp#(config)router bgp isp#(config-bgp)nei 2001:db8:0:1::2 remote-as 64501 isp#(config-bgp)nei 2001:db8:0:1::2 desc Customer_Name isp#(config-bgp)no nei 2001:db8:0:1::2 activate isp#(config-bgp)add ipv6 uni isp#(config-bgp-af)nei 2001:db8:0:1::2 activate isp#(config-bgp-af)nei 2001:db8:0:1::2 filter-list as64501-ipv6-filter in isp#(config-bgp-af)exit isp#wr mem
So the breakdown of these steps is:
- enter configuration mode on router
- build a filter to restrict what the customer (you) are allowed to announce (seq optional but required for multiple entries in list)
- enter BGP configuration mode
- create a specific session using target/destination IPv6 address and ASN of customer
- optionally add a description of the session perhaps to track who it is more clearly
- you don’t want IPv4 routes going out or coming in over the session, IPv6 routes only
- change address-family for IPv6 specific BGP settings
- activate sending and learning IPv6 routes over the session
- apply the filter for accepting INBOUND routes from you/customer
- exit & then write out the config
On the customer side it is similar but not exact:
you#conf t you#(config)ipv6 prefix-list outbound-ipv6-filter seq 1 permit 2001:db8:1234::/48 you#(config)router bgp you#(config-bgp)nei 2001:db8:0:1::1 remote-as 64500 you#(config-bgp)nei 2001:db8:0:1::1 desc ISP_Name you#(config-bgp)no nei 2001:db8:0:1::1 activate you#(config-bgp)add ipv6 uni you#(config-bgp-af)network 2001:db8:1234::/48 you#(config-bgp-af)nei 2001:db8:0:1::1 activate you#(config-bgp-af)nei 2001:db8:0:1::1 filter-list outbound-ipv6-filter out you#(config-bgp-af)exit you#wr mem
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:
isp#sh ipv6 bgp nei 2001:db8:0:1::2 routes There are 1 accepted routes from neighbor 2001:db8:0:1::2 Searching for matching routes, use ^C to quit... Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH S:SUPPRESSED F:FILTERED s:STALE Prefix Next Hop Metric LocPrf Weight Status 1 2001:db8:1234::/48 2001:db8:0:1::2 1 140 0 E AS_PATH: 64501
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:
ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48 le 64
ipv6 prefix-list as64501-ipv6-filter seq 1 permit 2001:db8:1234::/48 le 128
With the obvious requirement that the BGP sessions would need to be configured as blackhole community enabled on both sides.
One of the ISP participants in WorldIPv6Launch day is AT&T. They are working towards a goal of having at least 1% of their wired residential customers have IPv6 connectivity. A recent post on the NANOG mailing list states that they have started this with 6rd.
6rd was first launched into production by a residential ISP in France, Free.fr. Comcast was also looking at 6rd for their deployment as part of their trials. Their 6rd trial ended June 2011, and they have since decided that they will deploy native dual-stack to their customers.
Similar to 6to4, 6rd can work for getting your users connectivity, but does require the CPE or directly connected computers to understand and be compatible with 6rd. Another issue would be overloaded relays or what happens when one goes down. Users of 6to4 see this frequently, however with 6to4 it can be a bit more the troubleshoot which relay is having the issue. With 6rd it should be more obvious, and thus quicker to address since the relay is only operated on the residential ISP’s network.
I’ll preface this by stating that I’m still under NDA with Blizzard regarding their IPv6 deployment, so there are details I cannot get into.
For World IPv6 day in June 2011, Blizzard committed themselves to making their extremely popular MMO, World of Warcraft, available over IPv6. The only catch was that if their client detected that your only IPv6 connectivity was from either 6to4 (2002::/16) or Teredo (2001::/32) automatic tunnel methods, the option to use IPv6 would be made unavailable. This was because of the potential for a poor playing experience because of overloaded or poorly managed relays. However if you used a statically configured tunnel, from either HE.NET/Sixxs/etc., there was no distinction between those tunnels or native IPv6.
They also made it incredibly simple to enable IPv6 for their game. So if you play, and have native IPv6 or one of the statically configured tunnels from a provider, here is how you enable it with a few clicks. Fire up the game, and select Options on the log in screen:
On the options screen, select Network and you should see a check-box for enabling IPv6, as long as you aren’t connecting from either 6to4 or Teredo. Go ahead and check the box and save by clicking on Okay:
At this point, if you log into the game, and your server is part of the IPv6 enabled shards/servers/etc., you’ll be connected over IPv6. In-game, if you mouse over the Game Menu button/icon, it will display your connection information in the ToolTip window. Below you can see that it is preferring to connect over IPv6. Latency was high since the game was still installing. However retesting after a completed install, I’ve got on average 36-42ms over IPv6 to the realm server:
So that is it. That is how easy it is to enable WoW to use IPv6. Kudos to the Blizzard team for taking this important step into bringing some major content onto IPv6. Now if they would just do this with their patcher. Maybe they will for World IPv6 Launch 🙂
One of the great server technologies for Out-of-band management is IPMI (Intelligent Platform Management Interface), and more importantly version 2.0. This version allows for a true IP/KVM experience for the user to manage their server remotely. My preferred server hardware is from Supermicro for cost and features. For this example of IPMI available on IPv6, I’ll use their X7SPA-HF Atom based server board using the ATEN IPMI chipset.
Let me start by saying this IPv6 implementation is far from perfect, but who to blame: ATEN or Supermicro? First, you cannot configure IPv6 in the BIOS menu at all. You’ll need to configure it via the web software after you can reach it over IPv4. So log in and select Network under the Configuration menu.
So on this page, you’ll see all the network configuration options, most importantly IPv6. This implementation appears to support configuration either using SLAAC (autoconfiguration) or DHCPv6. You can also add a static IPV6 address. HOWEVER: you cannot manually configure an IPv6 default gateway/router. This means you are relying on the availability of Router Advertisements on the network to autoconfigure the gateway/router address.
So that is pretty much it. Not terribly hard to get up and running on IPv6, but could be done a little bit better in my opinion. It would be nice to see IPv6 configuration at the BIOS level.