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

[JORDI PALET MARTINEZ <[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.

[Jordi-2] Do you think it makes sense to let the implementors to not make them configurable? Because if that’s the case then a strong recommendation to make it configurable in section 8, should work ;-)
    
        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.
    
[Jordi-2] Here is the point. I now increase a bit the HE complexity, but we are taking a big opportunity of a successfully widely implemented mechanisms to do something very good with an update. If instead of that we choose to write a *new* mechanism specific for detecting the PMTUD problem, it will take much longer to become widely implemented, and I think we are in the IETF to solve the problems in a way that is more convenient and better for the community, right?
    
        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
    
[Jordi-2] got it, thanks!
    
    [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 <http://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).

[Jordi-2] Same argument as above for the PMTUD. I think is feasible to make it in the same document and take the opportunity of the success. I understand that it may mean that the move to last call may take a couple of additional cycles. It is not my intent to delay this at all, but instead, to make whatever is better for the community. A couple of months of delay is worth instead of waiting years for an alternative protocol to be implemented widely. I’m sure you understand my point. This is my suggestion. I guess you will be in Prague. Let’s work (probably other people is interested in that) in a couple of alternatives about how to do this from now to the meeting. Then we can met face to face on Sunday in Prague and we can advance it as much as possible, and we could ask in the v6ops session a poll about this with already “something” in draft (may be presenting) a couple of choices. I’m happy to draft something in the next couple of days. I understand what you mean about the privacy implications, however: 1) The ISPs are already mandated by law to log the data of the customers 2) We don’t need to send the ISP the address of the host, the WAN address is enough probably (just a quick idea).
    
    Thanks,
    David Schinazi



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