Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

Alejandro D'Egidio <adegidio@telecentro.net.ar> Mon, 07 November 2016 13:35 UTC

Return-Path: <adegidio@telecentro.net.ar>
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 7DEA3129656 for <v6ops@ietfa.amsl.com>; Mon, 7 Nov 2016 05:35:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.288
X-Spam-Level:
X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=telecentro.net.ar
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 Xo7gZbuX4Lq9 for <v6ops@ietfa.amsl.com>; Mon, 7 Nov 2016 05:35:55 -0800 (PST)
Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5C91294C4 for <v6ops@ietf.org>; Mon, 7 Nov 2016 05:35:54 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id BFD8BFA5504; Mon, 7 Nov 2016 10:35:52 -0300 (ART)
Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KkhJxek7dm0X; Mon, 7 Nov 2016 10:35:50 -0300 (ART)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 6C92DFA4BD1; Mon, 7 Nov 2016 10:35:50 -0300 (ART)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 6C92DFA4BD1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=24ECF6D8-6D11-11E5-A0E5-36DF068F9D73; t=1478525750; bh=cdbsHz/+t4Y/RjjrOEqA3OvyGqLKLkahWB59Yxpa2aM=; h=Date:From:To:Message-ID:MIME-Version; b=vK6gaofxUdh2oI9kJiR5ID9/FPTFJ5lfw+q5VlTpa7oBOCdeEA1bIVOV0utqBZVNu muKv8zG0c8O2HgTpyJ3G8TDNj7jG4yO4p4237Pi4mQVGDF8f3QSK9U19mslUQJzjdg AWQD/8v+e1bjGVeO8kok8lUebNEI1NGhXOMKZ8GI=
X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local
Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NXKhvIk9suFd; Mon, 7 Nov 2016 10:35:50 -0300 (ART)
Received: from tclmail6.telecentro.local (localhost.localdomain [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 3892BFA481F; Mon, 7 Nov 2016 10:35:50 -0300 (ART)
Date: Mon, 07 Nov 2016 10:35:48 -0300
From: Alejandro D'Egidio <adegidio@telecentro.net.ar>
To: Fred Baker <fredbaker.ietf@gmail.com>
Message-ID: <1977255708.2206967.1478525748858.JavaMail.zimbra@telecentro.net.ar>
In-Reply-To: <CA139CBE-C3AC-4B0C-B055-FFCE4FA962C5@gmail.com>
References: <BA6017DD-82A0-4094-9DFB-7C1929E1E259@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DA341D8@GAALPA1MSGUSRBF.ITServices.sbc.com> <F7EC1F7A-8456-46D7-A356-3FD3E6726F95@steffann.nl> <alpine.DEB.2.02.1611042257480.14320@uplift.swm.pp.se> <581D8B91.4070602@forthnet.gr> <79D538C7-504D-4719-9C67-27EE524E8DB1@consulintel.es> <CA139CBE-C3AC-4B0C-B055-FFCE4FA962C5@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [10.210.50.96]
X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - GC54 (Win)/8.7.0_GA_1659)
Thread-Topic: do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers
Thread-Index: Z1CL0PdGe/md/B7p1kQIeh7BGPjIgA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/GvBFbzn32pP5x02UbB_7E3B12SQ>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 07 Nov 2016 13:35:58 -0000

Dears,
  RFC6877 was released in April 2013 and RFC7084 was released in November 2013.
  If RFC6877 doesn't need any update yet, it's ok I think but since November 2013 until now appeared now definitions like RFC7599 and RFC7597 (July 2015).
  In RFC7084 section "4.4. Transition Technologies Support" is specified 6RD and DS-Lite.
  Do you really think that 6RD "must" be supported in a CPE of 2016?
  RFC7084 puts 6RD as a Transition Technologies Support and doesn't it include 464XLAT, MAP-T, MAP-E?

  On the other hand, in CableModems is not included 464XLAT (CLAT) yet because vendors don't want to include it. I have talked to Sagemcom, Technicolor and Cisco (now Cisco sold CPEs to Technicolor); they don't want implement it because they don't have enough requirements yet (how many are enought?) and if I want it I should request it to Broadcom (vendor of chipset included in all these CMs). Ok, I've talked to Broadcom also and they neither want to implement it because they say that they have DS-Lite, for them it works and we don't need any other protocol. I can not beleive this kind of answer.

  I have included RFC6877 in RFPs for new CMs as a mandatory feature but no one wanted to perform with this feature, so I had to remove it as a mandatory because if not I wouldn't be able to buy anyone.

  Regarding CGN, as we don't have more public IPv4, we didn't have any other option than deploy a CGN. For now, customers have Dual Stack (private IPv4 + IPv6).
  Lets think that with the inclusion of (for example) 464XLAT, ISPs like us won't need to deploy IPv4 (in normal cases).


Regards,

Alejandro D'Egidio 
Jefe de Ingeniería de Backbone 
[ mailto:adegidio@telecentro.net.ar | adegidio@telecentro.net.ar ] 

Lavardén 157 | Tel: 54 11 3977 1025 
C1437FBC | CABA | Argentina 
TELECENTRO S.A. 

ESTE MENSAJE ES CONFIDENCIAL. Puede contener información amparada por el secreto profesional. Si usted ha recibido este e-mail por error, por favor comuníquenoslo inmediatamente vía e-mail y tenga la amabilidad de eliminarlo de su sistema; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. 

THIS MESSAGE IS CONFIDENTIAL. It may also contain information that is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by e-mail immediately and delete it from your system; should also not copy the message nor disclose its contents to anyone. Many thanks.

----- Mensaje original -----
De: "Fred Baker" <fredbaker.ietf@gmail.com>
Para: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
CC: v6ops@ietf.org
Enviados: Sábado, 5 de Noviembre 2016 15:59:10
Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers

Speaking for myself.

One of the things that I would draw out of your list is that there is no market consensus. A vendor decides what features to put in a product based not on what the standards require, but what customers require. If he can’t sell more of a product by adding a feature, he has little argument for adding it. And the vendors see little revenue benefit to adding random transition technologies.

My personal guess, not based on data, of actual requirements is CGN for IPv4 in some form (could be translation to IPv6 or translation to another IPv4 address) plus native IPv6. 464XLAT adds NAT64 at a network boundary, and is an ISP issue. “Dual Stack” was intended to mean that one could turn IPv4 off or IPv6 off and have full operation either way, but was running both at the same time. “Dual Stack” as implemented usually means that some functionality requires IPv4 but IPv6 data is transported. The rest of what you mention are tunneling technologies in one form or another, a way to have IPvX be able to work around an IPvY-only domain. Again, those are usually ISP options - the ISP wants to deliver IPv6 service to residential customers, perhaps, but has an IPv4-only service between it and its customer, or the ISP wants to deliver dual stack service to a residential customer but is itself IPv6-only. Vendors will deliver to ISPs what the ISPs require in their RFI/RFQ.

If one can demonstrate a consensus, a standard shouldn’t be difficult to write or argue for. Absent that, I’m not holding my breath.

> On Nov 5, 2016, at 2:54 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
> 
> I’ve also some trials with DSL customers, thousands of users each trial.
> 
> Some of those trials have been running for a couple of years already, and the reason not to go into commercial is precisely because they will prefer to use the same transition mechanism in all the network (they are using 464XLAT in the cellular trial), but the vendors aren’t supporting it and one of the arguments is not suggested as a requirement from the IETF ...
> 
> Also looking at the recent IPv6 survey I can see the following stats:
> 1) 5 LTE/router deployments with dual stack - CGN (private IPv4, global IPv6).
> 2) 2 LTE/router deployments with dual stack (public IPv4, global IPv6).
> 3) 1 LTE/router deployment with DS-Lite.
> 4) 2 LTE/router deployment with tunnel broker.
> 5) 1 Cable deployment with 464XLAT.
> 6) 2 Cable deployments with 6to4.
> 7) 2 Cable deployments with dual stack - CGN (private IPv4, global IPv6)
> 8) 2 Cable deployments with DS-Lite.
> 9) 42 Cable deployments with dual stack (public IPv4, global IPv6)
> 10) 1 Cable deployment with lw4o6.
> 11) 1 Cable deployment with MAP-T.
> 12) 2 Cable deployments with tunnel broker.
> 13) 5 FTTH deployments with 464XLAT.
> 14) 2 FTTH deployments with 6RD.
> 15) 8 FTTH deployments with 6to4.
> 16) 7 FTTH deployments with dual stack - CGN (private IPv4, global IPv6).
> 17) 4 FTTH deployments with DS-Lite.
> 18) 93 FTTH deployments with dual stack (public IPv4, global IPv6).
> 19) 1 FTTH deployment with MAP-E.
> 20) 1 FTTH deployment with tunnel broker.
> 21) 4 xDSL deployments with dual stack - CGN (private IPv4, global IPv6).
> 22) 7 xDSL deployments with DS-Lite.
> 23) 71 xDSL deployments with dual stack (public IPv4, global IPv6).
> 24) 9 xDSL deployments with 6RD.
> 25) 3 xDSL deployments with 464XLAT.
> 26) 2 xDSL deployments with tunnel broker.
> 27) 1 xDSL deployment using softwires (L2TP).
> 28) 6 Wireless (LMDS, WiFi, WiMax, etc.) deployments with dual stack - CGN (private IPv4, global IPv6).
> 29) 22 Wireless (LMDS, WiFi, WiMax, etc.) deployments with dual stack (public IPv4, global IPv6).
> 30) 1 Wireless (LMDS, WiFi, WiMax, etc.) deployment with 464XLAT.
> 
> In addition to all that, there are some other access technologies being used, with different transition mechanisms.
> 
> By the way, most of the 464XLAT deployments are done using OpenWRT, taking advantage of existing CPEs that can be reflashed, because lack of support from the original vendors.
> 
> The survey got already 1.223 responses up to now. I’m providing here only the numbers for those that responded with specific details about the transition technology. There are many other answers with have left this empty, probably customers that don’t know. In general, more complete responses come from the ISP employees, which also provide the contact details, and I talked with them in some cases to clarify specific answers to the survey.
> 
> I did a recent presentation at the last RIPE meeting (not going into so many detailed data as here)
> Slides - https://ripe73.ripe.net/presentations/22-IPv6-survey-October-2016.pdf
> Video - https://ripe73.ripe.net/archives/video/1242/
> 
> Survey available here, if you still haven’t answered it or something changed in your network:
> http://survey.consulintel.es/index.php/175122
> 
> 
> Regards,
> Jordi
> 
> 
> -----Mensaje original-----
> De: v6ops <v6ops-bounces@ietf.org> en nombre de Tassos Chatzithomaoglou <achatz@forthnet.gr>
> Responder a: <achatz@forthnet.gr>
> Fecha: sábado, 5 de noviembre de 2016, 8:34
> Para: "v6ops@ietf.org" <v6ops@ietf.org>
> Asunto: Re: [v6ops] do we need to update RFC7084 ? - Basic Requirements for IPv6 Customer Edge Routers
> 
>    Mikael Abrahamsson wrote on 4/11/16 23:58:
>> On Fri, 4 Nov 2016, Sander Steffann wrote:
>> 
>>> At least in the Netherlands DS-Lite has been deployed to hundreds of thousands of users already, and the numbers are still going up. I think that ISPs did nothing with DS-Lite is a misconception.
>> 
>> All the ds.lite I know of are from Cable providers, ie DOCSIS3 deployments.
>> 
>> Do you see ds.lite in any other space, ie non-cable operators?
>> 
>    We, as a fixed/DSL operator, use DS-Lite  on a large percentage of our subscribers.
>    Recently we started adding PCP to the mix.
> 
>    --
>    Tassos
> 
>    _______________________________________________
>    v6ops mailing list
>    v6ops@ietf.org
>    https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops