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

[David Schinazi <[e-mail]>]

Hi Jordi,

Thanks for the review! I applied your clarifications to our working copy.

I don't think the document needs to mandate making constants configurable. Modern operating systems receive periodic software updates that can change the values as we work our way towards deprecating Happy Eyeballs. Average smartphone users shouldn't be bothered with this (if you can't configure it you can't misconfigure it).

As we discussed in Chicago, end users should never be made aware of IPv6 network failures as they are not their burden or responsibility to fix. Network operators shouldn't expect their users to be the first ones to notice something's broken. In effect HE will be deprecated when ISPs stop routing IPv4.

Regarding PMTUD, I'm not sure what you're suggesting. HE doesn't currently help with the issue so we marked it out of scope. Are you suggesting a remedy?

Regarding section 7.1, old socket APIs are out of scope as HE is implemented above or alongside sockets. Applications using sockets directly will not get any of these benefits.

Thanks,
David Schinazi


> On Jun 18, 2017, at 03:57, JORDI PALET MARTINEZ <[e-mail]> wrote:
> 
> 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 <[e-mail]> en nombre de David Schinazi <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: martes, 6 de junio de 2017, 2:10
> Para: IPv6 Ops WG <[e-mail]>
> 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
>    [e-mail]
>    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.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops