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

[Gyan Mishra <[e-mail]>]

Sorry for the emails..

I can see now why Microsoft is pushing for IPv6-only feature.

Gyan

On Wed, May 8, 2019 at 1:24 AM Gyan Mishra <[e-mail]> wrote:

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

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