Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

[Scott Morizot <[e-mail]>]

Perhaps the actual problem is a limited active participation in the IETF
process by certain groups, such as the large enterprise networks (outside
enterprise networks of large technology companies) sphere? That has always
been my day to day environment and focus whether as an application
developer, network engineer, or from any of the other hats that are dropped
in my lap, including interacting with groups of organizations outside my
own. I confess I read mailing list discussions intermittently and actively
say anything much less frequently than I read. But comments like the below
leave me bemused.

Those sorts of networks are highly constrained. Hosts and developers have
to coordinate even to be allowed on the network. Things that are purchased
and deployed generally have to meet our requirements and lots of things are
eliminated from consideration because they don't. If something has special
requirements, there's a lengthy process designing, testing, and documenting
the changes in the security boundary. Innovation is certainly restricted
and coordinated, even with in house developed applications.

There are lots of processes and tools integrated with DHCP assignment
information. But that's hardly the only data collected, the only layer of
protection, or the only avenue pursued when doing forensic analysis of an
attack. Connection security in one form or another is used. ARP/Neighbor
table information (as well as configuration in general) is collected and
tracked. Log data at every level is collected. There's IDS/IPS and packet
collectors at different key points. There are firewalls at all sorts of
different points from the host up. But no large enterprise is merely
looking for purely malicious traffic. They are also auditing and analyzing
all activity by authorized users. It's a highly inspected, highly
constrained networking environment and always will be.

A lot of those automated processes are tied into DHCP data. It's not that
that's the only source of forensic data, the sole audit point, or the
single point of protection. But a lot of automated tools/processes are
built around that data and that is not going to change quickly. Perhaps
when IPv4 is removed from much of the enterprise, it can be considered,
though there would have to be a compelling reason for enterprises to make
such a change. No such compelling reason currently exists. It will not
happen before then except in very special circumstances on different
networks from most hosts, not on general purpose data networks.

Host developers who want to sell to such enterprises will support DHCPv6
IA_NA address assignment on networks that provide no other alternative.
They already do for the most part because those networks exist today. And
they will continue to exist for a good number of years to come, whatever
the IETF decides to recommend or not recommend. If a host/node developer
has a special use case (as a limited IOT device such as door key card
access devices and alarm sensors very well might) and a large enterprise of
the sort I've described has a need for it, that might be engineered in a
special network of its own. So it's not an absolute that any given
host/node that wants to sell to large enterprises of the sort I've noted
above has to support DHCPv6 IA_NA address assignment. But as a general rule
of thumb? That should probably be the default expectation. It should be
considered, at least.

So I support the idea behind the changes to RFC 7934 proposed in the draft,
however they might be wordsmithed, as it more accurately reflects reality.
The current description may reflect a "best common practice" for general
use data on some networks and in some environments. It is not even vaguely
the common practice elsewhere. And it's unlikely to be anytime soon. If the
purpose of the document is to express what the IETF wished were the common
practice on most networks, that's fine. If its purpose is to express the
actual common practice, the current document falls short.

I have a hard time feeling too strongly about it, though. Host/node
developers often do want to sell to large enterprises, and as such they
typically will meet their specified requirements. I don't expect that to
change whatever the IETF chooses to publish. That's one situation in which
money does usually talk.

Scott

On Mon, Jul 17, 2017 at 7:59 PM, Mark Smith <[e-mail]> wrote:

> Fundamentally, we don't want hosts and application developers to have
> to ask for permission from the network to innovate, nor have the
> network impose artificial constraints on innovation. Artificial
> address scarcity is following the traditional telephone network
> scarcity model. (See David Isenberg's "Rise of the Stupid Network")
>
>