Re: draft-bourbaki-6man-classless-ipv6-00

David Farmer <farmer@umn.edu> Sun, 04 June 2017 19:50 UTC

Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119D2129410 for <ipv6@ietfa.amsl.com>; Sun, 4 Jun 2017 12:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdEnUjDWKRvD for <ipv6@ietfa.amsl.com>; Sun, 4 Jun 2017 12:49:58 -0700 (PDT)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A11128CD5 for <ipv6@ietf.org>; Sun, 4 Jun 2017 12:49:58 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 9E13997A for <ipv6@ietf.org>; Sun, 4 Jun 2017 19:49:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VunE-d5XugPF for <ipv6@ietf.org>; Sun, 4 Jun 2017 14:49:57 -0500 (CDT)
Received: from mail-vk0-f72.google.com (mail-vk0-f72.google.com [209.85.213.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 6B4D3284 for <ipv6@ietf.org>; Sun, 4 Jun 2017 14:49:57 -0500 (CDT)
Received: by mail-vk0-f72.google.com with SMTP id p85so35181621vkd.10 for <ipv6@ietf.org>; Sun, 04 Jun 2017 12:49:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=922DgpUKVq0dSPM2f30i6sW34PKhgT3++qTKNBySQEk=; b=Sq81FBq2kjKx30RPbcKLmAGwTwbCt2jPh/KAZ+xWsvqZg9ViNc6xX2LcLrcLi1cmqY tQnWSIDItjHDPuXMIvtJoDlLCmTfbURb+q+3CMUsPu4xyHtDndDptWKYJUO3hKpRC8Ql SttgAiXEvymN78vh7pgggainJjapCX3GHH2u2StQugsrZ1si/Xb5ef6NkkZcMjGU0cIg o1bYWohQlgCSipF9ohoKZXF0Q+xiu3GU4QiF3GYNKVGfr8b3fYdbwbCMfb8aXphuXlHv BEZB5JyIOHcE3w5AtT/x0tamvqSUqs1o2smMhaA/quktv0wlFSqOT4BXUPLfjefirqvf aQeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=922DgpUKVq0dSPM2f30i6sW34PKhgT3++qTKNBySQEk=; b=PnQWTK/deQWNZEVL2kt8bVIHZ/rKQiOyLwtp4GtdS3f4q2hnZjMI+7pKZIAL4WciNz ZNQE9NZ2p6IZWbcoWDjZk05bbQJIs4xHtVXaoowEzVPg6BVhmXGUjDjDcilCLVbhj0Vb dxgpWBhup1zVgOIF1uwgk3me7WDdyQOMs6X/Y0V80U7++ICHt9YjFIxkF4Bx3gL/l5gr QwG63WPLkgLzfinhYyjPNCeIz0i0laCdwDqRbLr0hsja6EmdyWrPdO9rpSBCubvWhXxj nHjcBY7jQAEYoaxvGaFFAA0ZDM2YA9DjZzuIkZPCqsY6lF93bZ+ssTgmUZ6RJW5LleHI 0CFw==
X-Gm-Message-State: AODbwcA+U/zNGOn+HXg89Ydp51e6bkXVYbrd2SS13Rfh/ZKMQhyHp6lf 3V4fOQqBz52Rz9oYpyTQnKKjTJDFkyr4+ZsTFTxA100q4v8OTb0CnsxceNBDmYLrsWcKkMFtMu3 JBFGknbjpSbKj68U=
X-Received: by 10.31.65.197 with SMTP id o188mr8275707vka.7.1496605796649; Sun, 04 Jun 2017 12:49:56 -0700 (PDT)
X-Received: by 10.31.65.197 with SMTP id o188mr8275700vka.7.1496605796458; Sun, 04 Jun 2017 12:49:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.44.137 with HTTP; Sun, 4 Jun 2017 12:49:55 -0700 (PDT)
In-Reply-To: <20170604.162014.74657518.sthaug@nethelp.no>
References: <CAKD1Yr3yzGqH5LfbB09iO81Fjbym1=gb=hijskdUSiTZWKX18w@mail.gmail.com> <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> <CAKD1Yr0t_X2d__C8j9se21CVHUEXZzoQNM_xnJgZN170OtpEhw@mail.gmail.com> <20170604.162014.74657518.sthaug@nethelp.no>
From: David Farmer <farmer@umn.edu>
Date: Sun, 04 Jun 2017 14:49:55 -0500
Message-ID: <CAN-Dau2Y+UpKa3Em2B7euNn6j5cMBvZYXQzvi8khrY5qG00afw@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: "sthaug@nethelp.no" <sthaug@nethelp.no>
Cc: Lorenzo Colitti <lorenzo@google.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="001a114dde62ddf4e0055127b0ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/UosTC-L0bUyyILDKD3pwC44KBg4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Jun 2017 19:50:00 -0000

On Sun, Jun 4, 2017 at 9:20 AM, <sthaug@nethelp.no> wrote:

> > > So for example, here you are adamant that a device should not have to
> "ask
> > > the network" for more addresses. What about networks where there are
> other
> > > priorities, what if the operator of a network requires to track
> > > addresses/address usage for whatever reasons ?
> > >
> >
> > Again, the answers are in RFC 7934. See section 9.1 which goes into some
> > detail on address tracking. But basically: tracking via DHCP is insecure
> > unless you have L2 security, and if you have L2 security, you may as well
> > use that to track addresses.
>
> Tracking via DHCP is good enough in many cases, and already implemented
> in lots of support systems. L2 tracking has an extra cost. Guess which
> will be used?
>
> Steinar Haug, AS2116
>

On this point I have to agree with Lorenzo, tracking MAC addresses with
DHCP without the addition of L2 security to enforce it is pointless. What
about static assignment of addresses, without L2 security there would be no
way to prevent it.

We scrape Neighbor Discovery tables out of routers just like we do for ARP
tables in IPv4. It is independent of how the addresses are assigned, it
works with static assignment, DHCP, SLACC, and what ever else comes along.
The whole point of address tracking is accountability, having
accountability only for the people that follow a rule, what ever it is, is
kind of pointless, you need to track the rule breakers too.  Therefore you
need a tracking solution that is independent of address assignment.

Since we can track any address used, in most parts of our network we allow
SLACC for IPv6 address assignment, because it's the easiest to use in most
cases. That said I still think DHCP is a perfectly valid mechanism for
address assignment as well.

Thanks.
-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================