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

[Gyan Mishra <[e-mail]>]

Updated migration steps to IPv6-only below:

Can we add this to the draft as a use case for deployment?

As far as IPv6 address management over IPv4 since IPv4 is classful it more
painful and IPv6 his hiearchial so their is tremendous gain as far as
administrative overhead of elimination of IPv4 to go to IPv6-only "NOW!!".

I think there could be a tremendous cost saving from an IT opex & capex
perspective as well.

Day 0 - IPv4 only
Day 1 - Migrate User access community to Dual Stack - IPv6 preferred over
IPv4 by default for all OS's
Day 2 - Migrate all server to Dual Stack - IPv6 preferred over IPv4 by
default for all OS's
Day 3- Set ipv6-only flag=1 all Default routers all subnets - migrating all
User access community to IPv6-only. Enable 6to4 nat, 6to4dns, 6to4 proxy.
Day 4 - Migrate all server to IPv6 only.  Eliminate 6to4 nat & 6to4 dns
internally within the enterprise as now all cilent/server communication is
over IPv6 only.  6to4 proxy remains in place until such time where 100% of
the internet is at a mimimum all dual stacked.
Day 6 - Once 100% of the internet is dual stacked - eliminate 6to4 proxy.
All communication both internally and externally is now all over IPv6.

Gyan

On Wed, May 8, 2019 at 1:08 AM Gyan Mishra <[e-mail]> 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]> 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]> 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]
>>> 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
>> 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
> 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
Mobile – 202-734-1000