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

Chongfeng Xie <xiechf@chinatelecom.cn> Tue, 01 February 2022 02:07 UTC

Return-Path: <xiechf@chinatelecom.cn>
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 28F873A0857 for <v6ops@ietfa.amsl.com>; Mon, 31 Jan 2022 18:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 Eae3NpoWYMUe for <v6ops@ietfa.amsl.com>; Mon, 31 Jan 2022 18:07:34 -0800 (PST)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.222]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20B3A084D for <v6ops@ietf.org>; Mon, 31 Jan 2022 18:07:33 -0800 (PST)
HMM_SOURCE_IP: 172.18.0.218:34096.1877233685
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-114.250.180.37 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 9F61D280029; Tue, 1 Feb 2022 10:07:22 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([172.18.0.218]) by app0025 with ESMTP id 1ebf6598a82645a39fdf0b395f422bd3 for vasilenko.eduard=40huawei.com@dmarc.ietf.org; Tue, 01 Feb 2022 10:07:23 CST
X-Transaction-ID: 1ebf6598a82645a39fdf0b395f422bd3
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 172.18.0.218
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
From: Chongfeng Xie <xiechf@chinatelecom.cn>
Message-Id: <6F534D7A-90F6-409E-959F-BED689B7347B@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B2FBD645-A188-43B7-8010-DCA518175D08"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 01 Feb 2022 10:07:18 +0800
In-Reply-To: <dbed2acb8bd747509647cf19fff6c796@huawei.com>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org" <v6ops@ietf.org>
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
References: <94961E2C-DEFE-429B-BCEC-2228472747D7@chinatelecom.cn> <FB97EF2F-5174-48A8-AC1C-230B6621F66E@gmail.com> <dbed2acb8bd747509647cf19fff6c796@huawei.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vfJVN4d5HCB2VxYf7hKY3nD3L5Y>
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: Tue, 01 Feb 2022 02:07:38 -0000

Hi,Eduard,
Thank you for your comments.  Although the draft I submitted is about requirement, I’d like to share some of my personal understanding of IPv4 As A service. Firstly, I don’t think it is a VPN-like stuff,  although the legacy IPv4 service data is encapsulated or translated into IPv6 when it traverse IPv6-only network , it is open to the public Internet, and not private, the only difference lies in the routing and data format.  Secondly, the requirements listed in this draft do not include the request of the cooperation of legacy servers. In order to support the access of the residual service of the IPv4 Internet,  a special carrier gateway may be needed, as you mentioned. From the standpoint from one large-scale operator,  a scalable, lightweight ,open, and secure solution should be available to meet the requirements, it may integrate some  the existing IPv6-only techniques, new components may also be needed. I hope more and more constructive suggestions can be raised and become  input to the requirement draft.

Best regards
Chongfeng


> 2022年1月31日 下午6:27,Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org> 写道:
> 
> 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 <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 <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 <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/ <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 <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
> 
> 
> 
>  
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org <mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>