IETF Logo Mail Archive

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

sthaug@nethelp.no Sun, 04 June 2017 14:20 UTC

Return-Path: <sthaug@nethelp.no>
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 CE81F129B38 for <ipv6@ietfa.amsl.com>; Sun, 4 Jun 2017 07:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 tOLYmX8SZU8X for <ipv6@ietfa.amsl.com>; Sun, 4 Jun 2017 07:20:16 -0700 (PDT)
Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1820A129B33 for <ipv6@ietf.org>; Sun, 4 Jun 2017 07:20:16 -0700 (PDT)
Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id A8355E6067; Sun, 4 Jun 2017 16:20:14 +0200 (CEST)
Date: Sun, 04 Jun 2017 16:20:14 +0200
Message-Id: <20170604.162014.74657518.sthaug@nethelp.no>
To: lorenzo@google.com
Cc: linux@thehobsons.co.uk, ipv6@ietf.org
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
From: sthaug@nethelp.no
In-Reply-To: <CAKD1Yr0t_X2d__C8j9se21CVHUEXZzoQNM_xnJgZN170OtpEhw@mail.gmail.com>
References: <CAKD1Yr3yzGqH5LfbB09iO81Fjbym1=gb=hijskdUSiTZWKX18w@mail.gmail.com> <1BE6C6B8-425A-47DC-AF10-506A52A2DA06@thehobsons.co.uk> <CAKD1Yr0t_X2d__C8j9se21CVHUEXZzoQNM_xnJgZN170OtpEhw@mail.gmail.com>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YoZ3WYqkVBTk8vnQkJCZZXJIvsI>
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 14:20:18 -0000

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

v2.23.0 | Report a Bug | By Email