Re: [v6ops] Operational Consensus on deployment

"Heatley, Nick" <nick.heatley@ee.co.uk> Tue, 05 August 2014 15:57 UTC

Return-Path: <nick.heatley@ee.co.uk>
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 A1D961B2A38 for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 08:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 DlbRaRfqbgBW for <v6ops@ietfa.amsl.com>; Tue, 5 Aug 2014 08:57:15 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id 61A121B2A46 for <v6ops@ietf.org>; Tue, 5 Aug 2014 08:57:14 -0700 (PDT)
Received: from [85.158.136.35:43696] by server-3.bemta-5.messagelabs.com id 1A/AE-13873-9DEF0E35; Tue, 05 Aug 2014 15:57:13 +0000
X-Env-Sender: nick.heatley@ee.co.uk
X-Msg-Ref: server-7.tower-125.messagelabs.com!1407254232!38548088!1
X-Originating-IP: [193.36.79.210]
X-StarScan-Received:
X-StarScan-Version: 6.11.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10013 invoked from network); 5 Aug 2014 15:57:12 -0000
Received: from unknown (HELO aphex) (193.36.79.210) by server-7.tower-125.messagelabs.com with SMTP; 5 Aug 2014 15:57:12 -0000
Received: from UK31S005EXS02.EEAD.EEINT.CO.UK (Not Verified[10.246.208.27]) by aphex with MailMarshal (v6, 8, 2, 9371) id <B53e100bc0003>; Tue, 05 Aug 2014 17:05:16 +0100
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK31S005EXS02.EEAD.EEINT.CO.UK ([2002:1ef6:d01b::1ef6:d01b]) with mapi id 14.03.0195.001; Tue, 5 Aug 2014 16:57:00 +0100
From: "Heatley, Nick" <nick.heatley@ee.co.uk>
To: Czerwonka Michał 1 - Hurt <Michal.Czerwonka1@orange.com>, Ca By <cb.list6@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [v6ops] Operational Consensus on deployment
Thread-Index: AQHPsATuKp4cYlfWs0iK+WcgE96R8pvAuWkAgAAE0QCAABWsAIAAcMQAgABn6gCAAB/6IA==
Date: Tue, 05 Aug 2014 15:57:00 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303B6F85F@UK30S005EXS06.EEAD.EEINT.CO.UK>
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> <2D29C51862222E49B991EF64EEB0B5B745F85768@OPE10MB05.tp.gk.corp.tepenet>
In-Reply-To: <2D29C51862222E49B991EF64EEB0B5B745F85768@OPE10MB05.tp.gk.corp.tepenet>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.246.208.5]
Content-Type: multipart/related; boundary="_004_6536E263028723489CCD5B6821D4B21303B6F85FUK30S005EXS06EE_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/qhG1P2wUtxnSLb__-4jux3MFo3A
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 15:57:19 -0000

Hi all, EE similar, but not identical. We are hot on 464xlat (RFC6877), it is perfect for networks that already extensively use NAT44, and gets customers off IPv4 (both public and private, as neither is sufficient).
Regards,
Nick

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Czerwonka Michal 1 - Hurt
Sent: 05 August 2014 10:22
To: Ca By; Brian E Carpenter
Cc: IPv6 Ops WG; Tore Anderson; Kossut Tomasz - Hurt
Subject: Re: [v6ops] Operational Consensus on deployment

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:image003.png@01CFB0A0.62223A60]
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

NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW