<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt">I'm responding to Chris Engel in this message, using his plans for what<br>he'll do after ARIN can't fulfill IPv4 requests. But it's only an example,<br>and the broader points apply to everyone who isn't planning to support<br>IPv6 in 2011-2012.<br><br>Those points are:<br>* Vendors may not come to your rescue.<br>* Your plan may include more IPv6 than you realize.<br>* In most cases, IPv6 is simpler and cheaper than the alternatives.<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">> > Lee Howard wrote:<br>> > "I'm very skeptical. Stateless NAT46/64 means a 1:1 mapping <br>> > of addresses, which doesn't help after IPv4 is unavailable. Stateful
<br>> > NAT46 isn't even on the table at IETF yet. Doubtful we'll have a <br>> > product in time. No equipment vendors say they'll have one-to- <br>> > many address family translation by EOY 2011"<br><br>> Took me all of about 5 minutes on Google to find this. Haven't dug too <br>> deeply into it yet, but it seems to address the sort of issues we'd be facing.<br><span>> <a target="_blank" href="http://www.f5.com/products/big-ip/feature-modules/ipv6-gateway.html">http://www.f5.com/products/big-ip/feature-modules/ipv6-gateway.html</a></span><br><br>I can't find anything on their website about how they're doing it. It's <br>important; I'll call F5 and ask them. Stateful? Stateless? Works both<br>ways, regardless of where traffic originated? Works for UDP and ICMP?<br>Solves the MTU mismatch problem?<br><br>> Again demand for these types of services is going to be big on the
<br>> corporate end... switching over to IPv6 native is just NOT going to be <br>> a good option for most. At the very least, it's going to be a VERY <br>> expensive option... which means they are going to be willing to spend <br>> significantly on some sort of gateway/translation services so they don't <br>> have to do so. Are you trying to tell me that vendors are simply going to <br>> ignore all that cash waved in thier faces?<br><br>Why is it less expensive to buy a big NAT box to translate nearly all of<br>your traffic than to migrate to IPv6?<br><br>> IETF hasn't done much to address those sort of options because IETF <br>> seems to have an allergic reaction to the term NAT....<br><br>IETF does whatever the people who participate want done. Many of<br>the people who would implement AFT (Address Family Translation)<br>at your favorite network equipment vendor are working on it at IETF<br>They're already working on it,
and don't think they'll have it in time; <br>are you betting your company that somebody else will just make a <br>drop-in product you can buy on your budget?<br><br>> > "As an enterprise network operator, do you support a VPN for <br>> > remote employees? Once they can't get a global IPv4 address, <br>> > if they change ISPs they'll either be behind IPv6 or large-scale <br>> > NAT (i.e., NAT444). Will your VPN work?"<br><br>> Yes, and I don't know. However the general way to address that <br>> issue would be to look for a VPN solution that could handle that. <br>> You don't redo your entire network infrastructure just to address <br>> a single problem issue like that. <br><br>Depends on how important the problem is. But now you've just <br>bought a big NAT64 box, and a new VPN solution. Of course, you<br>still need monitoring and management systems to support those new<br>things.
This is all still cheaper than just learning and using IPv6?<br><br>> Again, I don't assume it will be difficult to find a VPN client that can <br>> provide connectivity to a IPv6 edge device...once that connectivity is <br>> established the remote employee's machine would be getting an IPv4 <br>> Private Space Address anyways....the only thing that IPv6 would be <br>> needed for would be to establish the tunnel.<br><br>Well, IPSec with AH won't work. It's already broken by NAT.<br>Your VPN concentrator will be IPv4 or IPv6? If it's IPv4, then you<br>have to have a translator in front of it (so you already have at least<br>a data center routing and switching infrastructure running IPv6), and<br>you have to figure out what the IPv4 address it'll translate to (since <br>the IPv4 address of the VPN client is a private IPv4 address, which<br>you don't control and which may have routing conflicts for you).<br>If it's IPv6, then the
only thing on the VPN that's not IPv6 is the VPN<br>client host, which just needs an O/S upgrade [1]. Oh, and you still have<br>to figure out the data center routing and switching. And the security<br>and the monitoring and management systems. And train your helpdesk.<br>Geez, why not just do IPv6?<br><br>I agree that your network is yours to figure out. But everyone needs<br>to spend several dedicated hours writing a project plan for how they<br>will respond to an unavailability of IPv4 from ARIN. Compare <br>different possible strategies, make a good business decision, and <br>implement the plan. Do it this month, because IPv4 runout projections<br>are variable, and the plan you choose may require budget and labor in<br>2010.<br><br>Lee<br><br>[1] to an O/S issued in 2007 or later, which by end of 2011 is pretty<br>minimal; would you even allow something older on your network? <br>Arguably; even WinXP
might work, as long as you had a hack to do<br>IPv4 lookups. I understand Windows 7 uses IPSec built into IPv6 by <br>default, so that's a cheap option. <br></div></div>
<!-- cg7.c2.mail.re1.yahoo.com compressed/chunked Mon Dec 14 04:25:35 PST 2009 -->
</div><br>
</body></html>