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

From: Ron Bonica <[email-masked]>
Date: Mon, 4 Apr 2022 21:31:41 +0000

Folks,

This message begins a WG last call for 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.

                                            Fred and Ron

Juniper Business Use Only

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Apr 2022 17:08:16 +1200

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
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 09 Apr 2022 09:45:14 +0200

Hi Brian,

Quick question regarding the "IPv6-only" points.

Do you think that using "IPv6-only with IPv4aaS" (correctly defined early in the document), and used across the document (instead of just "IPv6-only"), resolve your points?

Also, should we definitively tackle the "IPv6-only" repeated confusion with https://datatracker.ietf.org/doc/html/draft-palet-v6ops-ipv6-only-05?

Regards,
Jordi
@jordipalet

El 9/4/22, 7:09, "v6ops en nombre de Brian E Carpenter" <[email-masked] en nombre de [email-masked]> escribió:

    Hi,

    ...

    ...

    ...

    Try:

    Try:

    That's it for now.

    Regards
          Brian

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

    _______________________________________________
    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: Brian E Carpenter <[email-masked]>
Date: Sun, 10 Apr 2022 08:53:20 +1200

Hi Jordi,

I'd really like to hear other people's opinion on this. My feeling
is that "IPv6-only with IPv4aaS" will still produce a negative
emotional reaction - not here, because we are all supposed to be
IPv6 lovers here, but in the wider operational community. It's also
quite a mouthful, too. I'm not completely convinced that "IPv6-backbone"
is right; maybe more use of "IPv6-underlay" would work?

Note, none of this questions the basic technical message, but I have
see so many emotional rejections of IPv6 in the public fora that
I think we must choose our language very carefully.

The same concern is behind my comments on the security and
application software sections.

Regards
    Brian Carpenter

On 09-Apr-22 19:45, JORDI PALET MARTINEZ wrote:
>      > 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>.
> 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: "[email-masked]" <[email-masked]>
Date: Sun, 10 Apr 2022 20:24:08 +0800

IPv6-only network should keep the ability for users to access the global IPv4 Internet, so IPv4aaS is a indispensible feature of IPv6-only network, which should become common sense and be solidfied in IETF.  
Best regards,
Chongfeng 

From: JORDI PALET MARTINEZ
Date: 2022-04-09 15:45
To: [email-masked]
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-ipv6-deployment
Hi Brian,

 
 
Regards,
Jordi
@jordipalet

    Hi,

 

 

 

 

 

    ...

 

 

 

 

    ...

    ...

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
    Try:

 
    Try:

 

 

    That's it for now.
 
    Regards
          Brian

---

From: [email-masked]
Date: Sun, 10 Apr 2022 19:52:25 +0200

> IPv6-only network should keep the ability for users to access the global IPv4 Internet, so IPv4aaS is a indispensible feature of IPv6-only network, which should become common sense and be solidfied…

That's generally resulting in what we call a dual-stack network. :-)

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Apr 2022 08:54:46 +1200

> That's generally resulting in what we call a dual-stack network. :-)

Nobody is arguing about the technical facts here. The issue is how we present them to the outside world.

What I am saying is that the phrase "IPv6-only" has an immediate *emotional* impact on the reader, and every time you use it, you repel exactly the people we are trying to reach: enterprise and ISP operators whose entire job today depends on IPv4.

We made a basic mistake 25 years ago by using the word "transition" when we should have used "coexistence", and we make our job harder every time we use the phrase "IPv6-only".

When people read "IPv6-only with IPv4AaS" they only see "IPv6-only". (That means all people except a few people who are on this list.) I believe that if we write "IPv6 backbone" or "IPv6 underlay" we will influence far more people.

    Brian

---

From: [email-masked]
Date: Sun, 10 Apr 2022 23:43:08 +0200

> We made a basic mistake 25 years ago by using the word "transition" when we should have used "coexistence", and we make our job harder every time we use the phrase "IPv6-only".

25 years ago we believed that a transition was possible, so I think it's awfully hard on our past selves to claim it a mistake.

There seems to be little agreement on what "IPv6 only" means (it's all about perspective) and there is even less for how to get there.

> When people read "IPv6-only with IPv4AaS" they only see "IPv6-only". (That means all people except a few people who are on this list.) I believe that if we write "IPv6 backbone" or "IPv6 underlay"…

Agree. IPv6-only with IPv4aaS is a meaningless term.

O.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 11 Apr 2022 09:30:38 +0000

Hi all,
IMHO: Just "IPv6-only" should never be used without any qualifier, because it may be not possible in this century (or never at all).
IMHO: IPv6-only is possible to use if it has qualifiers for the scope. The scope could be restricted by the layer or geography or both (most probable for the near future).
For example:
- "IPv6-only for services (overlay?) of the particular Carrier" (2 qualifiers: Carrier and Overlay). IPv4 is probably IPv4aaS in this case.
- "IPv6-only for the infrastructure (underlay?) of the particular Carrier" (2 qualifiers: Carrier and Underlay). It is SRv6 implemented fully in the domain.
- "IPv6-only for the particular Carrier" (1 qualifier: Carrier). It is the 2 above achievements at the same time.
- "IPv6-only for POD infrastructure"(2 qualifiers: POD and Underlay). A few big OTTs are already reported.
And so on.
Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Saturday, April 9, 2022 11:53 PM
To: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; [email-masked]
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-ipv6-deployment

Hi Jordi,

I'd really like to hear other people's opinion on this. My feeling is that "IPv6-only with IPv4aaS" will still produce a negative emotional reaction - not here, because we are all supposed to be
IPv6 lovers here, but in the wider operational community. It's also quite a mouthful, too. I'm not completely convinced that "IPv6-backbone"
is right; maybe more use of "IPv6-underlay" would work?

Note, none of this questions the basic technical message, but I have see so many emotional rejections of IPv6 in the public fora that I think we must choose our language very carefully.

The same concern is behind my comments on the security and application software sections.

Regards
    Brian Carpenter

On 09-Apr-22 19:45, JORDI PALET MARTINEZ wrote:
>         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
>      measurement methods, those numbers are pretty close. For 2018 
> they
have
>      This whole subsection seems weak to me and will not survive an 
> ART
Area
>      "IPsec protects IPv6 traffic at least as well as it does IPv4, 
> and
the
>         In addition to the discussion above [Section 7.5], the 
> security
considerations
>         relating to the protocols and transition tools are described 
> in
the
>      >                                              Fred and Ron
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: Paolo Volpato <[email-masked]>
Date: Mon, 11 Apr 2022 13:59:11 +0000

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 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Saturday, April 9, 2022 7:08 AM
To: [email-masked]
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.

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

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

>    achievements and remaining obstacles in the transition to IPv6-only

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:

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

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

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

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

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

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

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

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

...

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

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

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

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

Do you have any examples where this has happened?
[PV] Yes, we will provide references (e.g. Reliance, T-Mobile US)

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

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.

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

>       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

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

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

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.

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

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

>    constrained hardware deployed in some devices e.g., sensors, Internet

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.

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

>    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.2.  IPv6 Extension Headers and Fragmentation

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

Try:

Try:

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

[PV] Ok. Good suggestion.

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

[PV] Ok, that's better.

That's it for now.

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

Regards
      Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 11 Apr 2022 09:09:24 -0700

> On Apr 10, 2022, at 2:43 PM, [email-masked] wrote:
> 

I dunno. I would follow the dictionary on what the word "only" means. "IPv6-only", in my mind, means that IPv4 is turned off, at least in any equipment that natively switches IPv6. When folks talk about IPv4 as a service ("IPv4AAS"), in my mind that means that if IPv4 is switched at all, it is handled in a different way than IPv6.

I get a little lost when people argue about what "IPv6-only" means. There aren't many choices.

https://www.google.com/search?q=definition+only

---

From: Nick Buraglio <[email-masked]>
Date: Mon, 11 Apr 2022 13:14:04 -0500

On Mon, Apr 11, 2022 at 11:09 AM Fred Baker <[email-masked]>
wrote:

> > There seems to be little agreement on what "IPv6 only" means (it's all
> about perspective) and there is even less for how to get there.
>
> I dunno. I would follow the dictionary on what the word "only" means.
> "IPv6-only", in my mind, means that IPv4 is turned off, at least in any
> equipment that natively switches IPv6. When folks talk about IPv4 as a
> service ("IPv4AAS"), in my mind that means that if IPv4 is switched at all,
> it is handled in a different way than IPv6.
>

> I get a little lost when people argue about what "IPv6-only" means. There

I agree that "IPv6-only" should be defined in detail toward the beginning
of the document. My experience with migration to IPv6-only is exactly as
described in your prior email: It is interpreted as something being "taken
away" (IPv4), even though that is not the case, per se, and evokes an
emotional fight or flight response.  I don't know if it's useful or not,
but in much of the work I have been involved in we defined "IPv6-only" as
(paraphrasing): the disabling, lack of availability, or other absence of
IPv4 on a system, with access to IPv4 resources provided by an alternative,
intermediate mechanism.

>What I am saying is that the phrase "IPv6-only" has an immediate
*emotional* impact on the reader, and every time you use it, you repel
exactly the people we are trying to reach: enterprise and ISP operators >
whose entire job today depends on IPv4.

Agreed. Regardless of the definition, I have found that there is very much
ambiguity in what "IPv6-only" means in the context of operational network
functionality. The most common implication is that there will be no access
to IPv4, and that's not generally the case, which feels like it's addressed
in section 4.1, and specifically in section 5.

One other suggestion:

 > "As noted, the pandemic may have influenced the ICT industry including the
dynamic of the address allocations."

Not that we want another, different pandemic, it would probably be a good
idea to clarify that this was driven by the COVID-19 pandemic since this
document will be long-lived.

> https://www.google.com/search?q=definition+only
ᐧ

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 11 Apr 2022 23:19:49 +0200

In Spanish, migration and transition is not the same.

Migration is moving from Windows XP to Windows Vista, you don’t keep both together. In English may have a different connotation, but I still prefer to use “transition and coexistence” (the term that I prefer to use and teach my customers – I also tell them there are no migration mechanisms but “transition and coexistence”).

In scenarios for IPv4 to IPv6 “transition and coexistence”, you have different parts of the network that may be IPv4-only, IPv6-only, dual-stack, IPv4aaS or even IPv6aaS.

Clearly I need to retake the work on https://www.ietf.org/archive/id/draft-palet-v6ops-ipv6-only-05.txt. Will try this week, so we can reference to it in this document for a more complete definition.

Regards,

Jordi

@jordipalet

El 11/4/22, 20:15, "v6ops en nombre de Nick Buraglio" <[email-masked] en nombre de [email-masked]> escribió:

I agree that "IPv6-only" should be defined in detail toward the beginning of the document. My experience with migration to IPv6-only is exactly as described in your prior email: It is interpreted as something being "taken away" (IPv4), even though that is not the case, per se, and evokes an emotional fight or flight response.  I don't know if it's useful or not, but in much of the work I have been involved in we defined "IPv6-only" as (paraphrasing): the disabling, lack of availability, or other absence of IPv4 on a system, with access to IPv4 resources provided by an alternative, intermediate mechanism. 

>What I am saying is that the phrase "IPv6-only" has an immediate *emotional* impact on the reader, and every time you use it, you repel exactly the people we are trying to reach: enterprise and ISP operators > whose entire job today depends on IPv4.

Agreed. Regardless of the definition, I have found that there is very much ambiguity in what "IPv6-only" means in the context of operational network functionality. The most common implication is that there will be no access to IPv4, and that's not generally the case, which feels like it's addressed in section 4.1, and specifically in section 5.  

One other suggestion:

 > "As noted, the pandemic may have influenced the ICT industry including the dynamic of the address allocations." 

Not that we want another, different pandemic, it would probably be a good idea to clarify that this was driven by the COVID-19 pandemic since this document will be long-lived.  

ᐧ

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

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 11 Apr 2022 18:56:27 -0400

Hi Pablo

I agree with all of your comments in reply to Brian.

Brian

Thank you for all the detailed  comments.

Thanks

Gyan

On Mon, Apr 11, 2022 at 9:59 AM Paolo Volpato <paolo.volpato=
[email-masked]> wrote:

> 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).
>
> misunderstood and many readers will just give up as a result. (See details
> and proposed fix below.) I have some other concerns too.
>
> 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:
>
> [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.
>
> "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:
>
> [PV] As said above, the new Terminology section should provide the
> necessary explanation but we will rewrite as suggested
>
> 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] The shift to cloud also implies additional requests of IPv4 addresses
> (at least, so far). That was our original meaning.
> 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).
> 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
> [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.
> This title is confusing. You mean carriers and ISPs, but most people in
> enterprise netops think of themselves as network operators too.
>
> [PV] Acknowledged.
>
> 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.
>
> We believe that in an operational-oriented draft such this one the issues
> related to the transition of the applications need to be touched.
> 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.
>
> "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.
>
> Are you perhaps meaning that the previous few paragraphs are called "the
> consolidated approach"? Please help the reader here.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
> [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
> 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.
> I don't think this paragraph is needed. It isn't about security and it
> doesn't help the main argument of the document.
>
> > 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
> >
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*