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

[Gyan Mishra <[e-mail]>]

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=
[e-mail]> wrote:

> 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 <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: Saturday, April 9, 2022 7:08 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*