[arin-ppml] The non-deployment of IPv6

[Lee Howard]

I'm responding to Chris Engel in this message, using his plans for what
he'll do after ARIN can't fulfill IPv4 requests.  But it's only an example,
and the broader points apply to everyone who isn't planning to support
IPv6 in 2011-2012.

Those points are:
* Vendors may not come to your rescue.
* Your plan may include more IPv6 than you realize.
* In most cases, IPv6 is simpler and cheaper than the alternatives.


> > Lee Howard wrote:
> > "I'm very skeptical.  Stateless NAT46/64 means a 1:1 mapping 
> > of addresses, which doesn't help after IPv4 is unavailable.  Stateful 
> > NAT46 isn't even on the table at IETF yet.  Doubtful we'll have a 
> > product in time.  No equipment vendors say they'll have one-to- 
> > many address family translation by EOY 2011"

> Took me all of about 5 minutes on Google to find this. Haven't dug too 
> deeply into it yet, but it seems to address the sort of issues we'd be facing.
> http://www.f5.com/products/big-ip/feature-modules/ipv6-gateway.html

I can't find anything on their website about how they're doing it.   It's 
important; I'll call F5 and ask them.  Stateful?  Stateless?  Works both
ways, regardless of where traffic originated?  Works for UDP and ICMP?
Solves the MTU mismatch problem?

> Again demand for these types of services is going to be big on the 
> corporate end... switching over to IPv6 native is just NOT going to be 
> a good option for most. At the very least, it's going to be a VERY 
> expensive option... which means they are going to be willing to spend 
> significantly on some sort of gateway/translation services so they don't 
> have to do so. Are you trying to tell me that vendors are simply going to 
> ignore all that cash waved in thier faces?

Why is it less expensive to buy a big NAT box to translate nearly all of
your traffic than to migrate to IPv6?

> IETF hasn't done much to address those sort of options because IETF 
> seems to have an allergic reaction to the term NAT....

IETF does whatever the people who participate want done.  Many of
the people who would implement AFT (Address Family Translation)
at your favorite network equipment vendor are working on it at IETF
They're already working on it, and don't think they'll have it in time; 
are you betting your company that somebody else will just make a 
drop-in product you can buy on your budget?

> > "As an enterprise network operator, do you support a VPN for 
> > remote employees?  Once they can't get a global IPv4 address, 
> > if they change ISPs they'll either be behind IPv6 or large-scale 
> > NAT (i.e., NAT444).  Will your VPN work?"

> Yes, and I don't know. However the general way to address that 
> issue would be to look for a VPN solution that could handle that. 
> You don't redo your entire network infrastructure just to address 
> a single problem issue like that.  

Depends on how important the problem is.  But now you've just 
bought a big NAT64 box, and a new VPN solution.  Of course, you
still need monitoring and management systems to support those new
things.  This is all still cheaper than just learning and using IPv6?

> Again, I don't assume it will be difficult to find a VPN client that can 
> provide connectivity to a IPv6 edge device...once that connectivity is 
> established the remote employee's machine would be getting an IPv4 
> Private Space Address anyways....the only thing that IPv6 would be 
> needed for would be to establish the tunnel.

Well, IPSec with AH won't work.  It's already broken by NAT.
Your VPN concentrator will be IPv4 or IPv6?  If it's IPv4, then you
have to have a translator in front of it (so you already have at least
a data center routing and switching infrastructure running IPv6), and
you have to figure out what the IPv4 address it'll translate to (since 
the IPv4 address of the VPN client is a private IPv4 address, which
you don't control and which may have routing conflicts for you).
If it's IPv6, then the only thing on the VPN that's not IPv6 is the VPN
client host, which just needs an O/S upgrade [1].  Oh, and you still have
to figure out the data center routing and switching.   And the security
and the monitoring and management systems.  And train your helpdesk.
Geez, why not just do IPv6?

I agree that your network is yours to figure out.  But everyone needs
to spend several dedicated hours writing a project plan for how they
will respond to an unavailability of IPv4 from ARIN.  Compare 
different possible strategies, make a good business decision, and 
implement the plan.  Do it this month, because IPv4 runout projections
are variable, and the plan you choose may require budget and labor in
2010.

Lee

[1] to an O/S issued in 2007 or later, which by end of 2011 is pretty
minimal; would you even allow something older on your network?  
Arguably; even WinXP might work, as long as you had a hack to do
IPv4 lookups.  I understand Windows 7 uses IPSec built into IPv6 by 
default, so that's a cheap option.  



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20091214/60e96351/attachment.htm>