Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

[Brian E Carpenter <[e-mail]>]

On 04-May-19 16:14, Gyan Mishra wrote:
> Brian
> 
> I am on board with the draft and based on Microsoft and FB both big players driving IPv6 only and since Microsoft has a majority share in the desktop market that makes a big difference.
> 
> I have always been and still am a proponent of dual stack but now I understand more clearly that the use case for enterprises would be tpresenting dual stack to the public while being IPv6 only internally. I think this use case idea for enterprises should be added to the draft if not already.
> 
> What was Nick and Sanders operator and operational objection as I missed that in an earlier thread.

Thanks, I will forward their recent messages off-list to avoid repetition.

    Brian
> 
> Thank you 
> 
> Gyan
> 
> Sent from my iPhone
> 
>> On May 3, 2019, at 9:33 PM, Brian E Carpenter <[e-mail]> wrote:
>>
>>> On 04-May-19 12:04, Mark Smith wrote:
>>>> On Sat., 4 May 2019, 08:54 Gyan Mishra, <[e-mail]> wrote:
>>>>
>>>> Do we or anyone in the WG know of any enterprise that is thinking of going IPv6 only.  I don't.
>>>
>>> Case Study: Facebook Moving To An IPv6-Only Internal Network, 6 June 2014
>>> https://www.internetsociety.org/resources/deploy360/2014/case-study-facebook-moving-to-an-ipv6-only-internal-network/
>>>
>>> Microsoft making progress towards IPv6-only, 17 Sep 2018
>>> https://blog.apnic.net/2018/09/17/microsoft-making-progress-towards-ipv6-only/
>>
>> Thanks Mark. And of course the entire motivation of all the work on NAT64, 464XLAT and so on was to *allow* operators and enterprises to make that choice (and thereby reduce operational complexity) without the whole world having dual stack capability. So while I have always been a strong advocate of dual stack, it's clear that there will be a trend for far-sighted enterprises to go IPv6-only sooner rather than later. (Of course, they have to present a dual-stack face to the outside world.)
>>
>> It's the job of a standards organization to be preemptive and to be out ahead of vendors and operators - years ahead, that is. So personally I think the "too soon" argument is completely wrong. We should probably have worked on this sooner, while NAT64 and 464LAT were still in development, in fact.
>>
>> I'm definitely sensitive to the operational arguments from Nick and Sander. However, on that topic the authors can only wait for directives from Ole, since we're servants of the WG consensus. If it isn't clear, I at least don't know what else to change in the text in response to those objections. If the WG wants to un-adopt the draft, so be it. But that would need to be a new consensus call.
>>
>>   Brian
>>
>>>>
>>>> I agree you have nat64 and dns64 and 6to4 proxy  for IPv6 only enterprises to access IPv4 content but if I was an enterprise customer I would go with dual stack over IPv6 only as that is the recommended mainstream deployment of IPv6
>>>
>>> It's debatable.
>>>
>>>> and IPv6 only is a few and far between  extreme exception that I don't think will gain traction till we are close to 100% of all internet content being dual stacked.
>>>>
>>>>
>>>
>>> Further to what Bob said, we have to expect it may take 3 to 5 years,
>>> perhaps sometimes longer, for our work to become widely available in
>>> implementations.
>>>
>>> For example, the current IPv6 Flow Label specification (RFC 6438) was
>>> published in November of 2011. Yet it took somewhere in the order of 2
>>> to 3 years for Mac OS X to be updated to support it, 4 years for Linux
>>> to be updated, and 6 years for Windows to be updated.
>>>
>>> We also need to try to have solutions that may last and can be in use
>>> for decades in many different contexts (ideally with one solution
>>> being able to be used in all possible use contexts), not just ISP or
>>> corporate/enterprise networks. We need to have solutions that can and
>>> will be implemented on billions of hosts, because that is literally
>>> how many IPv6 capable hosts are already in end-users' hands.
>>>
>>> Here we're doing medium to long term engineering, in contrast to the
>>> relatively short to medium term engineering that takes place when
>>> building and operating production networks.
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Regards
>>>>
>>>> Gyan
>>>>
>>>>> On Fri, May 3, 2019, 4:12 PM Brian E Carpenter <[e-mail]> wrote:
>>>>>
>>>>>> So bottom line here is that until the internet content is 100% IPv6 there is no way any broadband provider would pull back IPv6 thus in essence making this IPv6 flag literally useless and added on way to early in the game which brings me to my next point.
>>>>>
>>>>> Sorry but you miss the point. An enterprise might choose to provide only IPv6 service (and presumably some variant of NAT64) this year. What a broadband service provider might decide is a different matter; of course they are driven by their own market.
>>>>>
>>>>> Regards
>>>>>   Brian
>>>>>
>>>>>> On 04-May-19 04:17, Gyan Mishra wrote:
>>>>>> Brian
>>>>>>
>>>>>> IPv6 penetration is honestly really defined by the percentage of content on the internet that is dual stacked which is still pretty far off and has a long ways to go to even get to a tipping point 50/50 mark.
>>>>>>
>>>>>> As far as cable and broadband providers for end users they are now starting to dual stack but it will be a long time as I said not until we hit the 100% mark that all content on the internet is dual stacked would broadband providers start thinking about pulling back and disabling IPv6.
>>>>>>
>>>>>> The internet really drives the local corporations and intranet which lags behind so that would be even further down the pike.
>>>>>>
>>>>>> All broadband providers small and the big ones like Comcast Verizon Time Warner etc would not want to risk losing customers to their competitors if they pulled back IPv4 early and the internet content was not 100% IPv6.
>>>>>>
>>>>>> If they did so god forbid they may be in for a a lot of class action suits as the entire internet majority being IPv4 would now not be accessible..
>>>>>>
>>>>>> So bottom line here is that until the internet content is 100% IPv6 there is no way any broadband provider would pull back IPv6 thus in essence making this IPv6 flag literally useless and added on way to early in the game which brings me to my next point.
>>>>>>
>>>>>> With regard to security ICMPv6 is not secure and with a SEND secure neighbor discovery that could be secure the iCMPv6 RFC 4861 RS/RA type 133/134 and NS/NA type 135/136.
>>>>>>
>>>>>> So the RA that has the reserved field 2 flag bits now allocated to the IPv6 only flag can be subject to a man in the middle attack easily with a sniffer and spoofing the packet from the router manipulation of the the bird setting from all sending routers to 0 and now basically you have a massive outage.  Thinking about this on a larger scale let’s say If a router was exposed to an attack that someone gained accesses via a stack overflow or glitch the the attacker could not manipulate the flag to set the IPv6 only flag on all routers and now you have an IPv4 meltdown and a massive outage.
>>>>>>
>>>>>> There are many scenarios of which this is only a few off the top of my head but maybe on a more grand scale since all hosts are talking ICMPv6 let’s say their was malware ddos virus that hit internet wise and was via email or any other type of delivery mechanism that was able to compromise all hosts gain root access and now on the host itself can set this IPv6 only flag to 1 and now you have an internet wide meltdown the  worst in history.
>>>>>>
>>>>>> So I a nutshell this IPv6 only flag in my opinion is way ahead of its time and is a good thought but at this point is way jumping the gun as the entire internet community is not ready for this flag as our penetration numbers are not there yet.
>>>>>>
>>>>>> I really think we should defer this RFC and put on hold for the future..
>>>>>>
>>>>>> Gyan
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>> On May 2, 2019, at 7:52 PM, Brian E Carpenter <[e-mail]> wrote:
>>>>>>>
>>>>>>> Nick,
>>>>>>>>> On 01-May-19 09:55, Nick Hilliard wrote:
>>>>>>>>> Brian E Carpenter wrote on 30/04/2019 21:48:
>>>>>>>>> So I'd rather understand *why* the costs outweigh the benefits. One
>>>>>>>>> more thing for an operator to configure and check in each first-hop
>>>>>>>>> router, vs reduction of pointless traffic on updated hosts.. I'm not
>>>>>>>>> sure how to make that an objective rather than a subjective
>>>>>>>>> trade-off.
>>>>>>>> Hi Brian,
>>>>>>>>
>>>>>>>> Email is being a serious barrier to communication in this discussion :-(
>>>>>>>>
>>>>>>>> The problem statement just isn't there:
>>>>>>>>
>>>>>>>> https://mailarchive.ietf.org/arch/msg/ipv6/GCGYTXhg0V9mQBrcO7zhC5wtnp0
>>>>>>>>
>>>>>>>> The contents of this email largely still apply to the current text in -05.
>>>>>>>
>>>>>>> It's a judgment call. IMHO the problem statement is adequate. In your opinion, it isn't.
>>>>>>>
>>>>>>>> The cost is too high:
>>>>>>>>
>>>>>>>> https://mailarchive.ietf.org/arch/msg/ipv6/NIJ194PI8CLkuZT8U_jKEOY01QI
>>>>>>>>
>>>>>>>> You've shown no analysis of realistic use cases.
>>>>>>>>
>>>>>>>> For something standards track, and this far down the protocol stack and
>>>>>>>> with such a large security considerations section, the proposal ought to
>>>>>>>> be thoroughly compelling for a wide variety of deployment scenarios, but
>>>>>>>> it isn't.  There are better ways of skinning this cat..
>>>>>>>
>>>>>>> Again, a judgment call. We do refer to Layer 2 solutions and this is clearly positioned as a complementary approach.
>>>>>>>
>>>>>>> The authors aren't going to make the final judgment call, obviously.
>>>>>>>
>>>>>>>  Brian
>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list
>>>>>>> [e-mail]
>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> [e-mail]
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>
>>
>