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

Hi Brian,

Many thanks for your careful reading of the draft and your comments.
Most of them seem related to the way we use specific terms (such as IPv6-only) and how they may be perceived or interpreted outside the IETF/v6ops community.
This brings us to consider adding a new section to discuss the terminology used in the draft so to remove the ambiguity that a certain term may create.
Speaking of terms, I agree that "IPv6-only" needs to be worked out. Personally, I am not sure that "IPv6-backbone" solves the problem either (I am not aware of references where it is discussed in the context of this draft).

Some more detailed answers to your comments can be found inline as [PV].

Thanks again.
Paolo

-----Original Message-----
From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
Sent: Saturday, April 9, 2022 7:08 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-ipv6-deployment

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.

[PV] Right, we'll fix it.

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

[PV] Good point. It can be done.

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

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

[PV] Sure, this is an issue of not being an English native speaker :-)

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

[PV] We agree that this statement is a bit ambiguous and does not mention the coexistence with v4; we will rewrite the sentence as you suggested.
Regarding the concept of IPv6-only, the new "Terminology" section that we plan to introduce should remove the ambiguity.

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

[PV] As said above, the new Terminology section should provide the necessary explanation but we will rewrite as suggested

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

[PV] Yes and we'll clarify the use of the terms.

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

[PV] Ok, we'll clarify it better.

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

[PV] The shift to cloud also implies additional requests of IPv4 addresses (at least, so far). That was our original meaning. 
Looking at the overall sentence, we will modify it to make it clearer.

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

[PV] Ok, but this section focuses on addressing, the idea is not to discuss here all the operational issues of the enterprises, which, instead, are described in other sections (e.g. 7.1.2).
If there is needed to add more, we are open to suggestions.

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

[PV] Right, we will add it.

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

[PV] Our approach was to consider the measurement of IPv6 from an independent organization such as APNIC instead of considering those of Google, Facebook, Akamai, etc.
We could add any of those of course, but we need to decide the criteria to choose from them.

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

[PV] Acknowledged.

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

[PV] Same as above, we'll align the terms.

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

[PV] This is a very good comment.
We believe that in an operational-oriented draft such this one the issues related to the transition of the applications need to be touched.
We'll review this section to address your comment.

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

[PV] We'll include terminology.

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

[PV] The terminology section should clarify. If useful to remove the ambiguity we'll look also at the names of the two stages.

> 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?
[PV] Yes, we will provide references (e.g. Reliance, T-Mobile US)

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

[PV] Will be addressed in the mentioned terminology section

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

[PV] Yes, that's the case. We will add the cross-reference to the relevant section.

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

[PV] Ack. We will rewrite this sentence.

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

[PV] We will clarify, in case we can add a diagram

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

[PV] As said, we'll specify what we mean by IPv6-only Service Delivery

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

[PV] Based on the new terminology this point should become clearer.

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

[PV] We will mention.

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

[PV] We will look at that and we are interested to know if new data are available

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

[PV] True, we focused more on security than on privacy. We'll add considerations on privacy.

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

[PV] Right, but from an operational standpoint the minimal requirement is that IPv6 offers the same level of security as IPv4.
Anyway we will revise the sentence.

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

[PV] We don't want to include too many details, but we'll provide the relevant references about the vulnerabilities of SLAAC and RD.

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

[PV] Ack, we will revise and try to improve that part.

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

[PV] Ok.

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

[PV] We'll revise this paragraph as a whole to address your concerns/comments

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

[PV] Ok. Good suggestion.

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

[PV] We meant that as a potential attack vector, but if it is not clear we will review the sentence.

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

[PV] Ok, that's better.

That's it for now.

[PV] More than enough ;-). Thanks!

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
> 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops