Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
draft-ietf-v6ops-transition-ipv4aas-15

[Ballot comment]
Thanks for addressing my DISCUSS. Here is my original COMMENT:

== Section 1 ==

OLD
This
  ensures that remote IPv4-only services continue to be accessible,
  from an IPv6-only Internet Service Provider access network (typically
  referred as WAN - Wide Area Network, even if in some cases it may be
  metropolitan, regional, etc.), from both, IPv4-only and IPv6-only
  applications or devices in the LAN side.

NEW
This ensures that remote IPv4-only services continue to be accessible
  from an IPv6-only Internet Service Provider (ISP) access network from both IPv4-only and IPv6-only applications and devices on the LAN side. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if in some cases they may be metropolitan or regional.

(Then you could deleted the parenthetical "(Internet Service Providers)" in the sentence below Figure 1.)

It seems odd that Figure 1 appears in Section 1 but isn't referenced in the text until Section 12. I think you need a sentence in this section to describe what is depicted in the figure or why it is there, or you need to remove the figure.

s/devices or applications/devices and applications/

== Section 3.2 ==

s/an automated IPv6 transition mechanism provisioning/automated IPv6 transition mechanism provisioning/

s/per interface/per interface/

Would suggest dropping "(which may depend on each transition mechanism)" since it makes the sentence confusing and doesn't add anything.

== Section 3.2.1 ==

OLD
If DNS64
  [RFC6147] is not used, or not trusted, as the DNS configuration at
  the CE (or hosts behind the CE) may be modified by the customer, then
  the service provider may opt to configure the NAT64 prefix either by
  means of [RFC7225] or [RFC8115], which also can be used if the
  service provider uses DNS64 [RFC6147].
 
NEW
It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]. These can also be used if the service provider uses DNS64.

== Section 7 ==

I would suggest starting this section with "At the time of this writing, ..."

== Section 12 ==

The text that refers to Figure 1 I think is meant to refer to Figure 2. Or if not, text is needed to describe Figure 2.

[Ballot comment]
[note: I reviewed the -12 version, as the -13 arrived during the middle of
my review and I wanted to remain internally consistent]

I don't think that making "DEFAULT" a capitalized keyword adds any value;
the one usage reads fine with "default" in lowercase.

Section 1

  These routers rely upon "Basic Requirements for IPv6 Customer Edge
  Routers" [RFC7084], so the scope of this document is to ensure the
  IPv4 "service continuity" support, in the LAN side, ensuring that
  remote IPv4-only services are accessible, from an IPv6-only Internet
  Service Provider access network (typically referred as WAN - Wide
  Area Network, even in some cases it may be metropolitan, regional,
  etc.) even from IPv6-only applications or devices in the LAN side.

nit: this is a single very-long sentence.  I suggest breaking it into two
or three smaller ones (e.g., break after "in the LAN side".

  device, causing IPv4 addresses to become prohibitive expense.  This,

nit: "a prohibitive expense" or "prohibitively expensive"

  Since it is impossible to know prior to sale which transition
  mechanism a device will need over its lifetime, IPv6 Transition CE
  Router intended for the retail market MUST support all the IPv4aaS
  transition mechanisms supported by this document.  Service providers

nit: it's probably more "listed in" this document than "supported by".

Section 1.1

I think it would be okay to just use the normal BCP 14 boilerplate, even
though this is an information document placing (opt-in) requirements on
devices to be used in a certain use case.

Section 3.2

  TRANS-2:  The IPv6 Transition CE Router MUST have a GUI, CLI and/or
            API option to manually enable/disable each of the supported
            transition mechanisms.

Do we really need to pick and name interfaces, or can we just say "MUST
have a configuration interface"?

  TRANS-3:  If an IPv6 Transition CE Router supports more than one LAN
            subnet, the IPv6 Transition CE Router MUST allow
            appropriate subnetting and configuring the address space

nit: perhaps "configuration of"?

            (which may depend on each transition mechanism) among the
            several interfaces.  In some transition mechanisms, this
            may require differentiating mappings/translations per
            interfaces.

nit: perhaps "different mappings/translations" or "differentiating
mappings/translations on a per-interface basis"

  CONFIG-1:  Request the relevant configuration options for each
              supported transition mechanisms, which MUST remain
              disabled at this step.

This seems like it could make for really bad UX in some cases, such as when
a user is only given one class of configuration information from their ISP
and is hopelessly confused by questions (about other mechanisms) that they
don't have answers for.  Is the MUST requirement (not quoted) to follow
this step really justified?

Section 3.2.1

                                                If 464XLAT is
  supported, it MUST be implemented according to [RFC6877].  [...]

Do we want to consider adding "or a successor document"?

  464XLAT-1:  The IPv6 Transition CE Router MUST perform IPv4 Network
              Address Translation (NAT) on IPv4 traffic translated
              using the CLAT, unless a dedicated /64 prefix has been

"MUST, unless" is sometimes an awkward formulation.  In general, even
reordering to "Unless X, Y MUST ..." is frequently an improvement.

              Plain IPv6 mode (i.e., no IPv4-in-IPv6 encapsulation is
              used) MUST be used to send PCP requests to the server.

What entity does this requirement apply to (and under what conditions, if
any)?

  464XLAT-7:  The priority for the NAT64 prefix, in case the network
              provides several choices, MUST be: 1) [RFC7225], 2)
              [RFC8115], and 3) [RFC7050].

I'm not entirely sure why this has to be a MUST -- a SHOULD would leave
room for implementations to have different preferences, say, if they like
DHCP discovery more than PCP.

                                                        If DNS64
  [RFC6147] is not used, or not trusted, as the DNS configuration at
  the CE (or hosts behind the CE) may be modified by the customer, then
  the service provider may opt to configure the NAT64 prefix either by
  means of [RFC7225] or [RFC8115], which also can be used if the
  service provider uses DNS64 [RFC6147].

This is another long and convoluted sentence.  If I am correct in inferring
that "as the DNS configuration at the CE (or hosts behind the CE) may be
modified by the customer" is intended to justify not trusting DNS64, then I
suggest putting it in parentheses (in which case the now-internal
parenthetical could be changed to just be offset by commas).

                                                            Plain IPv6
              mode (i.e., no IPv4-in-IPv6 encapsulation is used) MUST be
              used to send PCP requests to the server.

Same comment as for Section 3.2.1.

Section 7

                                                          However, it
  has been confirmed from existing open source implementations
  (OpenWRT/LEDE, Linux, others), that adding the support for the new
  transitions mechanisms, requires around 10-12 Kbytes (because most of
  the code base is shared among several transition mechanisms already
  supported by [RFC7084]), as a single data plane is common to all
  them, which typically means about 0,15% of the existing code size in
  popular CEs already in the market [OpenWRT].

nit: This sentence is very long.  Even if it is not split into smaller
sentences for clarity, I would suggest at least clarifying that the 0,15%
refers to 10-12 KB being 0.15% of the existing code size.

  In general, the new requirements don't have extra cost in terms of
  RAM memory, neither other hardware requirements such as more powerful
  CPUs, if compared to the cost of NAT44 code so, existing hardware
  supports them with minimal impact.

nit: s/neither/nor/; s/ so,/, so/; s/supports them/should be able to
support them/.

  Finally, in some cases, operators supporting several transition
  mechanisms may need to consider training costs for staff in all those
  techniques for their operation and management, even if this is not

nit: I don't think "those" is the right word here; maybe "the"?

Section 8

I agree with the secdir reviewer that it would be pretty easy to include
some more discussion of the DHCP (in)security situation in some common
network types that would be relevant for this document, e.g., giving some
guidance that for residential networks the risk/reward is likely in favor
of trusting the information in DHCP responses even without DHCP security.

Section 11

  The situation previously described, where there is ongoing IPv6
  deployment and lack of IPv4 addresses, is not happening at the same
  pace in every country, and even within every country, every ISP.  For

nit: "for every ISP"

  the global transition timings cannot be estimated.

nit: they can be estimated by anyone with a pulse; what cannot be done is
reliable estimation.

  Considering that situation and different possible usage cases, the
  IPv6 Transition CE Router described in this document is expected to
  be used typically, in residential/household, Small Office/Home Office
  (SOHO) and Small/Medium Enterprise (SME).  [...]

I share the concern expressed in the directorate review of the use of the
term "SME" here (but did not yet get a chance to fully follow the
subsequent discussion).

  The above is not intended to be comprehensive list of all the
  possible usage cases, just an overall view.  In fact, combinations of

nit: "a comprehensive"

  the above usages are also possible, as well as situations where the
  same CE is used at different times in different scenarios or even
  different services providers that may use a different transition
  mechanism.

nit: "or even with different"

  available in any IPv6 router, when using GUA (IPv6 Global Unicast

nit: no comma here

  Addresses), unless they are blocked by firewall rules, which may
  require some manual configuration by means of a GUI, CLI and/or API.

same comment as above -- can't we just say "manual configuration" and not
guess at modes of doing so?

  already provide a GUI and/or a CLI to manually configure them, or the
  possibility to setup the CE in bridge mode, so another CE behind it,
  takes care of that.  The requirements for that support are out of the

nit: no comma before "takes care of that"

  It is not relevant who provides the IPv6 Transition CE Router.  In
  most of the cases is the service provider, and in fact is
  responsible, typically, of provisioning/managing at least the WAN

nit: "it is the service provider"
nit: "in fact they are responsible, typically, for provisioning/managing"

  underscores the importance of the IPv6 Transition CE Routers
  supporting the same requirements defined in this document.

nit: generally I see "supporting" with "features" and "meeting" or
"fulfilling" with "requirements".

Section 12

  combined with a dynamic routing protocol.  Once again, this is true
  for both, IPv4 and IPv6.

nit: no comma here

[Ballot discuss]
(1) I think the standard RFC 8174 boilerplate is needed here. I think it was a mistake to use the 2119 keywords differently in RFC 7084, and that mistake need not be repeated. This document uses the normative keywords in the same ways as many other informational documents. RFC 2119 is not focused on interoperability, but rather on the requirements that the specification using the keywords is laying out.

(2) I don't think it is appropriate for this document to defined a new normative keyword, "DEFAULT," in Section 1.1. The right place to do that would be an update to RFC 2119 or RFC 8174. This is especially problematic given that the one place in this document where it is used, it is in a paragraph that also uses other normative keywords. Since it's only used once, I would suggest just explaining what it means in that location (3.2.2) rather than defining it as a keyword.

[Ballot comment]
== Section 1 ==

OLD
This
  ensures that remote IPv4-only services continue to be accessible,
  from an IPv6-only Internet Service Provider access network (typically
  referred as WAN - Wide Area Network, even if in some cases it may be
  metropolitan, regional, etc.), from both, IPv4-only and IPv6-only
  applications or devices in the LAN side.

NEW
This ensures that remote IPv4-only services continue to be accessible
  from an IPv6-only Internet Service Provider (ISP) access network from both IPv4-only and IPv6-only applications and devices on the LAN side. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if in some cases they may be metropolitan or regional.

(Then you could deleted the parenthetical "(Internet Service Providers)" in the sentence below Figure 1.)

It seems odd that Figure 1 appears in Section 1 but isn't referenced in the text until Section 12. I think you need a sentence in this section to describe what is depicted in the figure or why it is there, or you need to remove the figure.

s/devices or applications/devices and applications/

== Section 3.2 ==

s/an automated IPv6 transition mechanism provisioning/automated IPv6 transition mechanism provisioning/

s/per interface/per interface/

Would suggest dropping "(which may depend on each transition mechanism)" since it makes the sentence confusing and doesn't add anything.

== Section 3.2.1 ==

OLD
If DNS64
  [RFC6147] is not used, or not trusted, as the DNS configuration at
  the CE (or hosts behind the CE) may be modified by the customer, then
  the service provider may opt to configure the NAT64 prefix either by
  means of [RFC7225] or [RFC8115], which also can be used if the
  service provider uses DNS64 [RFC6147].
 
NEW
It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]. These can also be used if the service provider uses DNS64.

== Section 7 ==

I would suggest starting this section with "At the time of this writing, ..."

== Section 12 ==

The text that refers to Figure 1 I think is meant to refer to Figure 2. Or if not, text is needed to describe Figure 2.

[Ballot comment]
I share Ben and Mirja's question about the formal relationship between this
document and RFC 7084.

I also share Ben's confusion about the document's status as not being a BCP --
statements like the following are, by my understanding of the term, specifying
practices that are considered to be "best" at the present time:

* "The IPv6 Transition CE Router MUST implement a DNS proxy as
  described in [RFC5625] (DNS Proxy Implementation Guidelines)."

* "The IPv6 Transition CE Router MUST support the DHCPv6 S46
  priority options described in [RFC8026]."

* "The IPv6 Transition CE Router MUST have a GUI, CLI and/or
  API option to manually enable/disable each of the supported
  transition mechanisms."

If these (and similarly phrased) statements are not recommending best current
practices, then I don't understand the purpose of this document.

[Ballot discuss]
I guess this is related to Suresh's Discuss as well.

It's late in the day and I'm reading quickly, so my apologies if I've
missed something obvious and this is in fact a non-issue.  That said,
process-wise, it seems that 464XLAT-6 in Section 3.2.1 is attempting to
direct an implementation of RFC 8115 to violate a MUST-level requirement
from that document ("the conveyed multicast IPv6 prefix MUST belong to the
[ASM|SSM] range") by allowing for all-zero ASM_mPrefix64 and SSM_mPrefix64
fields.  (Furthermore, the end of Section 3 of RFC 8115 appears to suggest
that the Well-Known DNS Name heuristic discovery-based method should be
used instead, when only unicast services are needed.)

[Ballot comment]
General: I'm curious why this is not a BCP. The shepherd review states that it doesn't recommend practices, but that seems to be me to be exactly what it does.

abstract: Does this need to update RFC7084?

§1, 2nd paragraph: The paragraph does not parse.

§1.1: Is there a reason not to use the updated boilerplate from RFC 8174?

§3.2, third paragraph: The paragraph is hard to follow. Please consider breaking into simpler sentences.

§3.2.1: "The IPv6 Transition CE Router MUST support CLAT functionality
[RFC6877] if intended for the retail market. If 464XLAT is
supported, it MUST be implemented according to [RFC6877]."
The 2nd MUST seems redundant; we don't generally need to say that a function defined in an RFC MUST be implemented according to that RFC unless there's some reason to expect people might do otherwise.

§7:
- The entirety of this section is very hard to parse.

- "... only integration and testing cost may become a minor issue."
I don't think that's a judgement the IETF is in a position to make. It's not all that unusual for integration and testing to be greater costs than coding.

§8, 2nd paragraph: Is there any guidance that can be given for mitigating this issue in the context of transition mechanisms?

[Ballot comment]
I'm willing to believe that

  Since it is impossible to know prior to sale which transition
  mechanism a device will need over its lifetime, IPv6 Transition CE
  Router intended for the retail market MUST support all the IPv4aaS
  transition mechanisms supported by this document.  Service providers
  who specify feature sets for IPv6 Transition CE Router may specify a
  different set of features than those included in this document, for
  example supporting only some of the transition mechanisms enumerated
  in this document.

we can't do better than requiring all IPv6 Transition CE Routers to support all five transition mechanisms listed in this document, but I am wondering if five is hitting a natural law, or if someone is likely to come up with more transition mechanisms (that the existing CE routers won't support because they're already deployed).

But I trust the working group is doing its best ...

[Ballot comment]
Some more processing-related comments:

1) "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document, are not used as described in RFC 2119 [RFC2119]."
While it is not forbidden to define their own language requirements, I find this really confusing. I've seen that RFC7084 uses the same definition but actually I don't think the usage is really that different. I'd say the keywords are used in a similar fashion in other informational docs.

2) In the abstract:
"this document extends the "Basic Requirements for IPv6
  Customer Edge Routers" (RFC7084) in order to allow the provisioning
  of IPv6 transition services for the support of "IPv4 as-a-Service"
  (IPv4aaS) by means of new transition mechanisms."
Shouldn't this doc maybe actually update RFC7084 then? Otherwise,how is someone reading RFC7084 supposed to know about this RFC as well?

[Ballot discuss]
* Section 3.2.1.

I do not see why the use of RFC8115 (464XLAT-6) is being mandated for the use of 464XLAT. What is the intent of such a mandate? Especially, since the uPrefix64 is used for address synthesis for SSM for IPv4 *sources* in the IPv6 domain. Given that IPv4 multicast support itself is only conditional in Section 4, I do not see a need at all for this MUST requirement. Can you please clarify?

Asked authors to let mw know once they've had a chance to address, and post a new version - https://mailarchive.ietf.org/arch/msg/v6ops/bzGbITAd8IUxf6hSBh10acfYCIQ

(I'm trying to use the draft history page to help me track what the status for my documents is...)

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

The IANA Functions Operator has completed its review of draft-ietf-v6ops-transition-ipv4aas-11`. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Option Codes Permitted in the S46 Priority Option registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

a single, new registration will be made as follows:

Option Code: 113
S46 Mechanism: 464XLAT
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-12-14):

From: The IESG
To: IETF-Announce
CC: Ron Bonica , draft-ietf-v6ops-transition-ipv4aas@ietf.org, rbonica@juniper.net, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service) to Informational RFC


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document: - 'Requirements for IPv6 Customer Edge
Routers to Support IPv4
  Connectivity as-a-Service'
  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
ietf@ietf.org mailing lists by 2018-12-14. 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 specifies the IPv4 service continuity requirements for
  an IPv6 Customer Edge (CE) router, either provided by the service
  provider or through the retail market.

  Specifically, this document extends the "Basic Requirements for IPv6
  Customer Edge Routers" in order to allow the provisioning of IPv6
  transition services for the support of "IPv4 as-a-Service" (IPv4aaS)
  by means of new transition mechanisms.  The document only covers
  transition technologies for delivering IPv4 in IPv6-only access
  networks, commonly called "IPv4 as-a-Service" (IPv4aaS).  This is
  necessary because there aren't sufficient IPv4 addresses available
  for every possible customer/device.  However, devices or applications
  in the customer LANs may be IPv4-only or IPv6-only and still need to
  communicate with IPv4-only services at the Internet.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ballot/


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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

INFORMATIONAL. This is correct because the document does not describe new protocols or bits on the wire. It also does not recommend best practices.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document specifies the IPv4 service continuity requirements for
  an IPv6 Customer Edge (CE) router, either provided by the service
  provider or thru the retail market.

  Specifically, this document extends the "Basic Requirements for IPv6
  Customer Edge Routers" in order to allow the provisioning of IPv6
  transition services for the support of "IPv4 as-a-Service" (IPv4aaS)
  by means of new transition mechanisms.  The document only covers
  transition technologies for delivering IPv4 in IPv6-only access
  networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required
  in a world where IPv4 addresses are no longer available, so hosts in
  the customer LANs with IPv4-only or IPv6-only applications or
  devices, requiring to communicate with IPv4-only services at the
  Internet, are still able to do so.

Working Group Summary:

There was broad consensus behind this document and no controversy.

Document Quality:

This document contains a competent overview and comparison of IPv4aaS transition mechanisms. All of these mechanisms have been implemented by multiple vendors.

Personnel:

Ron Bonica is the Document Shepherd. Warren Kumari is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have read every word of this document. Coincidentally, I am doing a similar comparison as part of my day job. Therefore, I am testing all but one of the transition mechanisms mentioned in this document in the lab. (My employer doesn't implement one of the mechanisms.)

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

At least fifteen people have reviewed and commented on this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

None. (The Nit-checker complains that there is no RFC 2119 language, but such language is not required in this document.)

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document requests that IANA add an existing option (113 OPTION_V6_PREFIX64) to the list of options permissible in the Option Codes Permitted in the S46 Priority Option Registration. This is in compliance with RFC 8026.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None