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

[Gyan Mishra <[e-mail]>]

Do we or anyone in the WG know of any enterprise that is thinking of going
IPv6 only.  I don't.

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