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

[Mark Smith <[e-mail]>]

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.


Computers are about making things easier, so we get to spend that saved
time on something else.


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.


Saving battery on mobile devices saves people having to spend time more
regularly recharging their batteries.


This mechanism would be also applicable in data centres. Link-layer
broadcasts are a problem in them too.

Address Resolution Problems in Large Data Center Networks

https://tools.ietf.org/html/rfc6820


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.


Regards,
Mark.


> Regards
>    Brian
>
> 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.
> >>
> >> The draft seems to me to be clear it is focused on managed networks.
> >> It uses the word “administrator” 12 times.   There is, of course, no
> >> administrator on unmanaged networks.
> >>
> >> 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.
> >
> > What's important about managed networks is that they're managed.  I.e.
> > that whatever policy is put in place by the administrator can be
> > enforced.  v6only does not and cannot enforce anything, which means that
> > from the point of view of policy or enterprise management, it fails
> > before it leaves the block.  It fails because all it does is provide an
> > advisory hint to the operating system about the intentions of the
> > network administrator.
> >
> > Drilling down further and looking at the issue from the point of view of
> > an enterprise network, management would encompass either device
> > management or fine-grained network access control, or both.  In each
> > case, the management will be enforced because if it's not enforced, it's
> > not management: it's hand-waving.
> >
> > For device management, it might be e.g. Windows group policy, or macos
> > workgroup manager, or some orchestration tool (puppet / saltstack /
> > etc), or some COTS product to do all this - there are plenty out there.
> > The point is that the management of the devices on the network will be
> > centralised and will give the administrators of the network the ability
> > to enable or disable ipv4 by application of enforced policy.
> >
> > No sane operating system manufacturer will leave the v6only option
> > enabled by default on an out-of-the-box installation because the
> > possibility of mischief is far too great. This means that if the
> > administrator wants to change this default, they will need to touch the
> > configuration of each installation.
> >
> > 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?  More to the point, if they need to delve
> > into this level of operating system protocol capabilities, their policy
> > management tools will be sufficiently fine-grained to enable or disable
> > any specific protocol on any specific network that they choose.  In
> > other words, the v6only flag is almost entirely irrelevant for managed
> > networks where the management capabilities are done on the host devices.
> >   The job can be done more simply and more reliably by using existing
> tools.
> >
> > The other type of managed network is where control of the network access
> > is managed.  I've gone into some detail on this scenario on several
> > occasions before, so please forgive me for quoting these URLs:
> >
> > https://mailarchive.ietf.org/arch/msg/ipv6/NIJ194PI8CLkuZT8U_jKEOY01QI
> > https://mailarchive.ietf.org/arch/msg/ipv6/a9KBvO88PlPrO0kLr83VOBlGmpw
> >
> > Summarising:
> >
> > - L2 ACLs provide vastly superior functionality, and work today.
> >
> > - even L2 ACLs on core links can reduce the problems assertions in the
> > v6only-flag problem statement to background noise.
> >
> > - 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.e. if you want actual management, then you need to manage, and that
> > mandates enforcement.  The larger your network, the more effort you need
> > to put into designing it properly - and managing it using appropriate
> > equipment.
> >
> > 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.
> >
> > Nick
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>