[v6ops] 【Lack components for the transition of C2C communications】Re: Call For Adoption: draft-link-v6ops-6mops
Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 09 August 2024 07:15 UTC
Return-Path: <wangaijun@tsinghua.org.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 15FFBC151065 for <v6ops@ietfa.amsl.com>; Fri, 9 Aug 2024 00:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf632CT778CR for <v6ops@ietfa.amsl.com>; Fri, 9 Aug 2024 00:15:53 -0700 (PDT)
Received: from mail-m49198.qiye.163.com (mail-m49198.qiye.163.com [45.254.49.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9CAC14CE22 for <v6ops@ietf.org>; Fri, 9 Aug 2024 00:15:51 -0700 (PDT)
Received: from LAPTOP09T7970K (unknown [219.142.69.76]) by smtp.qiye.163.com (Hmail) with ESMTPA id 1538D7E01CF; Fri, 9 Aug 2024 15:15:30 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Nick Buraglio' <buraglio@forwardingplane.net>
Date: Fri, 09 Aug 2024 15:15:29 +0800
Message-ID: <00e801daea2b$eaa758a0$bff609e0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdrqK6jxjdoACCgRTHmlhM9HNi050Q==
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVlDTEhJVkMaTB1NH0hPTE1IQlYeHw5VEwETFh oSFyQUDg9ZV1kYEgtZQVlJSkJVSk9JVU1CVUxNWVdZFhoPEhUdFFlBWU9LSFVKS0lPT09IVUpLS1 VKQktLWQY+
X-HM-Tid: 0a9135fe17a003a2kunm1538d7e01cf
X-HM-MType: 10
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OBA6Ggw4NzI8NQ83IhcVKT8Q NwFPCw9VSlVKTElISkNMTEhKS0lNVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxNWVdZCAFZQUJLTE03Bg++
Message-ID-Hash: SIP2BIIUO3MST6JZNBYT6DIKNAJLS2RF
X-Message-ID-Hash: SIP2BIIUO3MST6JZNBYT6DIKNAJLS2RF
X-MailFrom: wangaijun@tsinghua.org.cn
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 'Tim Chown' <Tim.Chown@jisc.ac.uk>, 'Ron Bonica' <rbonica=40juniper.net@dmarc.ietf.org>, 'IPv6 Ops WG' <v6ops@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] 【Lack components for the transition of C2C communications】Re: Call For Adoption: draft-link-v6ops-6mops
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/d-0GHxTF8LsanxuRLwjvcg_QJyo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>
Hi, Nick: Based on the discussions, I think the "IPv6-Prefer" network may declare clearly the intention of this draft(also the operator)'aim to move forward, than that of "IPv6-Mostly" Anyway, it lacks one important part to describe how to cope with the transition of C2C communications(IPv4/IPv6 host to IPv4/IPv6 host). To facilitate the transition of C2C communication, some other components(STUN/TURN etc.) within the network should be deployed. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: Nick Buraglio [mailto:buraglio@forwardingplane.net] 发送时间: 2024年8月9日 0:21 收件人: Aijun Wang <wangaijun@tsinghua.org.cn> 抄送: Tim Chown <Tim.Chown@jisc.ac.uk>; Brian Carpenter <brian.e.carpenter@gmail.com>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; IPv6 Ops WG <v6ops@ietf.org> 主题: Re: [v6ops] 答复: Re: 答复: Re: Call For Adoption: draft-link-v6ops-6mops *No hat* On Thu, Aug 8, 2024 at 6:47 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote: > > No. Declaring the “IPv6-Only” network does not preclude that the network can support IPv4 communication. >From the perspective of an operator migrating off of IPv6 and onto IPv6 exclusively, I strongly disagree. Either by policy or by technical limitation (configured or inherent), "IPv6-only" is widely understood to mean "no IPv4". > > The IPv4 communication can still be transmitted via the tunnel technology, that is “IPv4 Communication as a IPv6 service” I think that is out of scope. Whatever is inside the tunnel - and thereby "invisible" to the network substrate is irrelevant. The tunnel would still be required to operate over IPv6. > > > > Comparing with evolution of mobile technologies, there is no operator declare their network is “4G-mostly network” when they want to put forward to the 4G phase, but need still support the 3G host/endpoint. Again, I think this is orthogonal. That is a lower layer. If I ran a network that was 70% Ethernet and 30% SONET I wouldn't call it "Ethernet only", either. I would describe it as "mostly ethernet". > > > > Introducing the “IPv6-Mostly Network” concept, in my POV, is worse than the “Dual Stack”, and it will also mask some hinder problems that can’t be emerged at the dual-stack phase. As someone that has been working on these migrations to IPv6-only for several years, I can assure you it is not the same as dual-stack. It is a welcomed transition strategy that has a visible end site with an operator incentive to continue the migration, whereas with dual-stack there was no real incentive to move past it. > > > > When the operators declare clearly they are toward to the “IPv6-Only Network”, they can certainly accelerate the conversion of IPv6-only application, and also the gradual removal of the outdated hosts. But, introduce the concept of “IPv6-Mostly Network”, can give the transition more time to take action-----Similar with the effect of “Dual Stack”. See above. Dual-stack was a necessary step, and one that the server and service side probably still needs. 6mostly is the next phase for the *access* networks. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > > > > > 发件人: Tim Chown [mailto:Tim.Chown@jisc.ac.uk] > 发送时间: 2024年8月8日 18:55 > 收件人: Brian Carpenter <brian.e.carpenter@gmail.com>; Aijun Wang > <wangaijun@tsinghua.org.cn> > 抄送: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; IPv6 Ops WG > <v6ops@ietf.org> > 主题: Re: [v6ops] Re: 答复: Re: Call For Adoption: draft-link-v6ops-6mops > > > > Indeed, it’s a very nice way to get on the path to removing IPv4 and a nice term for that process; the “most” referring to the property that most hosts on a subnet switch to IPv6-only, while those not capable continue to use IPv4 for some or all operation. > > > > Tim > > > > From: Brian Carpenter <brian.e.carpenter@gmail.com> > Date: Thursday, 8 August 2024 at 11:51 > To: Aijun Wang <wangaijun@tsinghua.org.cn> > Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, IPv6 Ops WG > <v6ops@ietf.org> > Subject: [v6ops] Re: 答复: Re: Call For Adoption: draft-link-v6ops-6mops > > Aijun, > > > > I disagree. When talking to site operators who want to proceed towards IPv6 infastructure but have vital systems that cannot be updated from IPv4 immediately, the new term "IPv6 mostly" is exactly what they want to hear. Many sites are in that situation but would like to avoid dual stack on the wire. > > > > (via tiny screen & keyboard) > Regards, > Brian Carpenter > > > > On Thu, 8 Aug 2024, 22:33 Aijun Wang, <wangaijun@tsinghua.org.cn> wrote: > > Hi, > > It seems that the newly assigned name "IPv6-Mostly network" may lead confusion or need more explanations to the customers. > How about change the document name solely to "Deployment and Operations Consideration on IPv6-Only Network", and omit the introduction of new concept of "IPv6-Mostly network"? > > And, for the operator transit to IPv6-Only network, besides the C2S(client to server) communication, the C2C(client to client) communication requirement should also need to be addressed. It seems the document is lack of consideration for such part. > > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: forwardingalgorithm@ietf.org > [mailto:forwardingalgorithm@ietf.org] 代表 Jen Linkova > 发送时间: 2024年8月5日 22:22 > 收件人: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> > 抄送: v6ops@ietf.org > 主题: [v6ops] Re: Call For Adoption: draft-link-v6ops-6mops > > The draft can be found at > https://datatracker.ietf.org/doc/draft-link-v6ops-6mops/ > > On Mon, Aug 5, 2024 at 11:21 PM Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote: > > > > Friends, > > > > This message begins a Call For Adoption for draft-link-v6ops-6mops. Please read the draft and send your comments in response to this email. > > > > The call for adoption will close on August 19, 2024. > > > > Ron > > > > > > > > Juniper Business Use Only > > > > _______________________________________________ > > v6ops mailing list -- v6ops@ietf.org To unsubscribe send an email to > > v6ops-leave@ietf.org > > > > -- > Cheers, Jen Linkova > > _______________________________________________ > v6ops mailing list -- v6ops@ietf.org > To unsubscribe send an email to v6ops-leave@ietf.org > > _______________________________________________ > v6ops mailing list -- v6ops@ietf.org > To unsubscribe send an email to v6ops-leave@ietf.org > > _______________________________________________ > v6ops mailing list -- v6ops@ietf.org > To unsubscribe send an email to v6ops-leave@ietf.org