Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01

David Schinazi <dschinazi@apple.com> Mon, 03 April 2017 21:45 UTC

Return-Path: <dschinazi@apple.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD0129329 for <v6ops@ietfa.amsl.com>; Mon, 3 Apr 2017 14:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEKL55Rz7H14 for <v6ops@ietfa.amsl.com>; Mon, 3 Apr 2017 14:45:21 -0700 (PDT)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D217128CD5 for <v6ops@ietf.org>; Mon, 3 Apr 2017 14:45:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491255921; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2iCOnO8l3iklcELQ8IMtZUoq7nUCb7FF/S71rMbXxSY=; b=K43PhdtDBp5Qmea7Krro8mE+NbXsgbJIbVY00BMfdP0b9jWDRVxR4DcdSexJgZI2 urFshQi/CPzCTovxwLGSjcijS8oOWy4TEi/IQ4T4pomPilU8y2MNK9ynN2JwOQFe bsVCyjBkPm/txR0FFXnsgobSIaFIdVVH6yTxHBEuLT7uWHAs6hU1ey6n6WWZX2Lq 3M8U7I+48smTn0uP4bf08EVVdT/3T0657NZvHYbK5SIGwCEPpThMtjiHy+5ekCDb DET+IhzEph8hMFlSiIOsE2HhCHLWGjr1VMQURaCMJFvCtxYxpgQa6+6bZJjx4GhB O49yt4+ufDdV8hY49iS0GQ==;
Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 3F.2F.25383.F62C2E85; Mon, 3 Apr 2017 14:45:21 -0700 (PDT)
X-AuditID: 11973e12-ad7fb70000006327-4d-58e2c26f3f92
Received: from koseret (koseret.apple.com [17.151.62.39]) by relay5.apple.com (Apple SCV relay) with SMTP id F2.C5.06491.E62C2E85; Mon, 3 Apr 2017 14:45:19 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_H9xZrPeQC46N/NDdmXbdhw)"
Received: from dschinazi.apple.com (dschinazi.apple.com [17.226.40.22]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONU000DHSFIKY40@koseret.apple.com>; Mon, 03 Apr 2017 14:45:18 -0700 (PDT)
Sender: dschinazi@apple.com
From: David Schinazi <dschinazi@apple.com>
Message-id: <004EF04D-AA6F-4301-A003-83E900826F4B@apple.com>
Date: Mon, 03 Apr 2017 14:45:17 -0700
In-reply-to: <CAD6AjGSxKftRXGfJ67rYN6Ccr961HMuU69Y=SSwnemvmsqddNQ@mail.gmail.com>
Cc: IPv6 Ops WG <v6ops@ietf.org>
To: Ca By <cb.list6@gmail.com>
References: <CAD6AjGSxKftRXGfJ67rYN6Ccr961HMuU69Y=SSwnemvmsqddNQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3251)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUi2FAYoVt46FGEwfLLjBarvnxksjh9bC+z A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWxc8Fr5oJOw4r7XT9YGhifaXYxcnJICJhI 7Jyxja2LkYtDSGAvo8SHrqPsMIn+D41MEIlVjBKPHvUwgyR4BQQlfky+xwJiMwuESUy9+YMR omgKk8TDO1fZQBLCAtISXRfusnYxcnCwCWhJHFhjBNFrI7Fk4lGoEnuJXfN2M4LYLAKqEvuu zmYFsTkFgiU6DvZAzVeQaHvXDlYjIiAn8ez1dLC4kECAxOEpS1khDpWV+PT8JzvIDRICR9gk jm7rYJrAKDQLya2zkNwKYWtJfH/UChTnALLlJQ6el4UIa0o8u/eJHcLWlnjy7gLrAka2VYxC uYmZObqZeSZ6iQUFOal6yfm5mxhBsTDdTmgH46lVVocYBTgYlXh4Fzg9ihBiTSwrrsw9xCjN waIkzhtw516EkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaoM4vuteofZ1GZ8r5DmXmyhdFf BdlJHZ1ehYtKFWc8lFzoF7L6Sd65tVH2hpuLPRmlJh2S4cpV/uC18NnT0G7HDfMqPsxQvrmt JIj5cleL7x6PszVf2gN2PDmy++vh8AWnJBtjg5elbUs/khwyJ3HfvS8ZTPrCfBd+hV2s44xY URF8/35qOrMSS3FGoqEWc1FxIgD4DfiqZgIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUiON1OXTf/0KMIg7MvpC1WffnIZHH62F5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugStj54LXzAWdhhX3u36wNDA+0+xi5OSQEDCR 6P/QyNTFyMUhJLCKUeLRox5mkASvgKDEj8n3WEBsZoEwiak3fzBCFE1hknh45yobSEJYQFqi 68Jd1i5GDg42AS2JA2uMIHptJJZMPApVYi+xa95uRhCbRUBVYt/V2awgNqdAsETHwR6o+QoS be/awWpEBOQknr2eDhYXEgiQODxlKSvEobISn57/ZJ/AyD8LyXmzkJwHYWtJfH/UChTnALLl JQ6el4UIa0o8u/eJHcLWlnjy7gLrAka2VYwCRak5iZWmeokFBTmpesn5uZsYQaHbUBixg/H/ MqtDjAIcjEo8vAucHkUIsSaWFVfmHmKU4GBWEuG9MhEoxJuSWFmVWpQfX1Sak1p8iHEiI9CT E5mlRJPzgZGVVxJvaGJiYGJsbGZsbG5iTkthJXHenPJ7EUIC6YklqdmpqQWpRTBHMXFwSjUw Xk6U+c+9JWeZjdqsSctv/bHavEDZZtGmR3PXSFgW7DmXoGJgYin3rme22JJPl1jPpaXvaazK 6TPYmM4/x26D/7KLR5Zf6rsj+Hf6OvbViu38IYHsx+8JVH2L2LTVNbpLaVVA3pWkPX0b73ka F5151yu4M4gno1KtxvythXae630//ag3hnE2SizFGYmGWsxFxYkAqu2nMtACAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/02KrmxZpaud3ddqvO5q_dY-93fI>
Subject: Re: [v6ops] draft-pauly-v6ops-happy-eyeballs-update-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 21:45:23 -0000

Hi Cameron,

Jordi was asking us to phase out Happy Eyeballs because it masks breakage in the network,
and what plan we could build to gradually phase it out. My response was that if you, as a
network operator, prefer to avoid Happy Eyeballs, you can deploy IPv6-only, as that will
in effect disable HE.

The scenario you describe is the opposite: you have a broken server and want HE to
hide that breakage from users. The tradeoff here is slightly different since that breakage
is much less widespread. It is something that a NAT64-aware HE stack could provide though.

David


> On Mar 29, 2017, at 13:22, Ca By <cb.list6@gmail.com> wrote:
> 
> Just a comment following up on Jordi's Mic comment
> 
> Jordi said there was an issue with HE hiding IPv6 issues.
> 
> David's response was something along the lines of "deploy ipv6-only".  I did not really understand this.
> 
> When folks deploy ipv6-only, they find they are all alone with a broken ipv6 scenarios that work on all their competitors IPv4-only networks and HE dual-stack networks.
> 
> Also, friendly reminder that Dan Wing catalogs a subset of the websites that fail on ipv6-only http://www.employees.org/~dwing/aaaa-stats/ <http://www.employees.org/~dwing/aaaa-stats/>
> 
> And, my customers still complain about www.fra.dot.gov <http://www.fra.dot.gov/> ... this works for everyone but me... because of HE...and I am already on IPv6-only ... and nobody will fix it.  This issues has been known by the USG DOT for over 3 months, noted to NANOG, nobody cares to fix it.
> 
> So, perhaps there is room in the I-D for including NAT64 synthesized address candidate set.  Meaning the HE algo on an IPv6-only host would include the set of available native IPv6 answers as well as a 500ms timer for attempting an A query with using whatever mechanism is available to the host for relaying IPv4 packets across an IPv6 only network (RFC6877, Bump in API, ...) 
> 
> Without this, IPv6-only networks are at a painful disadvantage since IPv6 must be perfect while every other scenario has HE to mask brokenness. 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops