[v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01

joel jaeggli <joelja@bogus.com> Wed, 14 November 2012 06:49 UTC

Return-Path: <joelja@bogus.com>
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 8E79221F8475; Tue, 13 Nov 2012 22:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level:
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 z3xabzp+V4cU; Tue, 13 Nov 2012 22:49:35 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC2AF21F87A6; Tue, 13 Nov 2012 22:49:34 -0800 (PST)
Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAE6nUbG049549 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 14 Nov 2012 06:49:32 GMT (envelope-from joelja@bogus.com)
Message-ID: <50A33EFA.7070008@bogus.com>
Date: Tue, 13 Nov 2012 22:49:30 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: draft-ietf-dhc-addr-registration@tools.ietf.org, IPv6 Ops WG <v6ops@ietf.org>, dhcwg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 14 Nov 2012 06:49:32 +0000 (UTC)
Subject: [v6ops] some feedback on http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01
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, 14 Nov 2012 06:49:35 -0000

I took a look at this draft since it was also presented in v6ops...

http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01

There's a couple issues that are quite striking. I kind of concur with 
Fred  Baker that the most appropiate method for tracking l2/l3 binding 
for address identification is probably more akin to syslog.

That is, since you don't really trust the hosts, having a switch/router, 
simply sysloging all new NDP cache entries pretty much achives the same 
thing execept with a lot less signaling.

If a strong assertion of L2 identity in support of l2/l3 bindings is 
required 802.1x or the wireless equivalanet seems appropiate, e.g. it's 
what we do today.

Availing oneself of a dhcp/ra option entails a lot of signaling for what 
is likely a relatively ephemeral port (windows machines and macs 
registering privacy addresses for example). specifiying a binding 
lifetime seems of limited utility since the host will probably discard 
the address long before the lifetime expires if it's sufficently long 
enough to allow for long lived connections using that address.