[homenet] some comments on baker-homenet-prefix-assignment
Michael Richardson <mcr@sandelman.ca> Tue, 17 January 2012 01:29 UTC
Return-Path: <mcr@sandelman.ca>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E2921F85E4 for <homenet@ietfa.amsl.com>; Mon, 16 Jan 2012 17:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.011
X-Spam-Level:
X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, SARE_MONEYTERMS=0.681]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qos8RygbXr6v for <homenet@ietfa.amsl.com>; Mon, 16 Jan 2012 17:29:10 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id CEAB921F85AA for <homenet@ietf.org>; Mon, 16 Jan 2012 17:29:10 -0800 (PST)
Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id C3CBE3446F for <homenet@ietf.org>; Mon, 16 Jan 2012 20:27:07 -0500 (EST)
Received: by marajade.sandelman.ca (Postfix, from userid 179) id 739809845D; Mon, 16 Jan 2012 20:29:08 -0500 (EST)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 6ED0A98147 for <homenet@ietf.org>; Mon, 16 Jan 2012 20:29:08 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: homenet@ietf.org
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 16 Jan 2012 20:29:08 -0500
Message-ID: <9482.1326763748@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: [homenet] some comments on baker-homenet-prefix-assignment
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2012 01:29:11 -0000
I finally read draft-baker-homenet-prefix-assignment on my way home on Friday. This mechanism is that I had expected that we would use. I agree that draft-arkko-homenet-prefix-assignment-01 might take fewer messages and less code. I had a few minor comments which are appended below, but I had two general questions. First, I think that the RAAI option first describe in section 3.1.1 is a new creation; certainly by the IANA considerations, that is clear, but at first I thought maybe that this was yet-another-RA-option I did not know about... Section 5 gives the abstract for what I think is a new option. Should this concept go forward, I suggest that the name of this option go into the title of the document, as in: Using the Router Advertisement Allocator Information (RAAI) for subnet allocation in Home Networks. Second, the process by which the two routers in section 3.1.2.2 hear each other and release the prefix was a bit startling! It wasn't until the last paragraph of 4.3 that some addition to the algorithm is mentioned. minor comments: 1. To avoid duplicate address assignment, a router first listens for RAs on the link attached to its downstream interface. If the router does not receive an RA after listening for INTERVAL1 microfortnights, the Assuming that my calculation is correct, and microfortnights are approximately 1.2s, my feeling is that this dead time should be on the order of 16 microfortnights (20s). I base this number upon the time it would take me to replace my home router back on the shelf after rebooting it, then walk back to the kitchen table, and check to see if my laptop got an address. Another 10s later, I'm back at the router to wonder if it really rebooted again. 2. why doesn't a router send a RS on the link first? Given multiple ISPs, it may be entirely reasonable that the interface is in fact downstream for another prefix, and an upstream interface for another, so the RS isn't even wasted. 3. a link would seem to be unclaimed if (a/one or more) RS is heard on the link, and no RA is later heard. As I recall, RAs in response to RS may be unicast, but, why can't the router in question send it's own RS to verify connectivity. Here is where the zOSPFv3 method may be more productive. 4. It seems that an ISP might well return a RAAI to a client machine, and if it did so, it could allocate as many or as few /64s as each customer needs, at the cost for it, of additional routing entries. I realize that this might be undesireable from an architectural point of view, but I can see occuring in some informal multi-tenant situations, where the "building" starts initially as a single tenant, and grows. As such, it may be useful to put a flag in the RAAI that says, "I am a security boundary". -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE> then sign the petition.
- [homenet] some comments on baker-homenet-prefix-a… Michael Richardson