Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157

John Mann <john.mann@monash.edu> Wed, 26 September 2012 23:23 UTC

Return-Path: <john.mann@monash.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFAA21F84FC for <v6ops@ietfa.amsl.com>; Wed, 26 Sep 2012 16:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level:
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPKJyRGwcQ7w for <v6ops@ietfa.amsl.com>; Wed, 26 Sep 2012 16:23:54 -0700 (PDT)
Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 91CCA21F84DC for <v6ops@ietf.org>; Wed, 26 Sep 2012 16:23:53 -0700 (PDT)
Received: from mail-ee0-f44.google.com ([74.125.83.44]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUGOOiYQUK6mec/9Liykh54SkBZAgTCGG@postini.com; Wed, 26 Sep 2012 16:23:53 PDT
Received: by eekd4 with SMTP id d4so649223eek.31 for <v6ops@ietf.org>; Wed, 26 Sep 2012 16:23:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=b9bqOCXwU3fgG4EhQeAJEtceuRMwfL+pRQbIXb86F1I=; b=fiEag4x6crh3kMr8FGlVfbAtaW/rDPK4Xe31aZjaF8WNFYUgGSU9ZMTzllxnvfGGG3 YRwDC1V2SrT5JC8XynsxxBTo4t7e+Q2wcqpz2dFujGDFNtEJYRP5qrDMBayrKTkUGv9P 9DnNZ5PzREw1bjju0gh/z3MajEtA23hL13VnbqEY74SAwSfsp5tPiWP/E9ssa0XPS531 tyy513NBiV3HjSlcaZk5lFh+0BBgmy2T4V7DZKns24zcMrNyiKBoVTJWy4n3IBN1hba5 LsRRUMSTGvqdr/tOuDP5nxDhT195/XfCnk3tKgdr4k8LLYzTVNWEwU+ioOgdN1DUjNHh B+Tg==
Received: by 10.14.215.69 with SMTP id d45mr3634778eep.16.1348701831742; Wed, 26 Sep 2012 16:23:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.96.72 with HTTP; Wed, 26 Sep 2012 16:23:31 -0700 (PDT)
In-Reply-To: <20120926222745.GA31684@hub.kern.lc>
References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local> <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local> <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> <20120926222745.GA31684@hub.kern.lc>
From: John Mann <john.mann@monash.edu>
Date: Thu, 27 Sep 2012 09:23:31 +1000
Message-ID: <CA+OBy1OXGGk=F0j+C+kKG4cbpMCQS+g+wdbmJ28YuTtTkn4wcg@mail.gmail.com>
To: Philipp Kern <phil@philkern.de>
Content-Type: multipart/alternative; boundary=047d7b621f5496c69304caa31d7d
X-Gm-Message-State: ALoCoQngjHwLOS8Gfl9MwbP+rHcX07qebTEpzIlS6uT+QBf9jRu5+R3v3KTB8b6OBC0KqkNIxBI5
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2012 23:23:54 -0000

Hi,

On 27 September 2012 08:27, Philipp Kern <phil@philkern.de>; wrote:

> On Wed, Sep 26, 2012 at 09:16:12AM +0200, Marksteiner, Stefan wrote:
> > There's a variety of reasons to keep track of addresses from usage and
> > statistics to forensic purposes in security incidents (also those which
> are
> > perpetrated from inside sources to outside targets).
>
> Wouldn't it be better to track the tables of your switches and routers
> (possibly with port info) instead? Because everybody can infer the subnet
> from
> one stateful DHCPv6 reply and just use another address. Well, unless your
> hardware can already do DHCPv6 snooping at the edge, which seems to be
> sort of
> rare.
>

I'm trying
a) to track which addresses are used by which hosts for forensics and
Internet authentication, and
b) allow for some basic network-level filtering (e.g. only allow those PCs
to ssh into this host)

Currently PCs get
1) MAC-based SLAAC addresses
2) a new Privacy IPv6 addresses every day -- that lasts for n days

There is no global event (like DHCPv4 traffic or RADIUS 802.1x) that
signifies when a new SLAAC or privacy address starts or stops being used.

Polling all routers for IPv6 neighbour tables (e.g. every hour) is
certainly possible, but it leads to lots of data.
It helps to do a FF02::1 multicast ping out each Vlan to refresh the tables
first, but many PCs have firewalls that drop all pings ...
If a PC is using a Privacy address for outbound communication, do you ever
see the MAC-based address?

As a test, I ran a ISC dhcpd to do stateful DHCPv6 address assignment to
get some sticky-ness to the IPv6 address used by a PC when connected to a
particular Vlan, and
3) the test PCs got an *extra* DHCPv6-assigned IPv6 address
But the PCs still preferred Privacy addresses for new outbound connections!!

To get PCs to use DHCPv6-assigned addresses instead of Privacy addresses,
do I need to change the RAs to disable all use of SLACC addresses
and then risk breaking IPv6 for any devices that don't support DHCPv6??

I'm at a University and have no control over the mixed BYOD fleet, just
over the network and DHCPv* servers.

Thanks,
    John