I-D list for IPv6 Operations RSS Feed

IPv6-Only and IPv6-Mostly Terminology Definitions

2026-10-30T15:49:52.809801+00:00

Intended Status changed to Informational from None

Testing Applications' IPv6 Support

2026-10-30T13:20:03.637567+00:00

AD Review: https://mailarchive.ietf.org/arch/msg/v6ops/z3hItHMrQ5LPKtP65qVLdJ2Oq_s/

IPv6-Only and IPv6-Mostly Terminology Definitions

2026-10-30T10:31:57.715056+00:00

Med's AD Review: https://mailarchive.ietf.org/arch/msg/v6ops/mhwI8b_ANwowHxX4vtZYIADwL6I/

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-30T07:40:06.510310+00:00

Thanks for merging the PR.

There are still some major points to address before putting the doc in the IETF LC, in particular the following points:

# Do we need to also tweak this part from 6147?

Section 7.3 of RFC6147 has the following:

Note that the IPv4 address can be a public or a
private address; the latter does not present any additional
difficulty, since an NSP must be used as Pref64::/96 (in this
scenario, the usage of the Well-Known Prefix is not supported as
discussed in [RFC6052]

# Idem for RFC 6877

Section 1 says:

The 464XLAT architecture *** only *** supports IPv4 in the
client-server model, where the server has a global IPv4 address.

Section 2 has also:

PLAT: PLAT is provider-side translator (XLAT) that complies with
[RFC6146] It translates N:1 global IPv6 addresses to global
IPv4 addresses, and vice versa.

CLAT: CLAT is customer-side translator (XLAT) that complies with
[RFC6145] It algorithmically translates 1:1 private IPv4
addresses to global IPv6 addresses, and vice versa.

The use of WKP will lead to non-global IPv6 addresses.

# Idem for RFC 7050

Appendix B says:

The IPv4 addresses for the well-known name cannot be non-global IPv4
addresses as listed in the Section 3 of [RFC5735]. Otherwise, DNS64
servers might not perform AAAA record synthesis when the well-known
prefix is used, as stated in Section 3.1 of [RFC6052].

# Suggestions to address other points in the review: https://github.com/furry13/6052-update-wkp1918/pull/12

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-30T07:40:06.503175+00:00

Changed action holders to Warren Kumari, Jen Linkova (IESG state changed)

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-30T07:40:06.429607+00:00

IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T21:56:17.824661+00:00

Changed action holders to Mohamed Boucadair (IESG state changed)

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T21:56:17.794148+00:00

Sub state has been changed to AD Followup from Revised I-D Needed

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T21:56:17.567150+00:00

New version available: draft-ietf-v6ops-nat64-wkp-1918-09.txt

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T21:56:17.563290+00:00

New version approved

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T21:55:26.043208+00:00

Request for posting confirmation emailed to previous authors: Jen Linkova , Warren Kumari

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T21:55:25.777024+00:00

Uploaded new revision

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T19:24:25.542532+00:00

Request for IETF Last Call review by ARTART is assigned to Pete Resnick

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T19:15:46.001288+00:00

Request for IETF Last Call review by SECDIR is assigned to Benjamin Kaduk

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T17:29:33.889663+00:00

IANA Review state changed to IANA - Review Needed

Last Call Issued: IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T17:29:33.856725+00:00

The following Last Call announcement was sent out (ends 2026-11-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-v6ops-6mops@ietf.org, mohamed.boucadair@orange.com, tim.chown@jisc.ac.uk, v6ops-chairs@ietf.org, v6ops@ietf.org
Reply-To: last-call@ietf.org, v6ops@ietf.org
Sender:
Subject: Last Call: (IPv6-mostly Networks: Deployment and Operations Considerations) to Informational RFC

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
'IPv6-mostly Networks: Deployment and Operations Considerations'

as Informational RFC

The IESG plans to make a decision on this document in the coming weeks, and
solicits last-call comments. Please send substantive comments to the
last-call@ietf.org mailing list, with v6ops@ietf.org copied, no later than
2026-11-12. Please retain the beginning of the Subject line to facilitate
automated sorting.

Abstract

This document discusses a deployment scenario called "an IPv6-mostly
network", when IPv6-only and IPv4-enabled endpoints coexist on the
same network (e.g. local area network (LAN)). This approach enables
incremental transition from dual-stack to IPv6-only networks by
allowing IPv6-capable devices to remain IPv6-only while the network
is seamlessly supplying IPv4 addresses to those devices that require
them. This document discusses the requirements, recommendations, and
challenges associated with deploying IPv6-mostly networks in
enterprise and public Wi-Fi environments.

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

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

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T17:29:33.806293+00:00

IESG state changed to In Last Call from Last Call Requested

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:46:27.988784+00:00

Last call was requested

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:46:27.835408+00:00

Last call announcement was generated

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:46:27.704061+00:00

Ballot approval text was generated

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:46:27.669783+00:00

Ballot writeup was generated

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:46:26.662665+00:00

IESG state changed to Last Call Requested from AD Evaluation::AD Followup

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:46:14.399887+00:00

Remaining points from AD review addressed in https://author-tools.ietf.org/iddiff?url1=draft-ietf-v6ops-6mops-11&url2=draft-ietf-v6ops-6mops-12&difftype=--html.

The doc is now ready for WGLC. Thanks.

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:14:59.247725+00:00

Changed action holders to Mohamed Boucadair (IESG state changed)

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:14:59.216676+00:00

Sub state has been changed to AD Followup from Revised I-D Needed

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:14:58.614896+00:00

New version available: draft-ietf-v6ops-6mops-12.txt

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:14:58.610575+00:00

New version accepted (logged-in submitter: Jen Linkova)

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T16:14:58.550278+00:00

Uploaded new revision

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T14:50:57.795195+00:00

A revised version is needed to address at least the normative references issues. The other points may wait for the next round, if needed.

See more at https://mailarchive.ietf.org/arch/msg/v6ops/9R8PCAf8Ug0mKa_yqSJ467fV4Do/

Thank you.

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T14:50:57.787243+00:00

Changed action holders to Nick Buraglio, Ondřej Caletka, Jen Linkova (IESG state changed)

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T14:50:57.704154+00:00

IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-29T14:49:21.255210+00:00

Almost all AD review comments were addressed in: https://author-tools.ietf.org/iddiff?url2=draft-ietf-v6ops-6mops-11

Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)

2026-10-29T06:34:17.509150+00:00

Returned to the WG. See the note at: https://mailarchive.ietf.org/arch/msg/v6ops/DWjCe_9cMG0hKOna2TCDeAoXh3k/

Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)

2026-10-29T06:34:17.194215+00:00

IETF WG state changed to WG Document from Submitted to IESG for Publication

Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)

2026-10-29T06:33:38.042900+00:00

IESG state changed to I-D Exists from AD Evaluation::AD Followup

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T01:10:23.561166+00:00

# Document Shepherd Write-Up for Working Group Documents

*This version is dated 9 October 2026.*

Thank you for serving as a document shepherd. One of the responsibilities of
the shepherd is to consider and answer the questions in this write-up to
provide helpful context to Last Call and Internet Engineering Steering Group
([IESG][1]) reviewers. Your diligence in completing it is appreciated. The full
role of the shepherd is described in [RFC 4858][2]. At a minimum, you will need
the cooperation of the authors and editors to complete these checks.

Note that some numbered items contain multiple, related questions; please be
sure to answer all of them. It is highly appreciated to elaborate your answers
with more contextual information (as appropriate).

When an item does not apply to the document, please indicate "N/A".

NOTE: Please remove the above text when posting your write-up.

## Document History & Implementations

1. Have the Chairs confirmed Working Group (WG) consensus for this document?
Did they indicate any issues to be called out with regard to that rough
consensus? If so, what were they?

Please supply any additional information about the quality of the WG
consensus from the Shepherd's view (e.g., whether the consensus represents
the strong concurrence of a few individuals, with others being silent, or
did it reach a broad agreement).

The WG reached agreement after active discussion and an extended WGLC. Multiple
participants reviewed the document, and comments were addressed in subsequent
revisions. No unresolved objections remain.

2. Indicate any significant disagreement in the WG about whether or not this
document falls within the current charter.

None.

3. If anyone threatened an appeal or otherwise indicated extreme discontent,
please summarize the areas of conflict in separate email messages to the
responsible Area Director.

(NOTE: This should be in a separate email because this completed
questionnaire will be publicly available.)

No.

4. For protocol documents, indicate whether the document adheres to the WG
implementation policy (if any). Also, indicate whether there are existing
(or planned) implementations and, if so, where they are listed.
([RFC 7942][3] recommends they be reported in the document itself).

No implementation has been reported as specifically implementing this draft.
However, Section 4.1 documents operational experience showing that many widely
deployed CLAT implementations already exhibit the translation behavior specified
by this document.

## Additional Reviews

5. Have reviews for the document happened in other IETF WGs or external
organizations that you are aware of? If so, please provide references to
those reviews (if any).

The document interacts with IPv6 address synthesis and translation behavior
relevant to 6man. Participants active in 6man reviewed and commented on the
document during the v6ops discussion. No formal external review is required.

6. Describe the results of formal expert reviews (e.g., media type, URI) that
the document has undergone. Also, indicate whether any of the required
reviews are missing.

No.

7. If the document contains a YANG module, does the document’s Datatracker page
indicate that it has no errors and warnings?

Has a YANGDOCTOR review been done on a recent version, indicating that it is
ready for publication?

This document does not contain a YANG module.

Does the document use the various templates in [RFC 9907][4] (mainly, YANG
module, Security, and IANA templates)?

N/A.

8. Describe all reviews and automated checks performed to validate sections of
the document written in a formal language, such as XML, JSON code,
ABNF/RBNF/BNF rules, ASN.1, CBOR CDDL, etc.

N/A.

9. Does the document describe any protocol elements that are intended for human
interpretation and understanding? If so, does the document contain an
Internationalization Considerations section that describes how those
protocol elements are suitable for international use?

No.

## Document Shepherd Checks

10. Confirm that (in your opinion) this document is clearly written, complete,
technically accurate, correctly designed, and ready to be handed off to the
responsible Area Director.

Yes.

11. Several IETF Areas have assembled
[lists of common issues that their reviewers encounter][5]. Have such
issues been identified and addressed? For which areas are subsequent
reviews believed particularly important to happen?

No additional specialized review has been identified as necessary. Operational
and security considerations received WG review; normal IETF Last Call, directorate,
and IESG review remain appropriate.

12. What type of RFC publication is being requested
([Best Current Practice][6], [Proposed Standard, Internet Standard][7],
[Informational, Experimental, or Historic][8])?

Proposed Standard.

Why is this the appropriate type of RFC?

The document normatively updates requirements in RFC 6052 and therefore
Standards Track is appropriate. The draft itself reflects this intent.

13. Will publication of this document change the status of any existing
RFC(s)? If so, does the Datatracker status page for this document correctly
list those RFCs on the Title page, in the Abstract, and in the Introduction
of the document?

No. Publication will not change the status of RFC6052; this document updates
RFC6052. The update is identified in the document header and Abstract.

14. If the document uses [BCP 14][9] key words, does the document follow the
guidance in the
[IESG Statement on Clarifying the Use of BCP 14 Key Words][10]?
Is there any use of the BCP 14 key words that could be considered unclear
or inappropriate? Please flag those.

Yes, it follows the guidance in [IESG Statement on Clarifying the Use of BCP 14 Key Words].

15. Confirm that reasonable efforts have been made to remind the WG (including
the document authors, editors, and contributors) about the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][11].

Please summarize any relevant discussion, including links to publicly
available messages when applicable.

All authors are aware of IPR responsibilities and have responded to the poll.

16. Confirm that each author, editor, and contributor has shown their
willingness to be listed as such. If the total number of authors and
editors on the front page is greater than five, please provide a
justification.

Yes, there are two authors on the front page.

17. Please list any remaining I-D nits in the version of the document you
reviewed that you feel are actual errors. Simply running the
[idnits tool][12] is not enough; please review the
["Content Guidelines" on authors.ietf.org][13]. Idnits may display false
positives; please flag those and please briefly explain as needed.
(NOTE: No need to provide explanation for common false positives that are
self-explanatory such as the existence of a newer version of referenced
I-D)

Idnits found no errors/flaws and the remaining warnings concern intentional
example/private addresses and the obsolete RFC5735 reference retained in the
quoted OLD TEXT.

There are a few spelling errors in the draft. These can be fixed during the IETF LC.

### Document References

18. List any informative references that should be normative or vice-versa?
If so, please list those.

See the [IESG Statement on Normative and Informative References][14].

None.

19. List any normative references that are not freely available to anyone.
Does the community have sufficient access to review these references?

None.

20. List any normative downward references (see [RFC 3967][15] and
[BCP 97][16]) that are not already listed in the [DOWNREF registry][17].

None.

21. List any normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear
state. For each, indicate the plan for their completion, if known.

None.

### IANA Considerations

22. Describe your review of the IANA considerations section, especially its
consistency with the body of the document.

Confirm that all IANA requested actions 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, allocation procedures, and a reasonable name (see
[RFC 8126][18]).

This document has no IANA actions.

23. List any new IANA registries that require Designated Expert Review for
future allocations (Expert Review, Specification Required). If any, please
confirm that the document includes guidelines for Designated Experts. Are
these instructions to the Designated Expert clear?

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/info/rfc4858/
[3]: https://www.rfc-editor.org/info/rfc7942/
[4]: https://www.rfc-editor.org/info/rfc9907/
[5]: https://wiki.ietf.org/group/iesg/ExpertTopics
[6]: https://www.rfc-editor.org/info/rfc2026/#section-5
[7]: https://www.rfc-editor.org/info/rfc2026/#section-4.1
[8]: https://www.rfc-editor.org/info/rfc2026/#section-4.2
[9]: https://datatracker.ietf.org/doc/bcp14/
[10]: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
[11]: https://www.rfc-editor.org/info/bcp79/
[12]: https://author-tools.ietf.org/idnits3/
[13]: https://authors.ietf.org/en/content-guidelines-overview
[14]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[15]: https://www.rfc-editor.org/info/rfc3967/
[16]: https://www.rfc-editor.org/info/bcp97/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://www.rfc-editor.org/info/rfc8126/

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T01:07:32.029200+00:00

# Document Shepherd Write-Up for Working Group Documents

*This version is dated 9 October 2026.*

Thank you for serving as a document shepherd. One of the responsibilities of
the shepherd is to consider and answer the questions in this write-up to
provide helpful context to Last Call and Internet Engineering Steering Group
([IESG][1]) reviewers. Your diligence in completing it is appreciated. The full
role of the shepherd is described in [RFC 4858][2]. At a minimum, you will need
the cooperation of the authors and editors to complete these checks.

Note that some numbered items contain multiple, related questions; please be
sure to answer all of them. It is highly appreciated to elaborate your answers
with more contextual information (as appropriate).

When an item does not apply to the document, please indicate "N/A".

NOTE: Please remove the above text when posting your write-up.

## Document History & Implementations

1. Have the Chairs confirmed Working Group (WG) consensus for this document?
Did they indicate any issues to be called out with regard to that rough
consensus? If so, what were they?

Please supply any additional information about the quality of the WG
consensus from the Shepherd's view (e.g., whether the consensus represents
the strong concurrence of a few individuals, with others being silent, or
did it reach a broad agreement).

The WG reached agreement after active discussion and an extended WGLC. Multiple
participants reviewed the document, and comments were addressed in subsequent
revisions. No unresolved objections remain.

2. Indicate any significant disagreement in the WG about whether or not this
document falls within the current charter.

None.

3. If anyone threatened an appeal or otherwise indicated extreme discontent,
please summarize the areas of conflict in separate email messages to the
responsible Area Director.

(NOTE: This should be in a separate email because this completed
questionnaire will be publicly available.)

No.

4. For protocol documents, indicate whether the document adheres to the WG
implementation policy (if any). Also, indicate whether there are existing
(or planned) implementations and, if so, where they are listed.
([RFC 7942][3] recommends they be reported in the document itself).

No implementation has been reported as specifically implementing this draft.
However, Section 4.1 documents operational experience showing that many widely
deployed CLAT implementations already exhibit the translation behavior specified
by this document.

## Additional Reviews

5. Have reviews for the document happened in other IETF WGs or external
organizations that you are aware of? If so, please provide references to
those reviews (if any).

The document interacts with IPv6 address synthesis and translation behavior
relevant to 6man. Participants active in 6man reviewed and commented on the
document during the v6ops discussion. No formal external review is required.

6. Describe the results of formal expert reviews (e.g., media type, URI) that
the document has undergone. Also, indicate whether any of the required
reviews are missing.

No.

7. If the document contains a YANG module, does the document’s Datatracker page
indicate that it has no errors and warnings?

Has a YANGDOCTOR review been done on a recent version, indicating that it is
ready for publication?

This document does not contain a YANG module.

Does the document use the various templates in [RFC 9907][4] (mainly, YANG
module, Security, and IANA templates)?

N/A.

8. Describe all reviews and automated checks performed to validate sections of
the document written in a formal language, such as XML, JSON code,
ABNF/RBNF/BNF rules, ASN.1, CBOR CDDL, etc.

N/A.

9. Does the document describe any protocol elements that are intended for human
interpretation and understanding? If so, does the document contain an
Internationalization Considerations section that describes how those
protocol elements are suitable for international use?

No.

## Document Shepherd Checks

10. Confirm that (in your opinion) this document is clearly written, complete,
technically accurate, correctly designed, and ready to be handed off to the
responsible Area Director.

Yes.

11. Several IETF Areas have assembled
[lists of common issues that their reviewers encounter][5]. Have such
issues been identified and addressed? For which areas are subsequent
reviews believed particularly important to happen?

No additional specialized review has been identified as necessary. Operational
and security considerations received WG review; normal IETF Last Call, directorate,
and IESG review remain appropriate.

12. What type of RFC publication is being requested
([Best Current Practice][6], [Proposed Standard, Internet Standard][7],
[Informational, Experimental, or Historic][8])?

Proposed Standard.

Why is this the appropriate type of RFC?

The document normatively updates requirements in RFC 6052 and therefore
Standards Track is appropriate. The draft itself reflects this intent.

13. Will publication of this document change the status of any existing
RFC(s)? If so, does the Datatracker status page for this document correctly
list those RFCs on the Title page, in the Abstract, and in the Introduction
of the document?

No. Publication will not change the status of RFC6052; this document updates
RFC6052. The update is identified in the document header and Abstract.

14. If the document uses [BCP 14][9] key words, does the document follow the
guidance in the
[IESG Statement on Clarifying the Use of BCP 14 Key Words][10]?
Is there any use of the BCP 14 key words that could be considered unclear
or inappropriate? Please flag those.

Yes, it follows the guidance in [IESG Statement on Clarifying the Use of BCP
14 Key Words].

15. Confirm that reasonable efforts have been made to remind the WG (including
the document authors, editors, and contributors) about the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][11].

Please summarize any relevant discussion, including links to publicly
available messages when applicable.

All authors are aware of IPR responsibilities and have responded to the poll.

16. Confirm that each author, editor, and contributor has shown their
willingness to be listed as such. If the total number of authors and
editors on the front page is greater than five, please provide a
justification.

Yes, there are two authors on the front page.

17. Please list any remaining I-D nits in the version of the document you
reviewed that you feel are actual errors. Simply running the
[idnits tool][12] is not enough; please review the
["Content Guidelines" on authors.ietf.org][13]. Idnits may display false
positives; please flag those and please briefly explain as needed.
(NOTE: No need to provide explanation for common false positives that are
self-explanatory such as the existence of a newer version of referenced
I-D)

Idnits found no errors/flaws and the remaining warnings concern intentional
example/private addresses and the obsolete RFC5735 reference retained in the
quoted OLD TEXT.

There are a few spelling errors in the draft. These can be fixed during the IETF LC.

### Document References

18. List any informative references that should be normative or vice-versa?
If so, please list those.

See the [IESG Statement on Normative and Informative References][14].

None.

19. List any normative references that are not freely available to anyone.
Does the community have sufficient access to review these references?

None.

20. List any normative downward references (see [RFC 3967][15] and
[BCP 97][16]) that are not already listed in the [DOWNREF registry][17].

None.

21. List any normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear
state. For each, indicate the plan for their completion, if known.

None.

### IANA Considerations

22. Describe your review of the IANA considerations section, especially its
consistency with the body of the document.

Confirm that all IANA requested actions 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, allocation procedures, and a reasonable name (see
[RFC 8126][18]).

This document has no IANA actions.

23. List any new IANA registries that require Designated Expert Review for
future allocations (Expert Review, Specification Required). If any, please
confirm that the document includes guidelines for Designated Experts. Are
these instructions to the Designated Expert clear?

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/info/rfc4858/
[3]: https://www.rfc-editor.org/info/rfc7942/
[4]: https://www.rfc-editor.org/info/rfc9907/
[5]: https://wiki.ietf.org/group/iesg/ExpertTopics
[6]: https://www.rfc-editor.org/info/rfc2026/#section-5
[7]: https://www.rfc-editor.org/info/rfc2026/#section-4.1
[8]: https://www.rfc-editor.org/info/rfc2026/#section-4.2
[9]: https://datatracker.ietf.org/doc/bcp14/
[10]: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
[11]: https://www.rfc-editor.org/info/bcp79/
[12]: https://author-tools.ietf.org/idnits3/
[13]: https://authors.ietf.org/en/content-guidelines-overview
[14]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[15]: https://www.rfc-editor.org/info/rfc3967/
[16]: https://www.rfc-editor.org/info/bcp97/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://www.rfc-editor.org/info/rfc8126/

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T00:46:10.567668+00:00

# Document Shepherd Write-Up for Working Group Documents

*This version is dated 9 October 2026.*

Thank you for serving as a document shepherd. One of the responsibilities of
the shepherd is to consider and answer the questions in this write-up to
provide helpful context to Last Call and Internet Engineering Steering Group
([IESG][1]) reviewers. Your diligence in completing it is appreciated. The full
role of the shepherd is described in [RFC 4858][2]. At a minimum, you will need
the cooperation of the authors and editors to complete these checks.

Note that some numbered items contain multiple, related questions; please be
sure to answer all of them. It is highly appreciated to elaborate your answers
with more contextual information (as appropriate).

When an item does not apply to the document, please indicate "N/A".

NOTE: Please remove the above text when posting your write-up.

## Document History & Implementations

1. Have the Chairs confirmed Working Group (WG) consensus for this document?
Did they indicate any issues to be called out with regard to that rough
consensus? If so, what were they?

Please supply any additional information about the quality of the WG
consensus from the Shepherd's view (e.g., whether the consensus represents
the strong concurrence of a few individuals, with others being silent, or
did it reach a broad agreement).

The WG reached agreement after active discussion and an extended WGLC. Multiple
participants reviewed the document, and comments were addressed in subsequent
revisions. No unresolved objections remain.

2. Indicate any significant disagreement in the WG about whether or not this
document falls within the current charter.

None.

3. If anyone threatened an appeal or otherwise indicated extreme discontent,
please summarize the areas of conflict in separate email messages to the
responsible Area Director.

(NOTE: This should be in a separate email because this completed
questionnaire will be publicly available.)

No.

4. For protocol documents, indicate whether the document adheres to the WG
implementation policy (if any). Also, indicate whether there are existing
(or planned) implementations and, if so, where they are listed.
([RFC 7942][3] recommends they be reported in the document itself).

No implementation has been reported as specifically implementing this draft.
However, Section 4.1 documents operational experience showing that many widely
deployed CLAT implementations already exhibit the translation behavior specified
by this document.

## Additional Reviews

5. Have reviews for the document happened in other IETF WGs or external
organizations that you are aware of? If so, please provide references to
those reviews (if any).

The document interacts with IPv6 address synthesis and translation behavior
relevant to 6man. Participants active in 6man reviewed and commented on the
document during the v6ops discussion. No formal external review is required.

6. Describe the results of formal expert reviews (e.g., media type, URI) that
the document has undergone. Also, indicate whether any of the required
reviews are missing.

No.

7. If the document contains a YANG module, does the document’s Datatracker page
indicate that it has no errors and warnings?

Has a YANGDOCTOR review been done on a recent version, indicating that it is
ready for publication?

This document does not contain a YANG module.

Does the document use the various templates in [RFC 9907][4] (mainly, YANG
module, Security, and IANA templates)?

N/A.

8. Describe all reviews and automated checks performed to validate sections of
the document written in a formal language, such as XML, JSON code,
ABNF/RBNF/BNF rules, ASN.1, CBOR CDDL, etc.

N/A.

9. Does the document describe any protocol elements that are intended for human
interpretation and understanding? If so, does the document contain an
Internationalization Considerations section that describes how those
protocol elements are suitable for international use?

No.

## Document Shepherd Checks

10. Confirm that (in your opinion) this document is clearly written, complete,
technically accurate, correctly designed, and ready to be handed off to the
responsible Area Director.

Yes.

11. Several IETF Areas have assembled
[lists of common issues that their reviewers encounter][5]. Have such
issues been identified and addressed? For which areas are subsequent
reviews believed particularly important to happen?

No additional specialized review has been identified as necessary. Operational
and security considerations received WG review; normal IETF Last Call, directorate,
and IESG review remain appropriate.

12. What type of RFC publication is being requested
([Best Current Practice][6], [Proposed Standard, Internet Standard][7],
[Informational, Experimental, or Historic][8])?

Proposed Standard.

Why is this the appropriate type of RFC?

The document normatively updates requirements in RFC 6052 and therefore
Standards Track is appropriate. The draft itself reflects this intent.

13. Will publication of this document change the status of any existing
RFC(s)? If so, does the Datatracker status page for this document correctly
list those RFCs on the Title page, in the Abstract, and in the Introduction
of the document?

No. Publication will not change the status of RFC6052; this document updates
RFC6052. The update is identified in the document header and Abstract.

14. If the document uses [BCP 14][9] key words, does the document follow the
guidance in the
[IESG Statement on Clarifying the Use of BCP 14 Key Words][10]?
Is there any use of the BCP 14 key words that could be considered unclear
or inappropriate? Please flag those.

15. Confirm that reasonable efforts have been made to remind the WG (including
the document authors, editors, and contributors) about the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][11].

Please summarize any relevant discussion, including links to publicly
available messages when applicable.

16. Confirm that each author, editor, and contributor has shown their
willingness to be listed as such. If the total number of authors and
editors on the front page is greater than five, please provide a
justification.

17. Please list any remaining I-D nits in the version of the document you
reviewed that you feel are actual errors. Simply running the
[idnits tool][12] is not enough; please review the
["Content Guidelines" on authors.ietf.org][13]. Idnits may display false
positives; please flag those and please briefly explain as needed.
(NOTE: No need to provide explanation for common false positives that are
self-explanatory such as the existence of a newer version of referenced
I-D)

### Document References

18. List any informative references that should be normative or vice-versa?
If so, please list those.

See the [IESG Statement on Normative and Informative References][14].

19. List any normative references that are not freely available to anyone.
Does the community have sufficient access to review these references?

20. List any normative downward references (see [RFC 3967][15] and
[BCP 97][16]) that are not already listed in the [DOWNREF registry][17].

21. List any normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear
state. For each, indicate the plan for their completion, if known.

### IANA Considerations

22. Describe your review of the IANA considerations section, especially its
consistency with the body of the document.

Confirm that all IANA requested actions 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, allocation procedures, and a reasonable name (see
[RFC 8126][18]).

23. List any new IANA registries that require Designated Expert Review for
future allocations (Expert Review, Specification Required). If any, please
confirm that the document includes guidelines for Designated Experts. Are
these instructions to the Designated Expert clear?

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/info/rfc4858/
[3]: https://www.rfc-editor.org/info/rfc7942/
[4]: https://www.rfc-editor.org/info/rfc9907/
[5]: https://wiki.ietf.org/group/iesg/ExpertTopics
[6]: https://www.rfc-editor.org/info/rfc2026/#section-5
[7]: https://www.rfc-editor.org/info/rfc2026/#section-4.1
[8]: https://www.rfc-editor.org/info/rfc2026/#section-4.2
[9]: https://datatracker.ietf.org/doc/bcp14/
[10]: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
[11]: https://www.rfc-editor.org/info/bcp79/
[12]: https://author-tools.ietf.org/idnits3/
[13]: https://authors.ietf.org/en/content-guidelines-overview
[14]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[15]: https://www.rfc-editor.org/info/rfc3967/
[16]: https://www.rfc-editor.org/info/bcp97/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://www.rfc-editor.org/info/rfc8126/

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-29T00:39:48.630881+00:00

# Document Shepherd Write-Up for Working Group Documents

*This version is dated 9 October 2026.*

Thank you for serving as a document shepherd. One of the responsibilities of
the shepherd is to consider and answer the questions in this write-up to
provide helpful context to Last Call and Internet Engineering Steering Group
([IESG][1]) reviewers. Your diligence in completing it is appreciated. The full
role of the shepherd is described in [RFC 4858][2]. At a minimum, you will need
the cooperation of the authors and editors to complete these checks.

Note that some numbered items contain multiple, related questions; please be
sure to answer all of them. It is highly appreciated to elaborate your answers
with more contextual information (as appropriate).

When an item does not apply to the document, please indicate "N/A".

NOTE: Please remove the above text when posting your write-up.

## Document History & Implementations

1. Have the Chairs confirmed Working Group (WG) consensus for this document?
Did they indicate any issues to be called out with regard to that rough
consensus? If so, what were they?

Please supply any additional information about the quality of the WG
consensus from the Shepherd's view (e.g., whether the consensus represents
the strong concurrence of a few individuals, with others being silent, or
did it reach a broad agreement).

The WG reached agreement after active discussion and an extended WGLC. Multiple
participants reviewed the document, and comments were addressed in subsequent
revisions. No unresolved objections remain.

2. Indicate any significant disagreement in the WG about whether or not this
document falls within the current charter.

None.

3. If anyone threatened an appeal or otherwise indicated extreme discontent,
please summarize the areas of conflict in separate email messages to the
responsible Area Director.

(NOTE: This should be in a separate email because this completed
questionnaire will be publicly available.)

No.

4. For protocol documents, indicate whether the document adheres to the WG
implementation policy (if any). Also, indicate whether there are existing
(or planned) implementations and, if so, where they are listed.
([RFC 7942][3] recommends they be reported in the document itself).

No implementation has been reported as specifically implementing this draft.
However, Section 4.1 documents operational experience showing that many widely
deployed CLAT implementations already exhibit the translation behavior specified
by this document.

## Additional Reviews

5. Have reviews for the document happened in other IETF WGs or external
organizations that you are aware of? If so, please provide references to
those reviews (if any).

The document interacts with IPv6 address synthesis and translation behavior
relevant to 6man. Participants active in 6man reviewed and commented on the
document during the v6ops discussion. No formal external review is required.

6. Describe the results of formal expert reviews (e.g., media type, URI) that
the document has undergone. Also, indicate whether any of the required
reviews are missing.

No.

7. If the document contains a YANG module, does the document’s Datatracker page
indicate that it has no errors and warnings?

Has a YANGDOCTOR review been done on a recent version, indicating that it is
ready for publication?

This document does not contain a YANG module.

Does the document use the various templates in [RFC 9907][4] (mainly, YANG
module, Security, and IANA templates)?

N/A.

8. Describe all reviews and automated checks performed to validate sections of
the document written in a formal language, such as XML, JSON code,
ABNF/RBNF/BNF rules, ASN.1, CBOR CDDL, etc.

N/A.

9. Does the document describe any protocol elements that are intended for human
interpretation and understanding? If so, does the document contain an
Internationalization Considerations section that describes how those
protocol elements are suitable for international use?

## Document Shepherd Checks

10. Confirm that (in your opinion) this document is clearly written, complete,
technically accurate, correctly designed, and ready to be handed off to the
responsible Area Director.

11. Several IETF Areas have assembled
[lists of common issues that their reviewers encounter][5]. Have such
issues been identified and addressed? For which areas are subsequent
reviews believed particularly important to happen?

12. What type of RFC publication is being requested
([Best Current Practice][6], [Proposed Standard, Internet Standard][7],
[Informational, Experimental, or Historic][8])?

Why is this the appropriate type of RFC?

13. Will publication of this document change the status of any existing
RFC(s)? If so, does the Datatracker status page for this document correctly
list those RFCs on the Title page, in the Abstract, and in the Introduction
of the document?

14. If the document uses [BCP 14][9] key words, does the document follow the
guidance in the
[IESG Statement on Clarifying the Use of BCP 14 Key Words][10]?
Is there any use of the BCP 14 key words that could be considered unclear
or inappropriate? Please flag those.

15. Confirm that reasonable efforts have been made to remind the WG (including
the document authors, editors, and contributors) about the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][11].

Please summarize any relevant discussion, including links to publicly
available messages when applicable.

16. Confirm that each author, editor, and contributor has shown their
willingness to be listed as such. If the total number of authors and
editors on the front page is greater than five, please provide a
justification.

17. Please list any remaining I-D nits in the version of the document you
reviewed that you feel are actual errors. Simply running the
[idnits tool][12] is not enough; please review the
["Content Guidelines" on authors.ietf.org][13]. Idnits may display false
positives; please flag those and please briefly explain as needed.
(NOTE: No need to provide explanation for common false positives that are
self-explanatory such as the existence of a newer version of referenced
I-D)

### Document References

18. List any informative references that should be normative or vice-versa?
If so, please list those.

See the [IESG Statement on Normative and Informative References][14].

19. List any normative references that are not freely available to anyone.
Does the community have sufficient access to review these references?

20. List any normative downward references (see [RFC 3967][15] and
[BCP 97][16]) that are not already listed in the [DOWNREF registry][17].

21. List any normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear
state. For each, indicate the plan for their completion, if known.

### IANA Considerations

22. Describe your review of the IANA considerations section, especially its
consistency with the body of the document.

Confirm that all IANA requested actions 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, allocation procedures, and a reasonable name (see
[RFC 8126][18]).

23. List any new IANA registries that require Designated Expert Review for
future allocations (Expert Review, Specification Required). If any, please
confirm that the document includes guidelines for Designated Experts. Are
these instructions to the Designated Expert clear?

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/info/rfc4858/
[3]: https://www.rfc-editor.org/info/rfc7942/
[4]: https://www.rfc-editor.org/info/rfc9907/
[5]: https://wiki.ietf.org/group/iesg/ExpertTopics
[6]: https://www.rfc-editor.org/info/rfc2026/#section-5
[7]: https://www.rfc-editor.org/info/rfc2026/#section-4.1
[8]: https://www.rfc-editor.org/info/rfc2026/#section-4.2
[9]: https://datatracker.ietf.org/doc/bcp14/
[10]: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
[11]: https://www.rfc-editor.org/info/bcp79/
[12]: https://author-tools.ietf.org/idnits3/
[13]: https://authors.ietf.org/en/content-guidelines-overview
[14]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[15]: https://www.rfc-editor.org/info/rfc3967/
[16]: https://www.rfc-editor.org/info/bcp97/
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://www.rfc-editor.org/info/rfc8126/

Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)

2026-10-28T13:53:07.079480+00:00

Changed action holders to Mohamed Boucadair (IESG state changed)

Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)

2026-10-28T13:53:07.051689+00:00

Sub state has been changed to AD Followup from Revised I-D Needed

Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)

2026-10-28T13:53:06.849723+00:00

New version available: draft-ietf-v6ops-icmpext-xlat-v6only-source-02.txt

Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)

2026-10-28T13:53:06.846239+00:00

New version accepted (logged-in submitter: Jen Linkova)

Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs)

2026-10-28T13:53:06.789566+00:00

Uploaded new revision

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-28T12:55:50.716508+00:00

Med's review: https://mailarchive.ietf.org/arch/msg/v6ops/ETxJ7xWZUEGAYRGzupnNRPBKtoQ/

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-28T12:55:50.708419+00:00

Changed action holders to Warren Kumari, Jen Linkova (IESG state changed)

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-28T12:55:50.637979+00:00

IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation

IPv6-Only and IPv6-Mostly Terminology Definitions

2026-10-28T11:49:07.611322+00:00

# Document Shepherd Write-Up for draft-ietf-v6ops-ipv6-only

## Document History

1. Have the Chairs confirmed Working Group (WG) consensus for this document? Did they indicate any issues to be called out with regard to that rough consensus? If so, what were they?

The document had very lively discussion and support since the earlier versions, probably over the average.
During the WG Last Call, only a few issues needed to be addressed and were addressed and the chairs confirmed consensus.

2. Indicate any significant disagreement in the WG about whether or not this document falls within the current charter.

No remarkable controversy was raised.

There is one capitalization issue -- e.g. 'IPv6-Only vs. IPv6-only' -- that got no
concluding consensus as most WG members had no strong opinions except for being
consistent across all these composite terms.

3. If anyone threatened an appeal or otherwise indicated extreme discontent, please summarize the areas of conflict in separate email messages to the responsible Area Director

No discontent has been indicated, so difficult to believe that anyone could consider an appeal.

4. For protocol documents, indicate whether the document adheres to the WG implementation policy (if any).
Also, indicate whether there are existing (or planned) implementations and, if so, where they are listed. ([RFC 7942][3] recommends they be reported in the document itself).

It is an Informational document, and contains no protocol that could be implemented.
The terminology defined in the document though has seen adoption by other WG documents.

## Additional Reviews

5. Have reviews for the document happened in other IETF WGs or external organizations that you are aware of? If so, please provide references to those reviews (if any).

As the terminology defined in the document influences future documents in 6man,
its draft has been shared on the 6man list after WGLC. Minor editorial feedback has been incorporated.

6. Describe the results of formal expert reviews (e.g., media type, URI) that the document has undergone. Also, indicate whether any of the required reviews are missing.

N/A

7. If the document contains a YANG module, does the document’s Datatracker page indicate that it has no errors and warnings?
Has a YANGDOCTOR review been done on a recent version, indicating that it is ready for publication?
Does the document use the various templates in [RFC 9907][4] (mainly, YANG module, Security, and IANA templates)?

N/A

8. Describe all reviews and automated checks performed to validate sections of the document written in a formal language, such as XML, JSON code, ABNF/RBNF/BNF rules, ASN.1, CBOR CDDL, etc.

N/A

9. Does the document describe any protocol elements that are intended for human interpretation and understanding? If so, does the document contain an Internationalization Considerations section that describes how those protocol elements are suitable for international use?

N/A

## Document Shepherd Checks

10. Confirm that (in your opinion) this document is clearly written, complete, technically accurate, correctly designed, and ready to be handed off to the responsible Area Director.

I believe it is needed and useful.
It is clearly written.
It has a good structure and is easy to read.
It is ready to be handed to the responsible AD.

11. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][5].
Have such issues been identified and addressed? For which areas are subsequent reviews believed particularly important to happen?

I don't think is the case for this document.

12. What type of RFC publication is being requested ([Best Current Practice][6], [Proposed Standard, Internet Standard][7], [Informational, Experimental, or Historic][8])?

Informational: The document defines terminology.

13. Will publication of this document change the status of any existing RFC(s)? If so, does the Datatracker status page for this document correctly list those RFCs on the Title page, in the Abstract, and in the Introduction of the document?

No.

14. If the document uses BCP 14 key words [9], does the document follow the guidance in the [IESG Statement on Clarifying the Use of BCP 14 Key Words][10]?
Is there any use of the BCP 14 key words that could be considered unclear or inappropriate? Please flag those.

No.

15. Confirm that reasonable efforts have been made to remind the WG (including the document authors, editors, and contributors) about the intellectual property rights (IPR) disclosure obligations described in [BCP 79][11].

Yes.

16. Confirm that each author, editor, and contributor has shown their willingness to be listed as such. If the total number of authors and editors on the front page is greater than five, please provide a justification.

Yes.

17. Please list any remaining I-D nits in the version of the document you reviewed that you feel are actual errors. Simply running the [idnits tool][12] is not enough; please review the ["Content Guidelines" on authors.ietf.org][13]. Idnits may display false positives; please flag those and please briefly explain as needed.
(NOTE: No need to provide explanation for common false positives that are self-explanatory such as the existence of a newer version of referenced I-D)

It seems ok.

### Document References

18. List any informative references that should be normative or vice-versa? If so, please list those.

No, all them seem rightly classified to me.

19. List any normative references that are not freely available to anyone. Does the community have sufficient access to review these references?

None.

20. List any normative downward references (see [RFC 3967][15] and [BCP 97][16]) that are not already listed in the [DOWNREF registry][17].

None.

21. List any normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state. For each, indicate the plan for their completion, if known.

None.

### IANA Considerations

22. Describe your review of the IANA considerations section, especially its consistency with the body of the document.
Confirm that all IANA requested actions 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, allocation procedures, and a reasonable name (see [RFC 8126][18]).

There are no IANA considerations.

23. List any new IANA registries that require Designated Expert Review for future allocations (Expert Review, Specification Required). If any, please confirm that the document includes guidelines for Designated Experts. Are these instructions to the Designated Expert clear?

None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://www.rfc-editor.org/rfc/rfc9907.html
[5]: https://wiki.ietf.org/group/iesg/ExpertTopics
[6]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[7]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[8]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[9]: https://datatracker.ietf.org/doc/bcp14/
[10]: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
[11]: https://www.rfc-editor.org/info/bcp79
[12]: https://author-tools.ietf.org/idnits3/
[13]: https://authors.ietf.org/en/content-guidelines-overview
[14]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[15]: https://www.rfc-editor.org/rfc/rfc3967.html
[16]: https://www.rfc-editor.org/info/bcp97
[17]: https://datatracker.ietf.org/doc/downref/
[18]: https://www.rfc-editor.org/rfc/rfc8126.html

Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses

2026-10-28T09:42:58.870160+00:00

IESG state changed to AD Evaluation from Publication Requested

IPv6-mostly Networks: Deployment and Operations Considerations

2026-10-27T16:46:23.248669+00:00

Changed action holders to Mohamed Boucadair (IESG state changed)