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

[Bob Hinden <[e-mail]>]

Gyan,

> On May 2, 2019, at 3:34 PM, Gyan Mishra <[e-mail]> wrote:
> 
> One other important concept of this theoretical distant future of IPv6 only networks is that we would have to be 100% every server on the internet dual stacked IPv6 reachable entire internet local intranets and extranet peering networks to 3rd parties customers have to be 100% dual stacked or only on IPv6 and even if let’s say there is one host 1 url that is not dual stacked that can only be reached via IPv4 then you cannot do IPv6 only.

In Section 4. IPv6-Only Definition it says:

   It is expected that on IPv6-Only networks it will be common to access
   to IPv4 external services by techniques such as NAT64 [RFC6146] and
   DNS64 [RFC6147]  at the edge of the network.  This is beyond the
   scope of this document.

So it is not expecting that 100% of every server on the internet is dual stack.

Bob


> 
> I get it that the directional is to move to IPv6 but this is not going to make it happen any quicker but the risk with attack vector created is far worse that a little bit of IPv4 traffic.
> 
> Gyan
> 
> Sent from my iPhone
> 
>> On May 2, 2019, at 6:29 PM, Gyan Mishra <[e-mail]> wrote:
>> 
>> I read through the draft as it has had 5 revisions and improvements I understand the rationale behind wanting this flag.
>> 
>> I would say my biggest concern with this flag at least introducing it now as we are not even anywhere close to a 50/50 tipping point that folks that end users would stop using IPv4.
>> 
>> The major downside is security vulnerabilities that can impact the mainstream of traffic flow which is IPV4.  
>> 
>> I could see introducing this flag let’s say we were past the tipping point and the proliferation and penetration of IPV6 was so tremendous that we were well beyond 50% and more like 70% plus and only few remaining stragglers on IPv4.
>> 
>> I would say for that to happen it would be beyond all of our lifetimes that the internet local intranet and extranet are even close to a tipping point
>> 
>> That being said the gains of negligible control plane dhcp traffic reduction is minuscule as compare to impact if their is an IPv4 outage from now newly introduced attack vector.
>> 
>> That being said I do not support this draf.
>> 
>> I would say maybe give it 50 to 100 years and I might change my mind given IPv6 penetration at that point.
>> 
>> Gyan
>> 
>> Sent from my iPhone
>> 
>>> On Apr 30, 2019, at 5:55 PM, Nick Hilliard <[e-mail]> 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.
>>> 
>>> 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.
>>> 
>>> Nick
>>> 
>>> --------------------------------------------------------------------
>>> 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
> --------------------------------------------------------------------