Re: [v6ops] Operational Consensus on deployment

Czerwonka Michał 1 - Hurt <Michal.Czerwonka1@orange.com> Tue, 05 August 2014 09:22 UTC

Return-Path: <Michal.Czerwonka1@orange.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3EB1B2999 for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 02:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.736
X-Spam-Level: **
X-Spam-Status: No, score=2.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUpPulhsjr2f for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 02:22:53 -0700 (PDT)
Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E02E1B2983 for <v6ops@ietf.org>; Tue, 5 Aug 2014 02:22:52 -0700 (PDT)
Received: from 10.236.62.156 (EHLO OPE10HT08.tp.gk.corp.tepenet) ([10.236.62.156]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id BWK75850; Tue, 05 Aug 2014 11:22:47 +0200 (CEST)
From: Czerwonka Michał 1 - Hurt <Michal.Czerwonka1@orange.com>
To: Ca By <cb.list6@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [v6ops] Operational Consensus on deployment
Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvAqKYAgAAE0ACAABWsAIAAcMQAgACEo7A=
Date: Tue, 05 Aug 2014 09:21:52 +0000
Message-ID: <2D29C51862222E49B991EF64EEB0B5B745F85768@OPE10MB05.tp.gk.corp.tepenet>
References: <256EAE0B-5C11-42C7-BCA1-CEC7EE6713A7@cisco.com> <53DFD634.4020304@fud.no> <DE860EBC-171E-46E7-A3B6-5E8B79A453CC@cisco.com> <53DFEC6C.3010707@gmail.com> <CAD6AjGRUWxT5XiNxMi_S5VgYtGMLb_FVHXN-ZfGpcY=geix15g@mail.gmail.com>
In-Reply-To: <CAD6AjGRUWxT5XiNxMi_S5VgYtGMLb_FVHXN-ZfGpcY=geix15g@mail.gmail.com>
Accept-Language: pl-PL, en-US
Content-Language: pl-PL
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/related; boundary="_004_2D29C51862222E49B991EF64EEB0B5B745F85768OPE10MB05tpgkco_"; type="multipart/alternative"
MIME-Version: 1.0
X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2014.8.5.81820:17:8.510, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __IMS_MSGID, __HAS_MSGID, __SANE_MSGID, __IN_REP_TO, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __EXTRA_MPART_TYPE_N1, __EXTRA_MPART_TYPE_1, __MIME_VERSION, __ANY_URI, __FRAUD_BODY_WEBMAIL, __CP_URI_IN_BODY, __SUBJ_ALPHA_NEGATE, SUPERLONG_LINE, __HTML_FONT_BLUE, __FORWARDED_MSG, __EMBEDDED_IMG, __HAS_HTML, SINGLE_IMG_ATTACH, BODY_SIZE_10000_PLUS, __PNG_WIDTH_100, __PNG_HEIGHT_100, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_NEG, __URI_NS, HTML_70_90, MULTIPLE_RCPTS, __FRAUD_WEBMAIL
X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0209.53E0A268.000C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine
X-Junkmail-IWF: false
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0209.53E0A268.000C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 3b4cc769aff48891f03de6b30b037e7c
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/r2mUXLFdyCLDeuZl6mqPt1AS48c
Cc: IPv6 Ops WG <v6ops@ietf.org>, Tore Anderson <tore@fud.no>, Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com>
Subject: Re: [v6ops] Operational Consensus on deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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, 05 Aug 2014 09:22:59 -0000

Hi all,

I confirm this is correct. Even we went further and we do not use DNS64. Our architecture is CLAT+NAT64+DNS. So with dns and without dns ipv4 traffic always goes via CLAT. It’s perfect solution ☺ UK EE will do the same.

See more at: http://www.data.proidea.org.pl/plnog/12edycja/day2/track4/01_ipv6_implementation.pdf

Even triple translation is not bad too: CLAT+NAT64stateless+NAT44statefull.

BR,
Mcz
Orange Poland

[cid:image001.png@01CFB09F.72C75B30]
February 1% of active PDP IPv6 ctx, now over 8%



From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ca By
Sent: Tuesday, August 05, 2014 5:10 AM
To: Brian E Carpenter
Cc: IPv6 Ops WG; Tore Anderson
Subject: Re: [v6ops] Operational Consensus on deployment


On Aug 4, 2014 1:26 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>> wrote:
>
>
> > My point in bringing this up is not that it is “useful in an IPv6 network” that might also be running IPv4 in parallel. It is that it seems useful to me in moving toward and IPv6-*only* network. Ross suggests that he sees conceptual movement - First they ignore you, then they laugh at you, then they fight you, and then you win. We may, Ross suggests, be approaching stage 4. It may be useful for us as a working group to lay out the game plan for that movement - not just to document IPv6 operational practice, but to help the IETF determine whether the dual stack consensus has changed or is changing, and help operators figure out how to turn IPv4 off without individually shooting their toes off. This would be part of that game plan.
>
> Well, I think the operators that moved early into genuine dual
> stack operation have no reason to regret it. I'm a happy customer
> of one such. On the other hand it seems that other operators are of
> the opinion (probably unprovable) that providing the illusion of dual
> stack service to the customer over an IPv6 infrastructure is cheaper.
> In any case the customer ends up with NATted IPv4 service in most
> cases, so at user level it doesn't really matter.
>
> I think we should probably not express a preference either way. It
> seems like a decision for each operator to make individually. What we
> probably should do is stop inventing more solutions.
>

Why?

I was told the same thing about 464xlat, we did not need another solution. If the ietf held the line against double translation i believe there would be exactly 1 ipv6 cellular provider in the world (verizon).

With 464xlat, afaik, there are globally 3 cellular providers that offer default ipv6 (464xlat at tmobile us and Orange PL and DS at VZ).

It does not matter if the cat is white or black, it matters that it catches mice.

CB

> (In parenthesis, I've never seen sunsetting IPv4 as a real problem.
> One day somebody will notice that there are no more IPv4 packets. But
> that is many years in the future.)
>
>     Brian
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org<mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops