Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)
Fernando Gont <fgont@si6networks.com> Wed, 22 January 2014 20:49 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E01E1A0214; Wed, 22 Jan 2014 12:49:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 sqPijgsYoKx4; Wed, 22 Jan 2014 12:49:48 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E2A261A0158; Wed, 22 Jan 2014 12:49:47 -0800 (PST)
Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1W64k5-0000rP-3F; Wed, 22 Jan 2014 21:49:45 +0100
Message-ID: <52E02EAD.1050009@si6networks.com>
Date: Wed, 22 Jan 2014 17:48:45 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Brian Haberman <brian@innovationslab.net>, The IESG <iesg@ietf.org>
Subject: Re: Brian Haberman's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS)
References: <20140122202434.30069.4084.idtracker@ietfa.amsl.com>
In-Reply-To: <20140122202434.30069.4084.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 22 Jan 2014 20:49:49 -0000
On 01/22/2014 05:24 PM, Brian Haberman wrote: > > I am taking the somewhat curious route of raising a DISCUSS on a document > that I am shepherding. I will return to a Yes when these issues are > resolved. Thomas Narten raised a good point that this document does not > mention the work published in RFCs 4436 and 6059 (from the concluded DNA > WG). Two of the points he raised are worth addressing in this document > prior to publication. > > 1. If you have stable storage (and many devices do), it makes sense to > just cache the addresses instead of > regenerating them. 1) Recording the addresses a node has visited during its lifetime would somehow be ironic for a document aiming at privacy. Just get the document compromised, and you get a list of where the node has been since it was first installed. 2) Recording the addresses seems like a waste of resources. How many networks you connect to only once in your lifetime? > DNA does this. Seems like that option should be > allowed. (the current document suggests saving the number of DAD > iterations in stable storage... why do that if you can just save the > address itself?) The current document allows that to happen for cases where you find a colission -- which would be close to nil, given that subnets are /64 and the IIDs are essentially random. That said, as an author, I don't expect implementations to record the dad counter ever, even in the presence of collisions. I'd argue that that paragraph is there with this rationale "if you're picky and you're going to argue that this spec doesn't guarantee a stable IID, you can do this if you want". > 2. DNA also has recommendations for detecting when you (re)connect to a > network you visited before. That is pretty much the same thing this spec > needs to do in order to generate the same addresses when connecting to a > previously visited network (i.e., the Network_ID paramater). For the > wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal > address pair of routers to identify a link. This document might suggest > doing the same thing. IMHO, using the linklayer/linklocal address of the router is not a good idea. Thing about a replaced NIC, or a backup router that kicks in in the event of failuer of the main one. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- Brian Haberman's Discuss on draft-ietf-6man-stabl… Brian Haberman
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Fernando Gont
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Brian Haberman
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Fernando Gont
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Stephen Farrell
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Brian Haberman
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Brian Haberman
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Stephen Farrell
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Fernando Gont
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Brian Haberman
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Fernando Gont
- Brian Haberman's Discuss on draft-ietf-6man-stabl… Brian Haberman
- Re: Brian Haberman's Discuss on draft-ietf-6man-s… Brian Haberman