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

[Ray Hunter <[e-mail]>]

> Gert Doering <mailto:[e-mail]>
> 8 August 2013 23:13
> Hi,
>
> Maybe you are using the term NAT64/DNS64 in a different way than Cameron
> and I do that. When I speak about NAT64, it means "go to IPv6-only on
> the inside, and only use NAT64 to talk to those outside hosts that have
> no IPv6".
>
> NAT64 is not a transition technology for your network, it's a transition
> technology for "talking to legacy peers".
Right. But I still don't see a scenario for a hosting location of
"legacy peers" where large scale NAT64/DNS64 makes sense compared to any
number of alternatives that are already well-known within the enterprise
space.

If the legacy apps are located within the enterprise relative to their
users, there's really no visible cost to running dual stack today or in
the foreseeable future.

Show me an enterprise carrier or managed service provider or router
vendor who charges more for their MPLS solution or managed service or
device for IPv4 support. I can show you plenty where IPv6 is a "premium
service." Until IPv4 becomes a "premium service" there's simply no
business case.
That transition has happened on the public Internet: public IPv4 is
starting to cost more on the public Internet, and it's visible to consumers.

If the legacy apps are located on the Internet, there are already any
number of border solutions in place: proxies, gateways, VPN's, and
stepping stones that can be adapted to perform the translation at a
higher layer, or to tunnel the IPv4 traffic over IPv6, without resorting
to DNS64/NAT64. Bearing in mind that most enterprises anyway run split
DNS, and resolving Internet addresses by end hosts located within the
border is the exception rather than the norm (although that is changing),

If the legacy apps are located on trusted 3rd party sites, or hosted
provider sites (private-cloud) then IPv4 issues can be solved
commercially to ensure native IPv4 support is available for a fixed
support period, or by introducing IPv4 over IPv6 tunnels or private links.

I agree entirely that the border needs to adapt, and quickly, because
that's where the business risks are.
I also get why ISP's like DNS64/NAT64 in an "eyeballs network."


As to the point of going pure IPv6 only on the inside: that also
introduces a new merger and acquisition risk. If your take over target
has gone pure IPv6 only, and you are still running dual stack, or vice
versa, that's IMHO tougher to transition than if you are both still
running dual stack. I wouldn't want to be the guy who had to go to my
boss and say "we need to turn IPv4 back on and it's going to cost us X"
after having spent a fortune on going IPv6 only.



Specifically looking at the draft text.

"the long term enterprise network roadmap should include
   steps on gradually deprecating IPv4 from the dual-stack network"

Why gradually? As Owen points out, IPX and appletalk phase out was
disruptive and fast.

Depending on the enterprise's strategic plan, a flag day approach to
turning off IPv4 is equally valid IMHO.
Never mind the technical aspects, a cut off date concentrates people's
minds.

Equally, given the history of the SNA, DECnet phase out, a strategy of
declaring certain systems "legacy" and running them as-is using native
protocols on the long-term until they reach a natural end of life would
also seem a valid strategy . A network might never reach pure IPv6 only,
and that IMHO would not be a problem.

"However, in
   the current environment, given that IPv4 is the dominant protocol on
   the Internet, an IPv6-only node most likely needs to talk to an
   IPv4-only node on the Internet."

I question this statement. There are plenty of enterprises that do not
allow any direct IP level session from an end node within the enterprise
to a server located on the public Internet. The adaptation can then take
place in a border system e.g. proxy or ALG, and both end-user devices
see their own native protocols.

"It is therefore important to provide
   such nodes with a translation mechanism to ensure communication
   between nodes configured with different address families."

Why? That's just one of many options.

Proxies and ALGs are well-known practice in the enterprise, they are
already deployed and well-understood, and IMHO there's no need to
deviate from that solution just to obtain IPv6 support on the outside
interface of the border unless there are other benefits. So just adding
IPv6 to the outside interface of these services is a perfectly valid
long-term solution IMHO. That also means you have less touch-points in
your migration plan.

I also have a customer who has specifically stated "there shall be no
address family translation within the network transport service" and "we
shall transport native protocols only end-to-end between end user
systems" (tunnels are OK but they must terminate on network equipment,
not end nodes). There are no magic boxes to make the pain go away. And
they just don't want the complexity and costs in that layer.



>
> Gert Doering
> -- NetMaster
> Ray Hunter <mailto:[e-mail]>
> 8 August 2013 22:40
>> 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