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

[Mark Smith <[e-mail]>]

On Wed., 8 May 2019, 11:53 Raymond Burkholder, <[e-mail]> wrote:

> On 2019-05-07 7:08 p.m., Mark Smith wrote:
>
> On Wed., 8 May 2019, 09:19 Brian E Carpenter, <[e-mail]>
> wrote:
>
>> Nick, excuse top posting but it seems to me that you are
>> assuming that in a managed network, the hosts are all
>> managed too. That's certainly a false assumption in my
>> experienced: managed routers and access points with
>> BYOD hosts is a very common scenario.
>>
>> It remains true that even so, in many cases the managed
>> network could be configured to block IPv4 at layer 2.
>> I can't argue against that argument.
>>
>
> Doing that is a lot more work than enabling a flag on typically no more
> than the 2 IPv6 routers on the link would be.
>
>
> Did we already go through the thought process of working with the fact
> that there is already an implicit ipv6-only flag?  Yep.  If there are no
> ipv4 addresses on key gateway links, ipv4 devices won't get anywhere, and
> will either automatically or be required to manually convert over to ipv6.
> Windows and Linux already have an ipv6 preference I believe.
>

Would I be correct in assuming you haven't read the draft at all?



>
> That's the only reason automated mechanisms like DHCP exist. ARP exists
> for the same reason. The jobs they do could have been done manually on each
> individual device. In the case of DHCP, it was done manually before DHCP
> was invented and supported on PCs. DHCP and ARP fundamentally save time.
>
> If this stuff is turned off, then devices will see there is no ipv4.
>
> Saving battery on mobile devices saves people having to spend time more
> regularly recharging their batteries.
>
> Is that up to the network operator to fix?  As time progresses, I think
> there will be a natural evolution away from ipv4.  Marketing pressures and
> market forces, etc.  Newer mobile which might be built to be aware of the
> flag, could just as readily be designed to deal with the ipv4/ipv6 issue
> implicitly.  No see'um ipv4, no use'um ipv4.
>
> This mechanism would be also applicable in data centres. Link-layer
> broadcasts are a problem in them too.
>
> See the 'gigantic l2 domains busted' comment further down.  Data center
> operators will probably be aware of their ip4/ipv6 addressing, and will be
> 'addressing' this via end to end (re-)configuration (removal/disabling ipv4
> stacks).
>
>
> Reducing and eliminating IPv4 link-layer broadcasts on large data centre
> links delays having to build more links as host numbers increase. Delaying,
> reducing and ideally completely avoiding that work saves time.
>
> I'm not sure if the flag buys anything.  Equipment will have to be
> upgraded to be aware of the flag.  Why not just let it evolve away.  Ipv4
> is but 'some percentage' of link-layer broadcast.  What with beacons,
> hello's, ND, ... would there be a noticable savings?  In ipv4's case, in
> dhcp, there is the exponential back off to nothingness.  After that, arps
> won't happen because there are no source/destination addresses to be
> resolved.  If an interface can't get an address, the mDNS and related
> services don't talk much.
>
> ipv4 death via suffocation, in other words?
>
> On 08-May-19 07:13, Nick Hilliard wrote:
>> > Bob Hinden wrote on 07/05/2019 17:31:
>> >> Enterprise networks are an important use case for this proposal.
>> >>
>> >> Would it help if the draft said the focus is for managed networks?
>> > Not really, no, because when you look at it more closely, it becomes
>> > apparent that the flag is redundant on managed networks.
>>
> I would tend to agree that a manager/administrator of said network will
> already be dealing with (re-)addressing issues and, well, legacy apparatus
> which they are stuck with.
>
> > But here's the thing: if they already have to change the default
>> > configuration to enable v6only, why wouldn't they go the whole hog and
>> > just disable v4 completely?
>>
> Agree.
>
> > - gigantic l2 domains were busted about 30 years ago as being terrible
>> > network design and the ietf has no responsibility to create workarounds
>> > for people who implement terrible network designs.  And if you really
>> > need to implement gigantic l2 domains, you need kit which is fit for
>> > purpose.
>>
>> > I'm sure it would be possible to contrive scenarios where marginal gain
>> > in functionality is achieved with the v6only flag, but in 18 months of
>> > discussion (and draft-perreault-sunset4-noipv4 before it), not even a
>> > single credible use case has come up where the alternatives weren't
>> better.
>>
> Agree.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>