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

[David Farmer <[e-mail]>]

Furthermore, on a mobile device, you can't just turn off IPv4 on the device
unless anywhere it goes will not have IPv4.  In this case want to turn off
IPv4 on certain networks, not all networks, not even all dual-stack
networks, but only some that we designate as IPv6-Only networks. This is an
important distinction, and it means turning off IPv4 on the host isn't
really an option.

The potentially bad side effects of the flag are a valid concern, but If
the meaning of the flag is changed to be similar to RFC2563, then I think
that mitigates the bad side effects completely.  Basically, the flag has no
meaning or effect by itself, it only has meaning if the host also doesn't
receive a DHCPv4 response. This way you set the flag in the IPv6 RA and you
also have to either layer 2 filter ether types 0x0800 and 0x0806 or
otherwise ensure there are no DHCPv4 responses on the network.

Thanks


On Tue, May 7, 2019 at 6:19 PM 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.
>
> 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
> --------------------------------------------------------------------
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================