[v6ops] Éric Vyncke's Discuss on draft-ietf-v6ops-ipv6-deployment-08: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-ipv6-deployment-08: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


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

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

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

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

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

Regards,

-éric

## DISCUSS

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

### Section 1.1

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

### Section 4.2 overlay

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

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

### Section 4.2 464XLT and MAP-T

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

### Section 5.2

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

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

### Section 5.4.2

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENTS

### Section 1.1

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

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

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

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

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

### Section 2.1

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

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

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

### Section 2.1.1

Please provide a date for the data in figure 1.

### Section 2.3

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

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

### Section 2.4

Suggestion to have one paragraph per country.

### Section 3.1

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

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

### Section 3.2

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

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

### Section 3.3

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

### Section 3.3.1

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

### Section 3.5

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

### Section 4

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

### Section 4.1

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

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

### Sections 4.2 and 4.3

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

### Section 5.1.2

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

### Section 5.1.3

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

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

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

### Section 5.1.4

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

Please describe what "NAT444" is.

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

### Section 5.2

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

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

### Section 5.3.1

"currently" has little semantic in a published RFC.

### Section 5.4

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

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

### Section 5.4.1

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

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

### Section 5.4.2

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

## NITS

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

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