Re: [homenet] a modest plugfest proposal
Hi, On Fri, Feb 27, 2015 at 05:14:47PM -0800, Dave Taht wrote: That sort of plugfest would get the known users of things like hnetd up from 2 to at least 50, and I would hope that the increased operational experience from the ensuing chaos twould be of benefit for setting future directions of the wg. I very much like that idea. (Unfortunately, I won't be at the IETF meeting, but I am one of those few that have actually deployed hnetd/HNCP before :) so I claim sufficient experience) 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] L2 link status [was: More about marginal links]
On Fri, Feb 27, 2015 at 10:37 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: Henning, How can a router make use of throughput to a mostly idle neighbor? How do you get packets sent to a neighbor that dropped or packets that a neighbor sent to you that didn't arrive here? Raw link speed or packet and byte counts don't by themselves tell you much. The equivalent of PPP LQM or MPLS-TP LM OAM would be the sort of thing needed is you didn't want to use BFD with a high probe rate. You need a bit of probing traffic... a few packets per second are enough to give you an idea about the speed of the link. Of course you only need to probe neighbors that you did not send normal unicast anyways since the last probe. Henning Rogge ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] L2 link status [was: More about marginal links]
In message caa93jw7yyj4ouagsed-dn4ttvkuwucyloqdsqxpho4af+3h...@mail.gmail.com Dave Taht writes: On Fri, Feb 27, 2015 at 1:37 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message cagnrvupwf3n9jqmi_txwbxketo_59zdqqapcfcsyfduvqp8...@mail.gmail.com Henning Rogge writes: On Wed, Feb 25, 2015 at 9:36 PM, Curtis Villamizar cur...@ipv6.occnc.com wrote: In message 87a903ef2j.wl-...@pps.univ-paris-diderot.fr Juliusz Chroboczek writes: As to wireless links -- as far as I'm aware, making efficient use of wireless L2 information in a routing protocol is an open research problem. Other than signal strength and collision rate, what L2 information is available? Per MAC information would be nice for the AP side or any node in mesh or adhoc mode but that isn't collected anywhere AFAIK. Raw linkspeed and (on Linux) even Throughput to each neighbor... and a lot more. Just run iw wlan0 station dump on a Linux system with wifi and you will be surprised how much information you will get. Henning Rogge Henning, How can a router make use of throughput to a mostly idle neighbor? How do you get packets sent to a neighbor that dropped or packets that a neighbor sent to you that didn't arrive here? Raw link speed or packet and byte counts don't by themselves tell you much. The equivalent of PPP LQM or MPLS-TP LM OAM would be the sort of thing needed is you didn't want to use BFD with a high probe rate. As I said above (or tried to say), the most useful hints that the link isn't as good as nominal link speed might indicate might be signal strength and collision rate. [What I meant above by available was available and useful for making efficient use of wireless L2 information in a routing protocol in the quoted text. So maybe I was too terse in saying that.] Thanks for the response though. I use FreeBSD and other than rate and S/N there isn't much, so could you send me sample output from a Linux host or better yet a Linux AP with a few neighbors. We can take this off list and discuss the sample output but so far lots of stuff (sic) doesn't help. Curtis ps - maybe I should stop procrastinating and compile and flash openwrt and see for myself, but for now ... You don't have to compile a thing, just download the right nightly from chaos calmer (preferred as hnetd etc are in it), and flash it. Everyone here, has been 90 bucks, 5 minutes and one reflash away from eating it's dogfood for 9+ months now. http://downloads.openwrt.org/snapshots/trunk/ Dave, I do need to compile if I prefer to try some of my own recipes for dog food. Not that I don't also want to try yours. I'm more interested in Ethernet than WiFi for my home use. WiFi is sort of like the penalty box here. It works fine for normal web browsing and such. If I want to move more than just a few bits around I plug the laptop into a GbE port somewhere. btw- You do have an advantage in any discussion based on running code. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] A poll
Dave Taht wrote: The homenet working group has been laboring for several years now to find ways to make ipv6 more deployable to home (and presumably small business) users. In addition to multiple specification documents some code has been produced to try and make things easier. At least in the USA, comcast has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on their router, and/or is willing to install a custom firmware on their router to get that, and of course tunneling ipv6 is possible if the ISP does not support it. So a quick poll: 0) Have you managed to get ipv6 working at all? If so, how? What sort of problems did you encounter? Been using IPv6 in production at home since around 2010. Main problems have been: The assumptions manufacturers have made about how the boxes will be plugged together and assuming they're the only router in the home. Hence Homenet. Several bugs in Apple airport and time capsule routers, blocking traffic incorrectly. Lack of Protocol41 forwarding support in a lot of equipment. Software updates killing 6to4 configured tunnel mode. Cisco EPC3925 that refused to go into bridge mode (probably by design of the ISP). Lack of fibre into the building means I'm stuck with the local cable provider, although there's net-neutral fibre in neighbouring streets supporting multiple native IPv6 providers. 1) Have you attempted to deploy a routing protocol in your home? Which one, and why? Yes. Static routing. Nothing else was supported in common, and I wanted a mail server on the outside in a DMZ and a private network on the inside. It took a lot of tweaking to find a topology that worked simultaneously with IPv4 and supported what I wanted to do in IPv6. 2) Have you attempted to get hnetd's prefix distribution system working? (it supports linux mainline and openwrt presently) Yes, but not tested too much yet as I've been moving a data centre. Just bought a stack of WDR4300's to test with. Also with the intention of looking at mesh networking. So hopefully I'll get around to it $day_job permitting. 3) Do you use ethernet? How many clients in your home are ethernet connected? Ethernet, powerline Ethernet, and wifi. 2 Raspberry Pi's 1 Linux server 2 iMacs 1 windows laptop bunch of music sequencers and synths 1 printer a couple of NAS boxes a few wireless routers guest devices Apple TV 2 iPads 1 playstation so probably ±10 hard wired. The rest wireless. 4) Do you use wifi? How many clients are wifi connected? Do you use range extenders? Yes I use wifi extensively. I used range extension (Apple Airport Extreme) for a while, but ended up running a cable. 5) How many devices do you think you will have connected to the network in your home in 5 years? How many now? 30? Audio Visual Bridging (AVB) could throw a spanner in the works of having seamless connectivity throughout the home. Hopefully someone will figure out a way of transmitting music/audio streams in a sample-coordinated manner at L3. 6) Do you use any other network connected technologies (homeplug, 802.14, LTE, etc). If so, which ones, and why? yes. Powerline IP to try to avoid running a cable. It wasn't too successful. 7) Do you use mdns service discovery? Unfortunately yes, and I wonder how this will scale over L3. UPnP too. 8) Why are you here? (especially, if your answers to 0-2, are no) Because if Homenet does solve the ISP multihoming problem, and possibly the wifi roaming problems at L3, it will also be used extensively in SME and SOHO set ups, and perhaps even in campus-size deployments. -- Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message caa93jw4tumfm_lvzkrx7ark2z+hwtw5jboenpvfejut4l9t...@mail.gmail.com Dave Taht writes: On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar cur...@ipv6.occnc.com 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. OTOH, invalidating a DHCP lease
Re: [homenet] L2 link status [was: More about marginal links]
In message CAA93jw627Q12XkZy3CFuV81CLbJc5D9oX6LK1=cgetwsop1...@mail.gmail.com Dave Taht writes: BFD, Hellos, or any form of probe traffic over wireless has the speed of detection vs overhead issue. At nominal 10 Mb/s (low end today for wireless) a small probe would take about 0.1 msec (for example, 125 bytes including all overhead is about 1000 bits). Not bad if running 100 probes/sec (30 msec detection) unless there are a very large number of stations using the AP and doing the same thing. In that You are thinking about it wrong. Wireless-g is only capable of roughly 1300 TXOPs total per second. Bandwidth has NOTHING to do with it. I don't have the figure in my head for n or ac, but it is not a lot, and in the presence of g, falls back to the above figure. losing 10% of the bandwidth - per station - to run BFD is not an option. case 10 probes per second might be better. A very high collision rate Still too much. Next question? Oops yeah. You are right. Forgot about TXOPs. How about a PPP LQM / MPLS-TP LM OAM equivalent? Briefly: A sends pkt/byte sent to B. B notes pkt/byte recv and adds that to the packet. B adds its pkt/byte sent and sends that back to A. A notes its pkt/byte recv and sends back to B. A saves this. B simply receives and saves this. Save prior packet, wait some time, and then repeat: Now subtract the two sets of counter (new - old packet). Each side compares other side sent to their own received. Difference is number of packets dropped. Repeat forever using prior result to update drop rate. If any of the control packets drop, drop a partial result, repeat later, and compare to the last complete result. Is one cycle per neighbor too much? How about one cycle per neighbor each 5 seconds? If B is the AP it sends only one packet per cycle but both sides get accurate drop rate for both directions. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Routing protocol comparison document
In message 17359.1424897...@sandelman.ca Michael Richardson writes: Ray Hunter v6...@globis.net 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 mcr+i...@sandelman.ca, 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] [Battlemesh] Battlemesh V8 Logo
On Sat, Feb 28, 2015 at 9:09 AM, Musti mu...@wlan-si.net wrote: Hi folks, I am happy to present the new logo for Battlemesh V8 in Maribor, designed by Barbara :) http://battlemesh.org/BattleMeshV8/PosterDesign Comments appreciated! That is a truly awesome poster! I hope you line up more sponsors for this conference! Kind regards, Musti ___ Battlemesh mailing list battlem...@ml.ninux.org http://ml.ninux.org/mailman/listinfo/battlemesh -- 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
[homenet] 6renum redux [Routing protocol comparison document]
Admittedly 6renum was targetted at enterprise networks, partly because of the observation that homenets renumber anyway after every power cut. But we have spent a lot of cycles on this issue. http://tools.ietf.org/html/rfc4192 http://tools.ietf.org/html/rfc5887 http://tools.ietf.org/html/rfc6866 http://tools.ietf.org/html/rfc6879 http://tools.ietf.org/html/rfc7010 and maybe it's time to revive https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines Brian On 01/03/2015 12:40, Curtis Villamizar wrote: In message caa93jw4tumfm_lvzkrx7ark2z+hwtw5jboenpvfejut4l9t...@mail.gmail.com Dave Taht writes: On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar cur...@ipv6.occnc.com 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).
