Re: [v6ops] New Version Notification for draft-ietf-v6ops-ipv6-deployment-04.txt

[Gyan Mishra <[e-mail]>]

Excellent !!

Just want to mention as well the proxy function is really helpful for
applications migration to IPv6 and have host connectivity to v4 or v6 URLs
all permutations.  Also as most all applications traffic is web based it
avoids any separate per protocol NAT functionality as that is built into
the web proxy.  So the permutations are 6to6 6to4 4to6 in those
permutations 6to4 is in particular handy for IPv6 only hosts accessing IPv4
web.  The 4to6 is handy as it also allows v4 hosts to access v6 web content
on the internet.  Also those same permutations for reverse proxy scenario.

Thank you

Gyan

On Thu, Mar 3, 2022 at 9:39 AM Paolo Volpato <[e-mail]>
wrote:

> Hi Gyan,
>
>
>
> 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]).
>
>
>
> Best regards
>
> Paolo
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Thursday, March 3, 2022 8:31 AM
> *To:* Paolo Volpato <[e-mail]>
> *Cc:* JORDI PALET MARTINEZ <[e-mail]>;
> [e-mail]; [e-mail]
> *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 good and well written and I
> believe will very helpful to operators looking to deploy IPv6.
>
>
>
> Few comments.
>
> In Section 3.6 it maybe worth mentioning 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.  This is extremely helpful when
> migration applications from IPv4 to IPv6 having a single DNS name with both
> A and AAAA record instead of having a separate VM instance for AAAA
> record.  In this way all applications can seamlessly migrate to IPv6 as
> IPv6 is preferred over IPv4 and so all IPv6 community dual stacked hosts
> can communicate using 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 are all dual stacked the application servers can
> now change to IPv6 only from dual stack.  For external connectivity to the
> internet web proxy can be used providing 6to6 or 4to6 proxy to the
> internet. This allows applications servers  on the inside internal network
> to change to IPv6 only once all host endpoints are all 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 overall process.
>
>
>
> [PV] Ack. Your description of HE expands the text already contained in
> section 3.6 so we will insert it.
>
>
>
> In section 5 you could add mention to RFC 5565 softwire mesh framework
> which is based on a standard single protocol IPv4-Only or IPv6-Only for
> core where where IPv4 packets can be tunneled over 4to6 MPLS software over
> an IPv6-Only core.
>
>
>
> [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
> general. Since a reference to softwire was 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
> without having to dual stack the interface without any tunneling mechanisms
> resulting in OPEX savings for operators elimination of IPv4 addressing and
> BGP peering.  Used to help address IPv6 address depletion issues.
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-ipv6-only-pe-design-00
>
>
>
> Also as far as deployment of IPv6 in an operator Core or Data Center
> network most vendors have a knob to enable IPv6 processing and forwarding
> messages of packets without having to configure an IPv6 address using a
> knob similar to Cisco “IPv6 enable”.  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  RFC 8335 to
> be utilized for probing for traceroute so you get the proper interface
> response.
>
>
>
> [PV] See my comment above. 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-only-pe-design-00 enforces this possibility and it is
> now adopted as a WG draft we will reference it as well.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
>
>
> On Mon, Feb 28, 2022 at 11:33 AM Paolo Volpato <paolo.volpato=
> [e-mail]> wrote:
>
> Hi Cong,
>
>
>
> Many thanks 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 address some online/offline comments we have received
> after the publication of version -04 and will take your input into
> consideration.
>
>
>
> Also, please see inline my answer (as [PV]).
>
>
>
> Best regards
>
> Paolo
>
>
>
>
>
> *From:* v6ops <[e-mail]> *On Behalf Of *JORDI PALET MARTINEZ
> *Sent:* Monday, February 28, 2022 3:51 PM
> *To:* [e-mail]
> *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-line, as co-author.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 28/2/22 9:49, "v6ops en nombre de Li Cong" <[e-mail] en
> nombre de [e-mail]> escribió:
>
>
>
> Hi, Paolo,
>
>
>
>
>
> This draft gives a comprehensive picture of global IPv6 development 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 prefixed
> [Cong] below,
>
>
>
>
>
> [Cong]: In this draft, you use the terms of “IPv6 introduction” and “IPv6-only
> to illustrate the first stage and second stage of IPv6 development
> respectively. However, I think they may overlap in some scenarios, for
> instance, some operators may use IPv6-only directly 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 transition, they do
> not correspond to the stages absolutely.
>
>
>
> [Jordi] Yes, in some cases, the “IPv6 introduction”can/will be directly
> bypassed. I thought was obvious in the text, but definitively we need
> stress it to ensure that is sufficiently clear.
>
>
>
> [PV] The sequence we have proposed comes from our experience and can be
> seen as a general approach often adopted by operators to deal with the
> 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
> clarify this point in the next version of the draft.
>
>
>
> In section 3.6, “The preliminary step to take full benefit of the IPv6
> capabilities is to write or adapt the application software for use in IPv6
> networks”
>
> [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.
>
>
>
> [Jordi] I don’t think that’s the case in some situation (unfortunately too
> many). I often still find all kinds of apps, including network management
> ones, that aren’t yet really working in a dual-stack or even IPv6-only
> environment. So I think we shall keep that section.
>
>
>
> [PV] I tend to agree with Jordi. Unfortunately, many applications don’t
> 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 support.
>
>
>
> In Section 4.1， “Although the Dual-Stack IPv6 transition is a good
> solution to be followed in the IPv6 introductory stage,”
>
> [Cong]: From the perspective of network operation, I don’t think
> dual-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.
>
>
>
> [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 moving to IPv6-only 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.. “IPv6-only transition technologies with IPv4aaS have a
> much lower need for IPv4 public addresses, because they make a more
> efficient usage without restricting the number of ports per subscriber.”
>
> [Cong]: I think the restriction of number of ports per-subscriber is
> related to the policy of address/port usage, IMO it should be independent
> 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’t need to restrict the number of
> ports per subscriber and the overall public 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 reference to it (
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/)
> should clear that.
>
>
>
> [PV] We will review the text here to be a bit more specific.
>
>
>
> I hope my comments will be helpful to your document.
>
> [PV] Sure, many thanks!
>
>
>
> Best regards，
>
> Cong Li
>
>
>
> -----Original Message-----
> From: Paolo Volpato
> Sent: Tuesday, February 8, 2022 4:54 PM
> To: [e-mail]
> Cc: Chongfeng Xie <[e-mail]>; Giuseppe Fioccola <
> [e-mail]>; Gyan Mishra <[e-mail]>;
> Jordi Palet Martinez <[e-mail]>; Nalini Elkins <
> [e-mail]>
> 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://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 adoption 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 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
> network).
>
> Please feel free to comment.
>
> On behalf of the authors
> Paolo
>
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Tuesday, February 8, 2022 4:34 PM
> To: Gyan S. Mishra <[e-mail]>; Chongfeng Xie <
> [e-mail]>; Giuseppe Fioccola <[e-mail]>;
> Gyan Mishra <[e-mail]>; Jordi Martinez <
> [e-mail]>; Jordi Palet Martinez <
> [e-mail]>; Nalini Elkins <
> [e-mail]>; Paolo Volpato <[e-mail]
> >
> Subject: New Version Notification for
> draft-ietf-v6ops-ipv6-deployment-04.txt
>
>
> 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-deployment-04.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-deployment-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.
>
>
>
>
>
> The IETF Secretariat
>
>
>
> _______________________________________________ v6ops mailing list
> [e-mail] 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 which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty 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
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*