Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

And this is what I tried to say several times:

We need to take advantage of HE and NHE, or other means, to "report" to the ISPs about brokenness.

https://tools.ietf.org/html/draft-palet-v6ops-he-reporting-00

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Tommy Pauly <tpauly@apple.com>
Fecha: miércoles, 26 de septiembre de 2018, 12:38
Para: Tony Finch <dot@dotat.at>, "STARK, BARBARA H" <bs7652@att.com>, dnsop <dnsop@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, Davey Song <songlinjian@gmail.com>
Asunto: Re: [v6ops] [DNSOP] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

    +1 to the point that the proposal for NHE is essentially a mechanism for the ISP and/or content provider to work around a broken deployment that they should be in a position to fix themselves, or between one another as Tony describes.

    The point of client-side Happy Eyeballs is to work around broken or suboptimal situations that the client has no control over. Following the analogy, the server or ISP should only employ a parallel mechanism in order to work around some problem it has no ability to fix otherwise—such as hiding IPv6 from clients with somehow broken IPv6 stacks. This isn't what the situation is like, however.

    The part that remains interesting is suggestions for networks to collect more reports on the relative health of IPv4 and IPv6 connections, to help fix bugs and broken deployments. Focusing on these improvements rather than filtering DNS answers seems like it would be a more fruitful direction.

    Best,
    Tommy

    > On Sep 26, 2018, at 8:15 AM, Tony Finch <dot@dotat.at> wrote:
    > 
    > STARK, BARBARA H <bs7652@att.com> wrote:
    > 
    >> Why would an ISP choose to deploy partial or broken IPv6 + NHE, rather
    >> than properly functioning IPv6?
    > 
    > That was my initial reaction too :-) I think the actual idea is to work
    > around brokenness on third party networks, e.g. the ISP has working v6,
    > the web site has working v6, but there's bad connectivity between them.
    > (It doesn't help that there are some stupid peering wars going on between
    > tier 1 v6 providers, as mentioned in the v6 section of [1].)
    > 
    > The right fix, I think, is to get better peering or to filter broken
    > routes. It would seem to me to be better to implement the fix in the
    > network layer not the DNS layer, since it's a network problem not a DNS
    > problem.
    > 
    > [1] https://blog.apnic.net/2018/09/21/2018-national-internet-segments-reliability-report/
    > 
    > Tony.
    > -- 
    > f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
    > South Utsire, Forties, Cromarty: Westerly 5 to 7, perhaps gale 8 later, but
    > variable 4 for a time. Moderate or rough, occasionally very rough in South
    > Utsire. Drizzle, rain later. Moderate or good.
    > 
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops

    _______________________________________________
    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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.