Subject: [homenet] HNCP: avoiding renumbering

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 16 Aug 2015 13:40:43 +0200

When an HNCP router is restarted, the prefixes it allocated to a link are
"adopted" by neighbouring routers; if the router then restarts, it will
agree to the prefixes advertised by its neighbours, which avoids
renumbering.

Unfortunately, this only applies to link with multiple HNCP routers: on
a stub link, a random prefix will be chosen every time we are restarted,
since there are no neighbours that can maintain the state for us.  I can
see the following solutions:

  1. store the chosen prefix in stable storage (but stable storage sucks);

  2. make an initial choice that is a hash of the interfaces MAC address
     (I believe that this is what hnetd does);

  3. snoop ND/ARP traffic and intuit a suitable prefix.

Any better ideas?

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 16 Aug 2015 16:01:23 +0300

> On 16.8.2015, at 14.40, Juliusz Chroboczek <[email-masked]> wrote:

hnetd does 1+2 (although not sure if OpenWrt version stores 1 to ramdisk currently or not at all by default, cough). 

>  3. snoop ND/ARP traffic and intuit a suitable prefix.

This may be tricky, at least in case of pure v6, as the ND target will be probably link-local address? I guess given multiple nodes on the link, ND would be enough, but I suspect for this to be generic in case of v6 you would have to snoop ‘everything’ and assume first assigned prefix source address that is not published by anyone else within HNCP is one that actually was on the link.

With v4, ARP snooping is probably enough to determine the old prefix.

Cheers,

-Markus

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Aug 2015 08:32:57 +1200

>> agree to the prefixes advertised by its neighbours, which avoids

Why do we care? Homenets need to be renumbering-proof anyway, because the ISP
might change the prefix anytime.

(We could contrive to have a stable ULA prefix, of course, but that only
affects in-home communications.)

    Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2015 01:01:51 +0200

>>> which avoids renumbering.

> Why do we care? Homenets need to be renumbering-proof anyway, because
> the ISP might change the prefix anytime.

You're right, that deserves clarifying.  We're trying really hard to make
sure that in no circumstances is running a Homenet router worse than
running an ordinary NAT/DHCPv6-PD router.  Consider the following trivial
topology:

    ISP ---- Homenet router ---- stub link

We'd like to ensure that:

  - the NATed IPv4 prefix assigned to the stub link remains stable;
  - if the /56 delegated by the ISP is stable, then the global /64
    assigned to the stub link remains stable;
  - if the Homenet router is announcing a ULA, then the ULA /64 assigned
  - to the stub link remains stable.

In short, we'd like any prefix assignments performed by the Homenet router
to survive a reboot, even in the absence of either explicit configuration
or stable storage.

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Aug 2015 12:58:42 +1200

> to survive a reboot, even in the absence of either explicit configuration

That may be desirable, but must not be depended on. The homenet architecture
is explicit on pp 25-26 that renumbering is an expected event:
https://tools.ietf.org/html/rfc7368#page-26
The addressing, routing and naming architecture has to be ready for
renumbering at any time. Anything else is broken.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Aug 2015 13:01:04 +1200

> to survive a reboot, even in the absence of either explicit configuration

That may be desirable to limit churn, but must not be depended on. The
architecture is explicit on pp 25-26 that renumbering is an expected event:
https://tools.ietf.org/html/rfc7368#page-25
The addressing, routing and naming architecture has to be ready for
renumbering at any time. Anything else is broken.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 16 Aug 2015 23:22:20 -0700

> renumbering at any time. Anything else is broken.

What analysis is there about application and API level problems in supprting
this model today ? My gut feeling is that a lot of applications or
even APIs like bind(::) may have problems, but thats just because i am paranoid.

Cheers
    Toerless

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 17 Aug 2015 09:41:24 +0300

> even APIs like bind(::) may have problems, but thats just because i am paranoid.

Just like in some other old workplace, cough, ’if it does not work without IPsec, do not expect it to work with it’.

That is, if single-router home experiences power outage, outcome is rather catastrophic renumbering event (and loss of NAT state).

I do not expect homenet stuff to do much better here, unless we want to make it crazily complicated.

Normal, graceful renumberings are a part of IPv6 and should work equally well given single 7084 router and homenet router network. IPv4 ‘renumbering’ will be bit less graceful no matter what, I am afraid, but that’s outside the architecture RFC mandate anyway and done just as a public service.

Cheers,

-Markus

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 16 Aug 2015 23:57:07 -0700

On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote:
> Just like in some other old workplace, cough, ???if it does not work without IPsec, do not expect it to work with it???.

Should i even try to understand that reference  ? ;-)

> Normal, graceful renumberings are a part of IPv6 and should work equally well given single 7084 router and homenet router network. IPv4 ???renumbering??? will be bit less graceful no matter what, I am afraid, but that???s outside the architecture RFC mandate anyway and done just as a public service.

I don't know why Juliusz called stable storage bad. I think it's great.
Where would i be without stable storage for my routers software, policy
configuration, passwords, logs and the like. Why should it be bad to
memorize addressing ? I think it's mandatory for IPv4, and for IPv6,
i'd love to have some option to either re-number when i click - to weed
out bad apps/OS problems - or a switch for persistency of addresses
(one to improve reality, one to live with it).

Cheers
    Toerless

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 17 Aug 2015 08:34:07 +0000

I think that Brian has summarized this renumbering avoidance as "desirable
but nothing to be depended on"

-éric

On 17/08/15 08:57, "homenet on behalf of Toerless Eckert (eckert)"
<[email-masked] on behalf of [email-masked]> wrote:

>> Just like in some other old workplace, cough, ???if it does not work
>>without IPsec, do not expect it to work with it???.
>
>> Normal, graceful renumberings are a part of IPv6 and should work
>>equally well given single 7084 router and homenet router network. IPv4
>>???renumbering??? will be bit less graceful no matter what, I am afraid,
>>but that???s outside the architecture RFC mandate anyway and done just
>>as a public service.
>
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Gert Doering <[email-masked]>
Date: Mon, 17 Aug 2015 11:02:32 +0200

Hi,

On Sun, Aug 16, 2015 at 11:57:07PM -0700, Toerless Eckert wrote:
> I don't know why Juliusz called stable storage bad. 

I'd assume it has to do with flash write cycles on $30 routers...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 17 Aug 2015 11:10:44 +0300

> Should i even try to understand that reference  ? ;-)

Probably not :)

> (one to improve reality, one to live with it).

I also think that stable storage is the sane default. However, the problems are combination of:

- cheap router vendors

- bad software

that kill stable storage by writing it to too much. E.g. Typical cheap home router does not have NVRAM to store this stuff in, but instead normal flash with limited rewrite count is used. If the software is bad, the flash dies fast due to running out of write cycles.

Cheers,

-Markus

---

From: Dave Taht <[email-masked]>
Date: Mon, 17 Aug 2015 12:00:50 +0200

> (one to improve reality, one to live with it).

Stable storage for conf info yes. Logging, or other excessive writes
to flash are generally a bad idea in embedded gear.

Traditionally openwrt writes to flash once or twice on boot (time,
only, I think), and then maybe once every 24 hours. All logging is
kept in a ring buffer in ram or sent to a log server. This is for very
good practical reasons (running out or wearing out flash is bad), that
are increasingly historical as flash sizes and life have grown.

How often will hncpd write to flash?

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2015 12:14:10 +0200

> I don't know why Juliusz called stable storage bad.

Ideology.

Soft state good, hard state bad.  A network protocol should be able to
recover all the data it needs just by consulting its neighbours.  If it
needs stable storage to function, then it's a failed design.

Yeah, I know, I'm a fanatic.

> configuration, passwords, logs and the like.

That's okay, static configuration data is not protocol state.

-- Juliusz

---

From: <[email-masked]>
Date: Mon, 17 Aug 2015 13:19:02 +0200

Hi,

+1. 

a) Any idea how often this data changes and really needs a re-write in "a typical home" ;-) ?
b) Impact of 

MS>- cheap router vendors
MS>
MS>- bad software

may depend on choice of flash file system, and how countermeasures against "flash wear" are considered by the file system software authors.

BR, 

Normen

-----Ursprüngliche Nachricht-----
Von: Markus Stenberg [mailto:[email-masked]] 
Gesendet: Montag, 17. August 2015 10:11
An: Toerless Eckert
Cc: [email-masked]; Juliusz Chroboczek
Betreff: Re: [homenet] HNCP: avoiding renumbering

Probably not :)

- cheap router vendors

- bad software

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 17 Aug 2015 17:47:53 +0300

On 17.8.2015, at 14.19, [email-masked] wrote:
> Hi,
> 
> +1. 
> 
> a) Any idea how often this data changes and really needs a re-write in “a typical home" ;-) ?

Not very often, at least if you don’t bother to prune ‘old’ stuff much (it depends a bit, but most conservative setup would have some sort of per-interface offset value it would _only_ store when a) it changes (due to conflict),b) local set of interfaces grows, or c) local set of clients grows if you want to offer them persistent leases which I consider a bad idea). But again, this is assuming clever software. Stupid software could do write per client DHCP/DHCPv6-stateful request (or per prefix assignment action) :-)

> may depend on choice of flash file system, and how countermeasures against “flash wear" are considered by the file system software authors.

Sure. But I know for a fact some consumer devices (not routers though that I know of, nowadays at least) using FAT(/FAT32) on a flash disk, and that is just a sign of ’shoot me in the head, please..’ ;) Then you’re relying on lower layers (=flash controller) doing the smart thing. And so on. Ultimately, counting on anything is counterproductive, and making design as simple as possible is appealing.

Cheers,

-Markus

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Aug 2015 11:15:25 +1200

> but nothing to be depended on"

Exactly. Apps that can't survive renumbering should be regarded as
broken (they are already broken today when roaming, so this is
nothing new).

We explicitly excluded home networks from the 6renum WG and its
documents [RFC 6866, 6879, 7010], because we assumed that for such
networks, renumbering was already a given.

   Brian