Re: [homenet] HNCP: avoiding renumbering
On 17/08/2015 20:34, Eric Vyncke (evyncke) wrote: > I think that Brian has summarized this renumbering avoidance as "desirable > 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 > > -éric > > > On 17/08/15 08:57, "homenet on behalf of Toerless Eckert (eckert)" > wrote: > >> 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 ? ;-) >> >>> 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. >> >> 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 >> >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On 17.8.2015, at 14.19, normen.kowalew...@telekom.de 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) :-) > 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
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:markus.stenb...@iki.fi] Gesendet: Montag, 17. August 2015 10:11 An: Toerless Eckert Cc: homenet@ietf.org; Juliusz Chroboczek Betreff: Re: [homenet] HNCP: avoiding renumbering On 17.8.2015, at 9.57, Toerless Eckert wrote: > 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 ? ;-) Probably not :) >> 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. > 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). 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
> 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. > Where would i be without stable storage for my routers software, policy > configuration, passwords, logs and the like. That's okay, static configuration data is not protocol state. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On Sun, Aug 16, 2015 at 11:57 PM, Toerless Eckert wrote: > 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 ? ;-) > >> 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. > > 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). 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? > Cheers > Toerless > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On 17.8.2015, at 9.57, Toerless Eckert wrote: > 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 ? ;-) Probably not :) >> 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. > 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). 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
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 AGVorstand: 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
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)" wrote: >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 ? ;-) > >> 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. > >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 > >___ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
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 ? ;-) > 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On 17.8.2015, at 9.22, Toerless Eckert wrote: > On Mon, Aug 17, 2015 at 01:01:04PM +1200, Brian E Carpenter wrote: >> 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. > 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On Mon, Aug 17, 2015 at 01:01:04PM +1200, Brian E Carpenter wrote: > 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On 17/08/2015 11:01, Juliusz Chroboczek wrote: 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
On 17/08/2015 11:01, Juliusz Chroboczek wrote: 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
>>> 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
n 17/08/2015 01:01, Markus Stenberg wrote: > >> On 16.8.2015, at 14.40, Juliusz Chroboczek >> wrote: >> 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP: avoiding renumbering
> On 16.8.2015, at 14.40, Juliusz Chroboczek > wrote: > 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); 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] HNCP: avoiding renumbering
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
