Re: [homenet] Please review the No IPv4 draft

Simon Perreault simon.perrea...@viagenie.ca writes: In a nutshell, it defines DHCPv6 and RA options indicating to the host that IPv4 is not available. Since home networks are among those likely to see its use, reviews coming from HOMENET would be of tremendous help. If I understand the draft

Re: [homenet] Please review the No IPv4 draft

Simon Perreault simon.perrea...@viagenie.ca writes: Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user can already do this today without this extension. Right, to a certain extent that is true, of course; but not in the same drive-by fashion where a single packet can put

Re: [homenet] Please review the No IPv4 draft

Simon Perreault simon.perrea...@viagenie.ca writes: Sure it can. Just send them to a non-existing default gateway. Unless I misunderstood your point. My point was that if you do this, the next time the real gateway sends out an advertisement, connections are going to be restored. Whereas if

Re: [homenet] Please review the No IPv4 draft

Ted Lemon mel...@fugue.com writes: No, because this just leaves the client open to a different DoS attack. If you have rogue configuration protocols running on your network, you need to fix it. This just moves the problem around—it doesn't solve it. Well, assuming this stays as an RA option

[homenet] Experiences implementing Babel in the Bird routing daemon

Hi everyone Over the last couple of weeks, I've amused myself with doing a clean-slate implementation of the Babel protocol in the Bird routing daemon, and thought I'd report my experiences here. I saw Juliusz' talk at the Babel side meeting in Prague (and again at Battlemesh), which is what

Re: [homenet] [babel] Experiences implementing Babel in the Bird routing daemon

Juliusz Chroboczek j...@pps.univ-paris-diderot.fr writes: Over the last couple of weeks, I've amused myself with doing a clean-slate implementation of the Babel protocol in the Bird routing daemon Excellent news, Toke. I've had a first read over your code, and it looks almost correct (I

Re: [homenet] Routing Design Team outcome and next steps

Lorenzo Colitti writes: > Hear, hear! > > We have spent far too much time arguing about this, and I am happy we have a > conclusion. A big thank you to the chairs for calling making this call. I > strongly agree that given the dynamics of the home networking market, there >

[homenet] Fwd: [babel] A quick summary of babel@ietf

This might be of interest to people here. In particular, checking out Dave's "homenet on hackerboards" talk could be worthwhile. -Toke --- Begin Message --- 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

[homenet] A TOFU approach to naming things in the homenet (with code!)

Hey everyone While following the naming discussions, I have been thinking about how to do one of the things that the current naming architecture draft excludes: Allowing devices on the homenet to register in (public) DNS so that one may find them. And since I also wanted to learn the Go

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

Ted Lemon writes: > Thanks for doing this! Did you come up with this on your own, or were > inspired by > https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-01 > section 3.4.2 and > https://tools.ietf.org/html/draft-lemon-stateful-dnssd-00 section 4.2? Well, I

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

Juliusz Chroboczek writes: > Simple and elegant, solves a real problem without too much ideology. Thank you! That is high praise, coming from you :) >> If the name in a claim is not already taken by another nclient, the >> client's claim will be successful and the daemon will

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

Toke Høiland-Jørgensen <t...@toke.dk> writes: >> Or put it in DNS under dot-home? Since the client already knows how to >> speak DNS, this avoids yet another coupling between protocols. > > Ah yes, that makes sense; since we have a domain that always refers to > the

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

Andrew Sullivan writes: > I really like this idea. Thanks! > Obviously, it's the sort of thing whose scope had better be pretty > limited (e.g. you better know what network those TOFU requests are > coming from), but apart from that it seems quite useful. Yeah. The

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon writes: >> Depending on the type of performance problem. If the performance problem >> is general, yes. If it is specific to DNS, there's no reason to not use >> the connection for other things; and the "send queries to all upstreams" >> solution will automatically

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mel...@fugue.com> writes: > El 15 ag 2017, a les 15:38, Toke Høiland-Jørgensen <t...@toke.dk> va escriure: >>> I think we are wandering off into nonsense territory here. Have you >>> observed this sort of problem in the field? If so, c

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon writes: > El 16 ag 2017, a les 9:40, Ted Lemon va escriure: >> Ah, if this is your concern, I think that's answered by the whitelisting >> stuff I was talking about earlier. But in this case you really do need to >> have separate caches per PvD,

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mel...@fugue.com> writes: > El 16 ag 2017, a les 9:26, Toke Høiland-Jørgensen <t...@toke.dk> va escriure: >> Ted Lemon <mel...@fugue.com <mailto:mel...@fugue.com>> writes: >> >>> El 15 ag 2017, a les 19:32, Toke Høiland-Jørgense

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mel...@fugue.com> writes: > El 15 ag 2017, a les 19:32, Toke Høiland-Jørgensen <t...@toke.dk> va escriure: >>> In both of these cases, you are better off doing what we discussed >>> earlier and setting up your own DNS cache, possibly with a whitelist

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ralf Weber <d...@fl1ger.de> writes: > Moin! > > On 15 Aug 2017, at 21:38, Toke Høiland-Jørgensen wrote: >> Ted Lemon <mel...@fugue.com> writes: >>> I think we are wandering off into nonsense territory here. Have you >>> observed this sort of pr

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon writes: > What I find completely perplexing about this conversation is that you, > Markus and Toke, all of whom I know to be smart people, think this is > hard. What is hard about it? I think the reason you think it's > hard is simply that you don't know how to do

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mel...@fugue.com> writes: > El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen <t...@toke.dk> va escriure: >> In any case, the failure mode of getting a it wrong is a sub-optimal >> path being chosen; but if ISP A's DNS server takes five seconds to >>

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

> The point is that what I have specified in the architecture document is > what is minimally required to allow a homenet to function given ordinary > ISPs and ordinary users. I think trying to do some of the things on the > above laundry list would be very interesting work; trying to get it to

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon writes: >> Perhaps it would help if you could explain (a) the details of "the CDN >> problem" (what mechanism is used to determine answers for a given >> prefix, and what is the failure mode if the wrong address is used?), and >> (b) how the client is supposed to

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mel...@fugue.com> writes: > El 13 ag 2017, a les 14:25, Toke Høiland-Jørgensen <t...@toke.dk> va escriure: >>> El 13 ag 2017, a les 11:49, Toke Høiland-Jørgensen <t...@toke.dk >>> <mailto:t...@toke.dk>> va escriure: >>>> In

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Juliusz Chroboczek writes: >> 1a. Router A exports over HNCP that it supports MPvD. Router B forwards >> all queries to router A, using a source address in the same prefix >> as the original request was received from. > >> 1b. Router A exports over HNCP that it supports

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon writes: > Why do you want it to be optional? What problem are you trying to solve? > Do you not know how to do it? Do you think it's resource intensive? Do you > think it reduces reliability more than not doing it? Because I'm not convinced the added implementation

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon writes: > How does the client know in which PvD a response is intended to exist. Well, in some cases normal source address selection rules are going to do the trick (i.e., the client picks the source address closest to the destination). In others it won't, and the

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Andrew Sullivan writes: > On Thu, Aug 10, 2017 at 08:33:11PM +, STARK, BARBARA H wrote: >> Does anyone else have an opinion? Does anyone who has expressed an opinion >> want to express a new and different opinion? >> Barbara > > I haven't weighed in because I can't

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mel...@fugue.com> writes: > On Aug 10, 2017, at 5:07 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> with the possible exception of the >> requirement for supporting multiple provisioning domains > > How would you solve the problem of dual-homing wi

Re: [homenet] Status of draft-tldm-simple-homenet-naming CFA

Ted Lemon <mel...@fugue.com> writes: > On Aug 10, 2017, at 6:07 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> Now, assuming that I am wrong and this is actually a serious issue that >> we need to solve (of which I am not opposed to being convinced), I think >

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

Toke Høiland-Jørgensen <t...@toke.dk> writes: > Ted Lemon <mel...@fugue.com> writes: > >> I think it would be worth presenting your work, yes. In addition to this, >> I've >> been working with Stuart Cheshire on an enhancement to the hybrid proxy that

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

Ted Lemon <mel...@fugue.com> writes: > On Apr 17, 2017, at 3:16 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Hmm, turns out RFC6763 already defines a way to do this (in section 11). > r._dns-sd._udp.. where is either the in-addr.arpa zone > derived from th

Re: [homenet] I-D Action: draft-ietf-homenet-dot-10.txt

>> you couldn't use the fact that you can publish in a name in it >> to do the ACME authentication. > > there SHOULD NOT be the ACME authentication or any neccessarity of any > other authentication, as these domain names need not be unique ... > > in case you use 'teddynet.home.arpa.' and I use

Re: [homenet] homenet "no host changes" assumption and DNS

Ted Lemon writes: > I think that what you are proposing here is great, except that I don't > think we actually _need_ to go out of charter on this. I think that > what Toke has been advocating can be worked into the framework you are > describing, so that you and I! get what

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

Ted Lemon writes: > I think it would be worth presenting your work, yes. In addition to this, I've > been working with Stuart Cheshire on an enhancement to the hybrid proxy that I > expect to present in Prague. It would be interesting to tie your work in with > that. I'm going

Re: [homenet] A TOFU approach to naming things in the homenet (with code!)

Toke Høiland-Jørgensen <t...@toke.dk> writes: > Ted Lemon <mel...@fugue.com> writes: > >> On Apr 17, 2017, at 3:16 PM, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >> >> Hmm, turns out RFC6763 already defines a way to do this (in section

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

Juliusz Chroboczek writes: >>> This is not the notion that I tried to express, probably badly. It's not >>> necessarily the important feature, it's the one that will make people >>> implement and deploy the protocol stack in the first place. > >> Suggestion for '"killer feature"

Re: [homenet] Genart last call review of draft-ietf-homenet-babel-profile-05

Juliusz Chroboczek writes: >> we are writing a standards document, not a 19th century romance novel > > It is a truth generally acknowledged that a single man in possession of > a good fortune must be in want of a home network. Ah yes, much better. I for one believe it prudent to

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Juliusz Chroboczek writes: > Exporting names from the Homenet into the global namespace, on the > other hand, should be done by the hosts, with no involvement of any > third party (neither the ISP nor the Homenet itself). This is where I > argue for some form of end-to-end, secured, dynamic DNS

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Juliusz Chroboczek writes: >> Why? What is wrong with the owner of the network selecting which devices >> / services he/she wants globally reachable > > I don't think this is about global reachability (which is hopefully > managed by PCP), it's about exporting names into the global DNS. We >

Re: [homenet] homenet: what now? ... next?

Mikael Abrahamsson writes: > On Wed, 13 Mar 2019, Toke Høiland-Jørgensen wrote: > >> Since you seem to be pretty up to date on the ISP-level CPE offerings, >> just out of curiosity: Do any of these fancy ARM boxes include actual >> fixes for bufferbl

Re: [homenet] homenet: what now? ... next?

Mikael Abrahamsson writes: > On Thu, 14 Mar 2019, Toke Høiland-Jørgensen wrote: > >> You're right that packet accelerators complicate things a bit. I'm not >> entirely convinced that the "doesn't lend itself to FQ-CoDel and the >> rest of the mechanisms the buffer

Re: [homenet] homenet: what now? ... next?

Juliusz Chroboczek writes: >> PIE [...] lends itself better for implementation in existing hardware, >> or hardware with small modification. > > Could one of you please explain why? With the caveat that I have never worked with any of this hardware, this is my understanding: Basically, you can

Re: [homenet] homenet: what now? ... next?

Mikael Abrahamsson writes: > On Fri, 1 Mar 2019, Michael Richardson wrote: > >> For the last 10 to 15 years the ISP-provided home router has come to >> dominate the market, with the belief by the ISPs that this is a MUST >> that they control the device. Many (but not all) at the IETF do not >>

Re: [homenet] Homenet market gap analysis...

Mikael Abrahamsson writes: > I especially agree with the statement on wifi roaming between APs does > require shared L2, and there has been discussions about this and how > to solve that, and I think it's a requirement for homenet to become a > useful solution in that space. This would probably

Re: [homenet] -CoDel

"David R. Oran" writes: > On 15 Mar 2019, at 8:34, Toke Høiland-Jørgensen wrote: > >> Juliusz Chroboczek writes: >> >>>> PIE [...] lends itself better for implementation in existing >>>> hardware, >>>> or hardware with

Re: [homenet] Homenet market gap analysis...

Ted Lemon writes: > I suppose a point to be investigated is that however roaming happens, > unless all packets are flooded to all links, the layer 2 switch always > triggers a routing change, whether at layer 2 or layer 3. > > So it might be worth doing an analysis of the pros and cons of L2

Re: [homenet] [Cake] [Cerowrt-devel] althea presentation on isp in a box at nanog 76

Maciej Sołtysiak writes: >> https://www.youtube.com/watch?v=G4EKbgShyLw >> >> Interesting stuff - wireguard, fq_codel/sch_cake, babel with new >> metric that allows for cryptocurrency traffic billing. > Very refreshing, would love to see that succeed and then get popular in > Europe too! > > On