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
I might experiment with working around some of these issues by using RFC
3203 and RFC 6704 (forcerenew with nonce authentication, which is
reportedly implemented by dhcpcd). If you have experience with this
subprotocol, please drop me a note.
The problem is we can't rely on it since it is
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.
The problem is we can't rely on it since it is not widely supported by
clients.
Chicken and egg. If you put it in hnetd, the clients will come.
Well, the thing is. Homenet is not really chartered for host changes and
many believe that IPv4 support is sort of deprecated anyway.
Yes there
When a Homenet router was previously acting as DHCPv4 server for
a link, and subsequently loses an election, should it:
1. remain silent;
2. remain silent in response to DHCPDISCOVER, but NAK any DHCPREQUEST; or
3. NAK both DHCPDISCOVER and DHCPREQUEST?
I think that #2 is probably correct
I've just reread the current HNCP draft (version of 17 August, 10:51), and
I have almost no nits. If anyone is interested, I've written up a few
notes about shncpd's compliance on
http://www.pps.univ-paris-diderot.fr/~jch/software/homenet/shncpd.html
This needs to be completed with DNCP and
Am 17.08.2015 um 12:23 schrieb Juliusz Chroboczek:
When a Homenet router was previously acting as DHCPv4 server for
a link, and subsequently loses an election, should it:
1. remain silent;
2. remain silent in response to DHCPDISCOVER, but NAK any DHCPREQUEST; or
3. NAK both DHCPDISCOVER
On 17.8.2015, at 9.57, Toerless Eckert eck...@cisco.com 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
2. remain silent in response to DHCPDISCOVER, but NAK any DHCPREQUEST; or
I think that #2 is probably correct, but I have two questions.
By the way, if some Wise Person were kind enough to check my DHCPv4
server for compliance, I'd be very grateful. The code is here:
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
If I'm reading this correctly, you're saying that a Homenet router SHOULD
implement stateless DHCPv6. That seems like a somewhat arbitrary
requirement -- could you please explain the rationale?
I think we discussed this already:
Am 17.08.2015 um 13:37 schrieb Juliusz Chroboczek:
I've just reread the current HNCP draft (version of 17 August, 10:51), and
I have almost no nits. If anyone is interested, I've written up a few
notes about shncpd's compliance on
Thanks.
Minor nits:
Section 6.5: MUST NOT for ULA if
On Mon, 17 Aug 2015, Steven Barth wrote:
At first glance all 3 behaviors seem sensible, while 2 and 3 look more
preferable.
However I do not particularly remember all the implications. In any case I'm
thinking of adding Routers which seize to be elected DHCP
servers SHOULD - when
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
Hi Fred,
a few comments:
A host receives on-link prefixes in a Router Advertisement [...] to identify
preference order among them
Is there really a preference order? Also I think off-link prefixes are
similarly usable for address assignment
or DHCPv6, they are simply not on-link.
apart from
Michael Richardson mcr+i...@sandelman.ca wrote:
1) if the v4 prefix on the link is renumbered because a different router
won the election, then the existing router may still have connectivity,
and may still be willing to route packets.
(b) - there may be static IPs assigned,
The old prefix is no longer announced over the routing protocol, so the
old addresses are unreachable now. (Or are you suggesting that we
That's not entirely true. Nodes on the same link (such as 99% of current
home setups) don't need the routing protocol to reach things.
It doesn't matter
Steven Barth cy...@openwrt.org wrote:
thinking of adding Routers which seize to be elected DHCP
s/seize/cease/
??
Of course. Looks like my English is still in vacation mode ;)
___
homenet mailing list
homenet@ietf.org
1) if the v4 prefix on the link is renumbered because a different router
won the election, then the existing router may still have connectivity,
and may still be willing to route packets.
The old prefix is no longer announced over the routing protocol, so the
old addresses are
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote:
1. remain silent;
2. remain silent in response to DHCPDISCOVER, but NAK any DHCPREQUEST;
or
3. NAK both DHCPDISCOVER and DHCPREQUEST?
I think that #2 is probably correct
Thanks. What after a renumbering event
Steven Barth cy...@openwrt.org wrote:
thinking of adding Routers which seize to be elected DHCP
s/seize/cease/
??
--
Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
Hnetd announces host routes to each of the router's interfaces over Babel.
Shncpd doesn't, it only announces the attached prefixes.
Who is right?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
Hnetd announces host routes to each of the router's interfaces over Babel.
Shncpd doesn't, it only announces the attached prefixes.
Who is right?
-- Juliusz
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
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
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
On 17.8.2015, at 9.22, Toerless Eckert eck...@cisco.com 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:
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)
homenet-boun...@ietf.org on behalf of eck...@cisco.com wrote:
On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg
27 matches
Mail list logo
