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

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Tue, 13 August 2013 15:20 UTC

Return-Path: <evyncke@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9217411E80A2 for <v6ops@ietfa.amsl.com>; Tue, 13 Aug 2013 08:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH65JjNgVDtH for <v6ops@ietfa.amsl.com>; Tue, 13 Aug 2013 08:20:42 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CA51B21E808C for <v6ops@ietf.org>; Tue, 13 Aug 2013 08:20:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8383; q=dns/txt; s=iport; t=1376407241; x=1377616841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NeCXqYMsA/QKi33TFNFU2W+9xVD5jAfZ6LIlaG2LN7I=; b=aSpklaY057EXw02Mio6vaybaqUGYlMZUgLK7/TTa4ha98T7gVBRayg89 UwXQTsaH+CaH2uL3u7xEZPy/LcdoGjbBjJ0sf6suBaIw+7T96wQpj8bGc O1kdPZoWonruZYOMfF64sRyAPU5pcSgqUXpeLUcuxF42E0aLtin3rNPBi g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAIJNClKtJV2Z/2dsb2JhbABbgwY1UL5cgSIWdIIkAQEBBAEBASRHAwgMBAIBCA4DBAEBAQodByEGCxQJCAIEAQ0FCBGHZQMPDK8ZDYhejUWCRjEHBoMVdgOIdY0GjhOFJ4FhgTqCKg
X-IronPort-AV: E=Sophos;i="4.89,870,1367971200"; d="scan'208";a="246773343"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 13 Aug 2013 15:20:41 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7DFKfNZ024748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Aug 2013 15:20:41 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 13 Aug 2013 10:20:40 -0500
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Ray Hunter <v6ops@globis.net>, Gert Doering <gert@space.net>
Thread-Topic: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]
Thread-Index: AQHOlDUr32tAPm6ECUujdCwLB2VfdpmLpDYAgAAwrYCAAAmAgIAABlqAgAdjsZA=
Date: Tue, 13 Aug 2013 15:20:39 +0000
Message-ID: <97EB7536A2B2C549846804BBF3FD47E113130A07@xmb-aln-x02.cisco.com>
References: <201308041800.r74I03pC023049@irp-view13.cisco.com> <5200804D.2050006@gmail.com> <CAD6AjGTGL9JVK6egOAVXhMFv77L0b=9eVjKAauwNzLnaM=Mcyw@mail.gmail.com> <52031D69.3070604@gmail.com> <CAD6AjGTAJVvmG_byRMW_F2g+WDBvdRLop_oLshgwbUsfBjRzbA@mail.gmail.com> <CAKC-DJh1q+sJB00yo7HsFifWb=42teg_ga4CjRQVVecU1emcDA@mail.gmail.com> <5203C7E5.3060106@globis.net> <20130808170533.GI65295@Space.Net> <5203D531.1080207@globis.net>
In-Reply-To: <5203D531.1080207@globis.net>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.185.71]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-incremental-ipv6 WGLC]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Aug 2013 15:20:46 -0000

Ray,

Reading you late (Summer time...)

I know several enterprises running out of RFC 1918 (WiFi, BYOD, VoIP, bad addressing plan, mergers & acquisitions)

Else, I agree with you: IPv4 will probably die on the Internet core first than in all enterprises. But, a lot of very big and very small enterprises will be IPv6-only first IMHO (reading my cheap crystal ball)

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
> Ray Hunter
> Sent: jeudi 8 août 2013 19:28
> To: Gert Doering
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] IPv6-only section [draft-ietf-v6ops-enterprise-
> incremental-ipv6 WGLC]
> 
> > Gert Doering <mailto:gert@space.net>
> > 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.
> 
> 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.
> 
> 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.
> 
> 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?
> >
> > Dual-stack is a major cost factor.
> >
> > Gert Doering
> > -- NetMaster
> > Ray Hunter <mailto:v6ops@globis.net>
> > 8 August 2013 18:31
> > Erik Nygren wrote:
> >> It's also likely the case that at least some enterprises control
> >> portions of their environments well enough that mostly-IPv6 could
> >> potentially be much more viable than a residential environment.  For
> >> example, a retail store chain using HTTP-based POS terminals and
> >> kiosks may have enough control over their environment that they could
> >> ideally deploy an IPv6-only environment and just use
> >> NAT64/DNS64
> >> to get to some of their supplier websites that still require IPv4.
> >> It might also be attractive to some US Government agencies who
> >> control the devices and clients within their network to use this
> >> approach as part of meeting the OMB September 2014 mandate for IPv6
> client support.
> >> That could be simpler for those agencies than rolling out a
> >> dual-stack environment.
> >> (I'm very curious if either of these cases exists in production in
> >> the field today...)
> >>
> >>       Erik
> >>
> >
> > Why would anyone in their right mind chose to deploy NAT64/DNS64 in a
> > commercial environment given the prices I've seen for that
> functionality?
> >
> > I can't imagine them wanting something like that in operations either.
> >
> > It's likely to be much cheaper to let legacy applications die off
> > naturally, run dual stack or even dual servers for some systems, and
> > deploy a combination of simple forward and reverse web proxies for the
> > rest (assuming web based apps).
> >
> > AFAIK There's still stuff happily running Bisync (BSC) out there (over
> > IP tunnels) and support for that was deprecated in the 1970's in
> > favour of SNA. So I wouldn't hold your breathe waiting for 100%
> > migration to IPv6. It's going to be pretty easy to maintain a private
> > IPv4 - IPv4 network over a GRE tunnel over an IPv6 Internet for a very
> long time yet.
> >
> >> On Thu, Aug 8, 2013 at 8:45 AM, cb.list6 <cb.list6@gmail.com
> >> <mailto:cb.list6@gmail.com>> wrote:
> >>
> >>
> >>     On Aug 7, 2013 9:24 PM, "Brian E Carpenter"
> >>     <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
> >>     wrote:
> >>     >
> >>     > On 08/08/2013 16:08, cb.list6 wrote:
> >>     > > On Aug 5, 2013 9:49 PM, "Brian E Carpenter"
> >>     <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>
> >>     > > wrote:
> >>     > >> On a different topic, section 5 covers IPv6-only issues.
> >>     > >> I'm a bit concerned that this might need a health warning:
> >>     > >> deploying NAT64/DNS64 might cause pain and suffering.
> >>     > >> Perhaps after this text:
> >>     > >>
> >>     > >>>    Together, RFCs
> >>     > >>>    6146 and RFC 6147 provide a viable method for an
> >>     IPv6-only client to
> >>     > >>>    initiate communications to an IPv4-only server.
> >>     > >> we should add something like:
> >>     > >>
> >>     > >>    At enterprise level, operating NAT64 and DNS64 services for
> >>     > >>    heavy usage may have significant practical implications.
> >>     > >>
> >>     > >
> >>     > > Can you be more specific? Pratical data?
> >>     >
> >>     > Not really, because I've never operated one in real life. It
> doesn't
> >>     > strike me as the sort of service that most enterprise network
> >>     > managers will be familiar with, and a v6-only site needing a
> normal
> >>     > level of access to v4-land would end up sending most of its
> external
> >>     > traffic via NAT64 and most of its external DNS queries via DNS64.
> >>     > Therefore, these would become an important single point of
> failure
> >>     > and a potential bottleneck. The text doesn't seem to point this
> out.
> >>     >
> >>
> >>     Agree with Joel, nat64 will be parity with common nat44 and
> >>     firewalls in terms of availability
> >>
> >>     Regarding majority of traffic, i believe the scales have tipped to
> >>     show v6 is the majority for campus networks, which is the best
> >>     proxy in the available data
> >>
> >>     http://www.worldipv6launch.org/measurements/
> >>
> >>     These numbers also skew low since Apple has a non-deterministic
> >>     happy eyeballs
> >>
> >>     Given that enterprises and all users of IP are out of ipv4, so
> >>     they need to not use ipv4 yet have access to it, guidance against
> >>     nat64 will frustrate the issue.
> >>
> >>     Guidance should be given to make as many flow v6 e2e. Full stop.
> >>
> >>     CB
> >>
> >>
> >>     >    Brian
> >>     >
> >>     > > CB
> >>     > >
> >>     > >> Also, the last paragraph of section 5:
> >>     > >>
> >>     > >>>    It is worth noting that for IPv6-only access networks
> >>     that use
> >>     > >>>    technologies such as NAT64, the more content providers
> (and
> >>     > >>>    enterprises) that make their content available over IPv6,
> >>     the less
> >>     > >>>    the requirement to apply NAT64 to traffic leaving the
> >>     access network.
> >>     > >> A reference to RFC 6883 would fit nicely there.
> >>     > >>
> >>     > >> Regards
> >>     > >>    Brian
> >>     > >> _______________________________________________
> >>     > >> v6ops mailing list
> >>     > >> v6ops@ietf.org <mailto:v6ops@ietf.org>
> >>     > >> https://www.ietf.org/mailman/listinfo/v6ops
> >>     > >
> >>
> >>     _______________________________________________
> >>     v6ops mailing list
> >>     v6ops@ietf.org <mailto:v6ops@ietf.org>
> >>     https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >>
> >
> >
> > ----------------------------------------------------------------------
> > --
> 
> 
> --
> Regards,
> RayH
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops