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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Jan 2019 06:49:50 -0800

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 10 Jan 2019 16:02:21 +0100

Hi Benjamin,

Thanks for your review. I saw your earlier comments earlier this morning, but only got this email right now.

I will check all the detailed suggestions, but I'm sure some of them have already been resolved in -13 (submitted earlier today), such as breaking long sentences and a few others.

Even if the subject of the emails says -13, I think you've been reviewing -12, but I will make sure to follow all them anyway, I guess is some kind of failure with the tools.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Benjamin Kaduk <[email-masked]>
Fecha: jueves, 10 de enero de 2019, 15:50
Para: The IESG <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
Asunto: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

    

    

    Section 1

    

    
    
    Section 1.1

    Section 3.2

    

    

    
    Section 3.2.1
    
                                                     If 464XLAT is

    

    

                                                            If DNS64

                                                                Plain IPv6

    Section 7
    
                                                               However, it

    

    
    Section 8

    Section 11

    nit: "for every ISP"

    

    
    nit: "a comprehensive"

    
    
    nit: no comma here

    

    

    
    Section 12

    nit: no comma here

    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 10 Jan 2019 17:43:32 +0100

Hi Benjamin,

Thanks again for your detailed review.

I'm already working in a draft for a new version including all the nits that you mention (some already were corrected in -13).

Some clarifications to some of your comments.
 
    Section 3.2

Yes, the point here is to make sure that at least there is a GUI and CLI (or API). The idea is that the customer is able to buy a CE and later on use it in a different ISP. So, having both facilitate that, even in the case of a manual configuration required by the user. Normally DHCP-based mechanisms should do it, and also is currently very common that both are already supported, so not a big issue.

This is needed to allow the rest of the config/priority process. I believe you are misinterpreting as something done by the user in the GUI or something. While it may be possible, it not the case. It is all done by DHCP.

    Section 3.2.1
    
                                                     If 464XLAT is

I think if we do that, we could need doing that for every RFC ... that's why we have documents updating previous ones, so I don't think so.
  
Regards,
Jordi

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Jan 2019 16:36:33 -0600

> Yes, the point here is to make sure that at least there is a GUI and CLI (or API). The idea is that the customer is able to buy a CE and later on use it in a different ISP. So, having both facilita…

Er, do you require both GUI and CLI, or not?  The current text only
requires at least one.  (But yes, I agree it's common to support both
already, so this is not likely to be a burdensome requirement.)

> This is needed to allow the rest of the config/priority process. I believe you are misinterpreting as something done by the user in the GUI or something. While it may be possible, it not the case.…

I think you are right about my confusion; thanks for picking up on it.

> I think if we do that, we could need doing that for every RFC ... that's why we have documents updating previous ones, so I don't think so.

Well, another alternative is (as Ben suggests) to just not include this
sentence at all.  Which would of course also address my point here :)

-Benjamin

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 11 Jan 2019 11:51:57 +0100

Hi Benjamin,

Responses below, in-line.

Regards,
Jordi

-----Mensaje original-----
De: Benjamin Kaduk <[email-masked]>
Fecha: jueves, 10 de enero de 2019, 23:36
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: The IESG <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

 
Yes, the idea is "GUI and CLI" or "GUI and API" or all them. I was reading that correctly, but may be (once more) is a problem between Spanish-English ...

What about:
"The IPv6 Transition CE Router MUST have a GUI and either a CLI or API (or both) to manually enable/disable each of the supported transition mechanisms."

We have this text for every transition mechanism. The transition mechanisms have "2/3" pieces. One is the transition mechanism itself, another one is what is needed in the operator network, and then what is needed in the CE. I think for clarity, even if looks like a repetition, we decided to keep using the same wording on this that was used in RFC7084.

For example, DS-Lite is the mechanism, AFTR is the operator part, B4 is the CE part. If you look at the text (section 3.2.2), we are referring first to the overall DS-Lite, then we say that the CE must implement the B4 following what is said about that in the RFC.

I still believe is good to keep that way.

Thanks!

Regards,
Jordi

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Jan 2019 15:25:00 -0600

> "The IPv6 Transition CE Router MUST have a GUI and either a CLI or API (or both) to manually enable/disable each of the supported transition mechanisms."

That says what you want, yes.

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

Well, this is a non-blocking comment, so I can't get in your way.

-Benjamin

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 14 Jan 2019 10:56:54 +0100

Thanks Bejamin,

I just uploaded a new version resolving all the discuss and comments.

Regards,
Jordi

-----Mensaje original-----
De: Benjamin Kaduk <[email-masked]>
Fecha: viernes, 11 de enero de 2019, 22:25
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, The IESG <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-transition-ipv4aas-13: (with DISCUSS and COMMENT)

    

    -Benjamin