From nobody Sun Mar 6 03:32:22 2022 Return-Path: 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 ECAF33A0C04 for ; Sun, 6 Mar 2022 03:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es 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 706677sNml5d for ; Sun, 6 Mar 2022 03:32:10 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id BDFAB3A0C2F for ; Sun, 6 Mar 2022 03:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1646566323; x=1647171123; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type; bh=y2kpl6JrmXR3Z6JwoLDZmvkLUm6LgMebRw De0j5crxs=; b=sMZlv0GPS1ur+2NpdxeUBLd0wNxx/sFSfiIrqQBc9wBQDnOwm5 I8gc1kYsDB9SD5vRXq6WNsG6EnZNoxaMMEpt/0PiFeLhUAjsUjlUT5FWn1vNnWjM es9J7qxjn8MRRb9u0ehw/BLE6Q8Y120fY1Us+5M0DCATIT/jfUgLjSuAM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 06 Mar 2022 12:32:03 +0100 X-Spam-Processed: mail.consulintel.es, Sun, 06 Mar 2022 12:32:01 +0100 Received: from [10.10.10.105] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000816323.msg for ; Sun, 06 Mar 2022 12:32:00 +0100 X-MDRemoteIP: 2001:470:1f09:495:21ca:9cf6:5c70:d4c X-MDHelo: [10.10.10.105] X-MDArrival-Date: Sun, 06 Mar 2022 12:32:00 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=106414fca0=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/16.60.22022702 Date: Sun, 06 Mar 2022 12:32:00 +0100 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <336BCECA-12BF-4A1B-A251-4F68CAAC8B87@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-ietf-v6ops-ipv6-deployment-04.txt References: <852D5420-FEFC-489F-8784-2087F38D4945@consulintel.es> <08f7be12cbcc46c0ab16a973ee860a95@huawei.com> In-Reply-To: <08f7be12cbcc46c0ab16a973ee860a95@huawei.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3729414720_1918003590" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-ipv6-deployment-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2022 11:32:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3729414720_1918003590 Content-type: multipart/related; boundary="B_3729414720_793766554" --B_3729414720_793766554 Content-type: multipart/alternative; boundary="B_3729414720_1300578316" --B_3729414720_1300578316 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Some more inputs in-line. =20 Regards, Jordi @jordipalet =20 =20 =20 El 3/3/22 15:39, "Paolo Volpato" escribi=C3=B3: =20 Hi Gyan, =20 Thanks for your review and comments. They are perfectly on time for our last editing before the deadline for the= IETF 113. Please see inline my answers (as [PV]). =20 Best regards Paolo =20 From: Gyan Mishra =20 Sent: Thursday, March 3, 2022 8:31 AM To: Paolo Volpato Cc: JORDI PALET MARTINEZ ; licong@chinatelecom.= cn; v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-ipv6-dep= loyment-04.txt =20 Hi Pablo & Co-authors=20 =20 I read the latest version and it looks very good and well written and I bel= ieve will very helpful to operators looking to deploy IPv6. =20 Few comments. In Section 3.6 it maybe worth mentioning that Happy Eyeballs plays a critic= al role where an application has FQDN A / AAAA record and IPv6 client / ser= ver communications by desktop browser and OS level allows for seamless fail= over to from IPv6 fo IPv4 in case of IPv6 network connectivity loss where I= Pv6 may not yet be fully deployed. This is extremely helpful when migratio= n applications from IPv4 to IPv6 having a single DNS name with both A and A= AAA record instead of having a separate VM instance for AAAA record. In th= is way all applications can seamlessly migrate to IPv6 as IPv6 is preferred= over IPv4 and so all IPv6 community dual stacked hosts can communicate usi= ng same URL to the server via IPv6 and all IPv4 only hosts can as well use = the same URL to communicate via IPv4. Eventually when all host endpoints a= re all dual stacked the application servers can now change to IPv6 only fro= m dual stack. For external connectivity to the internet web proxy can be u= sed providing 6to6 or 4to6 proxy to the internet. This allows applications = servers on the inside internal network to change to IPv6 only once all hos= t endpoints are all dual stacked. This same 6to6 proxy function for applic= ation server migration to IPv6 only can work for reverse proxy as well. Th= e above is some feedback on real world migrations of applications to IPV6 a= nd overall process. =20 [PV] Ack. Your description of HE expands the text already contained in sect= ion 3.6 so we will insert it. =20 [Jordi] Actually sometimes (too many times I will say), HE is bad, it depen= ds a lot on the OS implementation. For example: Some apps relay on the IP address for authentication or to keep the =E2=80= =9Clogin=E2=80=9D =E2=80=9Con=E2=80=9D. They don=E2=80=99t realize that an = IPv4 to IPv6 or back to IPv4 address because HE is still the same =E2=80=9C= login=E2=80=9D. I see too often that when the OS suspends for a few seconds= , and either IPv4 or IPv6 addresses take just a little longer time to be = =E2=80=9Cactivated=E2=80=9D in the interface, the app drops the =E2=80=9Clo= gin=E2=80=9D believing that is not the same =E2=80=9Cuser=E2=80=9D. This is= even worst in WiFi, or when a laptop has an Ethernet and a WiFi connection= even to the same VLAN. Many ISPs forget doing a proper monitoring of IPv6 towards upstreams or oth= er networks and then HE is always falling back to IPv4. So, it means that t= hey take longer (even months, I=E2=80=99ve seen cases), to detect broken IP= v6. I suggested long time ago HE reporting, and I still believe we should f= ind a way to ISPs realize when HE is falling back to IPv4 too often. =20 In section 5 you could add mention to RFC 5565 softwire mesh framework whic= h is based on a standard single protocol IPv4-Only or IPv6-Only for core wh= ere where IPv4 packets can be tunneled over 4to6 MPLS software over an IPv6= -Only core. =20 =20 [PV] The last review of the draft introduced some changes, in particular in= section 5. That was done in the attempt to make section 5 a bit more gener= al. Since a reference to softwire was already present and you suggest to ke= ep it we will introduce it again. =20 Also you could add reference to IPv6-Only PE design draft below which had b= een adopted by the BESS WG and basically allows dual stack functionality wi= thout having to dual stack the interface without any tunneling mechanisms r= esulting in OPEX savings for operators elimination of IPv4 addressing and B= GP peering. Used to help address IPv6 address depletion issues. =20 https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-0= 0 =20 Also as far as deployment of IPv6 in an operator Core or Data Center networ= k most vendors have a knob to enable IPv6 processing and forwarding message= s of packets without having to configure an IPv6 address using a knob simil= ar to Cisco =E2=80=9CIPv6 enable=E2=80=9D. This allows for the quick deplo= yment of IPv6 in a core or Data Center network without having to provisioni= ng P2P links with global unicast address with very large networks this can = be painfully long process. The reason why IPv6 GUA is not necessary with = is the IGP OSPF and ISIS use link local source address for sending link sta= te updates. For operations ping and traceroute this does require RFC 8335= to be utilized for probing for traceroute so you get the proper interface = response. =20 [PV] See my comment above. To keep section 5 general enough, we provided ju= st a short discussion of RFC 8950 and its effect in the underlay. Since dra= ft-ietf-bess-ipv6-only-pe-design-00 enforces this possibility and it is now= adopted as a WG draft we will reference it as well. =20 Kind Regards=20 =20 Gyan =20 =20 On Mon, Feb 28, 2022 at 11:33 AM Paolo Volpato wrote: Hi Cong, =20 Many thanks for your comments. We are currently working on a new version of the draft that will be uploade= d just before the deadline for the IETF 113. That version will address some online/offline comments we have received aft= er the publication of version -04 and will take your input into considerati= on. =20 Also, please see inline my answer (as [PV]). =20 Best regards Paolo =20 =20 From: v6ops On Behalf Of JORDI PALET MARTINEZ Sent: Monday, February 28, 2022 3:51 PM To: v6ops@ietf.org Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-ipv6-dep= loyment-04.txt =20 Hi Cong, =20 Tks a lot for the inputs! =20 My responses below in-line, as co-author. =20 Regards, Jordi @jordipalet =20 =20 =20 El 28/2/22 9:49, "v6ops en nombre de Li Cong" escribi=C3=B3: =20 Hi, Paolo, =20 =20 This draft gives a comprehensive picture of global IPv6 development and ext= racts some basic challenges that need to be solved by the industry. I think= this draft is useful. In addition, I also have some comments prefixed [Con= g] below,=20 =20 =20 [Cong]: In this draft, you use the terms of =E2=80=9CIPv6 introduction=E2= =80=9D and =E2=80=9CIPv6-only to illustrate the first stage and second stag= e of IPv6 development respectively. However, I think they may overlap in so= me scenarios, for instance, some operators may use IPv6-only directly and s= tride over the IPv6-introduction stage with dual-stack. What I mean here is= that dual-stack and IPv6-only are different approaches of transition, they= do not correspond to the stages absolutely. =20 =20 [Jordi] Yes, in some cases, the =E2=80=9CIPv6 introduction=E2=80=9Dcan/will= be directly bypassed. I thought was obvious in the text, but definitively = we need stress it to ensure that is sufficiently clear. =20 [PV] The sequence we have proposed comes from our experience and can be see= n as a general approach often adopted by operators to deal with the introdu= ction and deployment of IPv6. That does not preclude that, as you said, an = operator directly jumps to an IPv6-only solution. We will better clarify th= is point in the next version of the draft. =20 In section 3.6, =E2=80=9CThe preliminary step to take full benefit of the I= Pv6 capabilities is to write or adapt the application software for use in I= Pv6 networks=E2=80=9D [Cong]: As far as I know, the software code of most modern applications is = agnostic to the type of IP address, whether the application uses IPv6 lies = in the difference of address configuration of the host. =20 [Jordi] I don=E2=80=99t think that=E2=80=99s the case in some situation (un= fortunately too many). I often still find all kinds of apps, including netw= ork management ones, that aren=E2=80=99t yet really working in a dual-stack= or even IPv6-only environment. So I think we shall keep that section. =20 [PV] I tend to agree with Jordi. Unfortunately, many applications don=E2=80= =99t fully support IPv6 and have not been updated yet. The draft references= some technical papers that discuss what it is still missing for a full sup= port. =20 In Section 4.1=EF=BC=8C =E2=80=9CAlthough the Dual-Stack IPv6 transition is= a good solution to be followed in the IPv6 introductory stage,=E2=80=9D=20 [Cong]: From the perspective of network operation, I don=E2=80=99t think du= al-stack is a GOOD solution, for it increase the cost of O&M. In addition, = dual-stack provide exposure-face, it increases the risk of being attack. I = think it should be replaced by other term. =20 [Jordi] I definitively agree with you. Again, I thought it was clear in the= text, we shall stress it, but it is a case-by-case dependent. For example,= if an ISP has sufficient IPv4 addresses, and the CPEs support dual-stack, = but not IPv6-only with IPv4aaS, then the Capex may surpass the Opex if movi= ng to IPv6-only instead of dual-stack. Of course, that will have a break po= int at some time, but it will depend on every case. =20 In section 4.. =E2=80=9CIPv6-only transition technologies with IPv4aaS have= a much lower need for IPv4 public addresses, because they make a more effi= cient usage without restricting the number of ports per subscriber.=E2=80= =9D [Cong]: I think the restriction of number of ports per-subscriber is relate= d to the policy of address/port usage, IMO it should be independent to the = approach of IPv4aaS. =20 [Jordi] I will say that also depends a lot on the specific IPv6-only with I= Pv4aaS being used. In 464XLAT, you don=E2=80=99t need to restrict the numbe= r of ports per subscriber and the overall public IPv4 usage is lower. Howev= er, this is not the case in the other ones. I think this is very well descr= ibed in another document, so one more reference to it (https://datatracker.= ietf.org/doc/draft-ietf-v6ops-transition-comparison/) should clear that. =20 [PV] We will review the text here to be a bit more specific. =20 I hope my comments will be helpful to your document. [PV] Sure, many thanks! =20 Best regards=EF=BC=8C=20 Cong Li -----Original Message----- From: Paolo Volpato=20 Sent: Tuesday, February 8, 2022 4:54 PM To: v6ops@ietf.org Cc: Chongfeng Xie ; Giuseppe Fioccola ; Gyan Mishra ; Jordi Palet Mar= tinez ; Nalini Elkins Subject: RE: New Version Notification for draft-ietf-v6ops-ipv6-deployment-= 04.txt Dear WG, We have published version 04 of draft-ietf-v6ops-ipv6-deployment (https://d= atatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/). We have reviewed most of the draft, to update the status of IPv6 deployment= and to refresh some of its parts.=20 Here is the summary of the main changes: - Section 2: introduced the new numbers on the adoption IPv6 (as of January= 2022). - Section 3: updated the adoption of IPv6 in the enterprise, government and= education domains. We have also added references to more countries (e.g. I= ndia, the European Union). - Section 4: we have reviewed this section to address some offline comments= and discussions on the concept of "overlay" (i.e. how IPv6 may support the= service layer and its role to enable the transition to IPv6-only). - Section 5: reviewed the description of IPv6 in the "underlay" (the networ= k). Please feel free to comment. On behalf of the authors Paolo -----Original Message----- From: internet-drafts@ietf.org =20 Sent: Tuesday, February 8, 2022 4:34 PM To: Gyan S. Mishra ; Chongfeng Xie ; Giuseppe Fioccola ; Gyan Mishra = ; Jordi Martinez ; Jordi Palet Martinez ; Nalini Elkins ; Paolo Volpato Subject: New Version Notification for draft-ietf-v6ops-ipv6-deployment-04.t= xt A new version of I-D, draft-ietf-v6ops-ipv6-deployment-04.txt has been successfully submitted by Giuseppe Fioccola and posted to the IETF= repository. Name: draft-ietf-v6ops-ipv6-deployment Revision: 04 Title: IPv6 Deployment Status Document date: 2022-02-08 Group: v6ops Pages: 45 URL: https://www.ietf.org/archive/id/draft-ietf-v6ops-ipv6-deplo= yment-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deplo= yment/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-= deployment Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6-de= ployment-04 Abstract: This document provides an overview of IPv6 deployment status and a view on how the transition to IPv6 is progressing among network operators and enterprises. It also aims to analyze the related challenges and therefore encourage actions and more investigations in those areas where the industry has not taken a clear and unified approach. = =20 The IETF Secretariat =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --=20 Gyan Mishra Network Solutions Architect=20 Email gyan.s.mishra@verizon.com M 301 502-1347 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3729414720_1300578316 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Some more inputs in-line.

 

Regards,

Jordi

@jord= ipalet

 

&n= bsp;

 

El = 3/3/22 15:39, "Paolo Volpato" <paolo.volpato@huawei.com> escribi=C3=B3:

<= span lang=3DEN-US> 

Hi Gyan,

=  

Thanks for your review and comments.

=

They a= re perfectly on time for our last editing before the deadline for the IETF = 113.

Please see inline my answers (as [PV]).

=  

Best regards

Paolo

 

<= b>From: Gyan Mishra <ha= yabusagsm@gmail.com>
Sent: Thursday, March 3, 2022 8:31 AMTo: Paolo Volpato <paolo.volpato@huawei.com>
Cc: JO= RDI PALET MARTINEZ <jordi.palet@consulintel.es>; licong@chinatelecom.= cn; v6ops@ietf.org
Subject: Re: [v6ops] New Version Notification = for draft-ietf-v6ops-ipv6-deployment-04.txt

 

Hi Pablo & Co-authors 

 

I read the latest version and it looks very go= od and well written and I believe will very helpful to operators looking to= deploy IPv6.

 

<= div>

Fe= w comments.

In Section 3.6 it maybe worth mention= ing that Happy Eyeballs plays a critical role where an application has FQDN= A / AAAA record and IPv6 client / server communications by desktop browser= and OS level allows for seamless failover to from IPv6 fo IPv4 in case of = IPv6 network connectivity loss where IPv6 may not yet be fully deployed.  T= his is extremely helpful when migration applications from IPv4 to IPv6 havi= ng a single DNS name with both A and AAAA record instead of having a separa= te VM instance for AAAA record.  In this way all applications can seam= lessly migrate to IPv6 as IPv6 is preferred over IPv4 and so all IPv6 commu= nity dual stacked hosts can communicate using same URL to the server via IP= v6 and all IPv4 only hosts can as well use the same URL to communicate via = IPv4.  Eventually when all host endpoints are all dual stacked the app= lication servers can now change to IPv6 only from dual stack.  For ext= ernal connectivity to the internet web proxy can be used providing 6to6 or = 4to6 proxy to the internet. This allows applications servers  on the i= nside internal network to change to IPv6 only once all host endpoints are a= ll dual stacked.  This same 6to6 proxy function for application server= migration to IPv6 only can work for reverse proxy as well.  The above= is some feedback on real world migrations of applications to IPV6 and over= all process.

 

[PV] Ack. Your= description of HE expands the text already contained in section 3.6 so we = will insert it.

 

[Jordi] Actually sometim= es (too many times I will say), HE is bad, it depends a lot on the OS imple= mentation. For example:

  1. Some ap= ps relay on the IP address for authentication or to keep the =E2=80=9Clogin= =E2=80=9D =E2=80=9Con=E2=80=9D. They don=E2=80=99t realize that an IPv4 to = IPv6 or back to IPv4 address because HE is still the same =E2=80=9Clogin=E2= =80=9D. I see too often that when the OS suspends for a few seconds, and ei= ther IPv4 or IPv6 addresses take just a little longer time to be =E2=80=9Ca= ctivated=E2=80=9D in the interface, the app drops the =E2=80=9Clogin=E2=80= =9D believing that is not the same =E2=80=9Cuser=E2=80=9D. This is even wor= st in WiFi, or when a laptop has an Ethernet and a WiFi connection even to = the same VLAN.
  2. Many ISPs forget doing a proper monitoring of IPv6 towards upst= reams or other networks and then HE is always falling back to IPv4. So, it = means that they take longer (even months, I=E2=80=99ve seen cases), to dete= ct broken IPv6. I suggested long time ago HE reporting, and I still believe= we should find a way to ISPs realize when HE is falling back to IPv4 too o= ften.

 

In section 5 you = could add mention to RFC 5565 softwire mesh framework which is based on a s= tandard single protocol IPv4-Only or IPv6-Only for core where where IPv4 pa= ckets can be tunneled over 4to6 MPLS software over an IPv6-Only core.  = ;

 

[PV] The last review of the draft in= troduced some changes, in particular in section 5. That was done in the att= empt to make section 5 a bit more general. Since a reference to softwire wa= s already present and you suggest to keep it we will introduce it again.

 

Also you could add= reference to IPv6-Only PE design draft below which had been adopted by the BESS WG and basically allows dual stack functionality wit= hout having to dual stack the interface without any tunneling mechanisms re= sulting in OPEX savings for operators elimination of IPv4 addressing and BG= P peering.  Used to help address IPv6 address depletion issues.

 

Also as far as dep= loyment of IPv6 in an operator Core or Data Center network most vendors hav= e a knob to enable IPv6 processing and forwarding messages of packets witho= ut having to configure an IPv6 address using a knob similar to Cisco =E2=80= =9CIPv6 enable=E2=80=9D.  This allows for the quick deployment of IPv6= in a core or Data Center network without having to provisioning P2P links = with global unicast address with very large networks this can be painfully = long process.  The reason why IPv6 GUA  is not necessary with is = the IGP OSPF and ISIS use link local source address for sending link state = updates.  For operations ping and traceroute this does require  R= FC 8335 to be utilized for probing for traceroute so you get the proper int= erface response.

 

[PV] See my comment a= bove. To keep section 5 general enough, we provided just a short discussion= of RFC 8950 and its effect in the underlay. Since draft-ietf-bess-ipv6-onl= y-pe-design-00 enforces this possibility and it is now adopted as a WG draf= t we will reference it as well.

 

On Mon, Feb 28, 2022 at 11:33 AM= Paolo Volpato <paolo.volpato=3D40huawei.com@dmarc.ietf.org> wrote:

Hi C= ong,

&nbs= p;

Many t= hanks for your comments.

We are currently working on a new version of the draft that= will be uploaded just before the deadline for the IETF 113.

That version will addre= ss some online/offline comments we have received after the publication of v= ersion -04 and will take your input into consideration.

 

Also, please see inline my answer (as [PV]).

 

Best regards<= /o:p>

Paolo

 =

 

From= : v6ops <v6ops-bounces@ietf.org> On Behalf Of <= /b>JORDI PALET MARTINEZ
Sent: Monday, February 28, 2022 3:51 PMTo: v6ops@ietf= .org
Subject: Re: [v6ops] New Version Notification for draft-= ietf-v6ops-ipv6-deployment-04.txt

 

Hi Cong,

 

Tks a lot for the inputs!

 

My responses below in-l= ine, as co-author.

 

Regards,<= /o:p>

Jordi

= @jordipalet

 

 

 

El 28/2/22 9:49, "v6ops en nombre de Li Co= ng" <v6= ops-bounces@ietf.org en nombre de licong@chinatelecom.cn> escri= bi=C3=B3:

 

Hi, Paolo,

 =

&n= bsp;

This draft gives a comprehensive picture of global IPv6 developmen= t and extracts some basic challenges that need to be solved by the industry= . I think this draft is useful. In addition, I also have some comments pref= ixed [Cong] below, 

 

 

[Cong]: In this draft, you us= e the terms of =E2=80=9CIPv6 introduction=E2=80=9D and =E2= =80=9CIPv6-only to illustrate the first stage and= second stage of IPv6 development respectively. However, I think they may o= verlap in some scenarios, for instance, some operators may use IPv6-only di= rectly and stride over the IPv6-introduction stage with dual-stack. What I = mean here is that dual-stack and IPv6-only are different approaches of tran= sition, they do not correspond to the stages absolutely.    =

&n= bsp;

[Jordi] Yes, in some cases, the =E2=80=9CIPv6 introd= uction=E2=80= =9Dcan/will be directly bypassed. I thought was o= bvious in the text, but definitively we need stress it to ensure that is su= fficiently clear.

 

[PV] The sequence we have proposed comes from our experience and c= an be seen as a general approach often adopted by operators to deal with th= e introduction and deployment of IPv6. That does not preclude that, as you = said, an operator directly jumps to an IPv6-only solution. We will better c= larify this point in the next version of the draft.

 

In section 3.6, = =E2=80=9CThe preliminary step to take full benefit of the IPv6 capab= ilities is to write or adapt the application software for use in IPv6 networks=E2=80=9D

[Cong]: As far as I know, the soft= ware code of most modern applications is agnostic to the type of IP address= , whether the application uses IPv6 lies in the difference of address confi= guration of the host.

 

[Jordi] I don=E2=80=99t think that=E2=80=99s the case= in some situation (unfortunately too many). I often still find all kinds o= f apps, including network management ones, that aren=E2=80=99t yet really w= orking in a dual-stack or even IPv6-only environment. So I think we shall k= eep that section.

 

[PV] I tend to agree with Jordi. Unfortunately, many applications = don=E2=80=99t fully support IPv6 and have not been updated yet. The draft r= eferences some technical papers that discuss what it is still missing for a= full support.

=  

In Section 4.1=EF=BC=8C =E2=80=9CAlthough the Dual-Stack IPv6 transition is a good solution to= be followed in the IPv6 introductory stage,=E2=80=9D 

[Cong]: From the perspective of network operation, I don=E2=80=99t think dual-stack is a GOOD solution, for it increase the cost of O&= amp;M. In addition, dual-stack provide exposure-face, it increases the risk= of being attack. I think it should be replaced by other term.

 

[Jordi] I de= finitively agree with you. Again, I thought it was clear in the text, we sh= all stress it, but it is a case-by-case dependent. For example, if an ISP h= as sufficient IPv4 addresses, and the CPEs support dual-stack, but not IPv6= -only with IPv4aaS, then the Capex may surpass the Opex if moving to IPv6-o= nly instead of dual-stack. Of course, that will have a break point at some = time, but it will depend on every case.

 

In section 4.. =E2=80=9CIPv6-only transition technologies with IPv4aaS have a much lo= wer need for IPv4 public addresses, because they make a more efficient usag= e without restricting the number of ports per subscriber.=E2=80=9D

[Cong]: I think the restriction of number of ports per-subscriber = is related to the policy of address/port usage, IMO it should be independen= t to the approach of IPv4aaS.

 

[Jordi] I will say that also depends a lot on= the specific IPv6-only with IPv4aaS being used. In 464XLAT, you don=E2=80= =99t need to restrict the number of ports per subscriber and the overall pu= blic IPv4 usage is lower. However, this is not the case in the other ones. = I think this is very well described in another document, so one more refere= nce to it (https://datatracker.ietf.org/doc/dra= ft-ietf-v6ops-transition-comparison/) should clear that.

 

[PV] We will review the t= ext here to be a bit more specific.

 

I hope my comments will be helpful to = your document.

[PV] Sure, many thanks!

 

Best regards=EF=BC=8C 

Cong Li



-----Original Message-----
From: Paolo Volpato 
Sent: Tuesday, Feb= ruary 8, 2022 4:54 PM
To: v6ops@ietf.org
Cc: Chongfeng= Xie <xiechf@chinatelecom.cn>; Giuseppe = Fioccola <giuseppe.fioccola@huawei.com>; Gyan Mishra <gyan.s.mishra@v= erizon.com>; Jordi Palet Martinez <jordi.palet@theipv6company.com>; Nalini El= kins <nalini.elkins@insidethestack.com>
Subject: RE: New Version Notification for draft-ietf-v6ops-ipv= 6-deployment-04.txt

Dear WG,

We have published version 04 of = draft-ietf-v6ops-ipv6-deployment (= https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/).

We have reviewed most of the draft, to update the= status of IPv6 deployment and to refresh some of its parts. 

Here is the = summary of the main changes:
- Section 2: introduced the new numbers on = the adoption IPv6 (as of January 2022).
- Section 3: updated the adoptio= n of IPv6 in the enterprise, government and education domains. We have also= added references to more countries (e.g. India, the European Union).
- = Section 4: we have reviewed this section to address some offline comments a= nd discussions on the concept of "overlay" (i.e. how IPv6 may sup= port the service layer and its role to enable the transition to IPv6-only).=
- Section 5: reviewed the description of IPv6 in the "underlay&quo= t; (the network).

Please feel free to comment.

On behalf of t= he authors
Paolo


-----Original Message-----
From: <= span style=3D'font-size:10.0pt;font-family:Helvetica;color:purple'>internet= -drafts@ietf.org <internet-drafts= @ietf.org> 
Sent: Tuesday, February 8, 2022 4:34 P= M
To: Gyan S. Mishra <gyan.s.mishra@verizon.com>; Chongfeng Xie <xiechf@chinatelecom.cn>; Giuseppe Fioccola <giuseppe.fioccola@huawei.co= m>; Gyan Mishra <<= a href=3D"mailto:gyan.s.mishra@verizon.com" target=3D"_blank">gyan.s.mishra@verizon.com>; Jordi Martinez <jordi.palet@theipv= 6company.com>; Jordi Palet Martinez <= jordi.palet@theipv6company.com>; Nalini El= kins <nalini.elkins@insidethestack.com>; Paolo Volpato <paolo.volpato@huawei.com>
Subject: New Version Notification for draft-ietf-v6ops-ipv= 6-deployment-04.txt


A new version of I-D, draft-ietf-v6ops-ipv6-= deployment-04.txt
has been successfully submitted by Giuseppe Fioccola a= nd posted to the IETF repository.

Name:     &nbs= p;  draft-ietf-v6ops-ipv6-deployment
Revision:    04=
Title:        IPv6 Deployment Status
D= ocument date:    2022-02-08
Group:    &nbs= p;   v6ops
Pages:        45
U= RL:            https://www.ietf.org/archive/id/draft-ietf-v6ops-ipv6-deployment-= 04.txt
Status:        https://datatracker.ietf.org/doc/draft-ietf-v= 6ops-ipv6-deployment/
Htmlized:    &n= bsp; <= /span>https://datatracker.ietf.org/do= c/html/draft-ietf-v6ops-ipv6-deployment
Diff:&n= bsp;         ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6-deployment-04

Abstract:
  This document provides an ov= erview of IPv6 deployment status and a
  view on how the transition= to IPv6 is progressing among network
  operators and enterprises.&= nbsp; It also aims to analyze the related
  challenges and therefore encour= age actions and more investigations in
  those areas where the indu= stry has not taken a clear and unified
  approach.

  &n= bsp;                     =                      = ;                     &nb= sp;               


The IETF Secreta= riat

 

_______________________________________________ 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.theipv6company.com=
The IPv6 Company

This electronic message contains information wh= ich may be privileged or confidential. The information is intended to be fo= r the exclusive use of the individual(s) named above and further non-explic= ilty authorized disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited and will be considered a criminal offense. If you are not the i= ntended recipient be aware that any disclosure, copying, distribution or us= e of the contents of this information, even if partially, including attache= d files, is strictly prohibited, will be considered a criminal offense, so = you must reply to the original sender to inform about this communication an= d delete it.

______________= _________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.o= rg/mailman/listinfo/v6ops

--

3D"Image

Gyan Mishra=

Network Solutions A= rchitect 

Emai= l gyan.s.mis= hra@verizon.com

M 301 502-1347=

 


**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3729414720_1300578316-- --B_3729414720_793766554 Content-type: image/jpeg; name="image001.jpg"; x-mac-creator="4F50494D"; x-mac-type="4A504547" Content-ID: Content-disposition: inline; filename="image001.jpg" Content-transfer-encoding: base64 /9j/4AAQSkZJRgABAQEAkACQAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAm JSMgIyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAAbAHoBAREA/8QAHwAA AQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQR BRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RF RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEB AAA/APZqKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK/ /9kA --B_3729414720_793766554-- --B_3729414720_1918003590--