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

[David Schinazi <[e-mail]>]

> On Jun 28, 2017, at 01:18, JORDI PALET MARTINEZ <[e-mail]> wrote:
> 
>    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?

[DS] I don't believe the benefit of increasing HE timers outweighs the risk of misconfiguration.
The section is titled "Summary of Configurable Values" which means OS implementers can choose to make these configurable. Some implementers will not.

>    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 …

[DS] Solving PMTUD issues is currently done inside the TCP stack not HE, I'm not certain of the value of adding complexity to HE for this.

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

[DS] That isn't possible with current architectures, but either way we're moving away from sockets so I don't think there's much value in solving this issue:
https://tools.ietf.org/html/draft-trammell-taps-post-sockets <https://tools.ietf.org/html/draft-trammell-taps-post-sockets>

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

[DS] That sounds reasonable to me, I think it deserves its own draft though (and will require a serious discussion about user privacy implications).

Thanks,
David Schinazi