Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt
A host SHOULD select a default gateway for each prefix it uses to obtain one of its own addresses. That router SHOULD be one of the routers advertising the prefix in its RA. As a result of doing so, when a host emits a datagram using a source address in one of those prefixes and has no history directing it otherwise, it SHOULD send it to the indicated default gateway. The question is to which one (if there are multiple): this might be important for e.g. fail-over cases or if you want to dynamically optimize away that extra hop you mention. yes, that text should be changed to accommodate multiple default routers. ref rfc4311. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
How do Homenet routers configure NTP? Just use the pool? Either use the pool or use one from an SNTP DHCP option an edge router received from an ISP and published in HNCP. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
How do Homenet routers configure NTP? Just use the pool? Either use the pool or use one from an SNTP DHCP option an edge router received from an ISP and published in HNCP. +1 Default (e.g., in open source implementations) should be to use the pool, in the absence of DHCP option info. Router manufacturers / ISPs may choose to default their routers to other NTP servers. RFC 7084 recommends support for NTP option. If NTP is supported, the router is required to request the DHCPv6 option and use that, if it gets a response. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] NTP in Homenet?
How do Homenet routers configure NTP? Just use the pool? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
Hi, would be nice to have a NTP daemon on every Homenet router... gateways pull their time from the uplink, every other router pulls time from the gateway routers. Henning Rogge On Tue, Aug 18, 2015 at 2:34 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: How do Homenet routers configure NTP? Just use the pool? ___ 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] NTP in Homenet?
On Tuesday, August 18, 2015, Henning Rogge hro...@gmail.com wrote: Hi, would be nice to have a NTP daemon on every Homenet router... gateways pull their time from the uplink, every other router pulls time from the gateway routers. Henning Rogge On Tue, Aug 18, 2015 at 2:34 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr javascript:_e(%7B%7D,'cvml','j...@pps.univ-paris-diderot.fr'); wrote: How do Homenet routers configure NTP? Just use the pool? ___ homenet mailing list homenet@ietf.org javascript:_e(%7B%7D,'cvml','homenet@ietf.org'); https://www.ietf.org/mailman/listinfo/homenet I'd rather not have yet another service to exploit running on the gateway. Gateways have historically horrible security records and ntp exploits have nearly crushed the internet in the last few years. CB ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP and connected interfaces
On Aug 18, 2015, at 10:45, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Section 6.1 says: A node MUST be able to detect whether two of its local internal interfaces are connected, e.g., by detecting an identical remote interface being part of the Common Links of both local interfaces. Seems like this could be improved by rephrasing it to the effect that a node with multiple interfaces on the same common link MUST NOT advertise inconsistent information among them. That's too weak -- it also needs to take care to perform prefix assignment only once (although it will probably want to perform address assignment on both interfaces, especially if they're in ad-hoc mode), to run only one instance of RA and DHCPv4, etc. I'd really like to see it spelled out. Doesn’t section 6.3.1 already spell that out? Set of Shared Links: […] When multiple interfaces are detected as belonging to the same Common Link, prefix assignment is disabled on all of these interfaces except one. —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP and connected interfaces
Section 6.1 says: A node MUST be able to detect whether two of its local internal interfaces are connected, e.g., by detecting an identical remote interface being part of the Common Links of both local interfaces. Seems like this could be improved by rephrasing it to the effect that a node with multiple interfaces on the same common link MUST NOT advertise inconsistent information among them. That's too weak -- it also needs to take care to perform prefix assignment only once (although it will probably want to perform address assignment on both interfaces, especially if they're in ad-hoc mode), to run only one instance of RA and DHCPv4, etc. I'd really like to see it spelled out. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Shncpd news
Over the last week, shncpd has learnt: - to participate in DHCPv4 election; - to announce delegated prefixes (over HNCP and the routing protocol); - to configure the local host; - to deal with ad-hoc and leaf interfaces. It's not quite compliant yet, but it's getting there. The known issues are described on http://www.pps.univ-paris-diderot.fr/~jch/software/homenet/shncpd.html It's only been tested with up to 3 nodes (in various topologies), so there probably are bugs left. Quick demo number 1: instant access-point: # set up IPv4 NAT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # set up routing babeld -C 'redistribute local deny' -C 'redistribute proto 43 allow' wlan0 # announce two prefixes and a name server over HNCP, RA and DHCPv4 shncpd -E 2001:db8:42::/48 -E 10.0.0.0/8 -N 8.8.8.8 wlan0 Quick demo number 2: configure the local host using HNCP rather than DHCP, and get roaming for free: # set up routing babeld -C 'redistribute local deny' -C 'redistribute proto 43 allow' wlan0 # run shncpd with no RA and no DCHPv4 but with a configuration script shncpd -D -R -s ./shncpd-script.sh wlan0 There's no support for assigning a stable prefix to loopback yet, so roaming will cause renumbering whenever we move to a link that already has a prefix assigned to it. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP and connected interfaces
On Aug 18, 2015, at 06:38, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Section 6.1 says: A node MUST be able to detect whether two of its local internal interfaces are connected, e.g., by detecting an identical remote interface being part of the Common Links of both local interfaces. What should the node do if it detects that two interfaces are on the same link? (Disable HNCP on one interface? Speak HNCP on both interfaces but disable prefix assignment? Something even more exciting?) Seems like this could be improved by rephrasing it to the effect that a node with multiple interfaces on the same common link MUST NOT advertise inconsistent information among them. —james ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP and connected interfaces
Am 18.08.2015 um 19:45 schrieb Juliusz Chroboczek: That's too weak -- it also needs to take care to perform prefix assignment only once (although it will probably want to perform address assignment on both interfaces, especially if they're in ad-hoc mode), to run only one instance of RA and DHCPv4, etc. I'd really like to see it spelled out. How about adding In this case the respective interfaces MUST be treated as belonging to a single shared Common Link.? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP and connected interfaces
James: Doesn’t section 6.3.1 already spell that out? Set of Shared Links: […] When multiple interfaces are detected as belonging to the same Common Link, prefix assignment is disabled on all of these interfaces except one. Steven: How about adding In this case the respective interfaces MUST be treated as belonging to a single shared Common Link.? Ah, I missed that. Steven, yes, this deserves a pointer. Is that really all there is to it? I run two instances of PA (but treating them as a single common link), two instances of RA, two instances of DHCPv4? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Open-Source PIM BIDIR (and more) implementation
On Tue, 18 Aug 2015, Juliusz Chroboczek wrote: (If you test this with Babel, you need to set reflect-kernel-metric true What does that do? [...] So it takes whatever metric it came up with and sets the metric as kernel priority? That's right. So if there is a shorter prefix that has a lower metric, this will be chosen over a longer prefix with higher metric? No, the kernel still uses the most specific route -- it's only in case of equal prefixes that the kernel priority is used. It's analoguous to Cisco's administative distance. So this is to choose between identical routes. Why is this needed? Where do the duplicates come from? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Open-Source PIM BIDIR (and more) implementation
So this is to choose between identical routes. Why is this needed? I have no idea. You'll have to ask Pierre. (And I'd appreciate an explanation myself.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Open-Source PIM BIDIR (and more) implementation
On Tue, 18 Aug 2015, Juliusz Chroboczek wrote:
(If you test this with Babel, you need to set reflect-kernel-metric true
in babeld's config file; Pierre tells me that this is done automatically
by hnetd. I'll make some refinements to the reflect-kernel-metric code,
and make it the default in the next release of babeld.)
What does that do?
From: http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babeld.html
reflect-kernel-metric {true|false}
Reflect route metrics as kernel priorities. The priority effectively used
is kernel-priority + metric.
http://linux-ip.net/html/routing-selection.html
The kernel begins iterating by priority through the routing policy
database. For each matching entry in the RPDB, the kernel will try to find
a matching route to the destination IP address in the specified routing
table using the aforementioned longest prefix match selection algorithm.
When a matching destination is found, the kernel will select the matching
route, and forward the packet. If no matching entry is found in the
specified routing table, the kernel will pass to the next rule in the
RPDB, until it finds a match or falls through the end of the RPDB and all
consulted routing tables.
So it takes whatever metric it came up with and sets the metric as kernel
priority? So if there is a shorter prefix that has a lower metric, this
will be chosen over a longer prefix with higher metric?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
[homenet] HNCP and connected interfaces
Section 6.1 says: A node MUST be able to detect whether two of its local internal interfaces are connected, e.g., by detecting an identical remote interface being part of the Common Links of both local interfaces. What should the node do if it detects that two interfaces are on the same link? (Disable HNCP on one interface? Speak HNCP on both interfaces but disable prefix assignment? Something even more exciting?) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
Either use the pool or use one from an SNTP DHCP option an edge router received from an ISP and published in HNCP. Ah, silly me. Yes, of course, we're already publishing DHCP(v6) options. RFC 7084 recommends support for NTP option. If NTP is supported, the router is required to request the DHCPv6 option and use that, if it gets a response. Ok. That means that we don't want any NTP peering within the Homenet, right? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
I don't know of anything in the homenet routers that require a peering level of synchronization. And I think it would be dangerous to suggest it's achievable. Well, if configured with both client-server and peer relationships, NTP will converge to a set of disjoint lowest-dispersion trees, so I guess there's no harm in automatically configuring some peer relationships. But I agree with you that it doesn't need to be mentioned in the spec. It's clear to me now, thanks to both of you, I'll try to hack something up. (The reason I'm asking is that once shncpd has learned to do local configuration of DNS and NTP, it can be used instead of a DHCP/RA client -- with fast roaming as an added benefit. Does my enthusiasm show, or do I need to spam even more?) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
Either use the pool or use one from an SNTP DHCP option an edge router received from an ISP and published in HNCP. Ah, silly me. Yes, of course, we're already publishing DHCP(v6) options. RFC 7084 recommends support for NTP option. If NTP is supported, the router is required to request the DHCPv6 option and use that, if it gets a response. Ok. That means that we don't want any NTP peering within the Homenet, right? I don't know of anything in the homenet routers that require a peering level of synchronization. And I think it would be dangerous to suggest it's achievable. I can easily envision a multihomed network, where each CE router gets time from its ISP, and doesn't care what other devices in the home network do (or optionally both try to propagate their time). And then there are all the hosts doing their own thing. The most common use for NTP time that I know of is in logs. To get a reasonable sense of when something happened. So I'd suggest to keep it simple and not try for or expect synchronization. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New Open-Source PIM BIDIR (and more) implementation
I am pleased to announce the public release of pimbd, the PIM implementation that was demonstrated during the last Bits and Bites in Prague. Excellent news, Pierre, automagic site-local multicast would be a great feature for Homenet. I'll try it out as soon as it migrates into an OpenWRT snapshot. (If you test this with Babel, you need to set reflect-kernel-metric true in babeld's config file; Pierre tells me that this is done automatically by hnetd. I'll make some refinements to the reflect-kernel-metric code, and make it the default in the next release of babeld.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] NTP in Homenet?
On Tue, Aug 18, 2015 at 3:21 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Either use the pool or use one from an SNTP DHCP option an edge router received from an ISP and published in HNCP. Ah, silly me. Yes, of course, we're already publishing DHCP(v6) options. RFC 7084 recommends support for NTP option. If NTP is supported, the router is required to request the DHCPv6 option and use that, if it gets a response. Ok. That means that we don't want any NTP peering within the Homenet, right? There has been some good work starting up around ntp of late. I personally would rather like it if accurate time could be provided if an accurate device (gps) was found, and ntp was secured, and sane, and local when possible. there are two good mailing lists for getting opinions about where ntp should go and/or is going are - time-nuts and gpsd-devel and this was very good news on this front: http://www.informationweek.com/cloud/infrastructure-as-a-service/linux-foundation-funds-ntps-father-time/d/d-id/1321775 -- Juliusz ___ 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] New Open-Source PIM BIDIR (and more) implementation
(If you test this with Babel, you need to set reflect-kernel-metric true What does that do? [...] So it takes whatever metric it came up with and sets the metric as kernel priority? That's right. So if there is a shorter prefix that has a lower metric, this will be chosen over a longer prefix with higher metric? No, the kernel still uses the most specific route -- it's only in case of equal prefixes that the kernel priority is used. It's analoguous to Cisco's administative distance. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
