Re: [homenet] routing protocol comparison document and hncp
> > Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to > bootstrap a certificate infrastructure, zero touch. Once every device in a > domain has a domain certificate, two devices can directly authenticate each > other, without PSK. Then you can also authenticate a key negotiation > scheme such as IKE, to negotiate a PSK which you can then use in your > "normal" authentication scheme. Obviously, would be nice if protocol > supported certs directly, but it’s not required. > > IKE provides just symmetric crypto key between two parties. Typical > network has more (and routing protocols use multicast). Multiparty IKE is > more or less dead (or undead?). > > Remember, we need whole network to agree on the keys, or at least > everyone on the link if any multicast is used in a way that requires > authentication or confidentiality. (HNCP is designed to avoid transmitting > anything important over multicast; are routing protocols? For most part, I > think not.) Sorry, I haven't been following all this discussion so I may be missing something, but ... I would say: Pick a master (on a link, or the entire network); master calculates a random key; distributes it to the other nodes using asymmetric crypto; all nodes use that key. For rollover use some key chain mechanism such that for a period of time old and new key are accepted. Plug those keys into the "normal" routing protocol security mechanism. What am I missing? Michael ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 09:37 AM, Michael Behringer (mbehring) wrote: I scanned this over (I think I've scanned Max's base doc too, but it's been a long time), and don't think that the problem at hand has much to do with needing a CA of any sort. Binding "human" names to cryptographic identities is fraught with trouble -- and if they're not intended to be human consumable, they might as well be the fingerprint of a public key. The big question i have is whether the non-interactive nature of certs is being taken advantage of. For example, if I throw my root current CA in the trash what happens? I have a lot of other questions, but I'm not sure whether this is right time to go through them. There are lots of questions which we should discuss. To the above question, easiest case would be that you create a new root CA and re-enrol devices there. Not perfect, but probably acceptable in a homenet, if the enrolment process is easy (which I believe we can make it). Yuck, obviously. It seems to me that there's a larger distributed database problem that this is probably another for-instance of. I really want to be able to throw my current CPE in the trash when it dies and not spend an entire day of harrowing configuration annotated with the dictionary's 4-letter word section. (others being dns naming/config, router/routing configs, dhcp goodies, etc, etc). Should we set up an informal meeting in Dallas to discuss this? Find a slot that works for most, a quiet corner, and discuss? Alas, I will not be in Dallas. Grassy knolls give me the sneezes. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> -Original Message- > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Michael > Thomas > Sent: 03 March 2015 18:20 > To: homenet@ietf.org > Subject: Re: [homenet] routing protocol comparison document and hncp > > On 03/03/2015 08:43 AM, Gert Doering wrote: > > Hi, > > > > On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: > >> Considering that provisioning personal certificates is the almost the > >> polar opposite of zeroconf, the chances of the normal schlub seeing > >> an informative and/or trustworthy name are really, really low. > > You might want to entertain you reading > > > >draft-behringer-homenet-trust-bootstrap > > > > which gives a good idea how this could work (the general ideas, maybe > > not the specific implementation). > > > > Of course the normal end user is not going to ever look at or manually > > generate a certificate. > > > > > > I scanned this over (I think I've scanned Max's base doc too, but it's been a > long time), and don't think that the problem at hand has much to do with > needing a CA of any sort. Binding "human" names to cryptographic > identities is fraught with trouble -- and if they're not intended to be human > consumable, they might as well be the fingerprint of a public key. > > The big question i have is whether the non-interactive nature of certs is > being taken advantage of. For example, if I throw my root current CA in the > trash what happens? > > I have a lot of other questions, but I'm not sure whether this is right time > to > go through them. There are lots of questions which we should discuss. To the above question, easiest case would be that you create a new root CA and re-enrol devices there. Not perfect, but probably acceptable in a homenet, if the enrolment process is easy (which I believe we can make it). Should we set up an informal meeting in Dallas to discuss this? Find a slot that works for most, a quiet corner, and discuss? Michael > Mike > > ___ > 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] routing protocol comparison document and hncp
On 03/03/2015 08:43 AM, Gert Doering wrote: Hi, On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are really, really low. You might want to entertain you reading draft-behringer-homenet-trust-bootstrap which gives a good idea how this could work (the general ideas, maybe not the specific implementation). Of course the normal end user is not going to ever look at or manually generate a certificate. I scanned this over (I think I've scanned Max's base doc too, but it's been a long time), and don't think that the problem at hand has much to do with needing a CA of any sort. Binding "human" names to cryptographic identities is fraught with trouble -- and if they're not intended to be human consumable, they might as well be the fingerprint of a public key. The big question i have is whether the non-interactive nature of certs is being taken advantage of. For example, if I throw my root current CA in the trash what happens? I have a lot of other questions, but I'm not sure whether this is right time to go through them. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Tue, Mar 03, 2015 at 07:31:56AM -0800, Michael Thomas wrote: > Considering that provisioning personal certificates is the almost the > polar opposite of zeroconf, the chances > of the normal schlub seeing an informative and/or trustworthy name are > really, really low. You might want to entertain you reading draft-behringer-homenet-trust-bootstrap which gives a good idea how this could work (the general ideas, maybe not the specific implementation). Of course the normal end user is not going to ever look at or manually generate a certificate. 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] routing protocol comparison document and hncp
On 03/03/2015 05:55 AM, David Oran wrote: On Mar 2, 2015, at 9:05 PM, Michael Thomas wrote: On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says "Hi, I'm your friendly homenet router and here's my public key." so you're mollified if somebody's cert says "hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" instead? Actually, I’m suspicious, which is entirely appropriate. If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key. Considering that provisioning personal certificates is the almost the polar opposite of zeroconf, the chances of the normal schlub seeing an informative and/or trustworthy name are really, really low. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> On Mar 2, 2015, at 9:05 PM, Michael Thomas wrote: > > On 03/02/2015 01:21 PM, Brian E Carpenter wrote: >> On 03/03/2015 09:12, Michael Thomas wrote: >>> >>> I'm doubtful that routing protocols need PSK's. They almost certainly >>> would like to share a symmetric key(s) but >>> is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. >>> s/and certificates// >> Well, I want certificates, because I don't believe someone who >> says "Hi, I'm your friendly homenet router and here's my public >> key." >> > > so you're mollified if somebody's cert says "hi i'm > 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" > instead? > Actually, I’m suspicious, which is entirely appropriate. If, on the other hand, the cert says router3.orandom.net and orandom.net is my domain with delegated DNSSEC from my domain provider I might be a tad more trusting than if I just saw a 2048bit raw public key. > the possession of a cert does nothing in and of itself to make an enrollment > decision. > I agree that the cert itself does nothing. The name in the cert, as long as it isn’t self signed, provides a trust anchor. > Mike > > ___ > 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] routing protocol comparison document and hncp
> On Mar 2, 2015, at 7:32 PM, Curtis Villamizar wrote: > > In message <7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org> > Christian Hopps writes: > >> Hi homenet-wg, >> >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. If true should we be calling this out >> more explicitly in the document? >> >> Thanks, >> Chris. > > > Chris, > > Yes. I agree. > > And OSPF could do the same, without dragging CLNP in with it. Using CLNP framing for IS-IS packets at the L2 layer is not the same as dragging in CLNP. No homenet router is going to do anything with ISO like frames other than drop them or hand them off to IS-IS. > Maybe ISIS-WG should consider an ISIS-over-IP draft? I actually presented that draft back in 1999, it was my first presentation at IETF; it didn’t go anywhere. :) Chris. > > Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Mon, Mar 02, 2015 at 07:48:24PM -0500, Curtis Villamizar wrote: > The way IETF has normally done things is to allow multiple > developments to exist if they have support and then drop only those > that are not being deployed or prove to be less desirable. "Having multiple examples of running code" is certainly a good thing. "Discussing all potential approaches to death, unless the committee has won, and the result is an unimplementable nightmare of myriads of different options" is what IETF WGs have changed to in more recent years - and if I look at the last few rounds of discussions, I can certainly understand why Dave moved off to get something *done*. A: "here's a draft that got implemented, works, and needs feedback" "but I want ISIS!" "and I want OSPF!" goto A gert, tempted to call it a day and spend my time *deploying* IPv6 somewhere -- 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] routing protocol comparison document and hncp
On 03/02/2015 06:50 PM, Brian E Carpenter wrote: so you're mollified if somebody's cert says "hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" instead? the possession of a cert does nothing in and of itself to make an enrollment decision. No, of course not. That is the whole point of using draft-pritikin-anima-bootstrapping-keyinfra or an equivalent. The point being that enrollment decisions have very little to do with the name binding claimed by some third party, especially when the name binding itself in a zero/littleconf most likely has little/no meaning to the enrollor (ie, mybrandnewrouter1...@china.com). It's hardly news that I'm biased against certs, but the biggest reason is that people impute in them superpowers which only get in the way of discussing the actual problems. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Regards Brian Carpenter http://orcid.org/-0001-7924-6182 On 03/03/2015 15:05, Michael Thomas wrote: > On 03/02/2015 01:21 PM, Brian E Carpenter wrote: >> On 03/03/2015 09:12, Michael Thomas wrote: >>> >>> I'm doubtful that routing protocols need PSK's. They almost >>> certainly would like to share a symmetric key(s) but is not the >>> same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. >>> s/and certificates// >> Well, I want certificates, because I don't believe someone who says >> "Hi, I'm your friendly homenet router and here's my public key." >> > > so you're mollified if somebody's cert says "hi i'm > 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" > instead? > the possession of a cert does nothing in and of itself to make an > enrollment decision. No, of course not. That is the whole point of using draft-pritikin-anima-bootstrapping-keyinfra or an equivalent. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/02/2015 01:21 PM, Brian E Carpenter wrote: On 03/03/2015 09:12, Michael Thomas wrote: I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Well, I want certificates, because I don't believe someone who says "Hi, I'm your friendly homenet router and here's my public key." so you're mollified if somebody's cert says "hi i'm 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx" instead? the possession of a cert does nothing in and of itself to make an enrollment decision. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi Curtis, The main reason for going forward with IS-IS over OSPFv3 is that there was an open source implementation willing to implement and support all the enhancements necessary for Homenet. Admittedly, the source/destination routing requirement makes the entrance barrier a bit higher for OSPFv3 than other protocols. The reason for this is that it requires the implementation of http://www.ietf.org/id/draft-ietf-ospf-ospfv3-lsa-extend-06.txt in order to support fully extendable LSAs. Hopefully, we can get some implementation momentum for OSPFv3 Extendable LSAs this year. If not soon, I have an idea for a cheaper, yet less elegant approach. Thanks, Acee On 3/2/15, 7:32 PM, "Curtis Villamizar" wrote: >In message <7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org> >Christian Hopps writes: > >> Hi homenet-wg, >> >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. If true should we be calling this out >> more explicitly in the document? >> >> Thanks, >> Chris. > > >Chris, > >Yes. I agree. > >And OSPF could do the same, without dragging CLNP in with it. > >Maybe ISIS-WG should consider an ISIS-over-IP draft? Oh wait - >non-routability of CLNP is a security feature - so don't forget to >mention that in the security section. You might need providers to use >filters at borders and GTSM as they do for OSPF. > >Curtis > >___ >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] routing protocol comparison document and hncp
In message <87twy3wjtr.wl-...@pps.univ-paris-diderot.fr> Juliusz Chroboczek writes: > > I got my hands on ISO 10589 today and tried to very briefly glance through > > it. And personally I had a really hard time getting into it. > > > > Having read the comparison document beforehand I haven't found anything > > about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned > > in the draft (and that ISO standard was ~200 pages already). > > You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308. > > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet Hint: RFC 1195 does a better job explaining what ISIS does than ISO 10589. Read RFC 1195 first. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message Christian Hopps writes: > > > On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek > > wrote: > > > >> One thing that has been mentioned to me is that IS-IS could be used > >> (with proper TLV additions) to completely replace HNCP, if IS-IS were > >> used as the homenet protocol. > > > > I see that you've been speaking with Abrahamsson. Please let me give you > > some background. > > It's not just Mikael that has this opinion, he's just the more active > email participant. > > >> If true should we be calling this out more explicitly in the document? > > > > I seem to recall that I already mentioned that I find your tendency to > > bring out controversial arguments just before a deadline somewhat > > offputting. > > There was nothing nefarious here. I just thought of a question and > raised it. I think we should be open to doing that any time free > of attack. > > Thanks, > Chris. I agree with Chris. WGs are allowed to change their decisions particularly in early stages when there is no significant ***deployment***. Even then WGs can take a new direction but need to include backward compatibility or at least have a solid plan for (hopefully painless) transition. For example, MPLS started with RSVP-TE and CRLDP and years later dropped CRLDP due to lack of deployment. CIDR obsoleted EGP, BGP1-3, RIP1, and lots of other protocols, but there was a good reason and a clear transition plan. The way IETF has normally done things is to allow multiple developments to exist if they have support and then drop only those that are not being deployed or prove to be less desirable. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
In message <7615609f-512e-42aa-a2e7-4dbb31f1a...@chopps.org> Christian Hopps writes: > Hi homenet-wg, > > One thing that has been mentioned to me is that IS-IS could be used > (with proper TLV additions) to completely replace HNCP, if IS-IS were > used as the homenet protocol. If true should we be calling this out > more explicitly in the document? > > Thanks, > Chris. Chris, Yes. I agree. And OSPF could do the same, without dragging CLNP in with it. Maybe ISIS-WG should consider an ISIS-over-IP draft? Oh wait - non-routability of CLNP is a security feature - so don't forget to mention that in the security section. You might need providers to use filters at borders and GTSM as they do for OSPF. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
>>> I am sorry, I no longer share this opinion [...] The next version of >>> cerowrt will do translation from the external IPv6 address range to >>> a static internal one (or ones, in the case of multiple egress >>> gateways), >> (Insert strong expression of disagreement here. Use any means available >> to convince Dave otherwise, including flattery, threats, demagoguery, ad >> hominem attacks and photographs of cute animals.) > Hahaha. Thanks juliusz! I have laughed far too little in the past few > weeks. But I'm dead serious, Dave. I'm actually making my serious face right now. Just looking at stuff I'm intimately familiar with, you're breaking: - the IPv6 PEX code in Transmission, which assumes that if you call connect on an IPv6 UDP socket, then getsockname will return a currently usable IPv6 address; - the IPv6 DHT code in Tranmission, which assumes that calling the same sequence as above will return a host's currently preferred IPv6 address (Kademlia needs a bound socket, changing IPs per destination breaks the algorithm); - Matthieu's multipath Mosh, which puts the server's local IPv6 addresses on the wire. Dave, let's please find a way to solve the renumbering problem in a way that doesn't break applications. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 2.3.2015, at 21.34, Michael Behringer (mbehring) wrote: >>> Then one can always discuss what kind of information could go into each >> protocol after bootstrap. Perhaps what we actually need is a new bootstrap >> security protocol (not only for homenet), and that this is where the >> emphasis should be. >> >> Possibly. However, even if we had one, bootstrap protocol does not lead >> easily to widely shared PSKs, and that’s what routing protocols require. >> >> E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I >> had a >> certificate, I am not sure how it helps with PSK IS-IS scheme. > > Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to > bootstrap a certificate infrastructure, zero touch. Once every device in a > domain has a domain certificate, two devices can directly authenticate each > other, without PSK. Then you can also authenticate a key negotiation scheme > such as IKE, to negotiate a PSK which you can then use in your "normal" > authentication scheme. Obviously, would be nice if protocol supported certs > directly, but it’s not required. IKE provides just symmetric crypto key between two parties. Typical network has more (and routing protocols use multicast). Multiparty IKE is more or less dead (or undead?). Remember, we need whole network to agree on the keys, or at least everyone on the link if any multicast is used in a way that requires authentication or confidentiality. (HNCP is designed to avoid transmitting anything important over multicast; are routing protocols? For most part, I think not.) I might be wrong, hopefully some points me at some asymmetric crypto enabled multi-party authentication method for _some_ routing protocol.. Only way I could imagine this working is by firing up metric shitload of on-demand (e.g. GRE) tunnels on top of IPsec (based on some yet undefined on-link peer detection scheme), then running some RP over them in p2p mode. Then we realize that all security needed is really in the peer-detection (which can be conservative, very rate limited and so on) and the IPsec, and we would require no security features from the routing protocol itself. > I still think that the above draft is a very good way to bootstrap a > certificate infrastructure, which can be leveraged in many different ways. It is relatively heavy in terms of number of protocols to the functionality I would want, but I agree that on the paper[1] it does what it advertises it does, but it is not enough to make routing protocols work in and of itself, see above. Cheers, -Markus [1] I have yet to see an implementation; I have heard one exists. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 09:12, Michael Thomas wrote: > On 03/02/2015 11:54 AM, Brian E Carpenter wrote: >> On 03/03/2015 08:38, Michael Thomas wrote: Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. >>> I'm doubtful that routing protocols need PSK's. They almost certainly >>> would like to share a symmetric key(s) but >>> is not the same thing. >> But they need to agree on the shared key(s) securely, and the only way >> I know how to do that zero-touch is by starting with asymmetric keys >> and certificates. >> >> > s/and certificates// Well, I want certificates, because I don't believe someone who says "Hi, I'm your friendly homenet router and here's my public key." Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/02/2015 11:54 AM, Brian E Carpenter wrote: On 03/03/2015 08:38, Michael Thomas wrote: Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. s/and certificates// Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 03/03/2015 08:38, Michael Thomas wrote: > On 03/02/2015 11:34 AM, Michael Behringer (mbehring) wrote: >>> -Original Message- >>> From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Markus >>> Stenberg >>> Sent: 02 March 2015 15:11 >>> To: Mikael Abrahamsson >>> Cc: homenet@ietf.org; Markus Stenberg; Margaret Wasserman; Christian >>> Hopps >>> Subject: Re: [homenet] routing protocol comparison document and hncp >>> >>> On 2.3.2015, at 15.55, Mikael Abrahamsson wrote: >>>> On Mon, 2 Mar 2015, Margaret Wasserman wrote: >>>>> I think Markus' comments on security are also very important to >>>>> consider >>> here, as some sort of integrated security mechanism between the routing >>> protocol and HNCP might be strongly desired. >>>> Yes, I agree that HNCP has gained security that currently none of the >>> routing protocols have, and that this is important. >>>> Then one can always discuss what kind of information could go into each >>> protocol after bootstrap. Perhaps what we actually need is a new >>> bootstrap >>> security protocol (not only for homenet), and that this is where the >>> emphasis should be. >>> >>> Possibly. However, even if we had one, bootstrap protocol does not lead >>> easily to widely shared PSKs, and that’s what routing protocols require. >>> >>> E.g. anima bootstrap stuff is focusing only on enrolling >>> certificates. If I had a >>> certificate, I am not sure how it helps with PSK IS-IS scheme. >> Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way >> to bootstrap a certificate infrastructure, zero touch. Once every >> device in a domain has a domain certificate, two devices can directly >> authenticate each other, without PSK. Then you can also authenticate a >> key negotiation scheme such as IKE, to negotiate a PSK which you can >> then use in your "normal" authentication scheme. Obviously, would be >> nice if protocol supported certs directly, but it's not required. >> >> I still think that the above draft is a very good way to bootstrap a >> certificate infrastructure, which can be leveraged in many different >> ways. >> >> > > I'm doubtful that routing protocols need PSK's. They almost certainly > would like to share a symmetric key(s) but > is not the same thing. But they need to agree on the shared key(s) securely, and the only way I know how to do that zero-touch is by starting with asymmetric keys and certificates. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> On Mar 2, 2015, at 1:59 PM 3/2/15, Juliusz Chroboczek > wrote: > >>> If we carry NAT over to IPV6, then shame on us. > >> I am sorry, I no longer share this opinion [...] The next version of >> cerowrt will do translation from the external IPv6 address range to >> a static internal one (or ones, in the case of multiple egress >> gateways), Are you at least following NPTv6, RFC 6296? > > (Insert strong expression of disagreement here. Use any means available > to convince Dave otherwise, including flattery, threats, demagoguery, ad > hominem attacks and photographs of cute animals.) Photographs of threats to cute animals? "Don't code IPv6 address translation or the kitten gets it!" > > -- Juliusz > > ___ > 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] routing protocol comparison document and hncp
On 03/02/2015 11:34 AM, Michael Behringer (mbehring) wrote: -Original Message- From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Markus Stenberg Sent: 02 March 2015 15:11 To: Mikael Abrahamsson Cc: homenet@ietf.org; Markus Stenberg; Margaret Wasserman; Christian Hopps Subject: Re: [homenet] routing protocol comparison document and hncp On 2.3.2015, at 15.55, Mikael Abrahamsson wrote: On Mon, 2 Mar 2015, Margaret Wasserman wrote: I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Yes, I agree that HNCP has gained security that currently none of the routing protocols have, and that this is important. Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be. Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require. E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme. Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. I'm doubtful that routing protocols need PSK's. They almost certainly would like to share a symmetric key(s) but is not the same thing. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
> -Original Message- > From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Markus > Stenberg > Sent: 02 March 2015 15:11 > To: Mikael Abrahamsson > Cc: homenet@ietf.org; Markus Stenberg; Margaret Wasserman; Christian > Hopps > Subject: Re: [homenet] routing protocol comparison document and hncp > > On 2.3.2015, at 15.55, Mikael Abrahamsson wrote: > > On Mon, 2 Mar 2015, Margaret Wasserman wrote: > >> I think Markus' comments on security are also very important to consider > here, as some sort of integrated security mechanism between the routing > protocol and HNCP might be strongly desired. > > > > Yes, I agree that HNCP has gained security that currently none of the > routing protocols have, and that this is important. > > > > Then one can always discuss what kind of information could go into each > protocol after bootstrap. Perhaps what we actually need is a new bootstrap > security protocol (not only for homenet), and that this is where the > emphasis should be. > > Possibly. However, even if we had one, bootstrap protocol does not lead > easily to widely shared PSKs, and that’s what routing protocols require. > > E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I > had a > certificate, I am not sure how it helps with PSK IS-IS scheme. Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to bootstrap a certificate infrastructure, zero touch. Once every device in a domain has a domain certificate, two devices can directly authenticate each other, without PSK. Then you can also authenticate a key negotiation scheme such as IKE, to negotiate a PSK which you can then use in your "normal" authentication scheme. Obviously, would be nice if protocol supported certs directly, but it's not required. I still think that the above draft is a very good way to bootstrap a certificate infrastructure, which can be leveraged in many different ways. Michael > Babel + IKE + IPsec, on the other hand, could of course run with the > certificate, but would not be link-state => hard to replicate state. > > Looking at fast adoption, perhaps OSPF would be preferable then, as it > already runs over IP so the story would be just ’take TEH BOOTSTRAPPER, > IKE, IPsec, OSPF’ and world is your oyster. No standardization required > (beyond dst-src draft by Baker, just like IS-IS). > > Cheers, > > -Markus > > ___ > 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] Routing protocol comparison document
>> If we carry NAT over to IPV6, then shame on us. > I am sorry, I no longer share this opinion [...] The next version of > cerowrt will do translation from the external IPv6 address range to > a static internal one (or ones, in the case of multiple egress > gateways), (Insert strong expression of disagreement here. Use any means available to convince Dave otherwise, including flattery, threats, demagoguery, ad hominem attacks and photographs of cute animals.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 27, 2015 at 2:28 PM, Dave Taht wrote: > > [...] > The next version of cerowrt will do translation from the external IPv6 > address range to a static internal one (or ones, in the case of > multiple egress gateways), and lacking a standard for such will use > fcxx/8 addressing. I will make it be an option for people to turn off, > but I've had it with being renumbered. > And so it begins. > I am sure this will break stuff, and I don't know what all it will do, > and I intend to find out. > I'd prefer that we simply consider CeroWRT with this change to be fundamentally broken, and begin by keeping track of the things that still work with it, rather than what it breaks. > Until some far off day where we have stable name to ipv6 address > mapping, and vice versa, it is otherwise impossible to have useful > ipv6 based services inside the home or small business. > Doesn't seem impossible to me. Too difficult? I could agree with that, but I would have to say it's the ubiquitous RFC 6092 filters that are going to kill that idea before the frequent renumbering does. Seriously, people: we could give up on the IPv6 servers on home and small business networks thing any day now, and I don't think we would lose much steam. Given that those filters are everywhere and turned on by default in most cases, it's only just a little bit worse if home gateways are using NPTv6 too. It's not like you could use working address referral if you wanted. (p.s. I'm aware of at least one other serious proposal to use NPTv6 in a shipping home gateway. It would be easier to argue against it if those RFC 6092 filters weren't installed everywhere.) -- james woodyatt Nest Labs, Communications Engineering ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Thanks for the quick reply. Looks like I will be having something to read on the plane to Dallas. On 02.03.2015 15:56, Christian Hopps wrote: On Mar 2, 2015, at 9:07 AM, Steven Barth wrote: One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Yes. ISO standards are not always the best place to get an overview of things. :) The document referred to here is ISO10589:2002. Section 6.8 is an overview IS-IS link-independent stuff. (pages 12-14) Section 7 gets into specifics but skip anything about level 2 (definitely skip partition repair), at least to start, as we are only considering level-1 single-area operation. Feel free to skip over (or quickly glance through) any address specific stuff (7.1) as it mostly does not pertain. Also skip anything related to hosts for now (ES or end-systems, i.e., ISO hosts). 7.2 The "Decision Process" (pages 18-26) This is basically an SPF with bi-directional checks (both sides of a link refer to each other). Additionally the fact that a broadcast network is treated as a pseudo-node with routers (non-pseudonodes) attached to it (rather than a full-mesh of connections between routers) is important. So 7.3 is the update process (advertising and flooding of information). (pages 26-45) Primarily this is going to get into - How a router advertises it’s information (LSP generation) - How IS-IS makes sure things are flooded (using sequence number packets and internally 2 flags called SRM and SSN). - LSP expiration and collision detection. Feel free to skip 7.4 (forwarding process), 7.5 (constants and parameters). Section 8 is the link dependent stuff. Here the hello protocol is documented. Skip ES (end-system stuff). - P2P (pages 50-54) - Skip 8xxx - Broadcast (pages 59-63) Section 9 documents the protocol (on-the-wire) encodings (page 65-92) Everything else can be skipped (page 92 on). Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). There’s a new version that has the references to the RFCs for v4, v6, hmac and wide metrics. The core of the IS-IS protocol is contained in about 80 pages. From above you should be able to get an good idea of the protocol in about ~40 pages, although it won’t necessarily be easy reading. :) So I think I asked Mikael the same thing already but could you (or anyone else) please provide a dumbed down specification or at least an overview document that references all relevant ISO-standards, RFCs and drafts (or chapters thereof) that one needs to read to understand modern IS-IS? On top of that if you could mention what could / or should be removed for a trimmed down homenet version that would be a huge plus. Basically a trimmed down version is "level-1" operation only (everything in a single area). Whenever something mentioned level-2 operation discard it. Thanks, Chris. Cheers, Steven ___ 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] routing protocol comparison document and hncp
> On Mar 2, 2015, at 9:07 AM, Steven Barth wrote: > > >> One thing that has been mentioned to me is that IS-IS could be used (with >> proper TLV additions) to completely replace HNCP, if IS-IS were used as the >> homenet protocol. If true should we be calling this out more explicitly in >> the document? > I got my hands on ISO 10589 today and tried to very briefly glance through > it. And personally I had a really hard time getting into it. Yes. ISO standards are not always the best place to get an overview of things. :) The document referred to here is ISO10589:2002. Section 6.8 is an overview IS-IS link-independent stuff. (pages 12-14) Section 7 gets into specifics but skip anything about level 2 (definitely skip partition repair), at least to start, as we are only considering level-1 single-area operation. Feel free to skip over (or quickly glance through) any address specific stuff (7.1) as it mostly does not pertain. Also skip anything related to hosts for now (ES or end-systems, i.e., ISO hosts). 7.2 The "Decision Process" (pages 18-26) This is basically an SPF with bi-directional checks (both sides of a link refer to each other). Additionally the fact that a broadcast network is treated as a pseudo-node with routers (non-pseudonodes) attached to it (rather than a full-mesh of connections between routers) is important. So 7.3 is the update process (advertising and flooding of information). (pages 26-45) Primarily this is going to get into - How a router advertises it’s information (LSP generation) - How IS-IS makes sure things are flooded (using sequence number packets and internally 2 flags called SRM and SSN). - LSP expiration and collision detection. Feel free to skip 7.4 (forwarding process), 7.5 (constants and parameters). Section 8 is the link dependent stuff. Here the hello protocol is documented. Skip ES (end-system stuff). - P2P (pages 50-54) - Skip 8xxx - Broadcast (pages 59-63) Section 9 documents the protocol (on-the-wire) encodings (page 65-92) Everything else can be skipped (page 92 on). > Having read the comparison document beforehand I haven't found anything about > IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the > draft (and that ISO standard was ~200 pages already). There’s a new version that has the references to the RFCs for v4, v6, hmac and wide metrics. The core of the IS-IS protocol is contained in about 80 pages. From above you should be able to get an good idea of the protocol in about ~40 pages, although it won’t necessarily be easy reading. :) > So I think I asked Mikael the same thing already but could you (or anyone > else) please provide a dumbed down specification or at least an overview > document that references all relevant ISO-standards, RFCs and drafts (or > chapters thereof) that one needs to read to understand modern IS-IS? > On top of that if you could mention what could / or should be removed for a > trimmed down homenet version that would be a huge plus. Basically a trimmed down version is "level-1" operation only (everything in a single area). Whenever something mentioned level-2 operation discard it. Thanks, Chris. > > > Cheers, > > Steven > > ___ > 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] routing protocol comparison document and hncp
> I got my hands on ISO 10589 today and tried to very briefly glance through > it. And personally I had a really hard time getting into it. > > Having read the comparison document beforehand I haven't found anything > about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned > in the draft (and that ISO standard was ~200 pages already). You need RFC 1195, RFC 3719, RFC 3787, RFC 5304, RFC 5305, and RFC 5308. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 2.3.2015, at 15.55, Mikael Abrahamsson wrote: > On Mon, 2 Mar 2015, Margaret Wasserman wrote: >> I think Markus' comments on security are also very important to consider >> here, as some sort of integrated security mechanism between the routing >> protocol and HNCP might be strongly desired. > > Yes, I agree that HNCP has gained security that currently none of the routing > protocols have, and that this is important. > > Then one can always discuss what kind of information could go into each > protocol after bootstrap. Perhaps what we actually need is a new bootstrap > security protocol (not only for homenet), and that this is where the emphasis > should be. Possibly. However, even if we had one, bootstrap protocol does not lead easily to widely shared PSKs, and that’s what routing protocols require. E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I had a certificate, I am not sure how it helps with PSK IS-IS scheme. Babel + IKE + IPsec, on the other hand, could of course run with the certificate, but would not be link-state => hard to replicate state. Looking at fast adoption, perhaps OSPF would be preferable then, as it already runs over IP so the story would be just ’take TEH BOOTSTRAPPER, IKE, IPsec, OSPF’ and world is your oyster. No standardization required (beyond dst-src draft by Baker, just like IS-IS). Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
One thing that has been mentioned to me is that IS-IS could be used (with proper TLV additions) to completely replace HNCP, if IS-IS were used as the homenet protocol. If true should we be calling this out more explicitly in the document? I got my hands on ISO 10589 today and tried to very briefly glance through it. And personally I had a really hard time getting into it. Having read the comparison document beforehand I haven't found anything about IPv4, IPv6, HMACs, wide-metrics or other things that are mentioned in the draft (and that ISO standard was ~200 pages already). So I think I asked Mikael the same thing already but could you (or anyone else) please provide a dumbed down specification or at least an overview document that references all relevant ISO-standards, RFCs and drafts (or chapters thereof) that one needs to read to understand modern IS-IS? On top of that if you could mention what could / or should be removed for a trimmed down homenet version that would be a huge plus. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On Mon, 2 Mar 2015, Margaret Wasserman wrote: I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Yes, I agree that HNCP has gained security that currently none of the routing protocols have, and that this is important. Then one can always discuss what kind of information could go into each protocol after bootstrap. Perhaps what we actually need is a new bootstrap security protocol (not only for homenet), and that this is where the emphasis should be. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Juliusz, I've actually been wondering about this, too. I am not sure about the history here, because the last version of HNCP I read (in preparation for the last IETF meeting), HNCP contained its own (underspecified) link-state routing protocol… If that protocol were replaced with an already-existing link-state routing protocol, one that had the ability flood additional information about the links, it might be possible to use that already-existing routing protocol as the underlying communication mechanism for HNCP. We would still need to specify what HNCP information is sent, but the routing information and HNCP information could, possibly, be transmitted over the same protocol. I don't know if that would work with a non-link-state routing protocol, as part of what HNCP was using its internal routing protocol to distribute was information about all of the links. I don't know what facilities IS-IS or Babel have for sending additional information about each link, and I don't know if we actually want to require that very node that needs HNCP information run IS-IS or Babel, but I think this is worth considering. I will think about this, read some stuff, and try to come up with my own opinion about it ASAP. I would suggest that other people do that, too. I think Markus' comments on security are also very important to consider here, as some sort of integrated security mechanism between the routing protocol and HNCP might be strongly desired. Margaret On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek wrote: >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. > > I see that you've been speaking with Abrahamsson. Please let me give you > some background. > > Two years ago, there was a very animated discussion about whether the > configuration protocol and the routing protocol should be separate or not. > After a lot of energy was spent on the issue, Markus designed HNCP, which > went through a few iterations. The chairs judged that WG consensus was > achieved, and the configuration protocol is now separate from the routing > protocol. > > Since achieving consensus on this was a lot of work, some of us are > somewhat annoyed at Mikael bringing this argument back from the dead at > every opportunity. > >> If true should we be calling this out more explicitly in the document? > > I seem to recall that I already mentioned that I find your tendency to > bring out controversial arguments just before a deadline somewhat offputting. > > -- Juliusz > > ___ > 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] routing protocol comparison document and hncp
> On Mar 2, 2015, at 8:00 AM, Juliusz Chroboczek > wrote: > >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. > > I see that you've been speaking with Abrahamsson. Please let me give you > some background. It’s not just Mikael that has this opinion, he’s just the more active email participant. >> If true should we be calling this out more explicitly in the document? > > I seem to recall that I already mentioned that I find your tendency to > bring out controversial arguments just before a deadline somewhat offputting. There was nothing nefarious here. I just thought of a question and raised it. I think we should be open to doing that any time free of attack. Thanks, Chris. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
On 2.3.2015, at 15.00, Juliusz Chroboczek wrote: >> One thing that has been mentioned to me is that IS-IS could be used >> (with proper TLV additions) to completely replace HNCP, if IS-IS were >> used as the homenet protocol. > I see that you've been speaking with Abrahamsson. Please let me give you > some background. > > Two years ago, there was a very animated discussion about whether the > configuration protocol and the routing protocol should be separate or not. > After a lot of energy was spent on the issue, Markus designed HNCP, which > went through a few iterations. The chairs judged that WG consensus was > achieved, and the configuration protocol is now separate from the routing > protocol. > > Since achieving consensus on this was a lot of work, some of us are > somewhat annoyed at Mikael bringing this argument back from the dead at > every opportunity. Funny part is, the argument has changed substantially since. Originally I considered HNCP security to be strictly optional, but as there was push-back to have built-in security, I added it in. And now it is essentially more littleconf’able than any routing protocol security scheme I have ever met before. The current draft specifies only PSK based security; do you really want to bootstrap your home security either with well-known ‘IamGoodguy’ password, or perhaps by logging in to every router to do magic things? No, me neither. I am looking forward to hearing some of some relatively dynamic security protocol (think IKE, or TLS handshake) that runs on top of CLNP though that we can hook in to IS-IS. The current draft’s ’security’ requirements for (stand-alone) use of either routing protocol’s own security framework are inadequate to what the group has been discussing here (among other places) over the last year. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] routing protocol comparison document and hncp
Hi, On Mon, Mar 02, 2015 at 07:33:47AM -0500, Christian Hopps wrote: > One thing that has been mentioned to me is that IS-IS could be used (with > proper TLV additions) to completely replace HNCP, if IS-IS were used as the > homenet protocol. If true should we be calling this out more explicitly in > the document? I'm sure we could, but "what is it that the WG wants?" - achieve something that vendors could deploy, in finite time - do another few rounds on protocols, variations, personal peeves, and end up with something like IPSEC? I'm firmly in the "do something that is good enough, and get it deployed" camp, which means "no, we don't do everything-on-top-of-ISIS". 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] routing protocol comparison document and hncp
> One thing that has been mentioned to me is that IS-IS could be used > (with proper TLV additions) to completely replace HNCP, if IS-IS were > used as the homenet protocol. I see that you've been speaking with Abrahamsson. Please let me give you some background. Two years ago, there was a very animated discussion about whether the configuration protocol and the routing protocol should be separate or not. After a lot of energy was spent on the issue, Markus designed HNCP, which went through a few iterations. The chairs judged that WG consensus was achieved, and the configuration protocol is now separate from the routing protocol. Since achieving consensus on this was a lot of work, some of us are somewhat annoyed at Mikael bringing this argument back from the dead at every opportunity. > If true should we be calling this out more explicitly in the document? I seem to recall that I already mentioned that I find your tendency to bring out controversial arguments just before a deadline somewhat offputting. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message Dave Taht writes: > On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar > wrote: > > In message <54ee258e.8060...@gmail.com> > > Brian E Carpenter writes: > > > >> On 26/02/2015 05:14, Mikael Abrahamsson wrote: > >> > On Wed, 25 Feb 2015, Ray Hunter wrote: > >> > > >> >> That way the devices can roam at L3, without all of the nasty side > >> >> effects of re-establishing TPC sessions, or updating > >> >> dynamic naming services, or having to run an L2 overlay network > >> >> everywhere, or having to support protocols that require a > >> >> specialised partner in crime on the server side (mTCP, shim6 et al). > >> > > >> > It's my firm belief that we need to rid clients of IP address dependence > >> > for its sessions. Asking clients to participate in HNCP > >> > only addresses the problem where HNCP is used. > >> > > >> > Fixing this for real would reap benefits for devices moving between any > >> > kind of network, multiple providers, mobile/fixed etc. > >> > >> Violent agreement. This is not a homenet problem; it's an IP problem. > >> In fact, it's exactly why IP addresses are considered harmful in > >> some quarters. Trying to fix it just for homenet seems pointless. > >> http://www.sigcomm.org/ccr/papers/2014/April/000.008 > >> > >>Brian > > > > > > Brian, > > > > Seriously - your paper may be overstating the problem. At least if we > > discount IPv4 and in doing so eliminate NAT we solve a lot of problems > > that never should have existed in the first place. If we carry NAT > > over to IPV6, then shame on us. > > I am sorry, I no longer share this opinion. The pains of renumbering > someones entire home network every time the ISP feels like it, given > the enormous number of devices I have encountered that don't handle it > well, are just too much to bear. I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to ANSNET as part of the NSFNET decommissioning). Not by myself of course, but there were only a few of us on this. It wasn't all that bad and we had about 2,000 things to renumber in hundreds of locations, many of them not manned. Shell scripts and ksh (kerberized rsh, not the Korn shell) made it simpler. The worst was Cisco routers and various old DSU/CSU and other commercial stuff since you had to use "expect" scripts on their CLI rather than just something of the form "ksh fqdn -l root ifconfig newaddr/mask alias" People with root on their workstation that didn't give us acess were given notice. We used interface aliases and gradually took down the old aliases and subnet addresses. Nothing critical was affected. It took a day or two, then bake time, then less than a day to remove aliases. OTOH - Most homes can't run two prefixes for a week or two before taking the old prefix down. And lots of consumer devices don't do aliases. But now days there is DHCP which didn't exist then (and ICMPv6 RS/RA and SLAAC). Are you having problems with the provider not giving you a static IPv6 prefix, but rather changing it on a whim? I also renumbered my home net multiple times, but again, not much pain. Only a few consumer gadgets here have fixed addresses (one because it never renewed DHCP leases and therefore needed a fixed address, but that has since been tossed in e-waste recycling). > The next version of cerowrt will do translation from the external IPv6 > address range to a static internal one (or ones, in the case of > multiple egress gateways), and lacking a standard for such will use > fcxx/8 addressing. I will make it be an option for people to turn off, > but I've had it with being renumbered. Are you suggesting that we add NAT to IPv6? [I ask with disbelief.] I would definitely be turning that off since I have a plenty big and very static IPv6 prefix. I also have a (tiny) static IPv4 prefix so I have no choice but to IPv4 NAT due to its tiny size. A better option might be to use something that switches over faster than a DHCP lease times of days. It seems that ICMPv6 RA can be sent with prefix prefix information TLV with valid lifetime and/or preferred valid lifetime of zero. This is in RFC 4861 on Page 55: - If the prefix is already present in the host's Prefix List as the result of a previously received advertisement, reset its invalidation timer to the Valid Lifetime value in the Prefix Information option. If the new Lifetime value is zero, time-out the prefix immediately (see Section 6.3.5). Would that help? Also, stateful DHCPv6 can invalidate leases (me thinks)? Maybe DHCPv4? Am I mistaken about that? > I am sure this will break stuff, and I don't know what all it will do, > and I intend to find out. Just breaks the end-to-end principle and requires rendezvous and all that ugliness. IMHO it would be better to send an immediate RA with a zero lifetime on the old prefix and a normal lifetime on the new prefix. If hosts don't do the right thing they are in violation of RFC 4861
Re: [homenet] Routing protocol comparison document
In message <17359.1424897...@sandelman.ca> Michael Richardson writes: > Ray Hunter wrote: > > I agree that WiFi roaming is a problem that needs addressing in > > Homenet. > > Yes, but can we rule it out of scope for now? > > Can we agree that it's not strictly a routing problem, and that the set of > solutions that we are considering could be used, and that we could also > explain how to do something like automatically setup capwap using HNCP for > discovery, but that we don't have the head-of-queue block on this item for > now? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- Perhaps consider it two problems, roaming within an administrative domain and roaming into another administrative doamin. The latter is harder to solve. Other than bridging all of the AP within an administrative domain, there is no way to support the former without at least some host change. As I mentioned before, I favor putting a /128 on the loopback and having the routers/APs forward to the interface address of the moment to that /128. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar wrote: > In message <54ee258e.8060...@gmail.com> > Brian E Carpenter writes: > >> On 26/02/2015 05:14, Mikael Abrahamsson wrote: >> > On Wed, 25 Feb 2015, Ray Hunter wrote: >> > >> >> That way the devices can roam at L3, without all of the nasty side >> >> effects of re-establishing TPC sessions, or updating >> >> dynamic naming services, or having to run an L2 overlay network >> >> everywhere, or having to support protocols that require a >> >> specialised partner in crime on the server side (mTCP, shim6 et al). >> > >> > It's my firm belief that we need to rid clients of IP address dependence >> > for its sessions. Asking clients to participate in HNCP >> > only addresses the problem where HNCP is used. >> > >> > Fixing this for real would reap benefits for devices moving between any >> > kind of network, multiple providers, mobile/fixed etc. >> >> Violent agreement. This is not a homenet problem; it's an IP problem. >> In fact, it's exactly why IP addresses are considered harmful in >> some quarters. Trying to fix it just for homenet seems pointless. >> http://www.sigcomm.org/ccr/papers/2014/April/000.008 >> >>Brian > > > Brian, > > Seriously - your paper may be overstating the problem. At least if we > discount IPv4 and in doing so eliminate NAT we solve a lot of problems > that never should have existed in the first place. If we carry NAT > over to IPV6, then shame on us. I am sorry, I no longer share this opinion. The pains of renumbering someones entire home network every time the ISP feels like it, given the enormous number of devices I have encountered that don't handle it well, are just too much to bear. The next version of cerowrt will do translation from the external IPv6 address range to a static internal one (or ones, in the case of multiple egress gateways), and lacking a standard for such will use fcxx/8 addressing. I will make it be an option for people to turn off, but I've had it with being renumbered. I am sure this will break stuff, and I don't know what all it will do, and I intend to find out. Until some far off day where we have stable name to ipv6 address mapping, and vice versa, it is otherwise impossible to have useful ipv6 based services inside the home or small business. > > If we get rid of NAT a big part of the problem just goes away. No > alternate spaces, kludgy rendezvous mechanisms, etc. Using an address > on the loopback gets rid of the multiple interface problem and where > it really matters (ISP router and ISP or DS server reachability) this > has been done with configuration for two decades. The multihoming > failover or roaming are a bit more difficult but things MPTCP is > supposed to address. > > Curtis > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message <54ee258e.8060...@gmail.com> Brian E Carpenter writes: > On 26/02/2015 05:14, Mikael Abrahamsson wrote: > > On Wed, 25 Feb 2015, Ray Hunter wrote: > > > >> That way the devices can roam at L3, without all of the nasty side effects > >> of re-establishing TPC sessions, or updating > >> dynamic naming services, or having to run an L2 overlay network > >> everywhere, or having to support protocols that require a > >> specialised partner in crime on the server side (mTCP, shim6 et al). > > > > It's my firm belief that we need to rid clients of IP address dependence > > for its sessions. Asking clients to participate in HNCP > > only addresses the problem where HNCP is used. > > > > Fixing this for real would reap benefits for devices moving between any > > kind of network, multiple providers, mobile/fixed etc. > > Violent agreement. This is not a homenet problem; it's an IP problem. > In fact, it's exactly why IP addresses are considered harmful in > some quarters. Trying to fix it just for homenet seems pointless. > http://www.sigcomm.org/ccr/papers/2014/April/000.008 > >Brian Brian, Seriously - your paper may be overstating the problem. At least if we discount IPv4 and in doing so eliminate NAT we solve a lot of problems that never should have existed in the first place. If we carry NAT over to IPV6, then shame on us. If we get rid of NAT a big part of the problem just goes away. No alternate spaces, kludgy rendezvous mechanisms, etc. Using an address on the loopback gets rid of the multiple interface problem and where it really matters (ISP router and ISP or DS server reachability) this has been done with configuration for two decades. The multihoming failover or roaming are a bit more difficult but things MPTCP is supposed to address. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I am glad, incidentally, that for the first time, this wg is considering some of the problems wifi has, and growing towards understanding them in more detail. I have long been working on finding answers to these deep, underlying problems - after first identifying some the major ones: https://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be and proposing some solutions to the IEEE that still worked inside the standard (well, obsoleting part of 802.11e entirely) http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf and also proposing some deep changes for 802.11ax (the successor to ac). Work on getting some of that stuff done is proceeding - unfunded, by volunteers that care, in their spare time... (one major set of needed patches: "minstrel-blues" - coupled power and rate control - is out for review on the linux-wireless mailing list and it could used an acked-by because it is great and desperately needed. You don't need to transmit at the highest possible rate when you are right next to the AP, and vice versa) Finally, a few weeks ago, I convinced a major wifi testing house to actually start poking at one subset of the problem, which is multiple stations attempting to transmit at the same time. This test uses a single TCP flow each, 1 up, 1 down, and measures the latency. http://www.candelatech.com/downloads/rtt_fair4be-comparison-box-plot.png This is on the latest and "best" 802.11ac hardware on the retail market, transmitting at the highest possible rate, to 4 stations, under lab conditions. Under load, you presently observe latencies of 50-1000ms, and jitter, same. They only achieved ~ 1/3 the rate of the base mac capability. They haven't tried lower rates, or added interference, nor mixed in multicast, nor tried WDS, or 802.11s, or added stations - any one of which can mess things up by another order or two or *more* of magnitude, I am awaiting further results from them, testing lower rates in particular. But I do hope that they eventually manage to duplicate the kinds of results I have obtained all over the world in conference centers, hotels, and apartment buildings, where the typical latencies I observe can be in the 3-6 second range, and bandwidth, below a few dozen k, at best. This sort of result should be concerning to the people that would like to bridge everything, use range extenders, transmit any multicast at all (and add in new forms of multicast, like nd/hnetd/babel/etc), or have hope that wifi can continue to work at all - in the face of adding lots and lots more (IoT) wifi clients - without some major work on how our APs and client chipsets work at a deep level. And thus, this is why I am not paying a whole lot of attention to the ietf anymore, and sinking more of my energies into finding ways to preserve and repair one of the coolest, most free-ing internet technologies that has has ever existed. And it is also sort of why I am running ethernet or homeplugs everywhere I must. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 27, 2015, at 7:26 AM, Teco Boot wrote: > My call is: keep going, let's solve it. If it takes TRILL, CAPWAP, CPE/cloud > based SDN: so be it. I want to see two- or three-pack high-end wired/wireless > homenet router kits in the shop that will replace our current gear. I'd love it if it didn't require that, but in principle I think this is an avenue worth exploring. Maybe we can have a hackathon in Prague... :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Op 27 feb. 2015, om 12:39 heeft Juliusz Chroboczek > het volgende geschreven: > >>> When performance in dual stack networks with multiple WiFi AP's in homes >>> suffers from homenet protocols, this WG produces dead protocols. > >> Why would homenet cause wifi APs to suffer more than they do today? > > I think Teco was reacting to the suggestion that we perform wifi-wifi > bridging at a larger scale that is done today. I'm not advocating large layer-2 topologies. I prefer to stay away from broadcast storms and other fun. But today's WiFi stack is build on the assumption that an SSID equals an IP subnet. WiFi handover is within an SSID. My personal goal is to set up a standards based CAT5 + WiFi homenet that performs well. I can replace all my switches and wireless routers with the monthly budget for cable and mobile connections. But I cannot buy something that works, unless I tenfold the budget and buy an enterprise solution. My call is: keep going, let's solve it. If it takes TRILL, CAPWAP, CPE/cloud based SDN: so be it. I want to see two- or three-pack high-end wired/wireless homenet router kits in the shop that will replace our current gear. Teco > We'd need to actually try > it out and perform some serious measurements in order to be sure (no, I'm > not volunteering), but I'd expect it to suck, for at least the following > reasons: > > 1. 802.11 bridging is weird, there are some restrictions on the possible > topologies (but I don't recall the exact details). > > 2. I'd expect broadcast/multicast to be fun, especially if the different > APs are set up to interfere. > > 3. Things like TRILL aside, bridging performs spanning tree routing, so > unless you design your topology carefully, you have a good chance of > pushing all of your traffic through a slow link. Never mind avoiding > self-interference. > > I've already expressed my opinion (sometimes way too strongly, sorry Ted) > that I'm opposed to reliance on L2 bridging until somebody shows how it > can be made to work with good performance in a hybrid network. The 802.11s > experience doesn't encourage us to be optimistic. > > -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
>> When performance in dual stack networks with multiple WiFi AP's in homes >> suffers from homenet protocols, this WG produces dead protocols. > Why would homenet cause wifi APs to suffer more than they do today? I think Teco was reacting to the suggestion that we perform wifi-wifi bridging at a larger scale that is done today. We'd need to actually try it out and perform some serious measurements in order to be sure (no, I'm not volunteering), but I'd expect it to suck, for at least the following reasons: 1. 802.11 bridging is weird, there are some restrictions on the possible topologies (but I don't recall the exact details). 2. I'd expect broadcast/multicast to be fun, especially if the different APs are set up to interfere. 3. Things like TRILL aside, bridging performs spanning tree routing, so unless you design your topology carefully, you have a good chance of pushing all of your traffic through a slow link. Never mind avoiding self-interference. I've already expressed my opinion (sometimes way too strongly, sorry Ted) that I'm opposed to reliance on L2 bridging until somebody shows how it can be made to work with good performance in a hybrid network. The 802.11s experience doesn't encourage us to be optimistic. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Op 26 feb. 2015, om 13:56 heeft Mark Townsley het > volgende geschreven: > > > > On Thu, Feb 26, 2015 at 1:28 PM, Teco Boot wrote: > > > Op 25 feb. 2015, om 22:00 heeft Mark Townsley het > > volgende geschreven: > > > > > > > > > > > >> On Feb 25, 2015, at 9:50 PM, Michael Richardson > >> wrote: > >> > >> > >> Ray Hunter wrote: > >>> I agree that WiFi roaming is a problem that needs addressing in > >>> Homenet. > >> > >> Yes, but can we rule it out of scope for now? > > > > Yes, we can. > > > > I think the WG needs to focus on securing success before taking on wild > > success at this moment in time. > > When performance in dual stack networks with multiple WiFi AP's in homes > suffers from homenet protocols, this WG produces dead protocols. > > Why would homenet cause wifi APs to suffer more than they do today? Worst > case, wifi remains a single bridged dual-stack LAN. Best case, routing is > possible and hosts are resilient to IP address changes. Somewhere in between > HNCP helps with auto-configuration in one way or another. I don't see how the > status quo path we are without Homenet can be worse with Homenet (separating > out here whatever overhead of getting homenet itself deployed). Today's WiFi stacks typically prefer staying on connected SSID, until the link is really bad and breaks. Then the alternative SSID is selected, IP address is flushed and a new IP address is requested. This takes time. Connections break. Staying on the same SSID has advantages: IP address survives handover so connections continue to work. Also smarter handover can take place, this eliminates the bad link. So my opinion is that the homenet protocols shall be able to support a layer-2 backbone over a wired backbone connecting a set of access points. Or provide an alternative that works well over a layer-3 backbone. I'm all ears. Teco > > I am more hopeful. I hope we can enable 802.11 fast handover by distributing > the required info. Still open question how to route or bridge over the wired > backbone. > > certainly do not want to inhibit your hope in anyway. Indeed, history shows > that we successful protocols are often deployed in ways the designers do not > expect. Just trying to nudge the group towards a bit more focus in order to > ship sooner rather than later. > > - Mark > > > Teco > > > > > > - Mark > > > >> > >> Can we agree that it's not strictly a routing problem, and that the set of > >> solutions that we are considering could be used, and that we could also > >> explain how to do something like automatically setup capwap using HNCP for > >> discovery, but that we don't have the head-of-queue block on this item for > >> now? > >> > >> -- > >> Michael Richardson , Sandelman Software Works > >> -= IPv6 IoT consulting =- > >> > >> > >> > >> ___ > >> 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] Routing protocol comparison document
On Thu, Feb 26, 2015 at 1:28 PM, Teco Boot wrote: > > > Op 25 feb. 2015, om 22:00 heeft Mark Townsley het > volgende geschreven: > > > > > > > > > > > >> On Feb 25, 2015, at 9:50 PM, Michael Richardson > wrote: > >> > >> > >> Ray Hunter wrote: > >>> I agree that WiFi roaming is a problem that needs addressing in > >>> Homenet. > >> > >> Yes, but can we rule it out of scope for now? > > > > Yes, we can. > > > > I think the WG needs to focus on securing success before taking on wild > success at this moment in time. > > When performance in dual stack networks with multiple WiFi AP's in homes > suffers from homenet protocols, this WG produces dead protocols. Why would homenet cause wifi APs to suffer more than they do today? Worst case, wifi remains a single bridged dual-stack LAN. Best case, routing is possible and hosts are resilient to IP address changes. Somewhere in between HNCP helps with auto-configuration in one way or another. I don't see how the status quo path we are without Homenet can be worse with Homenet (separating out here whatever overhead of getting homenet itself deployed). > I am more hopeful. I hope we can enable 802.11 fast handover by > distributing the required info. Still open question how to route or bridge > over the wired backbone. > certainly do not want to inhibit your hope in anyway. Indeed, history shows that we successful protocols are often deployed in ways the designers do not expect. Just trying to nudge the group towards a bit more focus in order to ship sooner rather than later. - Mark > Teco > > > > > > - Mark > > > >> > >> Can we agree that it's not strictly a routing problem, and that the set > of > >> solutions that we are considering could be used, and that we could also > >> explain how to do something like automatically setup capwap using HNCP > for > >> discovery, but that we don't have the head-of-queue block on this item > for > >> now? > >> > >> -- > >> Michael Richardson , Sandelman Software Works > >> -= IPv6 IoT consulting =- > >> > >> > >> > >> ___ > >> 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] Routing protocol comparison document
> Op 25 feb. 2015, om 22:00 heeft Mark Townsley het > volgende geschreven: > > > > > >> On Feb 25, 2015, at 9:50 PM, Michael Richardson >> wrote: >> >> >> Ray Hunter wrote: >>> I agree that WiFi roaming is a problem that needs addressing in >>> Homenet. >> >> Yes, but can we rule it out of scope for now? > > Yes, we can. > > I think the WG needs to focus on securing success before taking on wild > success at this moment in time. When performance in dual stack networks with multiple WiFi AP's in homes suffers from homenet protocols, this WG produces dead protocols. I am more hopeful. I hope we can enable 802.11 fast handover by distributing the required info. Still open question how to route or bridge over the wired backbone. Teco > > - Mark > >> >> Can we agree that it's not strictly a routing problem, and that the set of >> solutions that we are considering could be used, and that we could also >> explain how to do something like automatically setup capwap using HNCP for >> discovery, but that we don't have the head-of-queue block on this item for >> now? >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> ___ >> 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] Routing protocol comparison document
> On Feb 25, 2015, at 9:50 PM, Michael Richardson wrote: > > > Ray Hunter wrote: >> I agree that WiFi roaming is a problem that needs addressing in >> Homenet. > > Yes, but can we rule it out of scope for now? Yes, we can. I think the WG needs to focus on securing success before taking on wild success at this moment in time. - Mark > > Can we agree that it's not strictly a routing problem, and that the set of > solutions that we are considering could be used, and that we could also > explain how to do something like automatically setup capwap using HNCP for > discovery, but that we don't have the head-of-queue block on this item for > now? > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > 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] Routing protocol comparison document
Ray Hunter wrote: > I agree that WiFi roaming is a problem that needs addressing in > Homenet. Yes, but can we rule it out of scope for now? Can we agree that it's not strictly a routing problem, and that the set of solutions that we are considering could be used, and that we could also explain how to do something like automatically setup capwap using HNCP for discovery, but that we don't have the head-of-queue block on this item for now? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 26/02/2015 05:14, Mikael Abrahamsson wrote: > On Wed, 25 Feb 2015, Ray Hunter wrote: > >> That way the devices can roam at L3, without all of the nasty side effects >> of re-establishing TPC sessions, or updating >> dynamic naming services, or having to run an L2 overlay network everywhere, >> or having to support protocols that require a >> specialised partner in crime on the server side (mTCP, shim6 et al). > > It's my firm belief that we need to rid clients of IP address dependence for > its sessions. Asking clients to participate in HNCP > only addresses the problem where HNCP is used. > > Fixing this for real would reap benefits for devices moving between any kind > of network, multiple providers, mobile/fixed etc. Violent agreement. This is not a homenet problem; it's an IP problem. In fact, it's exactly why IP addresses are considered harmful in some quarters. Trying to fix it just for homenet seems pointless. http://www.sigcomm.org/ccr/papers/2014/April/000.008 Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> On 25 Feb 2015, at 16:58, Ted Lemon wrote: > >> On Feb 25, 2015, at 10:47 AM, Ray Hunter wrote: >> One suggestion from my side for handling WiFi roaming is for these clients >> to incorporate a software loopback interface that does not renumber, and is >> always up, and these roaming clients also actively take part in HNCP, and >> the Homenet routing protocol as "stub routers." > > Something like this is currently done with Babel, but it's not a complete > solution because it requires Babel-specific modifications on the client. > The proposal to have a single bridged WiFi broadcast domain would eliminate > this problem, at the cost of some substantial pain in terms of how to set > that up automatically and in terms of performance, which clearly would suffer > from the expanded broadcast domain. And there's also the problem of > differentiating backbone wifi links from wifi leaf networks. Agreed. For the purposes of this discussion, I think a soft requirement on a stub-only implementation of the chosen Homenet routing protocol on a host OS could be an interesting differentiator. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Wed, 25 Feb 2015, Ray Hunter wrote: That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). It's my firm belief that we need to rid clients of IP address dependence for its sessions. Asking clients to participate in HNCP only addresses the problem where HNCP is used. Fixing this for real would reap benefits for devices moving between any kind of network, multiple providers, mobile/fixed etc. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 25, 2015, at 10:47 AM, Ray Hunter wrote: > One suggestion from my side for handling WiFi roaming is for these clients to > incorporate a software loopback interface that does not renumber, and is > always up, and these roaming clients also actively take part in HNCP, and the > Homenet routing protocol as "stub routers." Something like this is currently done with Babel, but it's not a complete solution because it requires Babel-specific modifications on the client. The proposal to have a single bridged WiFi broadcast domain would eliminate this problem, at the cost of some substantial pain in terms of how to set that up automatically and in terms of performance, which clearly would suffer from the expanded broadcast domain. And there's also the problem of differentiating backbone wifi links from wifi leaf networks. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Mikael Abrahamsson wrote: On Fri, 20 Feb 2015, Teco Boot wrote: Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Within the current framework to solve this problem with what exists today when it comes to clients, I would say we need either: 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the APs using the same SSID, so the SSID can have the same L2 domain. This would probably mean we want to increase MTU on the physical links to avoid fragmentation. Messy. Possibly we could advertise lower MTU on the wifi network to minimize fragmentation if we don't raise MTU. 2. We set up some kind of L2 switching domain between the APs. This would require VLAN support in the HGWs, and something to set this up with loop avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as control plane, that way we could possibly run the same IGP for both L2 and L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds like an understatement. Frankly, I don't know how to solve this without a lot of complication. We need clients to be able to change IPv6 addresses without losing existing connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two connections at once and inform the application that one address is going away soon so it can do its thing to try to handle this? I agree that WiFi roaming is a problem that needs addressing in Homenet. One suggestion from my side for handling WiFi roaming is for these clients to incorporate a software loopback interface that does not renumber, and is always up, and these roaming clients also actively take part in HNCP, and the Homenet routing protocol as "stub routers." That way the devices can roam at L3, without all of the nasty side effects of re-establishing TPC sessions, or updating dynamic naming services, or having to run an L2 overlay network everywhere, or having to support protocols that require a specialised partner in crime on the server side (mTCP, shim6 et al). YMMV. -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> So, there are limitations like: > struct router all_the_routers[256]; > > and then there are protocol collapses due to taking the entire channel for > adjacencies as happened with OLPC. We're in full agreement about most of what you say. Are you happy with the current wording, or are you suggesting I change something? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Juliusz Chroboczek wrote: >> So assuming some decent high-power 802.11ac in the Bradford house >> (http://en.wikipedia.org/wiki/Eight_Is_Enough) to link the per-room router to >> legacy 802.11b and per-person (phone) router to BTLE/PAN, it means we have >> about 30 routers on the wifi. > I'm under opposing pressures relating to scaling. A lot of people, like > you, seem to think it's irrelevant, some others feel very strongly about it. I'm not claiming its irrelevant, I'm claiming that it won't bite us all at once. I accept that some homenet-type installations will go up to 250 routers (which is only 1 order of magnitude larger than 30, btw), but they won't go up to 250 without some thought about it. So I totally agree with you: > The thinking is that if Homenet routers are cheaply and widely available, > then people will use them for larger deployments; no amount of legislating > such uses out of scope will change that fact. The obvious example would > be a hotel: why pay for a professionally installed network when you can > just plug in a bunch of $40 Homenet routers and be done with your customer > network. I can well imagine a hotel using 200 routers. but, what I'm claiming is that the 200 routers won't be in a single wifi channel.The network will get a small amount of tuning, if only because the walls will get in the way and some people will have to run some cables in places. That's exactly what most of think: that to scale things we need wired back hauls, so while we hit 250 routers in the routing table, we don't have to accomodate 250 routers forming adjacencies on a single wifi channel. > If hotels don't meet your fancy -- think schools, think appartment blocks > in third world countries, think hippy communes. Do we wish to explicitly > support such use cases? Hopefully not. But do we wish to have our > protocols collapse just because we didn't have the foresight to avoid > gratuitious limitations? So, there are limitations like: struct router all_the_routers[256]; and then there are protocol collapses due to taking the entire channel for adjacencies as happened with OLPC. The trickle mechanism of DNCP ought to deal with that. What we need to do is to make sure that whatever parameters we pick for scaling fail in a safe way when exceeded. I'd rather that the router which has HomeNet v1 parameters in it just stops when it reaches some limit rather than cause congestion collapse. The router will then get replaced (or better, reflashed), but if not, it won't get in the way of the newer, better tuned devices. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> So assuming some decent high-power 802.11ac in the Bradford house > (http://en.wikipedia.org/wiki/Eight_Is_Enough) to link the per-room router to > legacy 802.11b and per-person (phone) router to BTLE/PAN, it means we have > about 30 routers on the wifi. I'm under opposing pressures relating to scaling. A lot of people, like you, seem to think it's irrelevant, some others feel very strongly about it. The current version of the draft has this to say: Experts appear to disagree on the expected size of a Homenet: we have heard estimates ranging from just one router up to 250 routers. In any case, while scaling beyond a few thousand nodes is not likely to be relevant to Homenet in the foreseeable future, the Homenet protocols, if successful, will be repurposed to larger networks, whether we like it or not, and it is desirable to use a protocol that scales well. The thinking is that if Homenet routers are cheaply and widely available, then people will use them for larger deployments; no amount of legislating such uses out of scope will change that fact. The obvious example would be a hotel: why pay for a professionally installed network when you can just plug in a bunch of $40 Homenet routers and be done with your customer network. I can well imagine a hotel using 200 routers. If hotels don't meet your fancy -- think schools, think appartment blocks in third world countries, think hippy communes. Do we wish to explicitly support such use cases? Hopefully not. But do we wish to have our protocols collapse just because we didn't have the foresight to avoid gratuitious limitations? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Hi Michael, The work on the document is being done on https://github.com/choppsv1 and I try to keep an up-to-date version of the generated files on http://www.pps.univ-paris-diderot.fr/~jch/private/draft-mrw-homenet-rtg-comparison-XX.html http://www.pps.univ-paris-diderot.fr/~jch/private/draft-mrw-homenet-rtg-comparison-XX.txt > So the gateway machine (the 6LBR) will run the HOMENET routing protocol and > the LLN routing protocol (RPL, or some other mesh-under protocol), but the > HOMENET routing protocol will never be run by the sensors. I've vastly expanded the section about stub networks; please check if it suits you better or whether you wish anything added. > It also, btw, makes it unable to run over 15.4, Noted, will add. > 3) metrics. > We don't know how we will assign link metrics, so we don't know how important > X-bit metrics are. I've expanded the section about metrics. The IS-IS part is still woefully inadequate. > 4) convergence over 802.11 MAC... I've expanded this section. > 5) some amount of "my processor is slower than yours and still ran protocol > XYZ" > (http://www.phespirit.info/montypython/four_yorkshiremen.htm) Not my choice, sorry. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
{my comments before reading the ~170 messages on this thread.}
comparison> [Isn't it also the case that the HOMENET routing protocol will
comparison> be implemented on lower-end embedded devices, such as nodes in
comparison> a low-power wireless network? What is considered to be a
comparison> reasonable low-end system requirement for a HOMENET router? --
comparison> mrw]
As specified in the architecture document, section 3.5.1:
rfc7368> In this homenet architecture, LLNs and other specialised networks
rfc7368> are considered stub areas of the homenet and are thus not expected
rfc7368> to act as a transit for traffic between more traditional media.
So the gateway machine (the 6LBR) will run the HOMENET routing protocol and
the LLN routing protocol (RPL, or some other mesh-under protocol), but the
HOMENET routing protocol will never be run by the sensors.
The section 9, security consideration does indeed miss the mark.
Given that HNCP/DNCP would take care of "higher" identity and authorization
operations, and would produce some set of anchored credentials for the
routing protocols. the security question is not:
does the protocol support HMAC-FOOBAR.
The questions are rather:
1) how does the cost and convergence of the protocol change if security
considerations force the use of (secured 1:1) unicast for all messages
rather than multicast?
2) does the protocol include an asymetric method for authentication?
We know that multicast is hard to secure using symetric methods as all
parties involved can impersonate any other party. To what extent this is a
concern in homenet is not yet known, but on the other hand, in every
risk/cost/benefit analysis, if the cost of securing things is low enough,
it may make no sense not to...
In section 10, it is useful to know if multicast is supported; it is telling
that nobody has implemented multicast routing in ISIS. It would be
interesting to know how successful multicast routing is in other Link State
and Distance Vector protocols are. (Can Babel just include DVMRP for
instance? Why did nobody implement multicast for ISIS?)
A question which I did not see addressed is about debugging.
How easily can one (perhaps more capable, or having better management
interface) router give diagnostics about problems that might be occuring
elsewhere in the homenet?
Can one deal with broken/mis-having peer routers in a unilateral fashion?
(Consider the ability for parents to mitigate a dispute among technically
astute teenagers, while keeping both online)
Can one get diagnostics from just watching the traffic?
As much as we expect the network to be auto-tuning and auto-configuring and
self-healing; if people do get involved, which one is easier to understand?
{my comments after reading the thread}
Important things that I took out of the discussion:
1) Source address specific routing likely doesn't exist in some hardware.
My response is mostly: we often no idea what hardware can due to NDAs.
The movement (see netdev01.org conference this past week) is towards
having hardware which just lives under the linux kernel and its
configuration is transparent to "userspace"
2) Layer-2 aspect of ISIS.
> We didn't discuss the fact that Babel runs over UDP, while IS-IS runs
> directly over layer 2. This has a number of consequences, most notably
> related to ease of implementation, portability, and the ability to run
> over tunnels (say, GRE or OpenVPN in tun mode).
It also, btw, makes it unable to run over 15.4, since there is no ethernet
type. 6lo also has been defining ways to run IPv6/6lowPAN over other media
that have never seen IPv6. Probably doesn't matter as long as these are
really *LLNs*, but it could be that some of these technologies (802.15.4g has
much bigger packet sizes...) get used in new and unanticipated ways in the
IPv6 is dominant future.
3) metrics.
We don't know how we will assign link metrics, so we don't know how important
X-bit metrics are.
4) convergence over 802.11 MAC...
5) some amount of "my processor is slower than yours and still ran protocol XYZ"
(http://www.phespirit.info/montypython/four_yorkshiremen.htm)
6) discussion about multicast: do we even need it. With responses from
"nobody does it" to "we have 10^X customers" right now.
7) one comment was: "we need topology, so babel won't work for us."
8) some conversation about whether or not one can get link state for a wired
connection. I don't see that it matters: there could always be another
$9 layer-2 switch between the two routers. That's the problem with
layer-2 switching, we can't see it.
9) then there was a discussion of multiple (wifi) APs, how to either L2-mesh
them to
accomplish mobility, or to do L3-roaming by having stub versions of
homenet routing protocol and/or RIP.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Work
Re: [homenet] Routing protocol comparison document
Margaret Wasserman wrote: >> More generally, I think -01 puts undue stress on scaling and >> convergence speed. Sections 3 and 4 can be summarised as "any >> reasonable routing protocol scales sufficiently well and converges >> sufficiently fast for the needs of Homenet". > The sections in the document started from a list of routing > features/properties that were discussed in the WG meeting. There was > quite a bit of discussion of scaling. In particular, there was a lot > of discussion of how these protocols will scale "on Wi-Fi". I wasn't > entirely sure, during the meeting, what special requirements there are > for a routing protocol to scale well on Wi-Fi vs. other link types, but > perhaps someone on the WG mailing list can clarify? Counter-intuitively for a broadcast media, multicast on wifi is very expensive because not all stations can hear each other, and some stations require higher power lower-speed transmissions. So each time the AP transmits a multicast packet, it transmits at the highest power, using the slowest method. Many high-end APs (like we use at IETF), will actually deliver multicast via a series of L2 unicast messages. What this means is that a protocol that depends upon multicast to achieve flooding may perform very poorly over wifi compared to a protocol which forms 1:1 links associations. Now, does this matter in the home: how many homenet capable routers do we expect to create adjacencies over wifi? I will claim that over time, if we get this right, that it will be larger than what we see today in the home (which is 1 to 3 APs), but it's on the order of O(p + r): p=number of people in home, r=number of rooms. So assuming some decent high-power 802.11ac in the Bradford house (http://en.wikipedia.org/wiki/Eight_Is_Enough) to link the per-room router to legacy 802.11b and per-person (phone) router to BTLE/PAN, it means we have about 30 routers on the wifi. How much multicast and how much unicast traffic results? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
>>> ISIS already has these kinds of "rate-limiting" of how things are >>> happening. In modern core routers this is often tuned >> If you need to tune it, it's not smart enough. > To be fair, network operators have somewhat different priorities, Yes, that was a cheap shot. Sorry, I couldn't resist. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 2/19/15 9:22 AM, Juliusz Chroboczek wrote: >>> smart rate limiting. > >> ISIS already has these kinds of "rate-limiting" of how things are >> happening. In modern core routers this is often tuned > > If you need to tune it, it's not smart enough. To be fair, network operators have somewhat different priorities, e.g. rapid convergence at the expense of cpu may be ok, no effective bandwidth constraints when you're talking about an igp running on a gig or 10 gig point-to-point link... > -- Juliusz > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > signature.asc Description: OpenPGP digital signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Sat, Feb 21, 2015 at 07:02:44AM +0100, Mikael Abrahamsson wrote: > >NO, just between the first-hop (homenet) routers. Should work with > >unchanged > >of the shelf crap-APs as long as they're attached to a homenet router. > > Could someone please explain to me how this is supposed to work? How do > the first-hop routers figure out where the client is? Do we do /128 route > injection into the homenet for active IPv6 addresses in that /64, and > announce the same /64 everywhere, and then we use proxy-nd for all off-L2 > active IPs? I guess we need to handle IPv4 as well, so we use proxy-arp > for that? I was referring to eg: https://tools.ietf.org/html/draft-hertoghs-lisp-mobility-use-cases-01 and available commercial implementations, eg: from cisco for this (google lisp host mobility and try to ignore all the lisp details ;-)). I haven't tried to figure out all details and whether/how we would want to adopt a similar scheme to homenet. Something like: -> a first-hop-router would need to be able to detect presence of a roaming client. Probably based on MAC-address. And then generate the /128 (and /32) prefix for the clients address. Thats effectivly what LISP does, but they do not need to only create a route but feed into their database. -> for seamless mobility, you'd need to have on all subnets for the default-router the same virtual MAC address (eg: VRRP). Thats also someting set up with LISP. This ensures that traffic sent by the client will continue to be forwarded after roamin. -> What i couldn't figure out quickly yet is how DHCP updates to the client are dealt with especially default-router IP address. Cheers Toerless > Mikael Abrahamssonemail: swm...@swm.pp.se -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Toerless Eckert wrote: On Fri, Feb 20, 2015 at 02:57:21PM +0100, Mikael Abrahamsson wrote: L3 - route injection (got a routing protocol there already, use it) This sounds like it needs at least a coordination protocol between the APs? NO, just between the first-hop (homenet) routers. Should work with unchanged of the shelf crap-APs as long as they're attached to a homenet router. Could someone please explain to me how this is supposed to work? How do the first-hop routers figure out where the client is? Do we do /128 route injection into the homenet for active IPv6 addresses in that /64, and announce the same /64 everywhere, and then we use proxy-nd for all off-L2 active IPs? I guess we need to handle IPv4 as well, so we use proxy-arp for that? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 20, 2015 at 02:57:21PM +0100, Mikael Abrahamsson wrote: > >L3 - route injection (got a routing protocol there already, use it) > > This sounds like it needs at least a coordination protocol between the APs? NO, just between the first-hop (homenet) routers. Should work with unchanged of the shelf crap-APs as long as they're attached to a homenet router. Cheers Toerless ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> On 20.2.2015, at 22.01, Dave Taht wrote: > On Fri, Feb 20, 2015 at 11:34 AM, Steven Barth wrote: >> >> Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon : >>> Hm, I will have to try it out. Is it in a distribution? >> >> ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. >> >> Manual configuration without hncp is a bit awkward since you need to name >> each link manually and on every router configure the resolver (e.g. >> dnsmasq). I guess we might want to provide a little example for 2 links at >> some point. > I would like to deploy hncp in my upcoming make-wifi-fast testbed. > However the biggest headache is ensuring that all the routers > inbetween have hncp burned into them, and are only acting as relays as > I generally only obtain a few (/60) real IPv6 prefixes per GW and they > only need to be on the APs. > > GW1 - routerA - routerB - routerC - routerD - AP1 > | > GW2 - routerE - routerF - routerG - routerH - AP2 > | > AP3 > > GW3 ... > > (the actual topology of the testbed is way more complex than this > (covering ethernet, wifi, and moca) and I am not going into it here) > > 1) is there a way to configure hncpd as purely a relay, and NOT do any > address assignment at all on routers B,C,D,F,G,H? In theory (=spec), but not in current implementation (I _think_). You do not really need non-linklocal addresses for HNCP, or routing protocol, so as long as there are no hosts on the link.. (traceroute is a bitch though given just linklocals) As workaround in current implementation, if you set it to assign e.g. /80 per link used for your intermediate links, you would have almost all of address space left; however, in your case, I am not sure you can even afford to split one /64 for that purpose. > 2) have you tested that it is indeed possible to get the separate ipv6 > prefixes from GW1,GW2,GW3 to AP1,AP2, AP3? Yes. > 3) Can ULA and "Real" address assignment be distinguished along the > way? I have no problem assigning ULAs to the routers, but dont want to > use up real addresses on them. In theory (=spec), not in current implementation (ULA is actively discouraged in current impl, I cannot remember if there was option to override). > 4) What happens when someone pulls the plug on GW1, it reboots, and > gets a new Ipv6 subnet (I have seen comcast do this to me > every time that happens with the code I have in place now - no > retraction, and I go through hell manually eliminating every former > prefix from the network. Yes. I have upses. And cerowrt, at least, > stays up for 90+ days without a problem. But it happens and sucks when > it does) Renumbering should just work as usual. I.e. rest of nodes should learn of the new prefix, and old one should disappear. -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 20, 2015 at 11:34 AM, Steven Barth wrote: > > > Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon : >>Hm, I will have to try it out. Is it in a distribution? > > ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. > > Manual configuration without hncp is a bit awkward since you need to name > each link manually and on every router configure the resolver (e.g. dnsmasq). > I guess we might want to provide a little example for 2 links at some point. I would like to deploy hncp in my upcoming make-wifi-fast testbed. However the biggest headache is ensuring that all the routers inbetween have hncp burned into them, and are only acting as relays as I generally only obtain a few (/60) real IPv6 prefixes per GW and they only need to be on the APs. GW1 - routerA - routerB - routerC - routerD - AP1 | GW2 - routerE - routerF - routerG - routerH - AP2 | AP3 GW3 ... (the actual topology of the testbed is way more complex than this (covering ethernet, wifi, and moca) and I am not going into it here) 1) is there a way to configure hncpd as purely a relay, and NOT do any address assignment at all on routers B,C,D,F,G,H? 2) have you tested that it is indeed possible to get the separate ipv6 prefixes from GW1,GW2,GW3 to AP1,AP2, AP3? 3) Can ULA and "Real" address assignment be distinguished along the way? I have no problem assigning ULAs to the routers, but dont want to use up real addresses on them. 4) What happens when someone pulls the plug on GW1, it reboots, and gets a new Ipv6 subnet (I have seen comcast do this to me every time that happens with the code I have in place now - no retraction, and I go through hell manually eliminating every former prefix from the network. Yes. I have upses. And cerowrt, at least, stays up for 90+ days without a problem. But it happens and sucks when it does) > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Agree. I would not architect around multi-hop multicast, subnet OK, targeted probably. Not sure everyone has had the pleasure of running large IP multicast infrastructures running video, it is a wonderful challenge. It also has the side benefit of encouraging poorly designed applications. Interoperability on even core routers for IP multicast barely exists. In a home environment, although smaller, will be even less wonderful. Just the race conditions between PIM and the IGP are always challenging. On 2/20/15, 1:50 PM, "Joel M. Halpern" wrote: >It seems pretty clear that over time, the bulk of video will be unicast, >in order to meet on-demand needs. There will always be a few items that >folks really want to watch live, and thus where multicast may add value. > But making multicast the design driver for home networking >archtiecture seems backwards to me. > >Yours, >Joel > >On 2/20/15 1:22 PM, Dave Taht wrote: >> On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson >>wrote: >>> On Fri, 20 Feb 2015, Toerless Eckert wrote: >>> So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. >>> >>> >>> I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD >>>when >>> they receive two simultaneous IPTV streams when doing channel >>>switching. >>> >>> So it's not only about bandwidth, but about how much traffic these >>>kinds of >>> devices are designed to receive. >>> >>> Also, remember that we're going to 4k IPTV streams that might be in >>>the 20 >>> megabit/s range, and we might be doing multiples of them. All devices >>>on the >>> subnet will receive this if there is no MLD/PIM snooping precent. >> >> Is there a formal definition of IPTV? as used here, it seems to imply >>multicast. >> >> Frankly, until now, I was expecting the world to go to a HAS model for >>content, >> especially big content. >> >>> >>> -- >>> Mikael Abrahamssonemail: swm...@swm.pp.se >>> >>> ___ >>> 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] Routing protocol comparison document
Am 19. Februar 2015 20:05:56 MEZ, schrieb Ted Lemon : >Hm, I will have to try it out. Is it in a distribution? ohybridproxy in openwrt. It's mainly useful with hnetd (hncp) though. Manual configuration without hncp is a bit awkward since you need to name each link manually and on every router configure the resolver (e.g. dnsmasq). I guess we might want to provide a little example for 2 links at some point. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
It seems pretty clear that over time, the bulk of video will be unicast, in order to meet on-demand needs. There will always be a few items that folks really want to watch live, and thus where multicast may add value. But making multicast the design driver for home networking archtiecture seems backwards to me. Yours, Joel On 2/20/15 1:22 PM, Dave Taht wrote: On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson wrote: On Fri, 20 Feb 2015, Toerless Eckert wrote: So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when they receive two simultaneous IPTV streams when doing channel switching. So it's not only about bandwidth, but about how much traffic these kinds of devices are designed to receive. Also, remember that we're going to 4k IPTV streams that might be in the 20 megabit/s range, and we might be doing multiples of them. All devices on the subnet will receive this if there is no MLD/PIM snooping precent. Is there a formal definition of IPTV? as used here, it seems to imply multicast. Frankly, until now, I was expecting the world to go to a HAS model for content, especially big content. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ 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] Routing protocol comparison document
On Fri, Feb 20, 2015 at 10:10 AM, Mikael Abrahamsson wrote: > On Fri, 20 Feb 2015, Toerless Eckert wrote: > >> So foremost, it would be good to understand if there really is home L2 >> equipment that MUST see MLD to operate correctly. Otherwise i'd happily >> ignore the problem and say there is enough bandwidth to just NOT DO snooping >> but have multicast be flooded in the L2 segments. > > > I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when > they receive two simultaneous IPTV streams when doing channel switching. > > So it's not only about bandwidth, but about how much traffic these kinds of > devices are designed to receive. > > Also, remember that we're going to 4k IPTV streams that might be in the 20 > megabit/s range, and we might be doing multiples of them. All devices on the > subnet will receive this if there is no MLD/PIM snooping precent. Is there a formal definition of IPTV? as used here, it seems to imply multicast. Frankly, until now, I was expecting the world to go to a HAS model for content, especially big content. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Markus Stenberg wrote: - have clients talk stub RP + stub HNCP, be done with it Oooh, if we want to require changes to clients, I have all kinds of ideas how to solve this in other ways than you propose. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Toerless Eckert wrote: So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I know of ATA (VoIP) devices with 10/half uplinks that fall over HARD when they receive two simultaneous IPTV streams when doing channel switching. So it's not only about bandwidth, but about how much traffic these kinds of devices are designed to receive. Also, remember that we're going to 4k IPTV streams that might be in the 20 megabit/s range, and we might be doing multiples of them. All devices on the subnet will receive this if there is no MLD/PIM snooping precent. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Lets hope UPnP/DLNA are starting to consider to cooperate with IETF on > service discovery. "Cooperate" is such a strong word. :) They are aware of the issue, they will be kept informed as to how the issue is progressing and what homenet and dnsext are doing to tackle the issue, and they know what their options are. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Thanks, Barbara. Lets hope UPnP/DLNA are starting to consider to cooperate with IETF on service discovery. On Fri, Feb 20, 2015 at 02:37:38PM +, STARK, BARBARA H wrote: > > There are good proposal how to do servicce discovery in homenets or the > > like with DNS-SD (/mDNS), but i think we should still worry about > > compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are > > IMHO better solved with router-level "proxy" > > solutions than with ASM IP multicast. > > FYI. I did a presentation to DLNA (which has a lot of key UPnP people) that > warned them to start thinking about service discovery in the multi-router > world, and the world where more and more Wi-Fi APs are limiting the multicast > that makes it to Wi-Fi devices. I mentioned the DNS-SD proxy work, homenet, > and told them: > " - People have started to study the current quantity of multicast traffic > and its impact on power consumption by battery-operated Wi-Fi devices. > http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 > http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-00 > - Concern is growing and proposals are starting to appear for ways to > decrease the quantity of multicast messages. > http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 " > > My recommendations were that they had 2 basic options of either also > supporting DNS-SD / mDNS for service discovery, or defining a SSDP proxy > similar to what I expect will be done for DNS-SD. Anyway, I told them I'd > keep them updated on the state of affairs regarding this issue. > Barbara -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Hi Barbara, > OTT video does not use multicast. IPTV deployments do use multicast. Those > that I'm aware of require use of the provider-supplied CE router, which has > an IGMP proxy (and MLD proxy if IPv6 multicast is supported) for LAN-to-WAN > multicast management. Where Wi-Fi distribution of these multicast streams is > supported, it is only done on a dedicated (and highly managed and somewhat > proprietary) Wi-Fi network, that is distinct from the general-purpose (and > not "professionally" managed) Wi-Fi network. The LAN interfaces of the > provider-supplied CE router do tend to have IGMP/MLD snooping, to keep from > flooding the general-purpose network interfaces with large multicast streams. > There may also be a coax networking interface. If there is, this also tends > to be dedicated and highly managed. Where Ethernet is used for distribution > of multicast, it is done so that the provider STBs are all attached to the > provider CE router via the same Ethernet port (and no other devices use that > port) and the re are no intervening routers. I mentioned at the last IETF that I expect some "home networks" to have managed and unmanaged segments. I don't consider the dedicated, managed segments to be part of the homenet domain. I would hope that the provider-supplied CE router would support homenet on its general purpose network interfaces. > > I'd be curious to learn about multicast IPTV deployments that allow users to > supply their own CE routers and send multicast streams on network segments > that are also used for general-purpose home networking (especially > general-purpose Wi-Fi networks). The above is correct. Provider-supplied CPEs are currently necessary and intermediate routers are not supported. The TV streams can be on a separate VLAN. But this is what is currently done because of the difficulty of doing it over the regular home network. It doesn't mean we should design Homenet in the same way. I'd rather see that providers supply Homenet routers to their customers and that the multicast TV streams just work. Cheers, Sander ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> I am not mandating that each and every device is in its own broadcast > domain, I am however advocating that we leave the model that has been > prevalent for 10-15 years at least, ie that a home gateway has a "WAN" > port and 4 "LAN" ports, and these 4 ports are bridged. You certainly have a point -- that's something we never discussed, and it appears that there's no consensus. > I'm saying the typical device should have 4-5 "L3" ports. You're then > free to connect one of these to your L2 switch if you so please. I'll just point out that on all the hardware I know this is configurable -- it's quite possible to set up an OpenWRT router to put each Ethernet port on a different VLAN. So perhaps a Homenet router could ship with the LAN ports bridged, and have a configuratifon option somewhere in the "Beware the tiger" tab of the "Advanced" menu that allows unbridging selected ports? (I'm sure somebody will point out that the right configuration could be chosen automatically, but I'm not sure I'm comfortable with the set of interfaces changing at runtime on a home router.) -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 20, 2015, at 11:33 AM, Juliusz Chroboczek wrote: >> Has the group considered a Bier model for multicast in the home? > > As in a place where you put dead people? Bier is a new working group in the routing area. https://datatracker.ietf.org/wg/bier/charter/ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> L3 - route injection (got a routing protocol there already, use it) Yes, just put a stub router on the host and advertise /128. As far as I'm aware, current HNCP doesn't provide a way for a host to request a subnet-independent /128. What's the thinking on that? Just grab a /128 from whichever subnet you happen to be connected to at boot, and advertise that? > L3.5 - SHIM6. not deployable > L4/L5 - MP-TCP > L5/L7 - MOSH I don't think that's specific to Homenet -- being able to deal with multiple addresses that change over time is something that our stacks don't deal with very well. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Has the group considered a Bier model for multicast in the home? As in a place where you put dead people? Please explain. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Has the group considered a Bier model for multicast in the home? On 2/20/15, 9:41 AM, "Toerless Eckert" wrote: >I have seen more L2 switches that have broken IGMP/MLD snooping than >working ones. I am not aware of real proliferation of PIM snooping. >Snooping in transit LANs with PIM is a bad idea anyhow, and i have >tried to steer any customer who asked me away from it. > >Bidir-PIM makes snooping particularily difficult. For once >you have to track DF-winner election messages (difficult) and >secondly you have to then flood all multicast to all DF winners >because you don't know which group-range is served by which RP. > >IMHO, there is never enough multicast to justify this snooping complexity. >The only thing to worry about is what packets to send out from a router >to ensure the snooping doesn't screw up the traffic flow. > >I would be surprised to find equipemnt that does PIM snooping by default. > >So, i'd recommend to a homenet router: > >-> even if you don't do PIM, send out PIM Hellos. This should > effectively make all stupid "enterprise class" IGMP/MLD snooping > switches (that often have broken IGMP/MLD snooping) send > you all multicast traffic (inhibits snooping). > >-> Still send MLD/IGMP memberships to get traffic through the > L2 home equipment that has likely never heard about PIM. > I'd guess that eg: powerline equipment falls into this > category. > >Cheers >Toerless > >On Fri, Feb 20, 2015 at 11:04:41AM +1100, Andrew Mcgregor wrote: >> Why? PIM and MLD snooping are pretty standard on very low-end >>enterprise >> switches, which will be next year's midrange consumer models. If the >> dumb-as-rocks stuff goes away, that would generally make people happier. >> >> On 20 February 2015 at 05:22, Mikael Abrahamsson >>wrote: >> >> > On Thu, 19 Feb 2015, Ted Lemon wrote: >> > >> > On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson >>wrote: >> >> >> >>> I would like my router-to-router links to not have a lot of hosts in >> >>> them if I can avoid it. >> >>> >> >> >> >> Why is that? >> >> >> > >> > If we're going to be routing multicast within the home, we're most >>likely >> > going to have to use some kind of variant of PIM. Asking the L2 >>switches >> > people connect to the router to support both PIM and MLD snooping >>seem like >> > it might be asking too much. >> > >> > I might be wrong though. >> > >> > -- >> > Mikael Abrahamssonemail: swm...@swm.pp.se >> > >> > ___ >> > homenet mailing list >> > homenet@ietf.org >> > https://www.ietf.org/mailman/listinfo/homenet >> > >> >> >> >> -- >> Andrew McGregor | SRE | andrewm...@google.com | +61 4 1071 2221 > >> ___ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > >-- >--- >Toerless Eckert, eck...@cisco.com > >___ >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] Routing protocol comparison document
> > I don't know. Homenet multicast is an open issue. But I don't think this > use case represents a serious problem, because as far as I can tell streaming > video is not done using multicast in practice anyway. > > Sorry, bad assumption. I just finished working on a TV streaming project for > an ISP and there is lots of multicast there. All live TV channel streams to > STBs > are multicast and this is a common setup amongst ISPs. OTT video does not use multicast. IPTV deployments do use multicast. Those that I'm aware of require use of the provider-supplied CE router, which has an IGMP proxy (and MLD proxy if IPv6 multicast is supported) for LAN-to-WAN multicast management. Where Wi-Fi distribution of these multicast streams is supported, it is only done on a dedicated (and highly managed and somewhat proprietary) Wi-Fi network, that is distinct from the general-purpose (and not "professionally" managed) Wi-Fi network. The LAN interfaces of the provider-supplied CE router do tend to have IGMP/MLD snooping, to keep from flooding the general-purpose network interfaces with large multicast streams. There may also be a coax networking interface. If there is, this also tends to be dedicated and highly managed. Where Ethernet is used for distribution of multicast, it is done so that the provider STBs are all attached to the provider CE router via the same Ethernet port (and no other devices use that port) and there are no intervening routers. I mentioned at the last IETF that I expect some "home networks" to have managed and unmanaged segments. I don't consider the dedicated, managed segments to be part of the homenet domain. I would hope that the provider-supplied CE router would support homenet on its general purpose network interfaces. I'd be curious to learn about multicast IPTV deployments that allow users to supply their own CE routers and send multicast streams on network segments that are also used for general-purpose home networking (especially general-purpose Wi-Fi networks). BTW, the dedicated, highly-managed and somewhat proprietary Wi-Fi delivery of IPTV multicast streams has been very successful. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> On 20.2.2015, at 15.22, Mikael Abrahamsson wrote: >> Back to the subject: What are the requirements of a high performance WiFi >> home network to the homenet routing protocol? I guess we don't know. > Within the current framework to solve this problem with what exists today > when it comes to clients, I would say we need either: > > 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the > APs using the same SSID, so the SSID can have the same L2 domain. This would > probably mean we want to increase MTU on the physical links to avoid > fragmentation. Messy. Possibly we could advertise lower MTU on the wifi > network to minimize fragmentation if we don't raise MTU. > > 2. We set up some kind of L2 switching domain between the APs. This would > require VLAN support in the HGWs, and something to set this up with loop > avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as > control plane, that way we could possibly run the same IGP for both L2 and > L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds > like an understatement. > > Frankly, I don't know how to solve this without a lot of complication. > > We need clients to be able to change IPv6 addresses without losing existing > connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two > connections at once and inform the application that one address is going away > soon so it can do its thing to try to handle this? What if clients do not need to change addresses? In 2 words: Route /128s. Two ways to do it: - have clients talk stub RP + stub HNCP, be done with it - have first-hop router do proxying for them by advertising the /128s only when they are connected to it (may have issues with e.g. clients assuming /64, but nothing a redirect could not fix, hopefully) This L3(ish) solution actually works for all apps, unlike L4+ solutions some people advocated. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On 02/18/2015 11:54 PM, Mikael Abrahamsson wrote: On Wed, 18 Feb 2015, Michael Thomas wrote: But we're not talking about an interpreted language in the forwarding plane, right? Is the load from routing protocols we're talking about likely to have any noticeable effect on the the forwarding rate? even when you're running hot on the routing daemon side, you're not too likely to be running hot on the forwarding side because something is hosed, right? The complaints about the Erlang implementation has so far been on memory and flash footprint, not CPU resources and affecting performance. The above is true for most interpreted languages, such as python etc. When you install the environment, they're going to use noticable memory and disk space. Next application that needs the environment won't add much to the footprint though, it's the environment itself that takes space. My Python executable on my debian box is 2.7 megabyte. I don't know about the rest. So if one wants to run Python on the home gateway, that would also use significant space. But forwarding will be done the same way regardless of what routing protocol we use, that'll be done by the kernel. The routing protocol just programs the RIB/FIB. One nice side-effect of putting in, say, a headless android into a router is that it would forevermore insure that there's plentiful memory, just like it did for cell phones. It's not like we physically can't get enough ram/flash into those boxen after all... it's the will to bear the cost that's really at issue. A better development environment for home routers would *really* help development efforts along. From what I've seen they suck out loud. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Were you before me? http://www.ietf.org/mail-archive/web/homenet/current/msg00971.html (November 2011) More than three years later, same discussion. That makes me sad. Teco > Op 20 feb. 2015, om 15:14 heeft Ted Lemon het volgende > geschreven: > > On Feb 20, 2015, at 8:22 AM, Mikael Abrahamsson wrote: >> 2. We set up some kind of L2 switching domain between the APs. This would >> require VLAN support in the HGWs, and something to set this up with loop >> avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as >> control plane, that way we could possibly run the same IGP for both L2 and >> L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds >> like an understatement. > > Long ago I proposed using Trill to make this work, but nobody listened... > > :) > ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
I have seen more L2 switches that have broken IGMP/MLD snooping than working ones. I am not aware of real proliferation of PIM snooping. Snooping in transit LANs with PIM is a bad idea anyhow, and i have tried to steer any customer who asked me away from it. Bidir-PIM makes snooping particularily difficult. For once you have to track DF-winner election messages (difficult) and secondly you have to then flood all multicast to all DF winners because you don't know which group-range is served by which RP. IMHO, there is never enough multicast to justify this snooping complexity. The only thing to worry about is what packets to send out from a router to ensure the snooping doesn't screw up the traffic flow. I would be surprised to find equipemnt that does PIM snooping by default. So, i'd recommend to a homenet router: -> even if you don't do PIM, send out PIM Hellos. This should effectively make all stupid "enterprise class" IGMP/MLD snooping switches (that often have broken IGMP/MLD snooping) send you all multicast traffic (inhibits snooping). -> Still send MLD/IGMP memberships to get traffic through the L2 home equipment that has likely never heard about PIM. I'd guess that eg: powerline equipment falls into this category. Cheers Toerless On Fri, Feb 20, 2015 at 11:04:41AM +1100, Andrew Mcgregor wrote: > Why? PIM and MLD snooping are pretty standard on very low-end enterprise > switches, which will be next year's midrange consumer models. If the > dumb-as-rocks stuff goes away, that would generally make people happier. > > On 20 February 2015 at 05:22, Mikael Abrahamsson wrote: > > > On Thu, 19 Feb 2015, Ted Lemon wrote: > > > > On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson wrote: > >> > >>> I would like my router-to-router links to not have a lot of hosts in > >>> them if I can avoid it. > >>> > >> > >> Why is that? > >> > > > > If we're going to be routing multicast within the home, we're most likely > > going to have to use some kind of variant of PIM. Asking the L2 switches > > people connect to the router to support both PIM and MLD snooping seem like > > it might be asking too much. > > > > I might be wrong though. > > > > -- > > Mikael Abrahamssonemail: swm...@swm.pp.se > > > > ___ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > > > -- > Andrew McGregor | SRE | andrewm...@google.com | +61 4 1071 2221 > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> There are good proposal how to do servicce discovery in homenets or the > like with DNS-SD (/mDNS), but i think we should still worry about > compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are > IMHO better solved with router-level "proxy" > solutions than with ASM IP multicast. FYI. I did a presentation to DLNA (which has a lot of key UPnP people) that warned them to start thinking about service discovery in the multi-router world, and the world where more and more Wi-Fi APs are limiting the multicast that makes it to Wi-Fi devices. I mentioned the DNS-SD proxy work, homenet, and told them: " - People have started to study the current quantity of multicast traffic and its impact on power consumption by battery-operated Wi-Fi devices. http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00 http://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-00 - Concern is growing and proposals are starting to appear for ways to decrease the quantity of multicast messages. http://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00 " My recommendations were that they had 2 basic options of either also supporting DNS-SD / mDNS for service discovery, or defining a SSDP proxy similar to what I expect will be done for DNS-SD. Anyway, I told them I'd keep them updated on the state of affairs regarding this issue. Barbara ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, Feb 20, 2015 at 10:57:24AM +0100, Mikael Abrahamsson wrote: > I have thought of this as mostly L3 network. I thought the service > discovery problem between subnets was being solved or had been solved. > >From the discussion here the past few days it's clear to me now that the > mind image of what a future homenet is differs a lot between participants > in this working group. There are good proposal how to do servicce discovery in homenets or the like with DNS-SD (/mDNS), but i think we should still worry about compatibility with UPnP. Both of these requirements (UPnP and DNS-SD) are IMHO better solved with router-level "proxy" solutions than with ASM IP multicast. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Snooping switches would certainly be a good reason to prefer MLD proxying over PIM in homenet. There could be other reasons like reducing codeside (thats Pierre pet reason ;-). But trying to be compatible with snooping switches also implies that improvements in MLD that we might wnat then for homenet would break interoperability with that L2 equipment, because you must assume this L2 equipment will only correctly react to MLD message and message sequences as they have been defined 8 years ago. So foremost, it would be good to understand if there really is home L2 equipment that MUST see MLD to operate correctly. Otherwise i'd happily ignore the problem and say there is enough bandwidth to just NOT DO snooping but have multicast be flooded in the L2 segments. I only remember vaguely one old data point that seemed to indicate that some powerline equipment was doing snooping and you couldn't switch it off. can't find the pointers to this data point though. Would love to know if any powerline standards exist and what they say about MLD... Worst case, whatever the preferred solution for IP multicast is in homenet, if we identify that there is L2 equipment that MUST get MLD, we need to ALSO have homenet routers send out MLDv1/v2 backward compatible MLD messages to keep that L2 equipment happy. That is also pretty much what we do in commercial environments too, for example in satellite links where we really want to connect router-to-router signaling with PIM, but those routers are set up to ALSO send IGMP/MLD to keep the satellite modems happy. Toerless On Thu, Feb 19, 2015 at 07:22:34PM +0100, Mikael Abrahamsson wrote: > On Thu, 19 Feb 2015, Ted Lemon wrote: > > >On Feb 19, 2015, at 1:08 PM, Mikael Abrahamsson wrote: > >>I would like my router-to-router links to not have a lot of hosts in them > >>if I can avoid it. > > > >Why is that? > > If we're going to be routing multicast within the home, we're most likely > going to have to use some kind of variant of PIM. Asking the L2 switches > people connect to the router to support both PIM and MLD snooping seem > like it might be asking too much. > > I might be wrong though. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- --- Toerless Eckert, eck...@cisco.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Feb 20, 2015, at 8:22 AM, Mikael Abrahamsson wrote: > 2. We set up some kind of L2 switching domain between the APs. This would > require VLAN support in the HGWs, and something to set this up with loop > avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as > control plane, that way we could possibly run the same IGP for both L2 and > L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds > like an understatement. Long ago I proposed using Trill to make this work, but nobody listened... :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Ole Troan wrote: Frankly, I don't know how to solve this without a lot of complication. why do you think this has to be solved at L2? I don't that's why I wrote the next paragraph outlining L3 solutions. We need clients to be able to change IPv6 addresses without losing existing connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two connections at once and inform the application that one address is going away soon so it can do its thing to try to handle this? at least you can do: L3 - route injection (got a routing protocol there already, use it) This sounds like it needs at least a coordination protocol between the APs? L3.5 - SHIM6. not deployable L4/L5 - MP-TCP L5/L7 - MOSH I would prefer the last two. I use MOSH all the time, it's great. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Op 20 feb. 2015, om 14:22 heeft Ted Lemon het volgende > geschreven: > > So Teco, to satisfy your use case, which I share, you would actually need the > homenet to identify all Wifi access points that are being used to serve > hosts, and treat those as a single subnet, correct? Because I am not optimistic on deployment of mobility protocols in the home, my answer is yes. WiFi APs in same home has same SSID(s). Each SSID provides an IP subnet. Providing multiple SSIDs should be in scope, with and as default SSIDs. Both and differ from my neighbors SSIDs. Al least two directions for a solution: 1) the WLAN controller with tunnels between the APs and the WLC. 2) distribute the AP configuration for APs, either manually or guided by a homenet protocol. I hope we can circumvent VLANs in homenet. An alternative would be /128 prefix routing. Whatever we choose, we have to keep in mind that dual stack operation will not fade away soon. Teco ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Mikael, >> Back to the subject: What are the requirements of a high performance WiFi >> home network to the homenet routing protocol? I guess we don't know. > > Within the current framework to solve this problem with what exists today > when it comes to clients, I would say we need either: > > 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the > APs using the same SSID, so the SSID can have the same L2 domain. This would > probably mean we want to increase MTU on the physical links to avoid > fragmentation. Messy. Possibly we could advertise lower MTU on the wifi > network to minimize fragmentation if we don't raise MTU. > > 2. We set up some kind of L2 switching domain between the APs. This would > require VLAN support in the HGWs, and something to set this up with loop > avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as > control plane, that way we could possibly run the same IGP for both L2 and > L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds > like an understatement. > > Frankly, I don't know how to solve this without a lot of complication. why do you think this has to be solved at L2? > We need clients to be able to change IPv6 addresses without losing existing > connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two > connections at once and inform the application that one address is going away > soon so it can do its thing to try to handle this? at least you can do: L3 - route injection (got a routing protocol there already, use it) L3.5 - SHIM6. not deployable L4/L5 - MP-TCP L5/L7 - MOSH 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] Routing protocol comparison document
So Teco, to satisfy your use case, which I share, you would actually need the homenet to identify all Wifi access points that are being used to serve hosts, and treat those as a single subnet, correct? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Teco Boot wrote: Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Within the current framework to solve this problem with what exists today when it comes to clients, I would say we need either: 1. HNCP helps set up an overlay L2 tunnel infrastructure connecting all the APs using the same SSID, so the SSID can have the same L2 domain. This would probably mean we want to increase MTU on the physical links to avoid fragmentation. Messy. Possibly we could advertise lower MTU on the wifi network to minimize fragmentation if we don't raise MTU. 2. We set up some kind of L2 switching domain between the APs. This would require VLAN support in the HGWs, and something to set this up with loop avoidance etc. Oh oh oh, we could use IEEE 802.1aq that already uses ISIS as control plane, that way we could possibly run the same IGP for both L2 and L3. Interconnecting APs over wifi seems weird though. Oh, and messy sounds like an understatement. Frankly, I don't know how to solve this without a lot of complication. We need clients to be able to change IPv6 addresses without losing existing connections. SHIM6 anyone? MP-TCP? Asking IEEE to make 802.11 keep two connections at once and inform the application that one address is going away soon so it can do its thing to try to handle this? -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
Thanks sharing this. What I can add: Our house is a little bit bigger. It was formerly a farmhouse. It has a stone firewall between living room and formerly hay storage place. This firewall is quit good in blocking RF. My "production" network has 2 dual band APs. I have good indoor coverage. In summertime, I use WiFi in my garden to watch live TV (iPhone, iPad, MacBook, Android gear). It is partly testing, partly following Tour de France, news etc. My partner is less a geek and carries the TV, coax and power cables. Still possible with some analogue channels. Soon we have to carry a lot more stuff to decode DTV, this is bad. Or watch over WiFi. I don't want to CAT6 my garden, sorry. Walking from living room to desk to garden means AP switch-over. I used to have 2.4 and 5GHz SSIDs, this doesn't work well. With exact same SSID and keys, handover works. Not well, but it works. With different SSIDs and different IP subnets: no, total failure. There are WiFi AP kits around that operate in same channel and spoof AP BSSID. Roaming is transparent for clients. Nice idea, not accepted by standards bodies nor by industry. Back to my point: I want L3 on each and every homenet box. At the same time, I want high performance wireless links. It must be cheap, I don't want to pay € 1000 for a WLC and €400 for each AP. As long as homenet enlarges my WiFi problem, it is useless for me. And I thought I was candidate for early adoption, as I have multiple APs, a wired backbone, thinking of dual ISP links etc. And as geek, I want to pay a bit more for high performance and I am able to troubleshoot a bit. Back to the subject: What are the requirements of a high performance WiFi home network to the homenet routing protocol? I guess we don't know. Teco > Op 20 feb. 2015, om 13:17 heeft Mikael Abrahamsson het > volgende geschreven: > > On Fri, 20 Feb 2015, Teco Boot wrote: > >> Do you have CAT6 to WiFi APs in every room? Can you share experience with >> moving WiFi devices? > > No, my apartment is covered by a single 5GHz AP in the center of the > apartment. > > I mainly use cabled connections for media players and similar devices since > they work much better over full duplex gige than over wifi. If I just could > go back to my 1ms RTT Internet access link, things would be a lot better > because my current DOCSIS3 cable connection is a lot worse (for instance when > it comes to RTT and PDV) than my previous connection I had at the previous > apartment which was a lot more consistent. > > I tend to use a CAT6 ethernet adapter in my laptop when I'm at my desk, even > though both my AP and laptop has 802.11ac. Wifi is mostly used to handle > mobile devices such as tablets and mobile phones. > > My experience is that even with state of the art equipment, wifi still is not > even close in quality of experience compared to cable, apart from very light > use where it's still sufficient. > > My experience with multiple APs (from other places) is that clients don't > switch APs easily enough so they're seldom connected to the optimal AP. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
On Fri, 20 Feb 2015, Teco Boot wrote: Do you have CAT6 to WiFi APs in every room? Can you share experience with moving WiFi devices? No, my apartment is covered by a single 5GHz AP in the center of the apartment. I mainly use cabled connections for media players and similar devices since they work much better over full duplex gige than over wifi. If I just could go back to my 1ms RTT Internet access link, things would be a lot better because my current DOCSIS3 cable connection is a lot worse (for instance when it comes to RTT and PDV) than my previous connection I had at the previous apartment which was a lot more consistent. I tend to use a CAT6 ethernet adapter in my laptop when I'm at my desk, even though both my AP and laptop has 802.11ac. Wifi is mostly used to handle mobile devices such as tablets and mobile phones. My experience is that even with state of the art equipment, wifi still is not even close in quality of experience compared to cable, apart from very light use where it's still sufficient. My experience with multiple APs (from other places) is that clients don't switch APs easily enough so they're seldom connected to the optimal AP. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
> Op 20 feb. 2015, om 10:57 heeft Mikael Abrahamsson het > volgende geschreven: > > On Fri, 20 Feb 2015, Andrew Mcgregor wrote: > >> Why? PIM and MLD snooping are pretty standard on very low-end enterprise >> switches, which will be next year's midrange consumer models. If the >> dumb-as-rocks stuff goes away, that would generally make people happier. > > There are enterprise switches out there currently (pretty expensive ones) > that still do not have MLD snooping, and the ones having PIM snooping is most > likely a lot less. I've been in the networking industry for close to 20 > years, the first "bridge" I laid hands on was a pretty advanced thing back in > the time with 3 AUI ports, and could barely do 10 megabit/s. I've then seen > the evolution into 100meg hubs, then 10/100 dual speed hubs (basically two > hubs with a switch in between), to 10/100 switches with all ports switched, > to gig equivalent etc. During this entire time, switches that could do IGMP > snooping has always been substantially more expensive, mostly (I guess) they > couldn't be implemented in pure switch silicon, but always required > administration interface, operating system etc. Still today, these typically > cost 100 USD or more, when you can buy a stupid one for 30USD. So yes, over > time this might change, but I still think there will be cost involved. It > might be that the h omenet "routers" are going to look quite different than the typical router we see today when it comes to phsyical ports. Or perhaps they're only going to have 2-3 ports and the rest is going to be wifi. What do I know. > > What I do know is that so far, cable has always been a lot better than radio. > Lots of support calls to ISPs end up being related to wifi problems. I have > CAT6 to every room in my apartment, but then again, I am not a typical user. > However, I often speak to people who have performance problems who then end > up pulling a physical cable and after that their problems are solved. > > With 60GHz wifi, you're going to need line-of-sight to every AP from the > clients, which will probably be located in the ceiling in every room where > you want good performance. These APs are going to need physical cables for > uplinks to get any meaningful bump in performance. > > I have thought of this as mostly L3 network. What I can add: the multicast snooping feature could be somewhat behind development and deployment of the standards and / or buggy. So some administrators switch off the snooping / rate limiting feature. I do. L3 all the way to switch ports make the network more robust. But this requires L3 forwarding in hardware, multicast routing and adjustments in discovery protocols. Can all multicast forwarding be performed in hardware? Do you have CAT6 to WiFi APs in every room? Can you share experience with moving WiFi devices? Teco > I thought the service discovery problem between subnets was being solved or > had been solved. >> From the discussion here the past few days it's clear to me now that the > mind image of what a future homenet is differs a lot between participants in > this working group. > > -- > Mikael Abrahamssonemail: swm...@swm.pp.se > > ___ > 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] Routing protocol comparison document
On Fri, 20 Feb 2015, Andrew Mcgregor wrote: Why? PIM and MLD snooping are pretty standard on very low-end enterprise switches, which will be next year's midrange consumer models. If the dumb-as-rocks stuff goes away, that would generally make people happier. There are enterprise switches out there currently (pretty expensive ones) that still do not have MLD snooping, and the ones having PIM snooping is most likely a lot less. I've been in the networking industry for close to 20 years, the first "bridge" I laid hands on was a pretty advanced thing back in the time with 3 AUI ports, and could barely do 10 megabit/s. I've then seen the evolution into 100meg hubs, then 10/100 dual speed hubs (basically two hubs with a switch in between), to 10/100 switches with all ports switched, to gig equivalent etc. During this entire time, switches that could do IGMP snooping has always been substantially more expensive, mostly (I guess) they couldn't be implemented in pure switch silicon, but always required administration interface, operating system etc. Still today, these typically cost 100 USD or more, when you can buy a stupid one for 30USD. So yes, over time this might change, but I still think there will be cost involved. It might be that the homenet "routers" are going to look quite different than the typical router we see today when it comes to phsyical ports. Or perhaps they're only going to have 2-3 ports and the rest is going to be wifi. What do I know. What I do know is that so far, cable has always been a lot better than radio. Lots of support calls to ISPs end up being related to wifi problems. I have CAT6 to every room in my apartment, but then again, I am not a typical user. However, I often speak to people who have performance problems who then end up pulling a physical cable and after that their problems are solved. With 60GHz wifi, you're going to need line-of-sight to every AP from the clients, which will probably be located in the ceiling in every room where you want good performance. These APs are going to need physical cables for uplinks to get any meaningful bump in performance. I have thought of this as mostly L3 network. I thought the service discovery problem between subnets was being solved or had been solved. From the discussion here the past few days it's clear to me now that the mind image of what a future homenet is differs a lot between participants in this working group. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
