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

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

> I believe this could be a good use case to add to the draft.  I don't think I saw it mentioned. 

I'm not sure whether we want to delve into that detail in this draft, but I agree with you. Bjoern had some related discussion in draft-bz-v4goawayflag.

Regards
   Brian Carpenter

On 08-May-19 17:08, Gyan Mishra wrote:
> Bob & Brian 
> 
> At the bottom of page 8 it says...
> 
>   An attack would not succeed if the dual stack hosts had active IPv4 configuration. As specified in Section 7, a dual stack host will ignore the flag if it has active IPv4 configuration. 
> 
> So lets say Day 0 you have 4 Default gateways and you are trying to migrate hosts from Dual stack to IPv6 only you could change each of the 4 Default routers to change to start setting the flag=1 and at that point until the last router sets the flag the hosts on the subnet are able to communicate with the DHCPv6 server and have their lease until it hits the rebind time to renew.  So lets say once the last router sets his flag=1 so now we are sending all 1's by all default routers the hosts still all have active leases and lets say the lease time is 7 days.  So then what happens.  Do they continue to work until thee rebind time to renew and then IPv4 gets turned off and then all hosts are then migrated dynamically to IPv6-only.
> 
> So I guess I can see this flag being actually a very nice method to migrate all hosts on a subnet from dual stack to IPv6 only dynamically on managed networks.
> 
> From the support perspective I can see this being a big win and now you can eliminate from the "Access" user community getting the user community within an enterprise quickly converted to IPv6 only so that only IPv6 needs to be supported versus IPv4.  I can see many benefits to that one of which being IPv4 address depletion but even if you use private space internally and proxy out to the internet their are gains to be made from a IPv4 address space management overhead perspective and DHCPv4 scopes to be managed that can all be sunset.
> 
> As far as my previous points of why go IPv6 only now I can definitely see why now even though the internet is far behind that tackling the user community desktops is an easy "win" so to speak for IPv6 to get converted to IPv4 and then you can alway use 6to4 nat & 6to4 DNS to communicate with Servers within the enterprise and 6to4 proxy to communicate IPv4 out to the internet.
> 
> From a migration strategy you could do the following:
> 
> 1. Set the flag=1 and migrate Access User community subnets to IPv6 only.
> 2.  Migrate all internal enterprise servers from Dual stack to IPv6 only. 
> 
> Use 6to4 nat 6to4 dns and 6to4 proxy to get the v4 resources
> 
> Now the entire enterprise is 100% IPv6 only.  
> 
> 
> I believe this could be a good use case to add to the draft.  I don't think I saw it mentioned. 
> 
> 
> Gyan
> 
> 
> 
>   
> 
> On Wed, May 8, 2019 at 12:51 AM Gyan Mishra <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>     I like this option below gives flexibility to the managed networks or use cases where the desktops are not yet ready for IPv6 only and they can flip the switch when the time is right in the future.
> 
>     ***From B Zeeb***
>     Given as of the last draft there is an option to disable processing 
>     despite implementing, OS vendors can implement the draft and do what 
>     they think suits their users.   Even more so they might leave the 
>     default to “off” for now as an “advanced option to turn on” and 
>     with a major OS update, once the world has moved on, flip the switch in 
>     the future.  
> 
>     Gyan
> 
>     On Tue, May 7, 2019 at 1:36 PM Bjoern A. Zeeb <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         On 7 May 2019, at 16:54, Sander Steffann wrote:
> 
>         > Hi Bob,
>         >
>         >> Would it help if the draft said the focus is for managed networks?
>         >
>         > Hmm. Just stating where it's supposed to be used doesn't prevent abuse
>         > in other situations. If we can actually limit the potential impact on
>         > devices on unmanaged networks then that would be great.
>         >
>         > I understand this is not easy, as the same devices will be used on
>         > both networks.
> 
>         Given as of the last draft there is an option to disable processing
>         despite implementing, OS vendors can implement the draft and do what
>         they think suits their users.   Even more so they might leave the
>         default to “off” for now as an “advanced option to turn on” and
>         with a major OS update, once the world has moved on, flip the switch in
>         the future.
> 
>         I can foresee a time when ISPs really don’t want to deal with the IPv4
>         for end users anymore and you’ll be happy to have the option then. 
>         Based on 8+ years of an ipv6-only unmanaged home network (but some code
>         under my control) I can tell you that I’ll be happy if more vendors
>         start thinking “what if there’s no DCHPv4 or IPv4 gateway
>         anymore?” now!  Especially all the smart gadgets that make it into the
>         homes at the moment and multi-function devices.  If it doesn’t happen
>         soon, your support calls will come the moment you want to have the flag
>         and turn it on and it’s not there.  This is investing in a future to
>         come now with the option to leave it off until we get to the point.
> 
>         That said I am sure ISPs already talking to many of these “smart
>         entertainment device vendors” given they probably get enough support
>         calls for them anyway..  It’s in your hands to give them an extra bit
>         to better prepare for the future, and possibly in the meantime improving
>         the dual-stack IPv6 as well.
> 
>         /bz
> 
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail] <mailto:[e-mail]>
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------
> 
> 
> 
>     -- 
>     Gyan S. Mishra
>     IT Network Engineering & Technology Consultant
>     Routing & Switching / Service Provider MPLS & IPv6 Expert
>     www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
>     Mobile – 202-734-1000
> 
> 
> 
> -- 
> Gyan S. Mishra
> IT Network Engineering & Technology Consultant
> Routing & Switching / Service Provider MPLS & IPv6 Expert
> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT>
> Mobile – 202-734-1000
>