I suspect the challenges most face is Change Advisory Boards or managerial oversight on configuration changes. This means you're going to have to justify the changes (IPv6 ones) made and hence the selling it to C-level IT people so these changes aren't dismissed out of hand and supported. Then there's the risks that we understand and CAB's don't.<div>
<br></div><div>As an end user, my biggest issue is that way cisco CPE's deal with range allocation. 12 months ago you could abuse general-prefix in dhcp for SLAAC deployments. I hope that's change for the sake of ISP support desks and the like.</div>
<div><br></div><div>Just my $0.02.</div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 2:41 PM, Joshua D'Alton <span dir="ltr"><<a href="mailto:joshua@railgun.com.au" target="_blank">joshua@railgun.com.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And the Oscar for best IPv6 deployment strategy goes toooo... Mark Newton! If it was Friday I'd buy you a beer.<div class="HOEnZb">
<div class="h5"><br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 3:38 PM, Mark Newton <span dir="ltr"><<a href="mailto:newton@atdot.dotat.org" target="_blank">newton@atdot.dotat.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Mar 06, 2013 at 12:46:57PM +1000, Paul Gear wrote:<br>
<br>
> Nicely written, but moving away from the question again. Mark, what are<br>
> these low-key activities that we should have done in 2011 that are easy<br>
> to sell to management?<br>
<br>
</div>If they're low-key activities you don't need to sell them to<br>
management.<br>
<br>
You don't sell your IPv4 plan to management, do you? (unless they're<br>
actually micromanagement, in which case you probably have no hope).<br>
<br>
Steps:<br>
<br>
There are many ways to go about it, but here's one of them. Contents<br>
may settle in transit.<br>
<br>
1. Enable IPv6 on at least one of your transit edge routers.<br>
<br>
2. Take an IPv6 feed from at least one of the transit providers<br>
that lands on that router. You should now have connectivity<br>
to the IPv6 internet from that router.<br>
<br>
3. Nail-up IPv6 iBGP between that router and at least one<br>
router in your core. Congratulations, you should now have<br>
connectivity to the IPv6 internet from your core. It's<br>
only single-homed, but it's not mission critical yet so<br>
outages don't really matter, do they?<br>
<br>
4. You can now assign IPv6 prefixes to VLANs in your core.<br>
Start with your lab VLAN; hosts in your lab should now have<br>
full dual stack reachability to the internet.<br>
<br>
5. At your option, stand up other iBGP and eBGP sessions to<br>
other border routers and transit providers. Each one improves<br>
your redundancy and gets you incrementally closer to the same<br>
full mesh topology you have with v4.<br>
<br>
6. You'll eventually be at a point where all your routers are<br>
dual stack. Along the way you probably will have turned on<br>
all your lab VLANs, and possibly enabled your office network<br>
and any intermediate firewalls in the path. Congratulations,<br>
you now know how IPv6 firewalling works, and all your staff<br>
have access too.<br>
<br>
7. If you have a VPN concentrator, dual-stack that too; now your<br>
staff have dual-stack on your network from home. Even better.<br>
<br>
<br>
At that point, you're dual stack on your entire network except<br>
for the bits that are customer-facing, and you've probably been<br>
outage-free throughout the whole process, and haven't had to<br>
buy any new equipment.<br>
<br>
8. Enable "simple" server networks: things like DNS, HTTP and SMTP<br>
that don't involve complexity like load balancers. Probably<br>
a good time to add IPv6 to any VPS products you offer too.<br>
Congratulations, you're now offering IPv6 services to the<br>
public.<br>
<br>
If you're an eyeball service provider, add another step:<br>
<br>
9. The access network -- you'll need radius support and a few<br>
other odds and sods and a fair bit of planning, but is there<br>
any reason you can't dual-stack your BRAS/LNS and customer<br>
access now?<br>
<br>
Now the only bits of your network that aren't v6-enabled are the<br>
"complex" corner cases, which you can deal with at your leisure.<br>
<br>
If you're an IT services provider rather than a network operator,<br>
come up with a service offering that addresses each step in the<br>
plan above (research, develop,test). That's what made your business<br>
successful with IPv4, it'll make it successful with IPv6 too.<br>
<br>
Turn that into a 2 year roadmap and you'll be well on the way<br>
to mitigating your contribution to the IPv4 problem, broadening<br>
your base of service offerings, and improving your scope for<br>
profitability.<br>
<span><font color="#888888"><br>
- mark<br>
</font></span><div><div><br>
_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net" target="_blank">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
AusNOG mailing list<br>
<a href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br>
<a href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br>
<br></blockquote></div><br></div>