IPv6 Deployment Status
draft-ietf-v6ops-ipv6-deployment-10

** Section 2.1.1.
   It clearly derives
   from the allocation of addresses made in the early days of the
   Internet by the most advanced countries.

“Most advanced” in what sense.  Recommend alternative language.

** Section 2.1.1.  
   The next table compares the IPv4 addresses per capita ratio of a
   certain country with relative adoption of IPv6, expressed as the
   number of IPv6 capable users in the considered country.  

I don’t understand how the second column of Figure 1 is calculated.  For the USA, “IPv6 deployments” = 47.1%

Turning to the raw data in [POTAROO2], for the USA:
-- Internet Users = 256169053
-- v6 users = 135675677
-- population = 338635004

Calculating the ratios in different ways doesn’t produce a 47% figure:
V6 users / Internet Users = ~53%
V6 users / population = ~40%

** Section 2.3.  Figure 3.  Are these values the percentages of all website which are accessible over v6 or the total volume of web traffic which is v6?

** Section 2.3..
   If we consider that the big content providers (such as
   Google, Facebook, Netflix) generate more than 50% of the total mobile
   traffic [SNDVN], and in some cases even more up to 65% ([ISOC1]
   [HxBld]), the percentage of content accessible over IPv6 is clearly
   more relevant than the number of enabled IPv6 websites.

What percentage of that 50% of all mobile traffic is v6?  It would be ideal to connect that 50% metric to Figure 3 (i.e., the text currently cautions that the Figure 3 numbers don’t look so big, because it consists of all website; next it argues that the top sites generate most of the content; the ideal closing narrative would then to show how much of that 50% that relates to v6 usage).

** Section 2.4.  I appreciate these country-specific narratives linking government policy decisions to adoption.  However, these seem a bit anecdotal.   I’m only vaguely familiar with what’s happening in the US.  Linking the US adoption of IPv6 to US OMB’s mandate for federal systems would benefit from more text.  What’s the link to carriers, enterprises and non-profit behavior?  In 2010, OMB directed all external .gov services to be IPv6 native (https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/assets/egov_docs/transition-to-ipv6.pdf).  A decade later in 2020, OMB is still trying with a mandate for 20% of IPv6-only by FY23 for all assets (https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf)

** Section 3.2.  Kuddos on doing an updated survey.  Given that global trends have largely been discussed up to this section, it would be value to convey the regional nature of this survey.  If I understand Appendix A correctly, these are results are from a population of “service providers in the European region.”

** Section 3.4.  Thanks for explicitly mentioning the “Industrial Internet.”    The current text doesn’t provide any measurements, survey data or citations, but it is under the “survey” section (Section 3.*).  What is the basis of the analysis?

** Section 3.6.  Same comment as above.  No disagree with what’s said here.  However, this section is nested under “IPv6 survey” (Section 3).  Is there measurement or survey data that can be added to bolster this text? 

** Section 4.  Is there any way to connect these deployment scenarios to the deployment assessments done by sector in Section 3?

** Section 5.  What is the basis of this sections of challenges?  How was this list of challenges validated with the specific verticals/sectors outlined in the subsequent sections?

** Section 5.1.1.  This section could be clearer on identifying the specific challenges given that this is in the “Common IPv6 Challenges” section (Section 5.*)

** Section 5.1.1.
   On
   average, looking at the global statistics, the IPv6 traffic
   percentage is currently around 40%.

Please cite this figure.

** Section 5.1.1.
   As highlighted earlier, all
   major content providers have already implemented Dual-Stack access to
   their services and most of them have implemented IPv6-only in their
   Data Centers.

I’m not following which citation that might be.  Could it be repeated here.

** Section 5.1.2.  This section would benefit from being more concise on the challenge.  My reading of the text is that it is (1) no business case; and (2) limited training.

** Section 5.1.2.
   As pointed out in
   Section 3, enterprises may benefit deploying IPv6 in their public-
   facing services.

-- I didn’t see these advantages outlined in Section 3.0 or 3.3 (the section specific to enterprises).
-- Doesn’t the subsequent text of “ Enterprises ... do not have the business requirement or technical justification to transit to IPv6.”  This seems to conflict.

** Section 5.1.2.
   In most
   cases, the enterprise engineers and technicians do not know well how
   IPv6 works and the problem of application porting to IPv6 looks quite
   difficult, even if technically the issue is not overly complicated.

I would be careful making a value judgement (“not overly complicated”).

** Section 5.1.2.
  This creates an unfortunate cycle where misinformation about the
   complexity of the IPv6 protocol and unreasonable fears about security
   and manageability combine with the perceived lack of urgent business
   needs to prevent adoption of IPv6.

More value judgement language (“unreasonable fears”).  Strongly recommend rewording this text.

** Section 5.1.2
As the most promising protocol for network evolution, IPv6 ...

Is that too strong of a statement?

** Section 5.1.2.  The last two paragraphs discuss cloud, AI, OT, and IIoT.  None of this text appears related to IPv6 challenges.  It reads more like opportunities with IPv6.

** Section 5.1.4.

   It can be noted that most of the user devices (e.g. smartphones) are
   already IPv6-enabled since so many years.  

Please state this less colloquially.

** Section 5.2.  Editorial.

   There are important IPv6 complementary solutions related to
   Operations, Administration and Maintenance (OAM) that look not so
   complete compared to IPv4

Is there a way to say “not so complete” less colloquially?

** Section 5.2.  Editorial.
OLD
   This is
   because some IPv6 products are not field-proven as for IPv4

NEW
This is because some IPv6 products are not as field-proven as for IPv4

** Section 5.2.

   For example, YANG is the configuration language for networking but in
   the real world the data modeling may be still vendor dependent.

I’m not able to comment on real-world deployment and use of YANG.  What isn’t clear to me how YANG penetration and implementation is a proxy for IPv6 support.

** Section 5.2.
   Deploying IPv6 requires it as policies
   and procedures have to be adjusted in order to successfully plan and
   complete an IPv6 transition.

This sentence doesn’t parse.

** Section 5.2. Typo.  s/few extensive researches and measurement campaigns/few comprehensive measurement campaigns/

Thanks for addressing my previous blocking DISCUSS points (and most if not all my previous non-blocking COMMENTs).

For archiving purposes, here is the link to my previous ballot: https://mailarchive.ietf.org/arch/msg/v6ops/frlQEBmXdEE_kIHNEIuScxklZWI/

I sincerely hope that our discussion has improved the document.

Regards

-éric

# GEN AD review of draft-ietf-v6ops-ipv6-deployment-08

CC @larseggert

Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/F47VyYgPcz-3ggZraZAjBvuywqE).

## Comments

### Section 1, paragraph 17
```
        Section 2 reports data about the status of IPv6.

        Section 3 provides a survey of IPv6 deployments in different
        environments, including ISPs, enterprises, cloud providers and
        universities.

        Section 4 describes the IPv6 transition approaches for Mobile
        BroadBand (MBB), Fixed BroadBand (FBB) and Enterprise services.

        Section 5 analyzes the general challenges to be solved in the IPv6
        transition.  Specific attention will be given to operations,
        performance and security issues.
```
Section 2 and 3 have content I would have expected in this document, given the
title and abstract. Sections 4 and 5 seem to want to provide commentary on IPv6
transition mechanisms and challenges. Those two parts of the document seem so
unrelated that splitting the document in two might make it more readable. (It
might also be a solution to having more than five authors.)

### Section 2.1.1, paragraph 4
```
                 Figure 1: IPv4 per capita and IPv6 deployment
```
What was the criteria for inclusion in this table?

### Section 10.2, paragraph 15
```
     [BGR_1]    BIIGROUP, "China Commercial IPv6 and DNSSEC Deployment
                Monitor", 2022,
                <http://218.2.231.237:5001/cgi-bin/generate>.
```
Is an IPv4 literal URL really the only way to reference this page? (Also for
other similar URLs.)

### Too many authors

The document has six authors, which exceeds the recommended author limit. Has
the sponsoring AD agreed that this is appropriate?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `black-listing`; alternatives might be `blocklist`, `denylist`,
   `prohibited`, `refused`, `reject list`, `unapproved list`
 * Term `masterplan`; alternatives might be `active`, `central`, `initiator`,
   `leader`, `main`, `orchestrator`, `parent`, `primary`, `server`
 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`
 * Term `native`; alternatives might be `built-in`, `fundamental`, `ingrained`,
   `intrinsic`, `original`
 * Term `immature`; alternatives might be `imperfect`, `premature`,
   `underdeveloped`, `unfinished`, `unsophisticated`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4.1, paragraph 4
```
-    may also cause a loss of customers.  Based on feedbacks of network
-                                                          -
+    may also cause a loss of customers.  Based on the feedback of network
+                                                  ++++
```

### Duplicate references

Duplicate informative references to:
`https://cnlabs.in/IPv6_Mon/generate_industry.html`.

### Outdated references

Document references `draft-ietf-v6ops-transition-comparison`, but that has been
published as `RFC9313`.

Document references `draft-ietf-6man-hbh-processing-03`, but `-04` is the
latest available revision.

Document references `draft-ietf-v6ops-hbh-01`, but `-02` is the latest
available revision.

### URLs

These URLs in the document did not return content:

 * https://www.akamai.com/us/en/multimedia/documents/product-brief/ipv6-adaptation-product-brief.pdf

### Grammar/style

#### Section 1.1, paragraph 4
```
nly access network means that every nodes in this access network must be IPv6
                                    ^^^^^
```
The noun should probably be in the singular form.

#### Section 1.1, paragraph 5
```
y backbone network means that every nodes in this backbone network must be IP
                                    ^^^^^
```
The noun should probably be in the singular form.

#### Section 2.1.1, paragraph 3
```
apita ratio than countries like the U.S.A, Germany, France, even if their IPv
                                    ^^^^^
```
The abbreviation/initialism is missing a period after the last letter.

#### Section 2.2, paragraph 4
```
ht that, in quantitative terms, most of content is accessible via IPv6. 2.4.
                                ^^^^^^^^^^^^^^^
```
Consider using "most content" or "most of the content".

#### Section 3.1, paragraph 2
```
ses is repeated in the short term. Hence the two CAGR values in the table sh
                                   ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 3.3.1, paragraph 3
```
rt of IPv6 mail in China and IPv6 web sites in India), the numbers shown in t
                                  ^^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 4.1, paragraph 3
```
, higher bandwidth WAN links, better WiFi technologies, etc.). The CAPEX and
                                     ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.).

#### Section 4.3, paragraph 4
```
 Dual-Stack already started in most of service provider networks. On average
                               ^^^^^^^^^^^^^^^
```
Consider using "most service" or "most of the service".

#### Section 4.3, paragraph 4
```
option for an operator, but there are also other factors like the current IP
                            ^^^^^^^^^^^^^^^^^^^^
```
Consider using "there are other" or "there are also".

#### Section 4.3, paragraph 6
```
e transition is not unique and this bring different challenges in relation to
                                    ^^^^^
```
The verb "bring" is plural. Did you mean: "brings"? Did you use a verb instead
of a noun?

#### Section 5.1.1, paragraph 1
```
 technicians may want to get trained but the management do not see a busines
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 5.1.2, paragraph 2
```
DNs). The response is expected to be an high percentage, at least higher than
                                     ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 5.1.2, paragraph 3
```
ting customers. Because of the extremely small number of customers who notice
                               ^^^^^^^^^^^^^^^
```
Consider using an extreme adjective for "small".

#### Section 5.2, paragraph 1
```
 for a relative latency difference lays on the specificity of the IPv6 header
                                   ^^^^^^^
```
Did you mean "lies on"?

#### Section 10.2, paragraph 53
```
emand. Answer 1.C (30 respondents) On-going In 12 months After 12 months Don'
                                   ^^^^^^^^
```
Did you mean "ongoing"?

#### Section 10.2, paragraph 62
```
e gotten some training 1.85% Web site is IPv6 enabled
                             ^^^^^^^^
```
Nowadays, it's more common to write this as one word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Hi,

Thanks for this document.  I found it to be an interesting and informative read, particularly the earlier sections of the documents.  I did find a couple of sections in chapter 4 (flagged below) to be a bit harder to read.

Minor level comments:

(1) p 18, sec 4.2.  IPv4 as a Service and IPv6-only Overlay

   As defined in Section 1.1, IPv6-only is generally associated with a
   scope, e.g.  IPv6-only overlay or IPv6-only underlay.
   The IPv6-only overlay denotes that the overlay tunnel between the end
   points of a network is based only on IPv6.  It can be used to ensure
   IPv4 support via IPv4aaS and it can be a complex decision that
   depends on several factors, such as economic aspects, policy and
   government regulation.

It wasn't entirely clear to me, but am I right to presume that IPv4aaS is effectively running over the IPv6-Overlay (rather than alongside)?  I generally found this section (i.e., 4.2) to be somewhat harder to read than section 3.


(2) p 19, sec 4.3.  IPv6-only Underlay

   As opposed to IPv6-only overlay and IPv4aaS, discussed in the
   previous sections, IPv6-only underlay network uses IPv6 as the
   network protocol for all traffic delivery.  Both the control and data
   planes are IPv6-based.  The definition of IPv6-only underlay needs to
   be associated with a scope in order to identify the domain where it
   is applicable, such as IPv6-only access network or IPv6-only backbone
   network.

Can IPv4aaS still be used with an IPv6-only Underlay?  Again, I found this section (i.e., 4.3) to be less clear and precise that some of the sections earlier in the document.


Nit level comments:

(3) p 17, sec 4.1.  Dual-Stack

   For this reason, when IPv6 usage exceeds certain threshold, it may be
   advantageous to switch to start a transition to a next scenario.

'Switch to start' doesn't scan very well.

Regards,
Rob