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

[Bob Hinden <[e-mail]>]

Gyan,

> On May 3, 2019, at 3:53 PM, 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.  

Yes, Microsoft.   It was stated in 6man several meetings ago that they were planning IPv6 Only and that this was a mechanism that would be a useful tool.

Bob


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