Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]

[Ray Hunter <[e-mail]>]

> Owen DeLong <mailto:[e-mail]>
> 8 August 2013 19:54
> On Aug 8, 2013, at 10:28 AM, Ray Hunter <[e-mail]> wrote:
>
>>> Gert Doering <mailto:[e-mail]>
>>> 8 August 2013 19:05
>>> Hi,
>>>
>>> To get rid of dual-stack operations, while still being able to benefit
>>> from the large address space of IPv6 inside the enterprise?
>> Who has an IPv4 address shortage *inside* the enterprise?
>> And what are these benefits *inside* the enterprise?
>> LAN switches are written off over at least 10 years in the book keeping.
>
> Arguably, anyone using RFC-1918 space is suffering from an address
> shortage inside their enterprise. Given the clear and obvious benefits
> of eliminating NAT and having globally unique addresses for every
> system which communicates with the internet, I wonder how you can
> ask such a question with a straight face.
But that pain has been solved 5 years ago in most places I work. There's
no burning platform.

How would introducing a new technology like NAT64/DNS64 make things
better in places where it hasn't been solved?
[the original point of the thread] it's yet another NAT box.
>
> A 10 year depreciation on switches is absurd. Most enterprises I know of
> use either a 3-year or 5-year depreciation schedule for network equipment
> such as LAN switches and many end up retiring them faster than they
> depreciate.
>
>> AFAICS the only thing most large enterprises are worried about right now
>> is the border, and Internet and outward facing systems (and rightly so).
>> They'll be able to run *private* IPv4 networks over MPLS or GRE or
>> something else for many many years to come, with all of their important
>> partners, and there'll be plenty of vendors wiling to support them on
>> old kit at cut prices.
>
> I think you are right about what most enterprises are worried about right
> now (if they are even paying attention at all). However, enterprises are
> not exactly known for paying attention to anything more than 3 months
> away from now, so I don't think that's a great yardstick.
>
> It will be interesting to see how this plays out. I think that the cost of
> continuing to support IPv4 in the face of an ever-increasing proportion
> of the internet not being IPv4 capable will lead enterprises to abandon
> IPv4 for the most part much faster than is currently anticipated.
>
> We saw this with the IPX->IP transition. Everyone thought we'd be
> running IPX everywhere for 20-30 years, yet once IP gained critical
> mass in the enterprise, IPX all but disappeared in less than 5 years.
>
>> If SNA or DECnet IV is any transition model to go by, it took about 20
>> years for them to die inside most enterprises, whilst they generally
>> died much quicker at the border. It went something like: native SNA or
>> native routed DECnet IV on original vendor equipment -> multi-protocol
>> routers -> tunnelled SNA or DECnet IV -> islands with gateways ->
>> islands -> switch off.
>
> I think IPv4 will get to the islands with gateways much faster than DECNET
> or SNA. I think that the IPX (and/or Appletalk) transition(s) to IP are a much
> more informative model.
>
> SNA, especially, was a very different networking model from IP and IBM
> (as well as HDS and other IBM clones) were very very slow to support
> TCP/IP other than through gateways. They still depended on SNA for
> the vast majority of their peripherals, terminals, etc. It wasn't until most
> 3270/5250 terminals were replaced by PCs that the real move away
> from SNA started in earnest. At that point, SNA mostly disappeared fairly
> quickly. Much less than 20 years.
>
> IPX and Appletalk, OTOH, provided very similar overall services on a very
> similar conceptual model to IP. As a result, that transition was quite a bit
> easier and the enterprise migration consequently happened quite rapidly.
>
> I'm sure you can still point to islands of IPX or Appletalk running here and
> there in a few enterprises, but what was once the flagship product of a
> major player in the industry (IPX / Novelle) is now basically relegated
> to history and the company is an also-ran at best.
>
>> The final straw was making end users pay pro-rata for the support costs
>> of the shrinking infra. IMVHO Whilst there's still economies of scale,
>> there's simply no business case *inside* the enterprise except for
>> opportunistic switch on at standard scheduled lifecycle renewal. I've
>> been through this loop myself. But then again, why should the IETF care
>> what happens in that case if the border interface is clean and IPv6 only?
>
> The IETF probably shouldn't really care. However, this is  an informational
> RFC intended to help enterprises get from A to B in an orderly manner. As
> such, I think it is appropriate to document that process.
>
> Further, I think you will see the escalating cost of IPv4 at the eyeball ISP as
> the first driving factor for deprecating IPv4 and I think that will happen quite
> a bit faster than most people expect.
>
> As a general rule, once CGN starts to be widely deployed and ISPs start
> having to charge extra to cover the escalating costs of CGN (especially
> WRT the CALEA implications), you'll see consumers choosing IPv6 only
> over paying extra for even more degraded IPv4 service.
>
> Owen
>
>
Actually I think your reasoning and reference to the IPX and Appletalk
phase out would suggest it's easier to make a bold call: move to IPv6
ASAP for critical systems via dual stack, and for the rest you draw a
box around it and call it legacy and run it on IPv4 until it dies a
natural death.

IMHO Going half way with NAT64/DNS64 just prolongs the pain and locks
you into a transition technology that is expensive and difficult to
operate for the life cycle of that box, and which has to remain in place
until the last app is migrated or switched off.

I've been in a fair number projects where you sometimes just have to
dare to cut the cord whilst maintaining a process to find out what has
broken. So one valid IPv6 only migration strategy might be: "If it's
important, they'll migrate before a flag day date. Otherwise they get
cut off."

-- 
Regards,
RayH