Re: [v6ops] draft-vf-v6ops-ipv6-deployment and draft-vf-v6ops-ipv6-deployment

[Alexandre Petrescu <[e-mail]>]

The term 'IPv6-only' can be defined.

An 'IPv6-only' computer is a computer that runs IP and that IP is not
IPv4; it does not run IPv4 software.  For example, it does not have
127.0.0.1 in /etc/hosts, does not have an IPv4 stack in the running
kernel, etc.

An 'IPv6-only' link is a link that transmits only IPv6 packets and does
not transmit IPv4 packets.  For example the links of PDP Type IPv6 in 4G.

An 'IPv6-only' smartphone is a handheld portable computer connected on
an 'IPv6-only' link but, contrary to an 'IPv6-only' computer, it does
use an IPv4 stack and can browse IPv4 websites by means of address
translation.

We could also define an 'IPv6-only' marketing term, an 'IPv6-only'
concept, an 'IPv6-only' future Internet, etc.

Alex

Le 30/03/2021 à 10:27, Giuseppe Fioccola a écrit :
> Hi Jordi,
> 
> I see your point. IPv6-only alone can be misinterpreted. It can be 
> referred to different portions of the network, to the underlay, to
> the overlay (services).
> 
> So I think it is good to put order and be aligned with the
> terminology. In section 8.1.2 we have to distinguish between
> IPv6-only services (IPv4aaS) and IPv6-only network, according to
> draft-palet-v6ops-ipv6-only.
> 
> Regards,
> 
> Giuseppe
> 
> *From:*v6ops [mailto:[e-mail]] *On Behalf Of *JORDI
> PALET MARTINEZ *Sent:* Monday, March 29, 2021 7:16 PM *To:*
> [e-mail] *Subject:* Re: [v6ops] draft-vf-v6ops-ipv6-deployment
> and draft-vf-v6ops-ipv6-deployment
> 
> Regarding 8.1.2, I think that’s not correct.
> 
> Some operators may do IPv6-only at the access network only. It is a 
> case-by-case basis.
> 
> I will try to update ASAP I’ve some free time:
> 
> https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-05 
> <https://tools.ietf.org/html/draft-palet-v6ops-ipv6-only-05>
> 
> Regards,
> 
> Jordi
> 
> @jordipalet
> 
> El 29/3/21 17:09, "v6ops en nombre de Giuseppe Fioccola" 
> <[e-mail] <mailto:[e-mail]>en nombre de 
> [e-mail] <mailto:[e-mail]>> 
> escribió:
> 
> Hi Chongfeng,
> 
> Thanks a lot for your support.
> 
> I appreciate your comments which we can address in the next version.
> 
> Please find my answers inline tagged as [GF]
> 
> Regards,
> 
> Giuseppe
> 
> *From:*[e-mail] 
> <mailto:[e-mail]>[mailto:[e-mail] 
> <mailto:[e-mail]>] *Sent:* Monday, March 29, 2021 4:04
> PM *To:* Fred Baker <[e-mail] 
> <mailto:[e-mail]>>; [e-mail]
> <mailto:[e-mail]> *Cc:*
> [e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]> *Subject:* Re:
> [v6ops] draft-vf-v6ops-ipv6-deployment and 
> draft-vf-v6ops-ipv6-deployment
> 
> Hi，Giuseppe, Paolo,
> 
> This draft provide latest worldwide IPv6 status from various aspects，
> it is a constructive and useful document and I support its adoption.
> In addition, I provide some comments and personal suggestions as
> below,
> 
> P4.    Section 2 mentions "NAT and the address transfer to counter
> the IPv4 exhaustion".
> 
> It should be noted that in some cases, private address space can not
>  provide adequate address,  it is reused in the same network which
> make the network even more complex, so NAT can not solve the problem
> of address shortage.
> 
> Since each address blocks of Internet is owned by specific owner,
> which is stored in routing DB for the verification of the
> authenticity of routing information, frequent address transfer may
> make the global routing unstable and even in disorder.
> 
> [GF]: Agree, it is important to highlight in this section how private
>  10.0.0.0/8 space (RFC1918) is not enough in some cases. Also the 
> transfer of IPv4 addresses has also some drawbacks for the global 
> routing as you noted.
> 
> P7,    Section 4 listed several transtion technologies, they mainly 
> provide access to users at the edge of the network, so it better to
> add "for user access" when they are introdueced.
> 
> [GF]: Will do.
> 
> P8.  Section 5 illustrate about IPv6 for enterprise, IPv6 show its 
> advantages in the case of acqiusition, when enterprise merge two 
> networks which use IPv4 private addresses, the address space of the
> two networks may overlap which make the merging difficult.
> 
> [GF]: Good point. We can add this motivation for IPv6 for
> enterprise.
> 
> P9. "In this latter case, the service is delivered solely on IPv6." 
> should be changed to "In this latter case, the traffic is delivered 
> solely on IPv6, Including the traffic originated from IPv4-based
> nodes.
> 
> In addition,  "6to4" should be deleted since it has been outdated in
> IETF.
> 
> [GF]: Will do.
> 
> P10.    In  "The CPE has only an IPv6 address at the WAN side and
> uses an IPv6 connection to the operator gateway, e.g"
> 
> My understanding is that In dual-stack mode, CPE has an IPv6 address
> and IPv4 address simultaneously.
> 
> [GF]: Ok, I will revise this sentence.
> 
> "when IPv6 increases to a certain limit, it would be better to switch
> to the IPv6-only stage." should be changed to "when IPv6 usage 
> increases to a certain limit, it would be better to switch to the 
> IPv6-only stage."
> 
> [GF]: There was some discussion on this statement in a related
> thread. We plan to extend the concept of this paragraph and we will
> try to betterdefine the "limit" that could be "when IPv4 traffic is
> vanishingly small" or "when IPv6 usage increases to a certain limit"
> as you suggested. We will include some considerations about what is a
>  reasonable limit, in particular based on the data from the mailing
> list discussion or that we can find looking at public statistics.
> 
> In section 8.1.2, the following clause should be added,
> 
> "For an network operator, IPv6-only means that the whole network use
> IPv6 as the universal network protocol for all traffic delivery."
> 
> [GF]: Sure, Will do.
> 
> P12.  In "All MPLS services can be guaranteed in IPv6 as well through
>  6PE/6VPE protocols."
> 
> It should be noted that the coverage of MPLS is limted, for instance,
> it does not reach into the cloud/DC generally, therefore, it can not
> take effect in this scenario.
> 
> [GF]: Ok, it is better to specify.
> 
> p13， I propose the following clause about IPv6 action plan should be
>  added following the clause of  "The  Call for Comment is at [US-FR]
> and [US-CIO]."
> 
> "In China, the goverment launched IPv6 action plan in 2017, which 
> requires that networks, applications and terminal devices will fully
>  support the adoption of IPv6 by the end of 2025."
> 
> Reference: 
> http://www.china.org.cn/business/2017-11/27/content_41948814.htm 
> <http://www.china.org.cn/business/2017-11/27/content_41948814.htm>
> 
> 
> [GF]: This is a very good reference about the government incentives
> in China. We will surely add it.
> 
> Regards
> 
> Chongfeng
> 
> *From:*Fred Baker <mailto:[e-mail]>
> 
> *Date:* 2021-03-27 12:58
> 
> *To:*[e-mail] <mailto:[e-mail]>
> 
> *CC:*[e-mail] 
> <mailto:[e-mail]>; 
> [e-mail] 
> <mailto:[e-mail]>
> 
> *Subject:* [v6ops] draft-vf-v6ops-ipv6-deployment and 
> draft-vf-v6ops-ipv6-deployment
> 
>> On Mar 19, 2021, at 1:39 AM, Paolo Volpato
>> <[e-mail] <mailto:[e-mail]>>
>> wrote:
> 
>> 
> 
>> For lmhp-v6ops-transition-comparison, on behalf of the authors of
>> draft-vf-v6ops-ipv6-deployment I can say we  are in favor of the WG
>> adoption. Not only is it a good description
> of the transition technologies to IPv6, but it also constitutes a 
> basis for our draft.
> 
> OK, let me put this to the working group. We asked about adoption of 
> draft-lmhp-v6ops-transition-comparison once before (in January 2020),
> and got essentially no response. It has come up on the list twice
> since, in July and in November. The authors of 
> draft-vf-v6ops-ipv6-deployment would like to see it adopted. The two 
> sets of authors are disjoint. I therefore have at least nine people 
> that would like to see us adopt and publish it. What other folks have
> opinions, pro or con?
> 
> Along the same lines, are there opinions regarding the adoption of 
> draft-vf-v6ops-ipv6-deployment?
> 
> https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-lmhp-v6ops-transition-comparison%22
>
> 
<https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-lmhp-v6ops-transition-comparison%22>
> 
> https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-vf-v6ops-ipv6-deployment%22
>
> 
<https://mailarchive.ietf.org/arch/search/?qdr=a&q=%22draft-vf-v6ops-ipv6-deployment%22>
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] 
> <mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/v6ops 
> <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> ********************************************** IPv4 is over Are you
> ready for the new Internet ? http://www.theipv6company.com
> <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
>