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

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

On 08-May-19 06:21, Philip Homburg wrote:
>> Given as of the last draft there is an option to disable processing
>> despite implementing, OS vendors can implement the draft and do
>> what they think suits their users.   Even more so they might leave
>> the default to off for now as an advanced option to turn on and
>> with a major OS update, once the world has moved on, flip the switch
>> in the future.
> 
> This draft has two perspectives:
> - a network perspective (hosts trying to configure IPv4 waste bandwidth)
> - a host perspective (trying to use IPv4 may impact battery lifetime)
> 
> If this draft was part of a complete discussion on what to do with IPv4 
> and it became clear that this flag was required, then I would have no
> problem supporting the draft.
> 
> But nobody is doing any work on what IPv4 should look like in the future.

I don't understand that sentence. IPv4 is a legacy protocol,
so it will simply fade away.

> This draft is just a small hammer looking for a nail.

The nail has never been unknown, but some people claim it's too
small to be worth hammering.
 
> Without a clear idea of where we want to take IPv4 we can see some things
> happening:
> - To start with the host perspective. It is very like that many network will
>   not set this flag. Simply because there is no operator to decide if this
>   flag can be set or not. So hosts will implement counter measures to save
>   battery life even if the flag is not set.

I cerainly hope that's true.

>   Then because of security risks, it makes sense for hosts to either not
>   implement it of leave it off by default.

The draft already recommends configuring it off by default.

> 
>   Because there is no analysis from an IPv4 perspective, we don't actually
>   know if this draft is needed and how much effect it will have. 

We know that we're talking about a few percent of the traffic on an
IPv6-only network. Quantifying the effect on battery life is not
a reasonable task.

>   There is
>   justs some hints from hosts that are not optimized to live without IPv4.
> 
> - for a network, if many hosts do not implement this flag, then the network 
>   somehow has to cope. If the vast majority of the hosts do not implement
>   this draft then implementing this flag in a router is mostly an accident
>   waiting to happen. 

It's unclear to me what that accident might be, apart from what is
already in the security considerations.

>   Something that hardly any network engineer in the 
>   field can quickly diagnose. So it makes sense for routers to not implement
>   this draft. Which may reinforce host behavior to not rely on this flag.
> 
> - Finally, there is an existing code point in DHCPv4 to turn of IPv4 link
>   local configuration. Which is safe to implement for hosts and not hard
>   to provide for router vendors.

No disagreement there. I think we say that in the draft too.

> So we have a draft that clearly makes security worse. 

Not clear to me. Rogue RAs are a well-known danger already.

> That has operational
> risks if widely implemented. And at same time anybody sane will not
> implement the draft. So it probably live on as a useles flag that people will 
> remember to filter on their networks.

Sorry but that's a FUD argument.

   Brian