Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"

> So far so good. The problem is a (largely hypothetical at this point) > stub resolver that wants to do DNSSEC verification of the results the > router gives it. Yes, I'm following this discussion with interest. The only bit I object to is bringing .onion into the discussion -- .homenet is

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> So far so good. The problem is a (largely hypothetical at this point) > stub resolver that wants to do DNSSEC verification of the results the > router gives it. Yes, I'm following this discussion with interest. The only bit I object to is bringing .onion into the discussion -- .homenet is

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> On the computers I know, the stub resolver is in one shared library and > the SOCKS proxy is in another. What's the difference? The SOCKS library uses a completely different data transport (one that is circuit-switched and layered over TCP), with very different capabilities from the usual

Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"

> On the computers I know, the stub resolver is in one shared library and > the SOCKS proxy is in another. What's the difference? The SOCKS library uses a completely different data transport (one that is circuit-switched and layered over TCP), with very different capabilities from the usual

Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"

> requires special-case code in every single freaking DNS-speaking > application. Yeah, I'm still pissed off.) Since people seem puzzled about my rant, here's the relevant quotation from RFC 7686: Applications that do not implement the Tor protocol SHOULD generate an error upon the use

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> requires special-case code in every single freaking DNS-speaking > application. Yeah, I'm still pissed off.) Since people seem puzzled about my rant, here's the relevant quotation from RFC 7686: Applications that do not implement the Tor protocol SHOULD generate an error upon the use

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> This brings us to one of the knottiest parts of special use names, which > is that they're all handled differently. For .onion, it's generally > handled in a SOCKS proxy in the application, for .local it's handled by > mDNS, and for .localhost it's special cased in the stub client library.

Re: [homenet] [DNSOP] Fwd: WGLC on "redact" and "homenet-dot"

> This brings us to one of the knottiest parts of special use names, which > is that they're all handled differently. For .onion, it's generally > handled in a SOCKS proxy in the application, for .local it's handled by > mDNS, and for .localhost it's special cased in the stub client library.

Re: [Babel-users] Next Hop TLV meaning

> so if I understand correctly, when A sends an Update to B, B needs to know > address of A and, according to the proper circumstances, B gets address of A > either from IPv6 packet's source address (case 1) or from The Next-hop TLV > sent on purpose by A (case 2). Correct. > x y z

[Babel-users] ANNOUNCE: babeld-1.8.0

Dear all, Babeld-1.8.0 is available from https://www.irif.fr/~jch//software/files/babeld-1.8.0.tar.gz https://www.irif.fr/~jch//software/files/babeld-1.8.0.tar.gz.asc For more information about babeld and the Babel routing protocol, please see

Re: [homenet] draft-ietf-homenet-babel-profile-01

> I do not like REQ5. As a SHOULD, perhaps, but MUST seems excessive. > Guest networks without any HNCP / routing traffic are the way to go > anyway in my opinion. What happens behind closed doors (= non-guest) is > up to the home, I think. Right. Plus there's the fact that nobody has stepped

[homenet] draft-ietf-homenet-babel-profile-01

Hi, I've just submitted draft-ietf-homenet-babel-profile-01 It should hit the IETF repository soon, in the meantime, my working copy is on https://github.com/jech/babel-drafts/tree/master/draft-ietf-homenet-babel-profile The major change is the addition of Section 3, which describes how

Bug#842852: segmentation fault

>> I confirm this -- running 25.1+1-2 on amd64, I get the exact same backtrace: > If you get a chance, could you try 25.1+1-3 and see if it behaves > better? Hopefully it has fixed a problem with the choice of allocator > which might be related. It hasn't crashed yet.

Re: [homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

I think I now see how the pieces fit. Thanks, Markus. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

> In dnssd we have the “stitching” topic on our plate, around operation of > dns-sd > in unmanaged multi-link networks. So this is timely discussion. Aha, excellent. > We’re beginning work on a BCP for the use of the discovery/advertising proxy > in > enterprise/campus networks, where there

Re: [homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

>> - who merges data from multiple links? (I'd wish that the hybrid >> proxies compute a minimal spanning tree and perform peer-to-peer >> magic, but I suspect you're generating a config file dynamically >> and restarting dnsmasq whenever the set of hybrid proxies changes.) > There is no need

[beagleboard] Re: Beaglebone Green Wireless Wi-Fi

> I recently bought a BBGW and I am trying to send files from my laptop > (running linux mint) to the BBGW and forth but I am experiencing very poor > speeds - 9 Mbps. Could you please post the output of "iw dev wlan0 station dump"? -- For more options, visit http://beagleboard.org/discuss

[homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

>>> - ohybridproxy (only really scalable and sensible IPv6 rdns source that >>> I am aware of, given nodes talk mdns) >> Noted, thanks for the opinion. I still don't understand how it works (who >> gets port 53? how are data from multiple links merged?), but I intend to >> do my homework. > I

[homenet] Back to Ted's draft [was: Firewall hole punching]

> it doesn’t make sense to me why we should spend our time specifying > protocols for registering names of services in the global domain name > system unless we have a realistic usage scenario that shows how they > will be reachable directly by arbitrary public hosts. Agreed. > I just don’t see

Re: [homenet] Firewall hole punching [was: About Ted's naming architecture...]

> IoT land [...] there is bit more hope Joke, right? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

[homenet] Firewall hole punching [was: About Ted's naming architecture...]

>> (I see that hnet-full in OpenWRT/LEDE installs a thing called >> "minimalist-pcproxy", but I have no idea what it does and whether it >> handles multiple edge routers correctly.) > It does. Excellent. > Downside with it is that it is based on essentially non-IETF stuff (my > expired draft)

Re: [homenet] About Ted's naming architecture presentation and document

> I can put that controller into my own home and operate it Assuming that you can control the stateful firewall that's running on the edge routers. Recall that the edge router is not necessarily on the local link, and that there can be multiple edge routers. (I see that hnet-full in

Bug#845340: errno.h cannot be #included

Package: gcc-arm-linux-gnueabihf Version: 4:6.1.1-1 Try this: #include #include int main() { printf("%d\n", errno); return 0; } $ arm-linux-gnueabihf-gcc test.c In file included from /usr/arm-linux-gnueabihf/include/bits/errno.h:24:0, from

Bug#845340: errno.h cannot be #included

Package: gcc-arm-linux-gnueabihf Version: 4:6.1.1-1 Try this: #include #include int main() { printf("%d\n", errno); return 0; } $ arm-linux-gnueabihf-gcc test.c In file included from /usr/arm-linux-gnueabihf/include/bits/errno.h:24:0, from

Re: [homenet] About Ted's naming architecture presentation and document

> If there is anything in any of the Homenet working group documents or > pending drafts that contradicts the recommendations of RFC 6092 that > amount in practice to a prohibition against passive listeners in the > home network from being reachable by arbitrary exterior hosts, then I’m > not

Bug#845072: gpsd-clients depends on X11 libraries

Package: gpsd-clients Version: 3.11-3 Severity: wishlist Gpsd-clients depends on the X11 libraries, which on a headless system causes it to install over 50MB of useless stuff. It would be good if this package could be split into two, one of which does not depend on X11.

[beagleboard] Re: bbgw wlan0 users

> Okay, 4.4.22-ti-r49 has hit the repo: I can no longer reproduce the issue with 4.4.32-ti-r68. Thanks a lot, Nelson. -- Juliusz -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To

Re: [Babel-users] babel export routes from bird to routing table?

Hi Christof, > * I am aware that babel 1.8 is not stable yet. It's stable -- I just need to take the time to do a release. > As Babel 1.8 will be incompatible to 1.7 Babeld 1.8 will be fully compatible with 1.7. It's babeld 1.9 which will change the source-specific routing extension, and that

Re: [homenet] Clarification on homenet-dot slides

>> "The top-level domain name '.homenet.' is to be used for naming within >> a home network. Names ending with '.homenet.' MUST refer to >> services that are located within a home network (e.g., a printer, or >> a toaster)." > My comment was that I find the term "home network" ambiguous. Given

Re: [homenet] About Ted's naming architecture presentation and document

> But, do you agree that publishing your home lighting controller to the DNS is > how you manage to control your lights from your phone when you are out of > wifi distance, Yes, I didn't mean we should disallow this. If the user wants to publish his lightbulbs under .com, it's not our job to

Re: [Babel-users] [babel] feedback this Friday

Hi Denis, The Babel neighbour sensing mechanism is exactly as you describe: if a given IP address hasn't sent you a Hello, it doesn't exist, and all packets from it are silently dropped until it sends a Hello. This is by design. You are correct that an IHU does not carry explicit information

Bug#842852: segmentation fault

I confirm this -- running 25.1+1-2 on amd64, I get the exact same backtrace: Backtrace: emacs[0x50b89c] emacs[0x4f1c5c] emacs[0x50a00e] emacs[0x50a239] emacs[0x50a29f] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11100)[0x7f2b00e2b100]

[Polipo-users] Polipo web page updated

I've updated the Polipo web page with some information about why Polipo is obsolete. You can now stop e-mailing me ;-) -- Juliusz -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi

Re: [homenet] write up of time without clocks

> Poor visibility and diagnostics of faults make the cost of supporting > any service expensive and erode brand value Point. > So, would it be reasonable for devices that are not sure of the time, to > report that fact, and their view of what the time is to the user for > acceptance? Well, the

Re: [homenet] write up of time without clocks

ddos attack like against Dyn >> I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet, >> which propagates by exploiting devices configured with default credentials. >> This has nothing to do with outdated firmwares. > The problem is that you cannot realistically update

Re: [homenet] write up of time without clocks

>> ddos attack like against Dyn I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet, which propagates by exploiting devices configured with default credentials. This has nothing to do with outdated firmwares. -- Juliusz ___ homenet

Re: [homenet] write up of time without clocks

> But, we talked about how this wasn't a totally catch-22, that we could > know how it was "at least" some time based upon file timestamp, or > self-certificate not-before dates, or do DNSSEC without time validation > first. > My question is: did this get captured into document somewhere? In

Re: [Babel-users] Babel User

> Hello, I want to ask how babel read the message that send by other node to > themself ? Function parse_packet in file message.c. -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org

Re: [Babel-users] alternate source specific encoding?

>>> is that in a branch somewhere yet? >> No, sorry. > Got an ETA? Dave, it's September. Do you imagine what September looks like at university? > I'm in the process of rebuilding the yurtlab, Lucky man. I am in the process of grading undergrad internships. -- Juliusz

Re: [Babel-users] babel on an otherwise transparent bridge

> like it to do is have a dedicated ipv6 ULA ip address for management > purposes (not using a vlan here), and announce that to the network, but > never offer itself as a routing opportunity to anything [...] > out br-lan something deny? > in? > inflate the metric? out br-lan ula/128 allow out

Re: [Babel-users] alternate source specific encoding?

> is that in a branch somewhere yet? No, sorry. ___ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [homenet] ipv6 routing mind block

> Slightly OT: I have posted getstats.sh on the Homenet wiki. This is an > adaptation of a script that I created as a troubleshooting tool for > OpenWrt. The script collects a standard set of info and outputs it to > a single file for easy review.

Re: [homenet] ipv6 routing mind block

> Thanks for the suggestion, but no change. It's difficult to debug remotely, since you're not giving the relevant information. (Which interfaces are the routers connected over? How are they configured?) Did you install the "ip" OpenWRT package? (Check with "opkg status ip".) We've seen

[Polipo-users] Polipo is obsolete

I've just changed the web page and the README file to make it clear that Polipo is no longer being maintained. Sorry for that. -- Juliusz -- ___ Polipo-users mailing list

[beagleboard] Re: Fix for bluetooth issue [was: Beaglebone software issues]

> As far as the wl1835 driver is concerned it has MIMO enabled. > It is defined in the file /lib/firmware/ti-connectivity/wl18xx-conf.bin in the > entry wl18xx.phy.number_of_assembled_ant2_4 = 0x02. Right. It looks like I was confused, then. I'll do some more testing. Thanks for your help,

[beagleboard] Re: Fix for bluetooth issue [was: Beaglebone software issues]

> As far as the wl1835 driver is concerned it has MIMO enabled. After some further checking, I don't think it does. $ wlconf -i /lib/firmware/ti-connectivity/wl18xx-conf.bin -g | grep ht.mode wl18xx.ht.mode = 0x01 >From wl18xx/conf.h: enum wl18xx_ht_mode { /* Default -

Re: [Babel-users] Some minor incompatible changes to the configuration language

>> I guess I'll define a new type "conservative" which corresponds to what is >> done if the interface is not detected as wireless. Or do you have better >> ideas? > Call it "type default" so that there is no preconception, and explain what > it does in the man page? Point taken, but I don't

Bug#833185: Udhcd not killed when DHCP_ENABLED is no

Package: udhcpd Version: 1:1.22.0-9+deb8u1 Severity: minor Udhcpd is running. I edit /etc/default/udhcpd to set DHCPD_ENABLED to no, then do /etc/init.d/udhcpd stop The scripts checks the value of DHCPD_ENABLED, and does nothing. Is this the expected behaviour? Shouldn't the stop action

Bug#833185: Udhcd not killed when DHCP_ENABLED is no

Package: udhcpd Version: 1:1.22.0-9+deb8u1 Severity: minor Udhcpd is running. I edit /etc/default/udhcpd to set DHCPD_ENABLED to no, then do /etc/init.d/udhcpd stop The scripts checks the value of DHCPD_ENABLED, and does nothing. Is this the expected behaviour? Shouldn't the stop action

Re: [Babel-users] Some minor incompatible changes to the configuration language

>> Split-horizon is *disabled* on interfaces of type "auto", so if you want >> split-horizon, you should manually set the interface type. > I'm not sure I get the meaning of "auto", then. Does it mean babeld will > auto-detect the interface type (whenever possible, using e.g. netlink to > look

[beagleboard] Re: Beaglebone software issues [was: Using beaglebones as boards for the ietf "homenet" and "babel" working groups]

> I think Robert would have to reply, but I'm guessing that connman provides a > GUI and lots of seemingly useful defaults while remaining relatively small. Yes. See the note at the bottom. > Can /etc/network handle it all? How do you enable a GUI or even CUI to edit > it? It cannot and you

[beagleboard] Re: Fix for bluetooth issue [was: Beaglebone software issues]

> https://github.com/rcn-ee/repos/pull/17 Thanks for the speedy commit. Have you considered my suggestion to enable MIMO in the Wifi by default? Since the BBGW has two antenna connectors, it might make sense, although it might cause problems for people who decide not to connect any antennas --

[beagleboard] Re: Fix for bluetooth issue [was: Beaglebone software issues]

n <87oa5jp25b.wl-...@pps.univ-paris-diderot.fr> <87lh0nozu9.wl-...@pps.univ-paris-diderot.fr>

[Babel-users] Some minor incompatible changes to the configuration language

I've just pushed some changes that could, in some edge cases, break your configuration files. Since I'd like to release 1.8 before the end of the summer, I'll be grateful if you could test. First of all, the keyword "wired" is now deprecated (undocumented but supported for backwards

Re: [homenet] Trouble with hnet-full on WiTi Router from mqmaker

> I suspect it has something to do with the "disabling br-lan" messages, > but I don't know where that config comes from. No, that's just that as you change the configuration, the software bridge is being removed. What you're seeing are STP state transitions. Can you please paste a full boot

Re: [homenet] "Installing Homenet" guide (was: hnet-full & LEDE bug report)

>> The Commission for Truth in Advertising requires me to mention that the >> last feature is not quite ready yet -- with current software, when one >> provider goes down, you might need to manually disable the router that's >> connected to that provider. > The Commission for Truth in Advertising

Re: [homenet] "Installing Homenet" guide (was: hnet-full & LEDE bug report)

> Also... I'm aware that the Installing Homenet guide elides the reasons for > using it. Do we have a short paragraph that tells *why* a lay person would > want to use Homenet? > - No configuration - Homenet routers figure out how things are connected > and do the right thing Agreed, but

Re: [homenet] "Installing Homenet" guide (was: hnet-full & LEDE bug report)

>>> I think you mean E1 - that's what the instructions use for the wide area >>> interface. >> >> It looks like one of us is confused. > It looks like it was me. :-) Why not rename the interfaces to "internal" and "external"? > This is a corollary of your assertion at IETF the other day ("if

Re: [homenet] Tcpdump support for HNCP

> You guys did your homework, posted your code with (unit) test cases, and so > all the other tests passed. Thanks for the kind words. And thanks to you for the speedy pull, guys can go for holidays with clear confirmation that their internship was a success. -- Juliusz

Re: [homenet] Tcpdump support for HNCP

> Thank you... the 4.8.0-rc2 will go out on Monday with it. Jean-Raphaël is in my office, he's telling me "I thought upstreaming was supposed to be difficult" ;-) -- Juliusz ___ homenet mailing list homenet@ietf.org

Re: [homenet] Trouble with hnet-full on WiTi Router from mqmaker

> What I would suggest would be to convert the WAN and WLAN interfaces to > Homenet, but keep the LAN statically configured. Er, sorry. I missed the bit where you say that things only go wrong when you convert the LAN interface to hnet. I'm afraid you're going to have to log in through the WAN

Re: [homenet] Trouble with hnet-full on WiTi Router from mqmaker

> When I convert the lan port to hnet as described in Step 10, everything > comes to tears. After the reboot, the LAN ports do not give DHCP > addresses, and I cannot connect to either wireless interface... I assume you have no serial console on this board? What I would suggest would be to

[beagleboard] Re: Enabling 2x2 MIMO on the wl18xx [was: Beaglebone software issues]

>> After some reading of the kernel sources (always a pleasure), I've found >> how to enable 2x2 MIMO on the BBGW. I'm getting 77Mbit/s downstream (TCP >> iperf), which is pretty cool, but only 22Mbit/s upstream. > Is this AP/sta or adhoc mode? Client mode to a WNDR 3700 situated in the next

[beagleboard] Fix for bluetooth issue [was: Beaglebone software issues]

>>> There is a race condition between booting and loading the Bluetooth >>> firmware. Reloading the firmware manually works around the issue. >> This has been haunting us for a while. Okay, I found it. You just need to add Type=forking to the [Service] section of

[beagleboard] Enabling 2x2 MIMO on the wl18xx [was: Beaglebone software issues]

After some reading of the kernel sources (always a pleasure), I've found how to enable 2x2 MIMO on the BBGW. I'm getting 77Mbit/s downstream (TCP iperf), which is pretty cool, but only 22Mbit/s upstream. In order to enable 2x2 MIMO on the board, you need to add a file /etc/modprobe.d/wl18xx.conf

Bug#832481: Please remove "local stratum 10" from default config file

>> When run on a node with no RTC, this line causes chrony to disrupt the >> other nodes until the node manages to synchronise with a network node. > Could you please describe what kind of disruptions you’re seeing? Our Internet gateway synchronised with the NTP pool. There are a number of

Re: [homenet] hnet-full & LEDE bug report

> Rather than describe the symptoms, I think it might be more efficient > for someone to read through the steps outlined at > https://gist.github.com/richb-hanover/ec88b851c4da074e48003e6fe9276901 > and tell me if I've got it right? Looks good to me. You've correctly removed the software bridge

Bug#832481: Please remove "local stratum 10" from default config file

Package: chrony Version: 1.30-2+deb8u2 Severity: minor The default config file contains the line local stratum 10 When run on a node with no RTC, this line causes chrony to disrupt the other nodes until the node manages to synchronise with a network node. I suggest commenting it out in the

Re: [homenet] The HOMENET WG has placed draft-lemon-homenet-naming-architecture in state "Candidate for WG Adoption"

> I have no objection to implementing the ND option I retract that. I realise I don't know how difficult this is to implement in deployed host implementations, so I shouldn't be expressing an opinion. -- Juliusz ___ homenet mailing list

Re: [homenet] The HOMENET WG has placed draft-lemon-homenet-naming-architecture in state "Candidate for WG Adoption"

I would like to reiterate my opposition to four requirements of this draft (as described in my mail of 18 July): - the requirement for a new ND option; - the requirement for a RESTful management API; - the requirement for a local DNS resolver on each link; - the requirement for a ULA.

[homenet] xn--home

I have been informed by private mail that xn--home encodes to 㯝㯟. (Just kidding. Thanks to all for a pleasant IETF.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

[Babel-users] A quick summary of babel@ietf

Dear all, IETF is over, we've had the first meeting of the Babel WG. It went pleasantly smoothly. You'll find the full recording of the meeting[1], the minutes, as well as all the meeting materials, including slides[2]. [1]

[homenet] dot-homenet [was: What I really meant by option 5]

> But I think we all accept that there's going to have to be a special-use > top-level name allocated. That name is either going to be '.home' or > '.homenet' as far as I can tell. Ted, Is this domain meant to be specific to HNCP, or is it a generic site-local domain for home networks? If the

Re: [homenet] hnet-full & LEDE bug report

> Maybe I’m just much less good at getting the configurations right first > time In my experience, it's only the first two or three years that are difficult. -- Juliusz ___ homenet mailing list homenet@ietf.org

Re: [homenet] hnet-full & LEDE bug report

> Configuring and smoke testing >1 router, > once starts to look like > a devops problem. I think you're overthinking it. Once your routers are up and reachable from outside, propagating a new version of the config files is easily done using scp. Matthieu tends to automate that using a

Re: [homenet] Why configuration and routing are separate

> Well, in my testing I got the feeling (hard to tell since it was really > hard to get a comprehensive picture of what was going on over time), that > sometimes HNCP lost its connection to other HNCP nodes on the lan, while > babel was still working, and the other way around, babel went down and

Re: [homenet] hnet-full & LEDE bug report

> The problem came when “Step 3 - Converting WAN interface to Homenet” > didn’t work as described. I clicked Delete for the WAN interface. Don't use the web interface. Ssh into the router, and use vi on /etc/config/network, it's easier and more reliable. Here's how we make a Homenet router:

[homenet] Why configuration and routing are separate

Speaking with people at this week's IETF meeting, I've realised that some are confused about why configuration and routing are implemented by different protocols in Homenet. Contrary to what might seem, this is not some sort of weird political compromise, but a conscious technical decision.

[homenet] Manet address assignment

This message is being sent to the manet mailing list, with homenet in CC. I took to the microphone during this week's manet meeting to remind people that Homenet has designed HNCP (RFC 7788), a protocol for autonomous configuration of multilink home networks, and that it would be a terrible

Re: [Babel-users] [Battlemesh] Reminder: Babel IETF WG meets today

> What time zone is that? CEST, also known as UTC+2. Unless I got something wrong, that's 16:20 CEST (Berlin, Paris, Warsaw) 14:20 UTC 15:20 BST (London) 10:20 EDT (New York, NY) 7:20 PDT (Vacaville, CA) 11:20 ART (Buenos Aires) ___

[Babel-users] Reminder: Babel IETF WG meets today

Dear all, Just to remind you that the Babel IETF working group is meeting today for the first time from 16:20 to 18:20 in room Potsdam II. Remote participation is possible, and appreciated: https://www.ietf.org/meeting/96/remote-participation.html If you've got a decent connection, I

Re: [homenet] Naming: a strawman counter-proposal

> This proposal doesn't satisfy the problem statement. > (which nobody wrote. :) Perhaps we could start by writing up the usage scenarios we have in mind? I'll start: 1. I want to point a web browser at the configuration interface of the router in my attic; 2. I want to point a web browser

Re: [homenet] RFC 7788 and ".home"

> Current host stacks don't have support for saying "if the suffix is > ".TBD", go here, otherwise go there. Right, and I missed this point in my strawman. I guess I've been spoiled by dnsmasq. -- Juliusz ___ homenet mailing list homenet@ietf.org

Re: [homenet] RFC 7788 and ".home"

>> We want something short and memorable. ".co.uk" is short and memorable. >> ".univ-paris-diderot.fr" is not. > Why? This is, I suspect, part of the issue: it seems that we have > some assumptions about the use of these names, and I'm not entirely > sure what they are. It is not obvious to me

[homenet] Naming: a strawman counter-proposal

Not proposing this seriously, just attempting to explore the design space. Some of the ideas are due to Toke. Zones and authoritative nameservers are announced over HNCP together with their set of addresses, which SHOULD include a LUA and MUST include at least one IPv6 address. There are two

Making use of SADR at the higher layers

probes all available source-dest pairs, and performs fallback or load-balancing as necessary. Our experiences with MP-TCP in an IPv6+SADR network are described in Section VII.B of Matthieu Boutier and Juliusz Chroboczek. Source-specific routing. IFIP Networking 2015. https://arxiv.org/pdf

Re: [homenet] About ULAs in Ted's draft

> ps - i've read the draft and think it's ready for adoption. I most humbly disagree. Let's please leave some time for people to think it over and possibly come with counter-proposals. -- Juliusz ___ homenet mailing list homenet@ietf.org

Re: [homenet] RFC 7788 and ".home"

> - why do you need a TLD? Why won't a SLD work? We want something short and memorable. ".co.uk" is short and memorable. ".univ-paris-diderot.fr" is not. > - why do you need a word from natural language? We want something short and memorable. ".home" is short and memorable. ".in-addr.arpa" is

Re: [homenet] Attempt to summarize the value of various steps of 7788 fix

> Existing implementations by participants work and interoperate, Currently, shncpd doesn't do any naming at all except for pushing the addresses of upstream DNS resolvers to clients over RA and DHCPv4. You will find the exact status of shncpd at the bottom of

[homenet] About ULAs in Ted's draft

Ted, I've read the draft again, and I think that there's only one place where you rely on having a ULA. So I'd suggest: Section 3.3 point 2, replace "the homenet's ULA prefix" with "the homenet's ULA prefix (if any)". In Section 5.5, change "Homenets have at least one ULA prefix" with

[homenet] More about lossy links and yo-yo neighbours

Dear all, We only confirmed the yo-yo issue on Sunday, which caused me to send the latest version of my slides at the very latest moment. I therefore cannot blame the chairs for forcing me to work with an older version of my talk which didn't contain the explanation -- oh, what the heck, yes, I

Re: [homenet] My comment about Ted's naming draft

> Why wouldn't you allocate one? I would. ULAs are a goodness. Probably. I'm planning to add ULA generation to shncpd at some future date, and perhaps even enable it by default. The question is about the level of MUSTiness. I only see two reasonable possibilities: 1. ULA is SHOULD, and we

Re: [homenet] My comment about Ted's naming draft

>> (4) Is there WG consensus on requiring a ULA? > I believe that this is. > a) it's in rfc7084 (so they are there even before homenet existed) > b) it's in rfc7368 (it's in our architecture) RFC 7084 Section 4.3 says: The IPv6 CE router SHOULD be capable of generating a ULA prefix

Re: [homenet] My comment about Ted's naming draft

> Right now HNCP doesn't actually seem to have a TLV for advertising > resolvers. That's exactly what I was trying to get at. > How does this work now? Not very well. HNCP announces *external* resolvers in the DHCPv4- and DHCPv6-DATA sub-TLVs of the EXTERNAL-CONNECTION TLV. Hnetd uses this

Re: [homenet] My comment about Ted's naming draft

>> From my perspective, though, there is nothing technically hard about >> what we're talking about here; the main issue is that it's a >> substantial amount of work. You're possibly right, I don't know, but I'm worried about implementability. I'm very worried that you're apparently proscribing

[homenet] My comment about Ted's naming draft

This is to repeat the comment that I made at the mike about draft-lemon-homenet-naming-architecture-01. Among other things, this draft suggests: 1. having a new ND option (Section 3.5); 2. defining a RESTful management API (Section 3.6); 3. the use of a local resolver (Section 4.5);

[Babel-users] Reminder: IETF 96 next week, remote participation is encouraged

Dear all, This is to remind you that IETF 96 is next week in Berlin. There will be two sessions that should be of interest to members of these lists: Homenet, on Monday 18 July at 14:00 in room "Potsdam I"; Babel, on Thursday 21 July at 16:20 in room "Potsdam II". Other sessions might be

Re: [Babel-users] [BUG] Route "deadlocks" under load due to non-atomic kernel route updates

>> atomic updates in babel, > Patches gladly accepted. Or I'll do it at some point, but don't hold your > breath Anyone working on that? Or are you all holding your breath? -- Juliusz ___ Babel-users mailing list Babel-users@lists.alioth.debian.org

Re: [Babel-users] Redistributing /32 routes properly

> Which is one more argument in favour of disabling split horizon by default > in the next version. Opinions on that? Does anyone feel that doubling the amount of Babel traffic on wired links (no change on wireless links) is prohibitive? -- Juliusz

Re: [Babel-users] Redistributing /32 routes properly

> For the record, after a chat on IRC Jech helped me out and told me to > disable split-horizon processing on the interface (as the routes were > all coming in on the same interface). Works great now. Which is one more argument in favour of disabling split horizon by

<    3   4   5   6   7   8   9   10   11   12   >