Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01

Hi David,

Very good job! Some comments.

Implementations MUST NOT wait for both families of answers to return
   before attempting connection establishment.  If one query fails to
   return, or takes significantly longer to return, waiting for the
   second address family can significantly delay the connection
   establishment of the first one.  Therefore, the client MUST treat DNS
   resolution as asynchronous.  Note that if the platform does not offer
   an asynchronous DNS API, this behavior can be simulated by making two
   separate synchronous queries on different threads, one per address
   family.  If the AAAA query returns first, the first IPv6 connection
   attempt MUST be immediately started.  If the A query returns first,
   the client SHOULD wait for a short time for the AAAA response.  This
   delay will be referred to as the "Resolution Delay".  The RECOMMENDED
   value for the Resolution Delay is 50 milliseconds.

[Jordi] I’m not sure to fully understand this text, as somehow seems to me contradictory. “waiting for the second address family can significantly delay the connection”, but then you mention 50 milliseconds as recommended. I think it will be nice to clarify it. Also, I think the Resolution Delay should be a parameter, somehow configurable in the OS or apps. This would also facilitate “deprecating” the use of HE (by increasing the delay to an exaggerated value), without necessarily removing the code neither breaking apps that rely on it, when we decide that IPv6 is widely spread so any IPv6 failures should be noticed by end-users in order to pass the message to the ISP, etc.

(note that this is not
   referring to the sending of AAAA or A queries, but rather the address
   of the DNS server itself)

[Jordi] To make it clear, maybe you want to say something such as “… but rather the protocol used for the DNS transport”

This delay is referred
   to as the "Connection Attempt Delay".  One recommended value for this
   delay is 250 milliseconds.

[Jordi] Similar comments about the “Connection Attempt Delay” as earlier: should be a parameter, somehow configurable in the OS or apps. This would also facilitate “deprecating” the use of HE (by increasing the delay to an exaggerated value), without necessarily removing the code neither breaking apps that rely on it, when we decide that IPv6 is widely spread so any IPv6 failures should be noticed by end-users in order to pass the message to the ISP, etc.

464XLAT has the advantage of
   not requiring changes to user space software, however it requires
   per-packet translation and does not encourage client application …

[Jordi] I think this text will make it more accurate:
“464XLAT has the advantage of
   not requiring changes to user space software, however it requires
   per-packet translation in case the application is using IPv4 literals (or similar situations as older socket APIs) and does not encourage client application …

[Jordi] One question here. Should section 7.1 also consider not just literals but old socket APIs?

7.2 Host Names with Broken AAAA Records

[Jordi] I think you could add in this section (or a new section), the case for broken PMTUD. We have today many situations were on purpose or as a consequence of bad implementation of load-balancing, ECMP, etc. You can try it with any web site from 1&1 (for example diskmakerx.com) … just force a reduction on your MTU I you will find that the website is not only non-accessible with IPv6, but also doesn’t work with IPv4, because actual HE implementations aren’t able to detect this problem. I think it will be possible and of course, it will mean removing or having a different text for “9.1.  Path Maximum Transmission Unit Discovery”. I agree that because the nature of HE, active only at the initial stage, we need to somehow extend the HE algorithm to test that, but I think this is the perfect opportunity to make it, because HE is successfully implemented everywhere, so I guess it will be successfully updated. Making it a “different” RFC/protocol, may not have the same impact.

[Jordi] Of course, I think is a major ISP/date center issue, but they aren’t resolving it (tried for two years in this specific case), but there are many others, worldwide, and if we believe HE is the right solution for “ISPs not doing correctly their job”, then we should also support this “failure”. Again, using parameters, to make sure that when IPv6 is more globally spread we can “deprecate” HE and make sure to pass the ball again to those “bad guys in the sense that they don’t do a good job, or don’t make sure that they test correctly their deployments from the perspective of all kind of users”.

8.  Summary of Configurable Values

[Jordi] Looking at this section, you’re saying somehow what I was expressing earlier, so maybe we can make it clearer and is the right place to include a must to have all those parameters as OS configurable ones (by apps, users, network management, etc.).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de David Schinazi <dschinazi@apple.com>
Responder a: <dschinazi@apple.com>
Fecha: martes, 6 de junio de 2017, 2:10
Para: IPv6 Ops WG <v6ops@ietf.org>
Asunto: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01

    Hi v6ops,
    We have updated draft-ietf-v6ops-rfc6555bis to version 01.
    https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01

    This version incorporates feedback we received on the previous version,
    and adds a new section on "Supporting IPv6-only Networks with NAT64 and DNS64"
    as these technologies require changes in the Happy Eyeballs stack
    on devices that do not support 464XLAT.

    Please let us know what you think!

    Thanks,
    David Schinazi

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

            Title           : Happy Eyeballs Version 2: Better Connectivity Using Concurrency
            Authors         : David Schinazi
                              Tommy Pauly
    	Filename        : draft-ietf-v6ops-rfc6555bis-01.txt
    	Pages           : 13
    	Date            : 2017-06-05

    Abstract:
       Many communication protocols operated over the modern Internet use
       host names.  These often resolve to multiple IP addresses, each of
       which may have different performance and connectivity
       characteristics.  Since specific addresses or address families (IPv4
       or IPv6) may be blocked, broken, or sub-optimal on a network, clients
       that attempt multiple connections in parallel have a higher chance of
       establishing a connection sooner.  This document specifies
       requirements for algorithms that reduce this user-visible delay and
       provides an example algorithm.

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

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01
    https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-01

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

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.