Dual stack is definitely the way to go; tunneling IP over IP or involving NAT64 (e.g. 464xlat) has all the usual MTU and protocol busting issues. Using 6PE in the core and 6rd at the edge is tolerable as a short term measure while you get the backbone up to snuff. Keep very far away from the "automatic" client tunnels like ISATAP, 6to4, and Teredo, which are all being deprecated. Offering 6in4 point to point tunnels to customers as an interim measure could be helpful. It's customary to allocate /64's but run /127's for point to point.
Definitely worry about IPv6 in the core as a medium run issue, but it needn't be your first priority. However, given the various tunneling problems, getting your core native will give a better customer experience. PMTU discovery tends to be a bit erratic in the best of circumstances, latency and jitter are both worse with tunneling, and error reporting from congested tunnel hops suffers.
Begin with your network monitoring infrastructure; in the presence of any dual stack devices, which is pretty much 100% of anything deployed in this decade, you need to be watching both protocols. The tricky thing on the v6 side is that the devices will be using both global and local scope address on an ongoing basis, unlike v4, and they are liable to change the global scope address host parts at whim, unlike v4. Also, v6-enabled destination web sites are likely to be v6-mostly rather than v6-only; there are bound to be 3rd party CDN's or ad networks or something that is still v4-only, so that the v6 clients are emphatically dual-stack. Forensics for dual-stack network pretty much requires scraping the switch ports via SNMP to let you correlate current v6 addresses with v4 with layer-2 MACs.
The next step is getting switches and routers to forward v6, ideally native. You need to do your upstream interfaces before your customer edges, I think. Unless the network was built out of baling wire and chewing gum, the existing devices ought to be capable of line-rate v6 by now. However, the maturity of v6 stacks is lower than v4, so it's best to test any new firmwares before trusting that the vendor got it right. The large deployments from folks like Google, Facebook, Yahoo, Comcast etc. all ran into v6 firmware bugs along the way, and you may too. Budget time to work with your vendors into your deployment. While v6 probably mostly works, you may not find feature parity with v4.
You'll usually end up splitting any TCAM resources 50:50 between the protocols, so keep a wary eye on sizing issues. While external v6 routes are potentially twice the size (/48) of v4 (/24), the aggregation is empirically about 7x better on v6, so a v6 route cache is likely to actually be smaller than its corresponding v4 cache. However, you'll have plan to do both for the next decade, so the net memory load is still going to be higher. With v4 exhaustion the amount of address block trading is going create v4 dis-aggregation pressures, so the v4 situation is likely to seriously deteriorate over the next 2-6 years. If you aren't running any DFZ backbone routers, you may not care.
Third, firewalls. You want the same security on v6 as on v4, so you'll be filtering v6 on pretty much the same conditions as v4. After all, they are both packet-switched, next-hop routed, best-effort delivered. Be sure not to block all ICMPv6; while blocking all ICMP is bad on v4, on v6 it's catastrophic. In particular, transparent mode firewalls have to pass RS, RA, NS, NA between the upstream router and the downstream clients (types133-136), plus you'll want to let in the error types (1-4).
Layer 2 defense issues on v6 are a little tricky; ND spoofing is even harder to defend against than ARP spoofing, and in addition to preventing clients from pretending to be DHCP servers on either v4 or v6, now you really have to prevent them from sending rogue RA's. v4 actually allowed RA's too, but no one ever used them, so no one cared. On v6 the only way to get the LAN address of an upstream gateway is by scraping the link-local v6 sender off the RA packet - it's not a DHCPv6 option - so everyone cares about the integrity of the RA's now. This is an unsolved problem on Wifi.
Fourth, DNS. All modern DNS servers can store AAAA records and do v6 PTR records under ip6.arpa, and the underlying OS can certainly do v6 by now, so that's just a matter of configuring it. Ignore the experimental A6 and DNAME types; no one is using them. The sticky point for DNS is likely to be IPAM or CPE provisioning systems; those might have to be upgraded too. Probably your vendors latest version is dual stack, but is that the one you are running? If the network is small enough to maintain by hand, just go for it.
Fifth, outward facing web sites. The complication there is that backend systems will have to be prepared to do analytics, cookies, logging etc. with v6 addresses. Having load balancers or web front end proxies be dual stack isn't usually a problem by now; all of the usual suspects like apache, IIS, nginx etc. can handle it. It's not a priority to make the entire backend datacenter be dual stack or v6-only unless you are the size of facebook - they ran out of rack numbering space under 10.0.0.0/8 a while ago. No one cares if an app server is talking to a DB server over v4 as opposed to v6, as long as the front-end is dual-stack and the DB schema can handle v6 addresses. One option is to represent v4 as ::ffff:p.q.r.s v6 "mapped" address, and just log as 100% v6.
Ironically, dual-stacking e-mail is not a priority; anti-spam measures for v6 are lagging v4 and the 200k or so legit SMTP servers on the planet all have v4, and will continue to for a while longer. Save e-mail for last.
Rule of thumb: weeks to enable v6 for clients, months to re-engineer outward facing DMZ services, years to go v6-only on the back end.
Most production dual-stack networks are currently running with DHCP for v4, and SLAAC for v6. Downlevel OS's tend to not implement DHCPv6, and all but the most recent consumer-grade modems and wifi gear tends to get DHCPv6 service wrong; they are particularly likely to flub prefix delegation. Unless you control the CPE gear, plan on initially only delegating v6 /64's to home users for now, with an eventual upgrade to /60 or better later on.
A v6 /48 is actually a little small for an ISP; see if you can upgrade to a /44 or a /32, so that you can give your customers /48's. And do sprawl across your v6 address space to make your subnet planning resilient in the face of expected changes; unlike v4, v6 subnets are not a scarce commodity.
Best wishes with this,
-- Jim Leinweber, WI State Lab of Hygiene
