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

[JORDI PALET MARTINEZ <[e-mail]>]

Hi David,

Below in-line.
 

-----Mensaje original-----
De: <[e-mail]> en nombre de David Schinazi <[e-mail]>
Responder a: <[e-mail]>
Fecha: miércoles, 28 de junio de 2017, 4:43
Para: <[e-mail]>
CC: IPv6 Ops WG <[e-mail]>
Asunto: Re: [v6ops] Updated draft-ietf-v6ops-rfc6555bis to version 01

    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).

[Jordi] I understand that, however, having parameter in the OS, it means other apps can change that if they need it, even before there is an OS update. There are many users that don’t update the OS, so this is not a good way to ensure a correct future behaviour. Remember recent wannacry, etc., because outdates OS?   
    
    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.

[Jordi] Yes, and not. This is the intend of HE, but if HE only sort outs part of the possible issues, then one way or the other, the user notice it … so this is related with the suggestion for PMTUD failures to be also sorted out by HE …
    
    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?
    
[Jordi]  Exactly, what I’m suggesting is to improve a bit more HE and be able to verify the PMTUD filtering, so if IPv6 is faster than IPv4, but then PMTUD is filtered, then HE can also “take” the decision to use IPv4. This way we got what you wanted: User not aware of IPv6 failures! I don’t get then the “warning” to the ISP, but we can find a different way for that problem of course …


    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.
    
[Jordi] I understand that, and I’m somehow ignorant about how OS do this internally, so just wondering if we can take also the opportunity to also allow them to use HE.

[Jordi] Final comment. Do you think we can further extend HE in order to provide a way to warn the ISP that HE is forcing IPv4, because IPv6 performance is low? I think we can find several ways to do that, may be a common dns name such as he-fail.isp.com or something similar, that IF the ISP want to implement, gets info about those failures, but the ISP is free to implement it or not. This is useful for those ISPs that really do a good job monitoring their networks, of course, but I think is a perfect opportunity from HE instead of something different.

    
    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 <http://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
    



**********************************************
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.