From: Dave Taht <dave@taht.net>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: Dave Taht <dave.taht@gmail.com>, Ted Lemon <mellon@fugue.com>,
cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] meanwhile... .home, finally has a home.arpa.
Date: Tue, 23 Oct 2018 09:12:16 -0700 [thread overview]
Message-ID: <87ftwwy74v.fsf@taht.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1810231744390.26856@uplift.swm.pp.se> (Mikael Abrahamsson's message of "Tue, 23 Oct 2018 17:47:03 +0200 (CEST)")
Mikael Abrahamsson <swmike@swm.pp.se> 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.
next prev parent reply other threads:[~2018-10-23 16:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-23 3:51 Dave Taht
2018-10-23 4:13 ` Ted Lemon
2018-10-23 15:09 ` Dave Taht
2018-10-23 15:42 ` Ted Lemon
2018-10-23 16:15 ` Dave Taht
2018-10-23 16:44 ` Ted Lemon
2018-10-23 15:47 ` Mikael Abrahamsson
2018-10-23 16:12 ` Dave Taht [this message]
2018-10-24 8:22 ` Mikael Abrahamsson
2018-10-24 16:39 ` Dave Taht
2018-10-24 18:04 ` Mikael Abrahamsson
2018-10-23 23:28 ` Michael Richardson
2018-10-23 23:38 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ftwwy74v.fsf@taht.net \
--to=dave@taht.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=mellon@fugue.com \
--cc=swmike@swm.pp.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox