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

[David Farmer <[e-mail]>]

On Tue, May 7, 2019 at 1:22 PM Philip Homburg <
[e-mail]> 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)
>

While I support this draft, I very much support a broader look at the
problems and solutions in a world where IPv4 isn't the dominant Internet
Protocol, IPv6-Only is one manifestation of this world, but I'm quite sure
there are others. I'm thinking something similar to RFC6104 but for the
world where IPv4 isn't the dominant Internet Protocol anymore.


> 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.
> This draft is just a small hammer looking for a nail.
>
> 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.
>
>   Then because of security risks, it makes sense for hosts to either not
>   implement it of leave 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. 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. 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.
>
> So we have a draft that clearly makes security worse. 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.
>

I will grant you that this draft doesn't improve security, but then by my
assessment, it doesn't make things fundamentally any worse either. An
IPv4-only network, without accounting for IPv6 vulnerabilities, is
susceptible to all sort of IPv6 based attacks the most IT or security staff
will be incapable of diagnosing.


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