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

[Brian E Carpenter <[e-mail]>]

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