<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 14, 2009, at 9:15 PM, Stephen Sprunk wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Steve Bertrand wrote:<br><blockquote type="cite">I'm trying to envision the problem from your perspective. I'd like to<br></blockquote><blockquote type="cite">ask this:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What, if anything, would your ISP be able to do to help you at least<br></blockquote><blockquote type="cite">begin the transition/implementation?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Is there anything that an ISP could do differently other than just be<br></blockquote><blockquote type="cite">'IPv6 enabled'?<br></blockquote><br>That is a necessary first step. It's hard for an ISP to convince their<br>customers to enable IPv6 when most ISPs won't even sell them IPv6<br>connectivity or, if they sell it, can't actually deliver it.<br><br>After that? Enable IPv6 on every customer circuit and assign every<br>customer an IPv6 PA prefix, without waiting for them to ask for one. If<br>they have a PI prefix in v4, send them directions on how to get one in v6.<br><br></div></blockquote>Bad idea... Notify them that the PA prefix is available for the asking: good.</div><div>Assign it whether they want it or not: bad.</div><div><br></div><div>The latter will simply lead to cruft in the database and other issues.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>A much more important step for ISPs is getting the _eyeballs_ on v6,<br>whether native, 6to4, or Teredo. There are hundreds of millions of home<br>and SOHO users out there that need no more than a CPE software update to<br>get on v6. Realistically, how are you going to convince _anyone_ that<br>they need to v6-enable their content when none of the eyeballs can do<br>v6? OTOH, how much convincing will you need to do when market stats<br>show 90%+ of eyeballs have v6?<br><br></div></blockquote>Because in 3 years, none of the new eyeballs will be able to do anything</div><div>but IPv6? Getting the content providers dual-stacked is far more critical</div><div>than getting the eyeballs moved forward. If the content is dual-stacked,</div><div>then, the eyeballs will follow fairly automatically in a few years, or, when</div><div>they start to care about content that is IPv6 only. Either way, that's a</div><div>much easier problem (albeit larger in scope) to solve.</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>As Chris pointed out, there's a lot of old OSes out there. Win2k? <br>Heck, I know places that are still running Win95/98/NT4, OS/2, NetWare,<br>etc. Just getting all the OSes upgraded to something that can do IPv6<br>will be a multi-year project in some places.<br><br></div></blockquote>OTOH, do those hosts running 95/98/NT4 or OS/2, etc. actually matter about</div><div>getting dual-stacked? Do they actually access the internet? Chances</div><div>are not much or they wouldn't still be functional since there are relatively</div><div>well known and widely exploited holes available after end-of-life for</div><div>security updates in most cases.</div><div><br></div><div><blockquote type="cite"><div>Next, after the OSes are up to date, you have to go through every single<br>software package used anywhere in the entire company (officially or<br>not), checking whether or not it can handle v6--and what features<br>silently stop working (a _serious_ problem). This may mean an upgrade<br></div></blockquote><div><br></div>Only if you're turning off IPv4. In general, if the software can't handle IPv6,</div><div>it doesn't break just because you add IPv6 to the box. I suppose there's</div><div>a small chance that an application could be coded so badly that it somehow</div><div>does, but, it's hard to fathom how.</div><div><br><blockquote type="cite"><div>to a newer version, with all the attendant testing, documentation,<br>change management, training, etc. Maybe the vendor has gone out of<br>business, doesn't sell that product anymore, doesn't have a v6-capable<br>version yet, or wants outrageous fees for the upgrade. Maybe you have<br>to find an entirely new product or rewrite some in-house custom app--if<br>you even still have the source code for it. Now repeat that several<br>hundred (or thousand) times.<br><br></div></blockquote>For getting the application to run on IPv6 in order to be able to turn off</div><div>IPv4, sure. Outside of that, not so much.</div><div><br><blockquote type="cite"><div>Consider that it took the better part of a decade for enterprises to<br>switch from SNA, IPX, AppleTalk, Vines, XNS, DECnet, etc. to IPv4--and<br>all they had running on their networks back then were file and print<br>sharing and some dumb terminal emulators. The problem is orders of<br>magnitude worse now.<br><br></div></blockquote>Yes and no.</div><div><br><blockquote type="cite"><div>Realistically, the only way the "transition" is going to happen is to<br>convince them to buy new firewalls that can do NAT64 and let them<br>continue on in their RFC1918-isolated bliss. And, really, as long as<br>their v4-only internal and DMZ hosts can talk to the v6 Internet<br>somehow, isn't that good enough for now? You do not need to look behind<br>the curtain, Dorothy.<br><br></div></blockquote>There's two different transitions being discussed here, and, we need to be</div><div>more accurate about how we talk about them. I think much of the enterprise</div><div>resistance stems from the misuse of the words transition or migration to</div><div>describe the first step. The first step is dual-stacking. Dual-stacking should</div><div>be relatively painless and should not require a great deal of application</div><div>testing, etc. Yes, removal of IPv4 will be painful and take time. The good</div><div>news is that the first test cases for that will be new hosts after IPv4</div><div>addresses are no longer available with the possibility of using IPv4</div><div>NAT as a fallback to back-stop that issue initially while the native</div><div>IPv6 issues are resolved. Once the IPv6-only new hosts are working</div><div>fine without needing IPv4, then, we can look at removing IPv4 from</div><div>the remaining dual-stack hosts and finally the network infrastructure.</div><div><br></div><div>So, let's focus on getting existing services dual-stacked, then worry about</div><div>the next steps.</div><div><br><blockquote type="cite"><div><blockquote type="cite">I'm thinking purely from the perspective of having IPv6 ROUTING<br></blockquote><blockquote type="cite">available. The desktop/server is not what I'm concerned about at this<br></blockquote><blockquote type="cite">point. I just want to know what can be done differently so that the<br></blockquote><blockquote type="cite">backbone of the enterprise can communicate via v6, and when the PCs are<br></blockquote><blockquote type="cite">upgraded, they have a network ready to talk on.<br></blockquote><blockquote type="cite"><br></blockquote><br>Solving the easiest part of the problem and calling it a day doesn't do<br>much good.<br><br></div></blockquote>Yes and no. Solving that part of the problem does a lot of good. Calling</div><div>it a day when you get to that point, however, is problematic. It's a good</div><div>and necessary first step.</div><div><br></div><div>The equally necessary next step is to get existing services dual-stacked.</div><div><br></div><div>Dual-stacking desktops can come MUCH later and be done on a much</div><div>more piecemeal basis. So, the good news is that the hardest part of the</div><div>problem is easily left for last and can be done in small bites over a much</div><div>longer time horizon.</div><div><br></div><div><br></div><div>Owen</div><div><br></div></body></html>