From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 17C853B2A4 for ; Tue, 23 Oct 2018 12:12:30 -0400 (EDT) Received: from dancer.taht.net (unknown [IPv6:2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 7CC97213CB; Tue, 23 Oct 2018 16:12:28 +0000 (UTC) From: Dave Taht To: Mikael Abrahamsson Cc: Dave Taht , Ted Lemon , cerowrt-devel@lists.bufferbloat.net References: <10E89375-2591-49B2-9A67-AA0E14B17649@fugue.com> Date: Tue, 23 Oct 2018 09:12:16 -0700 In-Reply-To: (Mikael Abrahamsson's message of "Tue, 23 Oct 2018 17:47:03 +0200 (CEST)") Message-ID: <87ftwwy74v.fsf@taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cerowrt-devel] meanwhile... .home, finally has a home.arpa. X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 16:12:30 -0000 Mikael Abrahamsson writes: > On Tue, 23 Oct 2018, Dave Taht wrote: > >> Mikael is the sole survivor here, so far as I know. > > I ended up disabling the homenet stuff because lifetimes didn't align > with my preference in provider (my non-preferred provider has longer > lease-times than my preferred provider, so in the whole > source-selection mechanism my non-preferred provider won). Also, there > is no good way to detect L2 failures towards providers. > > https://tools.ietf.org/html/draft-patterson-intarea-ipoe-health-05 solves. I just ping6 my upstream dns server, roughly the same algorithm. But if it goes down, you don't want to take away the local ipv6 addresses, just the default route, and when you do that, you end up falling back to ipv4. which also needs that ping. >> As examples that persist, dhcpv6-pd renewals seem to be broken in >> openwrt still, so I get a bunch of prefixes... and a few a days >> later they vanish. I get static routes to nowhere, often, out of >> that. And: with only a /60 available, I also run out of prefixes to >> allocate if something reboots at the wrong time at the wrong place, >> and so on. > > I do not have this problem. I get /56 PD from provider and it hasn't > changed yet. (this is a case where I'm using dhcpv6-pd internally to get prefixes. Just one hop to comcast seems to work) You probably live in a place with reliable power. I get a power flicker at least once a week. the corest routers are on battery backup but that only lasts a few hours and the last big outage was about 9 hours about 6 weeks ago. When everything reboots, chaos reigns. When only some things reboot, different kinds of chaos reign. I am glad to see some standardized support for naming happen, but even then, names have to expire, somehow also. Secondly a usable set of /56s would be "enough" in my case (about 40 boxes), /60 doesn't divide into that. thirdly, I don't want to assign routable ipv6 prefixes to everything, just to end-user APs and when I last tried hnpd it wanted to give even my p2p boxes /64s fourthly, we have dnsmasq, odhcpd, odhcpc, babel and hnetd all battling it out with slightly different notions of how to redistribute things. fifthly, I started running into babel trouble in my original deployment when I ended up exporting, oh, 13? 11? prefixes and IPs per router by default. (and had 80 routers at the time) I have a bunch of "fixes" for babel on github of varying utility, but what mostly worked was to aggressively filter each "area" down to just the few routes that were needed - and then getting those filters right, through hnetd, was essentially impossible. These days I try to keep each area at one packet total for updates. I know my use case is "special" compared to the desired needs of homenet. The prefix allocation mechanism I need here is basically an authenticated request from many (ipv4 or ipv6 link local) hops deep into the network, which... I used to do with an itty bitty shell script over ssh, until I gave up for these other reasons. static, permanent, real ipv6 to your edge is better, then you can do whatever you want, however you want, do it once, and never do it again. I've come to rather appreciate NAT for what it does to separate my policies from my ISP's.