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

[Ballot comment]
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

Request for posting confirmation emailed to previous authors: Chongfeng Xie , Giuseppe Fioccola , Gyan Mishra , Jordi Martinez , Nalini Elkins , Paolo Volpato , v6ops-chairs@ietf.org

[Ballot comment]
# Internet AD comments for draft-ietf-v6ops-ipv6-deployment-08
CC @ekline

* There are many phrasing and wording choices that could use some help from
  an editorial pass.  I'm hoping the RFC Editor can work with the authors to
  improve them.

* I support Eric's discuss.

## Comments

### S1.1

* Is "CGN" really the write term to reference in a discussion of IPv6-only
  terms?  In theory, an IPv6-only overlay can ride on top of an IPv6-only
  underlay.

  Maybe just a full stop after "(BNG)".

  In general I'm not sure I fully agree that the terms and their assigned
  definitions.  They still leave many questions.

### S4.2

* "For applications with a large number of users"

  I think "applications" here risk confusion with other uses of the word
  elsewhere.  The meaning here seems to be more like "deployments"?

### S5.2

* I think it would be good to note in this SLAAC vs DHCPv6 sentence that
  only one of them is mandatory for hosts to implement.

### S5.4.1

* It might be noted also that isolating a host to a LAN segment (i.e. one
  where only the node and infrastructure routers are present) via
  sub-IP-layer mechanisms may address many of these concerns.

  I tried to look at the Security Considerations section of RFC 8273 but
  unfortunately it does not delve into this topic.

[Ballot comment]
# 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,
                .
```
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

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-v6ops-ipv6-deployment-08
CC @evyncke

Thank you for the work put into this document even if I had hoped for a cleaner document. I also regret that security is not mentioned as an incentive to deploy IPv6 security policies as most end-points have IPv6 enabled by default. I am also concerned that this document did not get enough reviews (thanks Robert for your https://mailarchive.ietf.org/arch/msg/v6ops/Trz62uglkVKOuXY3gXV_lNpyBEc/ and 3 reviews -- if not mistaken -- during V6OPS WGLC).

Please find below several blocking DISCUSS points (should the document be sent back to the V6OPS WG ?) and some non-blocking COMMENT points.

Special thanks to Fred Baker for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document because it is important

Regards,

-éric


## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

### Section 1.1

```
      IPv4 as a Service (IPv4aaS): It means that IPv4 service support is
      provided by means of transition mechanism, therefore there is a
      combination of encapsulation/translation + IPv6-only overlay +
      decapsulation/translation.  For an IPv6-only network, connectivity
      to legacy IPv4 is either non-existent or provided by IPv4aaS
      mechanisms.
```
It must be "IPv6-only underlay", see other use of "underlay/overlay" in other IETF published RFC: 7364, 7365, 9272, ...

### Section 4.2 overlay

Again the title and the introduction are incorrect. It should be "IPv4 as a Service and IPv6-only ***Underlay***".

```
  Both are IPv4aaS solutions by leveraging IPv6-only overlay.  IPv4aaS
  offers Dual-Stack service to users and allows an ISP to run IPv6-only
  in the network (typically, the access network).
```
The above text repeats the same mistake.

### Section 4.2 464XLT and MAP-T

While I really like 464XLT, it should not appear in a section with "underlay" as it is *not* an encapsulation mechanism. The same reasoning applies for MAP-T. The section should be about IPv4aaS then 464XLAT and MAP-T could be included.

### Section 5.2

```
  IPv6 addresses can be assigned to an interface
  through different means, such as Stateless Auto-Configuration (SLAAC)
  [RFC4862], stateful and stateless Dynamic Host Control Protocol
  (DHCP) [RFC8415]. 
```

Stateless DHCPv6 *does not* assign IPv6 addresses/prefixes.

### Section 5.4.2

As it is linked to security, I am raising this to a DISCUSS level. Fragmentation can be used to bypass all layer-4 filters not only in NDP as mentioned in the draft, but in any protocol. Please add text about RFC 8200 section 5:
```
          Extension headers, if any, and the Upper-Layer header.  These
          headers must be in the first fragment.
```

[Ballot comment]

## COMMENTS


### Section 1.1

About the IPv6-only interface, the definition only mentions 'forward only IPv6', does this mean that it can receive or transmit IPv4 ? I.e., is it router centric ? I obviously understand the authors' intent, but the definition would benefit from more clarity. It seems also a little IP-centric as there could still be some routed/forwarded protocols that are neither IPv4 not IPv6 (e.g., MPLS).

About "IPv6-only service", the definition assumes a unicast client-server relationship what about multicast streaming or a peer-to-peer (no client/server role like in RTP).

Unsure how to understand "facing interface of CGN" in "IPv6-only overlay".

```
      IPv6-only overlay in fixed network means that the
      encapsulation is only IPv6 between the interfaces of the Provider
      Edge (PE) nodes
```
This is ambiguous... what is meant by "encapsulation is only IPv6" ? Would prefer "where only IPv6 packets are encapsulated"

Please expand and add a reference at first use of "SRv6".

### Section 2.1

`Table 3 of [POTAROO1] shows` please indicate the date (in the text and not only a year in the references).

Please add some explanations about the use of double quotes around "usable".

s/on their WAN-facing side/on their Internet-facing side/

### Section 2.1.1

Please provide a date for the data in figure 1.

### Section 2.3

Just a thank you for the reference to W3tech (I did not know).

Please also note that Alexa does not publish anymore the Top web sites since May 2022 :-(

### Section 2.4

Suggestion to have one paragraph per country.

### Section 3.1

Unsure whether RIR allocation statistics are related to `IPv6 adoption in operational networks.` (line just above) as a prefix can be allocated but not put in operation. Should 'operational' be removed ?

After reading:
```
  Hence the two CAGR values
  in the table should not be compared directly as the weight of the
  allocations is different.
```
I really wonder whether figure 5 and its associated text is useful and not confusing ;-)

### Section 3.2

Please add the date in the section text (else the reader has to jump to the appendix to get it).

Please consider adding references to DS-lite and 464XLAT.

### Section 3.3

To repeat myself, please provide a date for the poll in the section text.

### Section 3.3.1

Please consider removing the European data reference as it includes domains in China and in the USA.

### Section 3.5

I would have expected to have different sections for large content provider (i.e., google.com could use a single IPv4 address) and for cloud provider (i.e., every AWS services must have their own IPv4 global address). I.e., vastly different use cases.

### Section 4

Should the section title indicate that this section is for Service Providers ? as indicated by `service providers may either adopt the scenarios proposed in a sequence or jump directly to a specific
  one.`

### Section 4.1

"CGN" and "IT" acronyms were already introduced before.

Was it "in June 2021" or "in June 2012" ?

### Sections 4.2 and 4.3

It seems to me that section 4.2 is mostly about residential access network while section 4.3 is more about layer-3 services. Should it be better reflected in the title ?

### Section 5.1.2

OT and IT were already expanded before, no need to re-expand.

### Section 5.1.3

The title of this section is about Cloud and DC but the actual content is mainly around CDN (which are very important indeed).

Also the references for CDN include an Amazon reference but this reference is about the cloud/VM and not any CDN.

The sentence `The challenge for CSPs is related to the support of non-native IPv4 since most CSPs provide native IPv6.` is really hard to parse.

### Section 5.1.4

Suggest not to introduce the STB acronym as it is not used at all.

Please describe what "NAT444" is.

Usually, "CE" is used when linked to "PE" as in layer-3 services. I think what should be used in this section is "CPE", which is usually residential grade and not enterprise grade.

### Section 5.2

What is the relationship to IPv6 of the following text:
```
  For example, YANG is the configuration language for networking but in
  the real world the data modeling may be still vendor dependent.
```

Also, if you mention YANG (which BTW is not limited to configuration), then please add NETCONF/RESTCONF to the list of network management protocols.

### Section 5.3.1

"currently" has little semantic in a published RFC.

### Section 5.4

Strongly suggest adding that most vulnerabilities are nowadays in the human being (social engineering) and in the application layer and *not* in the IP layer.

I do like the last paragraph, but it should be a call for staff training as well.

### Section 5.4.1

```
  These IPv6 associated protocols like ICMPv6, NDP and MLD are
  something new compared to IPv4, so they add new security threats and
  the related solutions are still under discussion today.
```
I am afraid that neither ICMPv6 (barring NDP) and MLD are new compared to IPv4 as they are quite similar to ICMPv4 and IGMP ;-)

Should the following section 5.4.2 be subsection of 5.4.1 ? and should fragmentation be mentioned in 5.4.1 ?

### Section 5.4.2

Please add a reference to RFC 5095 (Deprecation of Type 0 Routing Headers in IPv6).

## NITS


## 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.

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

[Ballot comment]
** 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/

[Ballot comment]
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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-v6ops-ipv6-deployment-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-09-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-v6ops-ipv6-deployment@ietf.org, fredbaker.ietf@gmail.com, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IPv6 Deployment Status) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'IPv6 Deployment Status'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-09-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document provides an overview of IPv6 deployment status in early
  2022.  Specifically, it looks at the degree of adoption of IPv6 in
  the industry, analyzes the remaining challenges and proposes further
  investigations in areas where the industry has not yet taken a clear
  and unified approach in the transition to IPv6.  It obsoletes RFC
  6036.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/



No IPR declarations have been submitted directly on this I-D.

Document History
For Documents Coming from IETF Working Groups
• Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?
• Was there controversy about particular points, or were there decisions where the consensus was particularly rough?
Broad agreement. No objections were raised.

• Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No such action has been threatened.

• For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?
Not applicable

Additional Reviews
• Does this document need review from other IETF working groups or external organizations? Have those reviews occurred?
No
• Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
Since it is an informational document on global IPv6 deployment, no specific formal expert review is necessary

Document Shepherd Checks
• Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?
Yes.

• Several IETF Areas have assembled lists of common issues that their reviewers encounter. Do any such issues remain that would merit specific attention from subsequent reviews?
Not really. It makes a number of factual statements, which can be independently verified. Some of the topics listed are mentioned in the draft, but only to describe the current IPv6 status without proposing any change to existing protocols. No specific issues apply to this document.

• What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?
The document is Informational because it intends to propose an update on the status of IPv6. In the IETF stream, it has always been Informational.

• Has the interested community confirmed that any and all appropriate IPR disclosures required by BCP 78 and BCP 79 have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails.
The authors confirm that there is no any formal IPR that applies to this document.

• Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification.
Every author / contributor has confirmed their willingness. The number of authors on the front page is 6 because everyone contributed in some way to develop the text.
• Identify any remaining I-D nits in this document. (See the idnits tool and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document.
A. Done. [Note for Fred: we will run the idnits check before submitting the new version that addresses the comments of the WGLC]
• Should any informative references be normative or vice-versa?
A. No. [Note for Fred: please double check that references are correct].
• List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?
A. All references are publicly available.
• Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them.
A. None applicable
• Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion?
A. No.
• Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.
A. RFC 6036 will be obsoleted.
• Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).
A. The document has no IANA actions.
• List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.
A. Not applicable.

Document History
For Documents Coming from IETF Working Groups
• Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?
• Was there controversy about particular points, or were there decisions where the consensus was particularly rough?
Broad agreement. No objections were raised.

• Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No such action has been threatened.

• For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)?
Not applicable

Additional Reviews
• Does this document need review from other IETF working groups or external organizations? Have those reviews occurred?
No
• Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
Since it is an informational document on global IPv6 deployment, no specific formal expert review is necessary

Document Shepherd Checks
• Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?
Yes.

• Several IETF Areas have assembled lists of common issues that their reviewers encounter. Do any such issues remain that would merit specific attention from subsequent reviews?
Not really. It makes a number of factual statements, which can be independently verified. Some of the topics listed are mentioned in the draft, but only to describe the current IPv6 status without proposing any change to existing protocols. No specific issues apply to this document.

• What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?
The document is Informational because it intends to propose an update on the status of IPv6. In the IETF stream, it has always been Informational.

• Has the interested community confirmed that any and all appropriate IPR disclosures required by BCP 78 and BCP 79 have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails.
The authors confirm that there is no any formal IPR that applies to this document.

• Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification.
Every author / contributor has confirmed their willingness. The number of authors on the front page is 6 because everyone contributed in some way to develop the text.
• Identify any remaining I-D nits in this document. (See the idnits tool and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document.
A. Done. [Note for Fred: we will run the idnits check before submitting the new version that addresses the comments of the WGLC]
• Should any informative references be normative or vice-versa?
A. No. [Note for Fred: please double check that references are correct].
• List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?
A. All references are publicly available.
• Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them.
A. None applicable
• Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion?
A. No.
• Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.
A. RFC 6036 will be obsoleted.
• Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126).
A. The document has no IANA actions.
• List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.
A. Not applicable.