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

[Ted Lemon <[e-mail]>]

The current document recommends generally against the particular use of
DHCP that you are using, but does not forbid it.   This is the correct
recommendation for most devices on the Internet.   The set of devices that
you use do not fall into that category, so the suggestion is really not at
all applicable to your use case.   This is why the document says what it
says.   It doesn't even say "SHOULD NOT."   It just says "won't have good
privacy characteristics, and therefore is not preferred."

Asking that IETF recommendations, which, again, remember, are aimed at *all
devices on the internet*, instead be tailored to just your use case, is not
reasonable.   The reason that the language reads the way it does is so as
to not exclude your use case.   I don't see how you could possibly justify
language that was any more accommodating of your use case.   As you say,
vendors of the sorts of devices that you use are not going to read that
document and think "oh, I guess I should disable IA_NA support now."

So what exactly would an update accomplish?   Please don't send another
long wall of text.   Just explain how we can balance these two competing
needs better than we currently are doing?

On Tue, Jul 18, 2017 at 7:38 PM, Scott Morizot <[e-mail]> wrote:

> 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")
>>
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>