Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-deployment-05.txt

From: [email-masked]
Date: Mon, 07 Mar 2022 02:30:12 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : IPv6 Deployment Status
        Authors         : Giuseppe Fioccola
                          Paolo Volpato
                          Nalini Elkins
                          Jordi Palet Martinez
                          Gyan S. Mishra
                          Chongfeng Xie
	Filename        : draft-ietf-v6ops-ipv6-deployment-05.txt
	Pages           : 46
	Date            : 2022-03-07

Abstract:
   This document provides an overview of IPv6 deployment status and a
   view on how the transition to IPv6 is progressing among network
   operators and enterprises.  It also aims to analyze the related
   challenges and therefore encourage actions and more investigations in
   those areas where the industry has not taken a clear and unified
   approach.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-deployment-05

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Paolo Volpato <[email-masked]>
Date: Mon, 7 Mar 2022 10:45:11 +0000

Dear WG,

We have just submitted version 05 of draft-ietf-v6ops-ipv6-deployment (https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/).

This version addresses and integrates new comments received from Jordi Palet, Cong Li and Gyan Mishra after the publication of version 04.
It also integrates other comments received off-line since then.
 
Comparing to version 04, this new one:
- Expands section 3.6 discussing the behavior of Happy Eyeballs
- Refines sections 4, 4.1 and 4.2 on IPv6 overlay and the approaches for the transition to IPv6-only
- Further expands section 5 on network underlay. It also introduces new references
- Introduces changes in sections 7.4. 7.4.1 and 7.4.2 on IPv6 performance

On behalf of the authors, best regards
Paolo

-----Original Message-----
From: v6ops <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, March 7, 2022 11:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-deployment-05.txt

Abstract:

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

---

From: Bob Harold <[email-masked]>
Date: Mon, 7 Mar 2022 09:56:31 -0500

On Mon, Mar 7, 2022 at 5:46 AM Paolo Volpato <paolo.volpato=
[email-masked]> wrote:

> Dear WG,
>
> We have just submitted version 05 of draft-ietf-v6ops-ipv6-deployment (
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/).
>
> This version addresses and integrates new comments received from Jordi
> Palet, Cong Li and Gyan Mishra after the publication of version 04.
Page 18

As I understand it, "Happy Eyeballs" sends both an "A" (IPv4) and "AAAA"
(IPv6) DNS query "at the same time" (actually, one right after the other),
and then takes the first response that it receives, which means that it
does not prefer IPv6, it takes whichever answer happens to come back first.

 Page 22

"a standard single protocol IPv4-Only or IPv6-Only for core where
where IPv4 packets can be tunneled over 4to6 MPLS software over an "

"where" is repeated at the end of on line and the beginning of the next

-- 
Bob Harold

---

From: Gabor LENCSE <[email-masked]>
Date: Mon, 7 Mar 2022 16:07:57 +0100

On 3/7/2022 3:56 PM, Bob Harold wrote:
> As I understand it, "Happy Eyeballs" sends both an "A" (IPv4) and 
> "AAAA" (IPv6) DNS query "at the same time" (actually, one right after 
> the other), and then takes the first response that it receives, which 
> means that it does not prefer IPv6, it takes whichever answer happens 
> to come back first.

Happy Eyeballs v3 is biased for IPv6. It gives about 50ms penalty to IPv4.

https://datatracker.ietf.org/doc/html/rfc8305#section-3

Gábor

---

From: Paolo Volpato <[email-masked]>
Date: Tue, 8 Mar 2022 09:59:59 +0000

Hi Bob,

Thanks for highlighting.
We will incorporate your comments in the next version of the draft together with those that are discussed at the IETF 113.

Best regards
Paolo

From: Bob Harold <[email-masked]>
Sent: Monday, March 7, 2022 3:57 PM
To: Paolo Volpato <[email-masked]>
Cc: [email-masked]; Jordi Palet Martinez <[email-masked]>; Gyan S. Mishra <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-deployment-05.txt

On Mon, Mar 7, 2022 at 5:46 AM Paolo Volpato <paolo.volpato=[email-masked]<mailto:[email-masked]>> wrote:
Dear WG,

-----Original Message-----
From: v6ops <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, March 7, 2022 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-deployment-05.txt

Abstract:

Page 18

As I understand it, "Happy Eyeballs" sends both an "A" (IPv4) and "AAAA" (IPv6) DNS query "at the same time" (actually, one right after the other), and then takes the first response that it receives, which means that it does not prefer IPv6, it takes whichever answer happens to come back first.

 Page 22

--
Bob Harold

---

From: Gabor LENCSE <[email-masked]>
Date: Sun, 20 Mar 2022 20:33:20 +0100

Dear All,

I have read the draft. (Only its main text, not the appendices.)

I feel that it is quite comprehensive, it covers a lot of aspects of 
IPv6 deployment and provides a good overview.

I have not found any significant issue, but only nits (see below). 
Perhaps a WGLC may follow.

Best regards,

Gábor

------------------ Nits ------------------

I was taking notes during reading. The majority of them are technical. 
For some reason unknown to me, some references did not became links in 
the htmlized version.

Section 2.3.

[W3Tech]

Section 3.1.

[APNIC2]

Section 3.3

[NST_1] -- should be a link
[BGR_1]  -- should be a link
[CNLABS_1] -- should be a link

Typo:
IPv6-enablesd --> IPv6-enabled

Grammar:
A poll ... show --> A poll ... shows

Section 3.3.1

DSN --> DNS

Section  4.2

[I-D.ietf-v6ops-transition-comparison] -- should be a link

    While it cannot be always the case, IPv6-only transition technologies
    such as 464XLAT require much less IPv4 public addresses
    [I-D.ietf-v6ops-transition-comparison  <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment#ref-I-D.ietf-v6ops-transition-comparison>], because they make a more
    efficient usage without restricting the number of ports per
    subscriber._This_  contributes to reduce troubleshooting costs and to
    remove some operational issues related to permanent black-listing of
    IPv4 address blocks when used via CGN in some services.  For example,
    Sony Play Station Network or OpenDNS imply a higher rotation of IPv4
    prefixes in CGN, until they get totally blocked, which means extra
    CAPEX in new IPv4 transfers.

What does "This" refer to?
- If it refers to 464XLAT, then I do not understand it. (Or, I think 
just the opposite is true: as the same public IP address and port number 
is ones used by a given user and then by another.)
- If it refers to MAP-E/T, then it should be made clear.

Section 7.1.1

                                                             On
    average, looking at the global statistics, the IPv6 traffic
    percentage is currently between 30% and 40% of_IPv6_.

Perhaps:

                                                             On
    average, looking at the global statistics, the IPv6 traffic
    percentage is currently between 30% and 40% of*the traffic*.

Section 7.1.3

an high percentage --> a high percentage

Section 7.2.

govern supporting --> governmental supporting

Section 7.4.1

[APNIC5] -- should be a link (twice)

                                       [APRICOT  <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment#ref-APRICOT>] highlights how when a
    difference in performance exists it is often related to asymmetric
    routing issues.

Perhaps "how when" is not proper.

                     Other possible explanations for a relative latency
    difference lays on the specificity of the IPv6 header which allows
    packet fragmentation.

I do not understand this.

Section 7.4.2.

[FB] -- should be a link

Section 7.5.

                           Some hints are in the
    paper [ComputSecur  <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment#ref-ComputSecur>].

Thank you for citing it. :-)

You might want to add also:

A. Al-Azzawi and G. Lencse, "Identification of the Possible Security 
Issues of the 464XLAT IPv6 Transition Technology", /Infocommunications 
Journal/, vol. 13, no. 4, pp. 10-18, December 2021, DOI: 
10.36244/ICJ.2021.4.2
Full paper in PDF 
<http://www.hit.bme.hu/~lencse/publications/InfocomJ_2021_4_2_Al-Azzawi.pdf>

Section 7.5.1.

[RIPE2] -- should be a link

---

From: Paolo Volpato <[email-masked]>
Date: Sun, 20 Mar 2022 20:18:57 +0000

Hi Gabor,
Many thanks for your careful review, we will fix all the remaining issues in the next version of the draft.
Talk about it tomorrow.
Paolo

From: v6ops <[email-masked]> On Behalf Of Gabor LENCSE
Sent: Sunday, March 20, 2022 8:33 PM
To: [email-masked]
Subject: [v6ops] My review results: a few nits -- Re: I-D Action: draft-ietf-v6ops-ipv6-deployment-05.txt

Dear All,

I feel that it is quite comprehensive, it covers a lot of aspects of IPv6 deployment and provides a good overview.

I have not found any significant issue, but only nits (see below). Perhaps a WGLC may follow.

Best regards,

Gábor

------------------ Nits ------------------

I was taking notes during reading. The majority of them are technical. For some reason unknown to me, some references did not became links in the htmlized version.

Section 2.3.

[W3Tech]

Section 3.1.

[APNIC2]

Section 3.3

Typo:

Grammar:

Section 3.3.1

DSN --> DNS

Section  4.2

   [I-D.ietf-v6ops-transition-comparison<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment#ref-I-D.ietf-v6ops-transition-comparison>], because they make a more

   subscriber.  This contributes to reduce troubleshooting costs and to

What does "This" refer to?
- If it refers to 464XLAT, then I do not understand it. (Or, I think just the opposite is true: as the same public IP address and port number is ones used by a given user and then by another.)
- If it refers to MAP-E/T, then it should be made clear.

Section 7.1.1

                                                            On

   percentage is currently between 30% and 40% of IPv6.

Perhaps:

                                                            On

   percentage is currently between 30% and 40% of the traffic.

Section 7.1.3

Section 7.2.

Section 7.4.1

                                      [APRICOT<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment#ref-APRICOT>] highlights how when a

   routing issues.

   packet fragmentation.

Section 7.4.2.

[FB] -- should be a link

Section 7.5.

                          Some hints are in the

   paper [ComputSecur<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-deployment#ref-ComputSecur>].

A. Al-Azzawi and G. Lencse, "Identification of the Possible Security Issues of the 464XLAT IPv6 Transition Technology", Infocommunications Journal, vol. 13, no. 4, pp. 10-18, December 2021, DOI: 10.36244/ICJ.2021.4.2
Full paper in PDF<http://www.hit.bme.hu/~lencse/publications/InfocomJ_2021_4_2_Al-Azzawi.pdf>

Section 7.5.1.

[RIPE2] -- should be a link
On 3/7/2022 11:30 AM, [email-masked]<mailto:[email-masked]> wrote:

                          Paolo Volpato

                          Nalini Elkins

                          Jordi Palet Martinez

                          Gyan S. Mishra

                          Chongfeng Xie

  Pages           : 46

  Date            : 2022-03-07

Abstract:

   approach.

v6ops mailing list

[email-masked]<mailto:[email-masked]>