Re: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 31 January 2022 10:50 UTC

Return-Path: <vasilenko.eduard@huawei.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 EF7083A2C35 for <v6ops@ietfa.amsl.com>; Mon, 31 Jan 2022 02:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 eopKLhw8odPE for <v6ops@ietfa.amsl.com>; Mon, 31 Jan 2022 02:50:55 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB7D3A2C2F for <v6ops@ietf.org>; Mon, 31 Jan 2022 02:50:55 -0800 (PST)
Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JnPwY5XPwz67xS0; Mon, 31 Jan 2022 18:50:21 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.21; Mon, 31 Jan 2022 11:50:51 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 31 Jan 2022 13:50:51 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2308.021; Mon, 31 Jan 2022 13:50:51 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
Thread-Index: AQHYFjZpmo7ciMyVgUGVpoZAFltCkqx84WmQgAARghA=
Date: Mon, 31 Jan 2022 10:50:51 +0000
Message-ID: <93ac2cc5178c4d619de5b640f743caf9@huawei.com>
References: <94961E2C-DEFE-429B-BCEC-2228472747D7@chinatelecom.cn> <FB97EF2F-5174-48A8-AC1C-230B6621F66E@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.190.191]
Content-Type: multipart/alternative; boundary="_000_93ac2cc5178c4d619de5b640f743caf9huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VTIR_ZRA__rcwAVR4ek8VkqQPq0>
Subject: Re: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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, 31 Jan 2022 10:51:00 -0000

Theoretically, this policy filtering could be moved to carriers PEs.
It looks like yet another Lawful Intercept:
if the destination address is in the long filter of Carrier’s prefixes supporting “VPNv4aaS cross-carrier” then forward it to “VPNv4aaS cross-carrier PLAT” (for translation or encapsulation to IPv6).
I doubt that many carriers would agree to such a solution.
Ed/
From: Vasilenko Eduard
Sent: Monday, January 31, 2022 1:29 PM
To: 'Fred Baker' <fredbaker.ietf@gmail.com>; v6ops@ietf.org
Subject: RE: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt

Hi all,
Of course, it would be good to have “VPNv4aaS cross-carrier”, but …
IMHO: this draft rises the bar to “impossible” because it requests cooperation (and small expenses) from owners of the legacy IPv4 servers.
If such cooperation is possible then it is better to just activate IPv6 on all servers on the Internet (no need for VPNv4aaS at all).

More detailed explanation:

https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00 is discussing only control plane unification to IPv6-only. The Data plane still assumes Dual-Stack. It is perfectly possible.
draft-xie-v6ops-reqirements-multi-domain-ipv6only is asking for IPv6-only for the cross-carrier data plane too.

Consider any IPv4 session.
The IPv4 source could use any VPNv4aaS technology for all IPv4 traffic – it is not a problem (well, RFC 8585 compliancy is still a huge problem for FBB, but let's assume the best).
The IPv4 destination is a principal problem. It should send the traffic of some sessions to the special carrier gateway (for some sort of cross-carrier VPNv4aaS) but other sessions to IPv4 Internet.
Because would be some IPv4 sources that do not participate yet in “cross-carrier VPNv4aaS”.
Every owner of server resources should have some special policy forwarding (probably, on the gateway router) to split traffic properly between

-          A special carrier gateway (like PLAT) that would tunnel or translate (probably in IPv6) to cross-carrier VPNv4aaS

-          Normal IPv4 routing to the internet for Carriers that do not participate in cross-carrier VPNv4aaS
This policy forwarding should be managed from Carrier’s side! The carrier should update what is reachable by “cross-carrier VPNv4aaS” and what is not.
IMHO: such an additional policy forwarding requirement for legacy IPv4 servers defeats the purpose of the solution.
The server owner would probably prefer to enable IPv6 than to add special functionality to the router in front of the server farm, especially in the situation when it should be updated by Carrier.

The good news is that any server owner that would agree to activate policy routing managed by his carrier on the Internet gateway
Could start participation in “cross-carrier VPNv4aaS“ immediately, he does not need to wait for all other server owners – they could continue to send plain IPv4 to the global IPv4 Internet.
The particular Carrier would not become IPv6-only till the last one server owner would not enable Dual-Stack or install policy forwarding in front of it.

Eduard
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker
Sent: Monday, January 31, 2022 3:06 AM
To: v6ops@ietf.org<mailto:v6ops@ietf.org>
Subject: Re: [v6ops] New Version Notification for draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt

I’m very interested in working group comments on this.
Sent from my iPad

On Jan 29, 2022, at 6:37 PM, Chongfeng Xie <xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>> wrote:


Hi, all,
We have submitted a new draft as below. It mainly specifies requirements of multi-domain IPv6-only network from the perspective of operators.  Mutli-domain herein means a network is compose of multiple ASes and serves multiple scenarios, which is a common model for large-size operators.  This is only -00 draft and a start point, we are looking forward to receiving more comments and suggestions.   Thank you!

Best regards
Chongfeng






A new version of I-D, draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
has been successfully submitted by Chongfeng Xie and posted to the
IETF repository.

Name:             draft-xie-v6ops-reqirements-multi-domain-ipv6only
Revision:         00
Title:               Requirements to multi-domain IPv6-only network
Document date:          2022-01-29
Group:             Individual Submission
Pages:              13
URL:            https://www.ietf.org/archive/id/draft-xie-v6ops-reqirements-multi-domain-ipv6only-00.txt
Status:         https://datatracker.ietf.org/doc/draft-xie-v6ops-reqirements-multi-domain-ipv6only/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xie-v6ops-reqirements-multi-domain-ipv6only


Abstract:
  Dual-stack requires IPv4 and IPv6 are deployed in parallel, as it
  costs more to run two technologies than one.  IPv6-only is considered
  to be the next stage of IPv6 development from dual-stack.  This
  document specifies requirements when deploying IPv6-only in multi-
  domain networks.




The IETF Secretariat