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

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

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:
> 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" <[e-mail] en nombre de [e-mail]> escribió:
> 
>      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
>      >
> 
> 
>      _______________________________________________
>      v6ops mailing list
>      [e-mail]
>      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.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>