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

[Raymond Burkholder <[e-mail]>]

On 2019-05-07 7:08 p.m., Mark Smith wrote:
> On Wed., 8 May 2019, 09:19 Brian E Carpenter, 
> <[e-mail] <mailto:[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.

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