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

On Mon, Apr 3, 2017 at 3:34 PM Sander Steffann <sander@steffann.nl> wrote:

> Hi,
>
> > I understand that a gradual phase out may be not feasible, or even
> difficult to standardize as I’m not even sure the IETF process provides
> that path. So, maybe the only option is to come back in 1-2 years and
> declare HE historic, maybe as part of the sunset4 WG work.
>
> I once suggested to increase the HE timers to make broken IPv6 a bit more
> noticeable without breaking stuff completely. In the cases where the server
> is broken (I have seen insane AAAA records) it might be slightly less
> pleasant for the user, but suddenly there is a tangible incentive for the
> server to get fixed. "Unfortunately" the implementation of HE is on the
> user's side and the software developer's main goal is to provide a good
> user experience.
>
> But yeah, HE is hiding brokenness. On one hand this is a good thing
> because it makes people less afraid of deploying IPv6 because the "risk" is
> lower. On the other hand that lower risk also means that problems don't get
> solved. My guess is that when more and more NAT64 networks get deployed,
> and HE doesn't help anymore, the brokenness will get fixed.
>

My experience is that when clients see failure due to broken severs, nat64
based solutions get rolled back or shelved completely

After all, that website with the bad aaaa works on my DS competition's
network and my ipv4 only  competition's network.

HE has created a situation where ipv6-only must be perfect (impossible)
while ipv4 and ipv6 have a nonzero acceptable error budget.

Note, 464xlat is effectively DS in this example and can tolerate
misconfigured ipv6

> Cheers,
> Sander
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>