[v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-v6ops-transition-ipv4aas-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/



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


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