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

[JORDI PALET MARTINEZ <[e-mail]>]

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.