Re: [v6ops] Éric Vyncke's Discuss on draft-ietf-v6ops-ipv6-deployment-08: (with DISCUSS and COMMENT)

[Giuseppe Fioccola <[e-mail]>]

Thank you Eric for reviewing this draft.
Regards,

Giuseppe and Paolo

-----Original Message-----
From: Eric Vyncke (evyncke) <[e-mail]> 
Sent: Thursday, December 1, 2022 7:55 PM
To: Giuseppe Fioccola <[e-mail]>; Giuseppe Fioccola <giuseppe.fioccola=[e-mail]>; Paolo Volpato <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Éric Vyncke's Discuss on draft-ietf-v6ops-ipv6-deployment-08: (with DISCUSS and COMMENT)

Perfect, I will then clear my previous DISCUSS ballot

Regards

-éric


On 01/12/2022, 18:49, "Giuseppe Fioccola" <[e-mail]> wrote:

    Hi Eric,
    I just published the new revision (-10) that should solve the two remaining points.

    Regards,

    Giuseppe

    -----Original Message-----
    From: v6ops <[e-mail]> On Behalf Of Giuseppe Fioccola
    Sent: Thursday, December 1, 2022 2:56 PM
    To: Eric Vyncke (evyncke) <[e-mail]>; Paolo Volpato <[e-mail]>; The IESG <[e-mail]>
    Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
    Subject: Re: [v6ops] Éric Vyncke's Discuss on draft-ietf-v6ops-ipv6-deployment-08: (with DISCUSS and COMMENT)

    Hi Eric,
    Thanks a lot for the quick feedback.
    It was our oversight. I missed these points when merging different reviews.
    I will try to publish a new revision later today.

    Regards,

    Giuseppe

    -----Original Message-----
    From: Eric Vyncke (evyncke) <[e-mail]> 
    Sent: Thursday, December 1, 2022 2:41 PM
    To: Paolo Volpato <[e-mail]>; The IESG <[e-mail]>
    Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Giuseppe Fioccola <[e-mail]>
    Subject: Re: Éric Vyncke's Discuss on draft-ietf-v6ops-ipv6-deployment-08: (with DISCUSS and COMMENT)

    Hello Giuseppe and Paolo,

    Thank you for the revision -09, which addresses many of my points *EXCEPT*:
    - blocking DISCUSS: section 5.2 " or by using stateful and stateless DHCPv6", stateless DHCP *does not* lease IPv6 address(es) only stateful DHCP does ;-)
    - blocking DISCUSS: section 5.4.1.1. as " Header chain should go only in the first fragment [RFC8200]" as it is not correct per RFC 8200 section 5 (upper-layer header *must* be in the first fragment and extension header can also be in non-initial fragments)

    I am afraid that I will have to wait for -10 before clearing my DISCUSS ;-)

    Next Tuesday, 6th of December, is Saint-Nicolas[1] day in Belgium when kids got presents: so I am hoping for the -10 when I wake up on Tuesday 6 ;-)

    Regards

    -éric

    [1] https://en.wikipedia.org/wiki/Sinterklaas don't ask me why Wikipedia uses the Dutch name and not the French / German one...

    On 03/11/2022, 22:44, "Eric Vyncke (evyncke)" <[e-mail]> wrote:

        Hello Giuseppe and Paolo,

        Thank you for your reply. See below for EV> (as we agreed on many points, I did not put "EV>OK" in all the comments), we are in 98% agreement,, see below for suggestions.

        In short, I will clear my blocking DISCUSS quickly after the revised I-D is uploaded. So, looking forward to reading it (next week will be busy though)

        Best regards

        -éric

        On 31/10/2022, 17:38, "Paolo Volpato" <[e-mail]> wrote:

            Hi Eric,

            Many thanks for your comments.
            We plan to address them in the next revision of the draft.
            Please also see some more replies inline marked as [PV].

            Best regards
            Giuseppe and Paolo


            -----Original Message-----
            From: Éric Vyncke via Datatracker <[e-mail]>
            Sent: Wednesday, October 26, 2022 10:48 AM
            To: The IESG <[e-mail]>
            Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
            Subject: Éric Vyncke's Discuss on draft-ietf-v6ops-ipv6-deployment-08: (with DISCUSS and COMMENT)

            Éric Vyncke has entered the following ballot position for
            draft-ietf-v6ops-ipv6-deployment-08: Discuss

            When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


            Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
            for more information about how to handle DISCUSS and COMMENT positions.


            The document, along with other ballot positions, can be found here:
            https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/



            ----------------------------------------------------------------------
            DISCUSS:
            ----------------------------------------------------------------------


            # Éric Vyncke, INT AD, comments for draft-ietf-v6ops-ipv6-deployment-08
            CC @evyncke

            Thank you for the work put into this document even if I had hoped for a cleaner document. I also regret that security is not mentioned as an incentive to deploy IPv6 security policies as most end-points have IPv6 enabled by default.
            I am also concerned that this document did not get enough reviews (thanks Robert for your https://mailarchive.ietf.org/arch/msg/v6ops/Trz62uglkVKOuXY3gXV_lNpyBEc/ and 3 reviews -- if not mistaken -- during V6OPS WGLC).

            Please find below several blocking DISCUSS points (should the document be sent back to the V6OPS WG ?) and some non-blocking COMMENT points.

            Special thanks to Fred Baker for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

            I hope that this review helps to improve the document because it is important

            Regards,

            -éric

            ## DISCUSS

            As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

            ### Section 1.1

            ```
                  IPv4 as a Service (IPv4aaS): It means that IPv4 service support is
                  provided by means of transition mechanism, therefore there is a
                  combination of encapsulation/translation + IPv6-only overlay +
                  decapsulation/translation.  For an IPv6-only network, connectivity
                  to legacy IPv4 is either non-existent or provided by IPv4aaS
                  mechanisms.
            ```
            It must be "IPv6-only underlay", see other use of "underlay/overlay" in other IETF published RFC: 7364, 7365, 9272, ...

            [PV]: Yes, it was our oversight. In the very first versions of the draft we developed the idea of the end-to-end overlay service. Then, following the mailing list discussions, we refined the approach (in line with the RFCs you mentioned): the IPv6-only overlay refers to the inner header between the two end points while the outer header is the underlay. It is our fault, we did not change the word in the definition. In the next version we will fix it and specify that IPv4aaS "is a combination of encapsulation/translation + IPv6-only underlay + decapsulation/translation".

        EV> "errare humanum est" ;-)  
        EV> all is good then

            ### Section 4.2 overlay

            Again the title and the introduction are incorrect. It should be "IPv4 as a Service and IPv6-only ***Underlay***".

            [PV]: As above, we will fix it. We propose to change the title to "IPv4 as a Service" and revise the introduction accordingly.

        EV> OK

            ```
               Both are IPv4aaS solutions by leveraging IPv6-only overlay.  IPv4aaS
               offers Dual-Stack service to users and allows an ISP to run IPv6-only
               in the network (typically, the access network).
            ```
            The above text repeats the same mistake.

            [PV]: Yes, we will replace "overlay" with "underlay".

        EV> OK

            ### Section 4.2 464XLT and MAP-T

            While I really like 464XLT, it should not appear in a section with "underlay"
            as it is *not* an encapsulation mechanism. The same reasoning applies for MAP-T. The section should be about IPv4aaS then 464XLAT and MAP-T could be included.

            [PV]: Yes, we agree. We will revise this section to focus only on IPv4aaS.

        EV> OK

            ### Section 5.2

            ```
               IPv6 addresses can be assigned to an interface
               through different means, such as Stateless Auto-Configuration (SLAAC)
               [RFC4862], stateful and stateless Dynamic Host Control Protocol
               (DHCP) [RFC8415].
            ```

            Stateless DHCPv6 *does not* assign IPv6 addresses/prefixes.

            [PV]: Ok, will reword this sentence.

        EV> actually you only need to remove "and stateless" if your prefer

            ### Section 5.4.2

            As it is linked to security, I am raising this to a DISCUSS level.
            Fragmentation can be used to bypass all layer-4 filters not only in NDP as mentioned in the draft, but in any protocol. Please add text about RFC 8200 section 5: ```
                       Extension headers, if any, and the Upper-Layer header.  These
                       headers must be in the first fragment.
            ```

            [PV]: We will revise this sentence and add the reference to RFC8200 for any protocol.

        EV> looking forward to reading your revised I-D

            ----------------------------------------------------------------------
            COMMENT:
            ----------------------------------------------------------------------


            ## COMMENTS

            ### Section 1.1

            About the IPv6-only interface, the definition only mentions 'forward only IPv6', does this mean that it can receive or transmit IPv4 ? I.e., is it router centric ? I obviously understand the authors' intent, but the definition would benefit from more clarity. It seems also a little IP-centric as there could still be some routed/forwarded protocols that are neither IPv4 not IPv6 (e.g., MPLS).

            [PV] We will clarify the definition, explaining that the interface only receives and transmits IPv6 packets and no IPv4 can be handled by this interface.

        EV> OK

            About "IPv6-only service", the definition assumes a unicast client-server relationship what about multicast streaming or a peer-to-peer (no client/server role like in RTP).

            [PV]. We will extend the definition to also consider both multicast and peer-to-peer.

        EV> OK

            Unsure how to understand "facing interface of CGN" in "IPv6-only overlay".

            [PV] The scope was to report the end-points of the overlay tunnel, but we can simply state that for fixed residential services the tunnel is between the CE and the BNG, to avoid any misunderstanding.

        EV> this would be clearer indeed

            ```
                  IPv6-only overlay in fixed network means that the
                  encapsulation is only IPv6 between the interfaces of the Provider
                  Edge (PE) nodes
            ```
            This is ambiguous... what is meant by "encapsulation is only IPv6" ? Would prefer "where only IPv6 packets are encapsulated"

            [PV] We will reword to say, as you propose, that only IPv6 packets are encapsulated.

        EV> ack

            Please expand and add a reference at first use of "SRv6".

            [PV] Sure, thanks.

        EV> thanks

            ### Section 2.1

            `Table 3 of [POTAROO1] shows` please indicate the date (in the text and not only a year in the references).

            [PV] Yes, we'll add it.

            Please add some explanations about the use of double quotes around "usable".

            [PV] Ok.

            s/on their WAN-facing side/on their Internet-facing side/

            [PV] Ok.

            ### Section 2.1.1

            Please provide a date for the data in figure 1.

            [PV] Ok.

            ### Section 2.3

            Just a thank you for the reference to W3tech (I did not know).

            Please also note that Alexa does not publish anymore the Top web sites since May 2022 :-(

            [PV] Yes, we were aware and will double-check the reference.

            ### Section 2.4

            Suggestion to have one paragraph per country.

            [PV] Sure, we will make this change to improve the readability.

            ### Section 3.1

            Unsure whether RIR allocation statistics are related to `IPv6 adoption in operational networks.` (line just above) as a prefix can be allocated but not put in operation. Should 'operational' be removed ?

            [PV] It is very hard that an allocated IPv6 prefix is not put in operation, but it is okay to remove it.

        EV> you would be surprised... some multi-national companies have a /32 from all RIR but are only using one of them...

            After reading:
            ```
               Hence the two CAGR values
               in the table should not be compared directly as the weight of the
               allocations is different.
            ```
            I really wonder whether figure 5 and its associated text is useful and not confusing ;-)

            [PV] Ok, we will review it taking into consideration the last available data before publication. If more updated data are available (e.g. related to 2022) we will revise the table, otherwise we can consider to omit it.

            ### Section 3.2

            Please add the date in the section text (else the reader has to jump to the appendix to get it).

            Please consider adding references to DS-lite and 464XLAT.

            [PV] Ok to both.

            ### Section 3.3

            To repeat myself, please provide a date for the poll in the section text.

            [PV] Sure.

            ### Section 3.3.1

            Please consider removing the European data reference as it includes domains in China and in the USA.

            [PV] We considered only the European domains present in the IPv6 Forum list, not all of them (we did some post-processing of the data).

        EV> suggest to explain this in the text

            ### Section 3.5

            I would have expected to have different sections for large content provider (i.e., google.com could use a single IPv4 address) and for cloud provider (i.e., every AWS services must have their own IPv4 global address). I.e., vastly different use cases.

            [PV] This is a very valid point. We didn't receive any input on this from the list during the editing process.
            If we are able to find more information we will include it.

        EV> I sincerely believe that this part requires more investigation

            ### Section 4

            Should the section title indicate that this section is for Service Providers ?
            as indicated by `service providers may either adopt the scenarios proposed in a sequence or jump directly to a specific
               one.`

            [PV] Indeed.

            ### Section 4.1

            "CGN" and "IT" acronyms were already introduced before.

            [PV] Ok.

            Was it "in June 2021" or "in June 2012" ?

            [PV] It is 2021, when we took the relevant analytics. Based on your comment, we will specify that the analytics are taken from the web site of the World IPv6 Launch that keeps on monitoring the use of IPv6 in different networks.

            ### Sections 4.2 and 4.3

            It seems to me that section 4.2 is mostly about residential access network while section 4.3 is more about layer-3 services. Should it be better reflected in the title ?

            [PV] We will review based on the comments received.

            ### Section 5.1.2

            OT and IT were already expanded before, no need to re-expand.

            [PV] Ok.

            ### Section 5.1.3

            The title of this section is about Cloud and DC but the actual content is mainly around CDN (which are very important indeed).

            Also the references for CDN include an Amazon reference but this reference is about the cloud/VM and not any CDN.

            [PV] We'll revise the title and include CDN and we check also the references.

            The sentence `The challenge for CSPs is related to the support of non-native
            IPv4 since most CSPs provide native IPv6.` is really hard to parse.

            [PV] We'll rephrase it.

            ### Section 5.1.4

            Suggest not to introduce the STB acronym as it is not used at all.

            Please describe what "NAT444" is.

            [PV] Ok to both.

            Usually, "CE" is used when linked to "PE" as in layer-3 services. I think what should be used in this section is "CPE", which is usually residential grade and not enterprise grade.

            [PV] We'll consider to make this change.

            ### Section 5.2

            What is the relationship to IPv6 of the following text:
            ```
               For example, YANG is the configuration language for networking but in
               the real world the data modeling may be still vendor dependent.
            ```

            Also, if you mention YANG (which BTW is not limited to configuration), then please add NETCONF/RESTCONF to the list of network management protocols.

            [PV] There was already a comment on this. We will omit it.

            ### Section 5.3.1

            "currently" has little semantic in a published RFC.

            [PV] Ok.

            ### Section 5.4

            Strongly suggest adding that most vulnerabilities are nowadays in the human being (social engineering) and in the application layer and *not* in the IP layer.

            I do like the last paragraph, but it should be a call for staff training as well.

            [PV] Ok and we agree :-)

            ### Section 5.4.1

            ```
               These IPv6 associated protocols like ICMPv6, NDP and MLD are
               something new compared to IPv4, so they add new security threats and
               the related solutions are still under discussion today.
            ```
            I am afraid that neither ICMPv6 (barring NDP) and MLD are new compared to IPv4 as they are quite similar to ICMPv4 and IGMP ;-)

            Should the following section 5.4.2 be subsection of 5.4.1 ? and should fragmentation be mentioned in 5.4.1 ?

            [PV] Our point of view was to consider the security vulnerabilities of IPv6-associated protocols but we will re-read and review accordingly.

            ### Section 5.4.2

            Please add a reference to RFC 5095 (Deprecation of Type 0 Routing Headers in IPv6).

            [PV] Ok.

            ## NITS

            ## Notes

            This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues.

            [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
            [ICT]: https://github.com/mnot/ietf-comments






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