Re: [v6ops] WGLC: draft-ietf-v6ops-ipv6-deployment

[Brian E Carpenter <[e-mail]>]

Hi,

Summary: This is very useful work, but it's not quite ready. My big
concern is that frequent use of the phrase "IPv6-only" will be badly
misunderstood and many readers will just give up as a result. (See
details and proposed fix below.) I have some other concerns too.

There is quite a lot of work for the RFC editor, where the syntax
is a bit hard to understand.

> Abstract
> 
>    This document provides an overview of IPv6 deployment status and a
>    view on how the transition to IPv6 is progressing...

I find the word "view" is ambiguous. Does it mean "opinion" or
"description"? It's important to tell the reader what to expect.

Also I'd add something like "in early 2022" to this sentence, so that
future readers will not be confused.

> 1.  Introduction
> 
>    [RFC6036] described IPv6 deployment scenarios adopted or foreseen by
>    a number of Internet Service Providers (ISPs) who responded to a
>    technical questionnaire in early 2010.

Would it be useful to formally obsolete RFC6036? It really is historic
by now.

> This document intends to explode such statements, ...

I strongly recommend s/explode/amplify/. "Explode" has a rather negative
implication.

>    ... providing a survey
>    of the status of IPv6 deployment and highlighting both the
>    achievements and remaining obstacles in the transition to IPv6-only
>    networks.

This could be taken as setting a goal of IPv6-only, but most of the
audience will not share that goal; their goal is continued v4/v6
coexistence. As has been discussed before, the phrase "IPv6-only"
is ambiguous. (See my later comments.) Our old friend "the universal
deployment of IPv6" would be less provocative for many readers.
I don't find any mention of coexistence in the draft, but many will
look for it. So here's a possible rewrite of the whole sentence:

   This document intends to amplify such statements, providing a survey
   of the status of IPv6 deployment and highlighting both the
   achievements and remaining obstacles in the universal deployment of
   IPv6, in coexistence with continued IPv4 services.

>    ... At present, Dual-Stack (DS) is the
>    most deployed solution for IPv6 introduction, while 464XLAT and Dual-
>    Stack Lite (DS-Lite) seem the preferred ones for those players that
>    have already enabled IPv6-only service delivery.

The problem here is that you have not yet explained what you mean by
"IPv6-only service delivery" and to most readers it will mean "we
switched off IPv4". At that point they will stop reading and post
aggressive comments on the nearest tech forum. Suggested rewrite:

   At present, Dual-Stack (DS) is the
   most widely deployed method of adding IPv6 service. However, carriers
   that decide to base their own infrastructure purely on IPv6,
   with IPv4 delivered as a service, seem to prefer either 464XLAT or Dual-
   Stack Lite (DS-Lite). In all cases, the user site or device can receive
   dual stack service.

You explain the term ""IPv6-only service delivery" later, but in the
Introduction it would just confuse the reader.

> 2.1.  IPv4 Address Exhaustion
...
>    On the other, [POTAROO1] again highlights the role of both NAT and
>    the address transfer to counter the IPv4 exhaustion.

What's "the address transfer"? Do you mean IPv4 address resale (and its
grey market)?

>    ... NAT systems
>    well fit in the current client/server model used by most of the
>    available Internet applications...

That's true for a single level of NAT but it cannot be true for
a picture with lots of CGNAT or a NAT444 scenario. I think the
text needs to be more nuanced.

>    ... with this phenomenon amplified by
>    the general shift to cloud. 

Really? I don't see the amplification; the IETF has been client/server
since the Mosaic browser was released.

>    ... Anyway, it should be noted that, in some
>    cases, private address space cannot provide adequate address and the
>    reuse of addresses may make the network even more complex.

If this is referring to large enterprises that have to use internal
NATs, you are understating the operational horror.

>    ... But, since each address blocks of
>    Internet is licensed by a specific resource-holder and stored for the
>    verification of the authenticity, frequent address transfer may
>    affect the global assignment process.

How about the impact on BGP4 aggregation?

> 2.2.  IPv6 Users

Why not quote the Google observations too? Their measurement at the end
of January 2022 is around 35%, where you have 29.5%. With such different
measurement methods, those numbers are pretty close. For 2018 they have
~20% and you have 15%.

> 3.2.  IPv6 among Network Operators

This title is confusing. You mean carriers and ISPs, but most people
in enterprise netops think of themselves as network operators too.

> 3.3.  IPv6 among Enterprises
...
>    A poll submitted to a group of large enterprises in North America
>    (see Appendix B) show that the operational issues are likely to be
>    more critical than for operators.

Same problem. Read that carefully and it makes no sense...

> 3.6.  Application Transition
...
>    At the current stage, the full support of IPv6 is not yet complete
>    [Wikipedia], as issues remains in particular for applications known
>    not to work properly behind NAT64.

This whole subsection seems weak to me and will not survive an ART Area
review. What fraction of (non-IETF, non-W3C) applications have been
deployed with IPv6 support? What issues have been found? Which apps
fail behind NAT64 and why? What fixes does IPv6 need to overcome the
app transition issues?

Appealing to a list on Wikipedia doesn't help much. My feeling is
that this issue is very important and needs a draft of its own, and
the skills needed largely don't exist in v6ops.

> 4.  Towards an IPv6 Overlay Service Design
> 
>    This section reports the most deployed approaches for the IPv6
>    transition in MBB, FBB and enterprise.

Please either repeat the definitions of MBB and FBB, or include
a Terminology section.

> 
>    Two approaches are usually considered [ETSI-IP6-WhitePaper], namely:
>    (1) IPv6 introduction, and (2) IPv6-only.

I assume that "IPv6 introduction" means "dual stack"? If so, please
say so.

"IPv6-only" is ambiguous here. Is it meant literally (scrap IPv4) or in
the sense of "IPv6-only service delivery". The latter is only meaningful
for carriers, surely? Anyway, it needs to be clearer here or the reader
will have to guess. In any case, almost no enterprise operator will
consider literal IPv6-only for many years. I can imagine that a large,
multinational enterprise might consider a IPv6-only backbone with
IPv4aaS, but individual sites will stay dual stack until the last IPv4
packet disappears.

> In some cases, operators may instead jump directly to IPv6-only to
> avoid the operational burden of a transient phase.

Do you have any examples where this has happened?

> For this reason, the IPv6-only
> stage is also called IPv4aaS (IPv4 as a Service).

Oh, *now* you tell us. Two comments
(1) Please rearrange the whole section so that this explanation
comes first.
(2) Please change your terminology. Every time you use the phrase
"IPv6-only", you lose another reader. Actually, what you mean
is not "IPv6-only" at all, it's simply another form of dual stack
as far as the user is concerned.

Get this straight: for most people, "dual stack" means that the
socket API supports AF_INET and AF_INET6. "IPv6-only" means that it
only supports AF_INET6.

I'm not sure what the best terminology is, perhaps "IPv6-backbone",
but "IPv6-only" will kill this document.

>    The consolidated approach foresees to enable IPv6 in the network
>    (sometimes referred to as the underlay) ...

Which consolidated approach? This hasn't been mentioned before.
Are you perhaps meaning that the previous few paragraphs are
called "the consolidated approach"? Please help the reader here.

>    Recently, the attention has shifted to enabling IPv6
>    at the service layer (the overlay) leaving the transition of the
>    network to IPv6 at a later stage. 

Whose attention? It seems to me that this is quite backwards;
we started with IPv6 as an overlay - all the early transition
mechanisms were IPv6-over-IPv4, but recently interest has grown
in IPv4-over-IPv6 - so I just don't understand what this sentence
is trying to say.

> 4.1.  IPv6 introduction
> 
>    In order to enable the deployment of an IPv6 service over an underlay
>    IPv4 architecture, there are two possible approaches:
> 
>    o  Enabling Dual-Stack [RFC4213] at the Customer Edge router (CE)
> 
>    o  IPv6-in-IPv4 tunneling, e.g. with IPv6 Rapid Deployment (6rd) or
>       Generic Routing Encapsulation (GRE).

It isn't clear here to a newcomer that you are talking about the
ISP (WAN) side of the CE. A diagram might help.

> 4.2.  IPv6-only Service Delivery
> 
>    The second stage, named IPv6-only ...

I think this would be clearer and less provocative:

4.2.  IPv6-backbone Service Delivery

    The second stage, named IPv6-backbone ...

> 5.  IPv6-only Underlay Network Deployment
> 
>    IPv6-only alone can be misinterpreted as not supporting IPv4. 

Add: 'For that reason, we prefer the term "IPv6-backbone" used above'.
And with a little editing, this section 5 will then fit into the
story nicely.

> 7.3.  Network Management and Operations

In this section, I think you need to mention the tricky issue
of DHCPv6 vs SLAAC and RA. And the need for more complex APAM
solutions.

> 7.4.  Performance

If Tim Chown is watching: are there recent data on IPv6
performance from HEP? The last numbers I saw were very encouraging.

> 7.5.  IPv6 security

As we know, many readers think NAT=Security and NAT=Privacy.
I think the document needs to tackle this point. In fact, no
discussion of privacy is given, and that is just as important
as security these days.

>    The security aspects have to be considered to keep the same level of
>    security as it exists nowadays in an IPv4-only network environment.

That is a weak ambition. Surely the target should be to show that IPv6
can be made more secure (and more private) than IPv4?

>    The autoconfiguration features of IPv6 will require some more
>    attention.  Router discovery and address autoconfiguration may
>    produce unexpected results and security holes. 

We can't publish that! We should discuss how and why any vulnerabilities
in RD and SLAAC are avoided.

>    The IPsec protocol
>    implementation has initially been set as mandatory in every node of
>    the network, but then relaxed to recommendation due to extremely
>    constrained hardware deployed in some devices e.g., sensors, Internet
>    of Things (IoT).

That's backwards (and the imaginary "mandatory" IPsec was dropped long
before we were talking about IoT). Say it forwards:

"IPsec protects IPv6 traffic at least as well as it does IPv4, and the
security protocols for constrained devices (IoT) are designed for
IPv6 operation."

Probably good to get an IoT expert to review that and provide some
details and references.

>    There are some concerns in terms of the security but, on the other
>    hand, IPv6 offers increased efficiency.  There are measurable
>    benefits to IPv6 to notice, like more transparency, improved
>    mobility, and also end to end security (if implemented).

Huh? This seems partly irrelevant to security (efficiency? transparency?),
negative for no reason (concerns?) and wrong (e2e security is perfectly
possible for IPv4). I would delete this paragraph completely.

>    Finally, implementation of IPv6 security controls obviously depends
>    on the availability of features in security devices and tools.
>    Whilst there have been improvements in this area, there is a lack of
>    parity in terms of features and/or performance when considering IPv4
>    and IPv6 support in security devices and tools.

Is that really still true in 2022? If so, the document should include
a specific list of features that are lacking in some or all products.
At the moment, it sends a very negative message. It would be better
to give a plan for improvement.

> 7.5.1.  Protocols security issues

> 7.5.2.  IPv6 Extension Headers and Fragmentation

It is correct to present potential issues in these
sections, but the overall impression is quite negative.
Just an example:

>    IPv6 Extension Headers imply some issues, in particular their
>    flexibility also means an increased complexity, indeed security
>    devices and software must process the full chain of headers while
>    firewalls must be able to filter based on Extension Headers.

Try:

  IPv6 Extension Headers provide a hook for interesting new
  features to be added, and are more flexible than IPv4 Options.
  This does add some complexity, and in particular some security
  mechanisms may require to process the full chain of headers,
  and some firewalls may require to filter packets based on
  their Extension Headers.

>    There are some possible attacks through EHs, for example RH0 can be
>    used for traffic amplification over a remote path and it is
>    deprecated.

Try:

   Defense against possible attacks through Extension Headers
   is necessary. For example, the original IPv6 Routing Header
   type 0 (RH0) was deprecated because of possible remote
   traffic amplification.

In other words rewrite all these two sections to provide
hope rather than FUD.

>    A lot of additional functionality has been added to IPv6 primarily by
>    adding Extension Headers and/or using overlay encapsulation.  All of
>    the these expand the packet size and this could lead to oversized
>    packets that would be dropped on some links...

I don't think this paragraph is needed. It isn't about security and
it doesn't help the main argument of the document.

> 8.  Security Considerations
> 
>    This document has no impact on the security properties of specific
>    IPv6 protocols or transition tools.  The security considerations
>    relating to the protocols and transition tools are described in the
>    relevant documents.

This really does look strange coming right after a sub-section called
"IPv6 security". At least insert a cross-reference, e.g.

   In addition to the discussion above [Section 7.5], the security considerations
   relating to the protocols and transition tools are described in the
   relevant documents.

That's it for now.

Regards
      Brian

On 05-Apr-22 09:31, Ron Bonica wrote:
> Folks,
> 
> This message begins a WG last call for https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/ <https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/>.
> 
> Please respond the this message with comments by April 19, 2022. Your comments will be tracked at https://github.com/ietf-wg-v6ops <https://github.com/ietf-wg-v6ops>.
> 
>                                              Fred and Ron
>