Re: [homenet] Thoughts about routing - trends
Hi Jim, I agree with you. Let me just add a few words on #2 : You are absolutely right that pulling cable is hard and expensive. That is the rationale of PLC : Using existing wires. PLC is already used reliabily for high speed networking, but you are correct that it is not as popular as Wireless. Mostly because networking devices already embed a Wifi and/Or Ethernet interface, rather than a PLC interface. So people don't see the need of buying additional material for a connectivity they already have… Though people use PLC because they feel surrounded by RF, or they cannot reach some point of the network with wireless, or the PLC device is provided by their ISP (like in France). (There are others reasons for using PLC outside the home, but I think it is out of the scope of Homenet). PLC also suffers from a lack of standardization, and different technologies/Standards are often non-interoperable, or simply cannot coexist on the same electrical grid. An effort is ongoing in IEEE P1901.2 to create a standard for low frequency narrowband PLC. Just my 2 cts, Cédric. Le 11 oct. 2011 à 21:10, Jim Gettys a écrit : On 10/07/2011 03:48 AM, Fred Baker wrote: 4) The use of OLSR in mesh network scenarios Jim Gettys commented on the fact of OLSR use. The general sense of the room was that OLSRv2 is interesting but out of scope for this discussion as mesh networks are quite different from typical residential and SOHO networks. Actually, I have no opinion of OLSR, Babel, Babelz or OSPF; it's not my area of expertise. Babel/BabelZ is appearing in CeroWrt today as the people who are interested in such things are doing the work (we don't need a routing protocol in the simple single home router case), and it provided the functionality we needed. For those who want something else, quagga is in the CeroWrt build for your hacking pleasure. And I'm not advocating the homenet working group do anything unusual about routing at this date; as I said, it's not my area of expertise. Having said this, I do note the following technological trends: 1) As soon as we get real plug and play routers that don't need manual configuration that work, we'll see a lot more routers in a home environment. Other radio technologies (e.g. zigbee) may encourage this trend. It seemed like the working group agreed that getting to the point that just hooking things together would really just worked was a fundamental requirement (and I agree entirely with this sentiment, as it reflects reality of what already happens in the homes of hackers and non-hackers alike). 2) wireless is much cheaper to implement than wired networking, particularly in most houses where pulling cable is hard. I know this first hand, where I've pulled a lot of cat 6 and wish I could get it to places I don't have it. Unless power line networking really works, I believe that this trend isn't going to change. Is there any progress in this area? I've seen many promises, and few reliable working products. 3) As soon as you have two routers, you have at least two paths; the wired connection between them and the wireless. You may have 3 paths, if you have both 2.4 and 5ghz radios. Frequency diversity routing becomes immediately interesting, along with using your ethernet when it's available in preference to wireless. 4) an apartment building look like a mesh, and possibly with multiple backhauls possibly with multiple ISP's. One should at least think about what happens when you have homes, in such a building, and make sure nothing breaks. Wireless is messy: it isn't limited to where a wire goes. Taking down an entire apartment building/blocks/city would not be fun. I know, I've been there (at least to the point of taking down buildings, and came within a week of a much larger scale disaster). If you believe 1 + 2 + 3 +4 (as I do), then if you look a few years out, you end up with something in the home that begins to resemble very strongly what the community mesh networking folks are doing at a higher scale geographically and in terms of # of nodes today, with many/most of the same concerns and solutions. Understanding the problems they've faced/are facing is therefore worth a bit of investment; Radio diversity is one of the concerns, and interference (of various sorts). Julius' talk about why frequency diversity is an issue is here: http://www.youtube.com/watch?v=1VNzm0shSA8 While the issues outlined above are not where home networking is today, my gut feel is they will be in five years. If there is *anything* I can urge on the group, is to respect the scaling problems that can/will occur, and to internalise wireless !=wired: wireless goes where wireless goes and does not behave like ethernet. The group needs to ensure nothing bad happens when people start building systems in ways you don't expect, particularly in an apartment building. The challenge is balancing the
Re: [homenet] Homenet strawman slides
Erik, btw, border discovery needs to be done regardless of topology or prefix assignment solution choice. on a border you (may) want firewall on, you want a ULA border, you want a organisational or site multicast border... cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
2011/10/12 Joel jaeggli joe...@bogus.com On 10/11/11 18:38 , Ted Lemon wrote: On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: However, I am thinking that we can perhaps bootstrap equipment that has never been configured (or has been factory reset) in some fashion such that if the equipment is virginal that it can essentially always try some default keys, and bring up enough networking to let all equipment be discovered and identified. There would be strong nag screens to get the user to up a network password. A pre-shared key that is pre-shared to every device is the same as no key. Not really, it could serve an important hygenic function, notionaly, it could be filtered by default on all non-home-network gear. that is serves the purpose of identifying a well-known-service. there are of course other perhaps better ways to implment that. So you might as well not bother with that complexity. Conceivably CGA could be used to publish public/private key pairs allowing devices to automatically recognize each other and present their relationships in a UI for the end user to approve, but that's not precisely plug and play. I think the simplest thing would be to require that each device be able to talk to a USB drive. Each device collects all the public keys on the USB drive, and stores their own there. Devices then share their public key with other devices identified on the USB drive, so that as each device joins the network, the other devices learn about it. This isn't bulletproof—an infected PC that's configured with these keys could be used to gain access to the keys, for example. But it's a lot better than a well-known key. What about ID-based signature? Just improvising (so forgive me for any naivety): the ID of the device could be a triplet (producer-ID, product-ID, serial-number); the key generator could be the producer itself (avoiding in this way the key escrow problem related to ID-based cryptography) and a certificate with the public key of the producer could be downloadable from some well-known host (alternatively, the key of most known producers could be built in the device). The authentication procedure would follow the usual challenge scheme: the device receives a challenge string, it appends to it a nonce and signs the result with its private key (hardwired at production time). If the authentication is positive, then you know that you are talking to that type of device, produced by that producer (if you trust the producer is another matter). Of course, this simple scheme would fall to a device-in-the-middle attack, but maybe in this context it is not a likely attack. Of course, this isn't quite as plug and play as you seem to want, and it requires that each device have a USB port, which might not be acceptable. Plus, it would mean that the IETF would have to talk about hardware, which seems like a bit of a non-starter. But I think it's the right way to solve the problem. ___ 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] Thoughts about routing - trends
Le 12 oct. 2011 à 13:51, Russ White a écrit : You are absolutely right that pulling cable is hard and expensive. Pulling cable is indeed hard and expensive. In my experience, it is the right thing for some applications, such as TV and my home office. Personally, I have both wired and wireless throughout the house; my personal rule is that I use the shared wireless network for activities that move around, to provide convenience at the expense of consistency and bandwidth, and wired for things that stand still, to provide stable bandwidth at the price of a one-time wiring effort. I do the same --I pull cable for televisions, and even for locations where a desktop or laptop is going to be sitting on a regular basis. So I think we should expect wired and wireless as the norm, rather than expecting wireless all the time. I agree. I may have precised pulling *NEW* cable is hard and expensive in my sentence. While I wouldn't want to rule OLSRv2 completely out, I think it should compete head to head with an extended OSPF and an extended IS-IS, or even other efforts afoot. I'd rather see requirements first, and a good solid evaluation of what's available against those requirements, rather than choosing technologies out of the gate. :-) I think it is a good process, for each competing protocol. Russ Cédric. ___ 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] Homenet strawman slides
On 11/10/2011 14:23, Michael Richardson wrote: Curtis == Curtis Villamizar cur...@occnc.com writes: Curtis I really don't know how many support calls are just the consumer Curtis plugging the computer into the wrong Ethernet port on the NAT box and Curtis the uplink on the other port and then not being able to figure out Curtis what is wrong. All the cables fit in the connector. It should work! So, I was interrupted yesterday, reading homenet email, in order to go to my neighbour's house and sort out this EXACT problem. My box and the cables at home have connectors in different colors, making it easy to plug the right cable in the right port. Henk -- -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
Russ You need a unique identifier at the equipment level for Russ anything you intend to auto-configure --autoconfiguring Russ uniqueness is a very hard, probably impossible, problem on a Russ global scale. So we need to count on this one thing, no matter Russ what else we might need to back in to. Russ Now, it might be possible to some hash over a GPS location for Russ a base, and then add on MAC addresses, or some such, but We've assumed a unique MAC, which is 48 bits long. But OSPF router-id is 32 bits.What is the likelyhood of a collision in the bottom 32-bits of the MAC? Ah, I see the problem... There is a pretty high likelihood of a collision, actually, at least as long as you use multiple vendors in your home network. It's bound to happen to someone, someplace. So, a suggestion to resolve this: 1. Use the lower 32 bits of one of the mac addresses on the box as the initial id. 2. Add a new field to the router capabilities that carries the full 48 bit mac address, or even some munged together longer id, based on multiple mac addresses on the device, or some such. 3. During initial setup, if you receive a capability that appears to be from yourself, you open this secondary id section to find out if it's really you, or someone else who happens to have the same 32 bit id. 4. If it's really you, discard the packet. 5. If it's not really you, and if the other router's large id is lower than yours, choose another mac address from which to take your local id, and restart your ospf process. 6. If it's not really you, and the other router's large id is higher than yours, then send a router capabilities LSA unicast to this other router, so the other router knows to change its id. I don't think IS-IS would have this problem. :-) Russ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
Ted, using the electricity network as an analogy, can we make a distinction between safety and security? the electricity network in the home is somewhat self protecting with breakers and earthing. a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks and so on. I am highly sympathetic to the desire not to try to solve this problem. However, unfortunately network topology isn't the same as electrical topology, for a couple of reasons. The first reason is that electrical systems are generally set up by professionals. Yes, you plug devices into the electrical wiring of your house, but someone skilled set it up (or if not, I hope you sleep in asbestos pajamas). The devices we are talking about are more analogous to circuit distribution panels than to toasters. The second reason is that electrical systems are essentially topology-free. Any point on the system is essentially equivalent to any other. This is not true of a home network with routing. What we are talking about is essentially the possibility of rogue distribution panels intentionally or accidentally being connected to your distribution system. Which is a result of the third reason: home networks are typically wireless, or partially wireless, and so there is no physical security, unlike an electrical network in a house, which is secure by virtue of being entirely enclosed by the house. I think what you are getting at is that we cannot be responsible for securing the network. And that is probably true. But if the system doesn't have a built-in mechanism for distinguishing between friend and stranger, the autoconfiguration mechanism will create topologies that aren't desired, either by accident or because a stranger wants access to the network. I do agree with that. I think we can figure out a way of pairing devices. whatever layer that ends up being done at. it will be much more difficult to protect against hostiles injecting default routes, or pretending to be DHCP servers and so on. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
On 10/10/11 1:17 PM, Michael Richardson wrote: Erik == Erik Nordmarknordm...@cisco.com writes: Erik There might be some more difficult aspects if we want to allow Erik a router or its interfaces to be repurposed, such as splitting Erik an existing link into two separate links. In that case it Erik might be hard to avoid renumbering. The requirements question Moving/repurposing a router without a factory reset seems like the perhaps the most important source of conflict in the architecture that we discussed. Particularly if the router is put into a junk drawer for a few months until it is needed. So, we might need to consider if we can expire persisted settings after some long (from the point of view of the network) time, like 1 week... FWIW My existing IPv4 NATting home routers don't need to be quaranteened for a week; I can just rewire. At worst I have to power cycle. I thought IPv6 would make things better ;-) Erik ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Does ND Proxy useful for homenet?
Mark, A few points on this topic. As noted, the Cell system will have PD capabilities until a future 3GPP release (Rel-10) as noted. Although, even when the functionality is in place (generally), small devices like Smartphone and the mini gateways (3G/LTE devices which allow for 4-5 hosts to attached to Cell system) - PDs may not be used. Many of these devices (I.e in the case of the smartphone) have modes of operation where they tether, which turns them into a mini gateway. They are not likely to be be full blown gateways equivalent to what you see common CPEs. In the IPv4 case, these devices NAT the IPv4 private addresses used by hosts behind the device to the network assigned address. In the case of IPv6, it will have access to the network assigned ::/64. PCs (maybe other devices) behind such devices will need access to the IPv6 network, but may not have access to PD space. This was one of the specific use cases I was eluding to before. These devices (in such operating modes) are however not likely to participate in a home network (as the gateway device or a router) and it's very unlikely to be the head of home network. With this explanation, I am not sure if this should/would be considered as such in HomeNet. These devices technically become gateways/bridges to the Internet. And the hosts that use them are often the same type of devices which connect to common home networks. Regards, Victor K On 11-10-10 4:51 PM, Rajeev Koodli rkoo...@cisco.com wrote: Hi, The smartphone will only get a /64 in the current 3G/4G releases (rel-8, rel-9). Prefix delegation is specified in Rel-10. -Rajeev On 10/10/11 1:01 PM, Mark Townsley towns...@cisco.com wrote: Or are you saying a mobile device (a smartphone) will only ever get a /64 to share? My (limited) understanding of the various 3/4G standards are that a PD for a phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or someone else here can elucidate. - Mark ___ 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] Thoughts about routing - scaling
I've alluded to having suffered from routing problems in the past, and urged people to be very careful about scaling, and interacting with unexpected/unintended neighbours, something that seldom happens in wired networking. I thought I'd elaborate slightly to help people focus on the problems. Both of these experiences come from my tenure at OLPC, which attempted to deploy mesh networking, where I worried about the base system software (but not the networking, in particular; Michailis Bletsas was in charge of that). Both added grey hair to my head and scars to our backs. 1) we had a situation, in which one of our machines tickled a bug in existing routers being used in an apartment building causing most all of the home networks in the apartment building to crash, to the point of needing reboot. It wasn't our bug; but it was sure our problem :-(. This is about all I can say on an open list about what happened here. The moral: lots of people can hear the packets you transmit; ensuring nothing bad will happen is interesting. The packets escape into the ether and may have consequences you don't anticipate. And just because you think that there are only a few participants in a conversation doesn't make it so. 2) The 802.11s committee, in their infinite wisdom, specified a routing protocol at layer 2. At least in the draft standard we were working from, the properties of this routing algorithm had the consequence of N^2 messages where N was determined by the number of machines that could hear each other simultaneously (each machine that heard you looking for the exit to the mesh would each turn around and send another message). I don't know if the current version of the standard is so brain-dead or not: the committee had ruled the scaling problem out of scope for the group: after all, no one would ever think of running a mesh in such a circumstance. Reality is that kids show up at school at the same time, (or people enter a conference room at the same time), and it happens. Let us not suffer from the attitude the IEEE did with 802.11s. It doesn't take many machines (somewhere between 15 and 30), that can hear each other to fry your channel entirely. It was so bad that we could only get about 14-16 bits into the preamble of the message before someone else would transmit and step on the attempted transmission: another words, the network completely collapsed with scale. We called this the dense mesh problem. Any routing protocol used on wireless should be evaluated for its scaling properties carefully. Your first ARP would, of course, trigger this melt down. The third problem we had in networking we didn't figure out at all: that awaited my personal encounter with bufferbloat to understand. - Jim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing - flash/stable storage constraints
On 10/11/2011 12:05 AM, Jari Arkko wrote: Home routers would also have MAC addresses, but again, if we need a 32-bit quantity then shortened 48/64 bit identifiers may (theoretically) have collisions. That being said, if the home routers have to discover their IPv6 prefix through a protocol and store it in flash, they could probably do so also for a router ID. Unless there was some chicken and egg problem that required the router ID for all this discovery to work... As to storing in flash, since most in homenet have not typically worked on embedded systems, worse luck... There is typically a read/write file system that can store state on a current Linux home router (e.g. OpenWrt); it may or may not mapped over the entire flash (which is desirable, as you'd like wear levelling to use all blocks on the flash). The bulk of the firmware is likely contained in a read-only file system called Squashfs, which does LZW compression on a per file basis; overlayed on top may be a read/write file system. Most commonly the read/write file system has been a file system called jffs2 over bare flash, originally implemented on the Compaq iPAQ handheld, a project I helped lead after I got sick of HTTP. And OLPC had a gigabyte of flash (which pushes jffs2 to/beyond it's design limits). There are later flash file systems under development, but I don't have first hand experience with any of them. Flash has the characteristic that write is relatively slow, and erase is generally glacial. Most interesting flash file systems try to do lazy erasure (erase freed blocks when they have a chance later, rather than at the time you may free a file). Since you don't want to wear out the flash, the jffs2 does journaling; one write will commit (potentially) a bunch of changes to multiple files, rather than each write generating one write. How many writes you get depends on the flash technology, whether the flash is bare or has some smart controller, and the wear levelling technology (if any) in use, along with whether all blocks participate in the wear levelling or not (jffs2 does good wear levelling; but using a big squashfs file system + a very small jffs2 file system will reduce the effectiveness; some cheap USB storage devices only do wear levelling on the free blocks, and try to hide the fact it is flash from the system above. I put smart in quotes, because they've often been hideously stupid, with their smarts limited to looking like IDE with a very lame flash translation layer. The most recent smart flash disks for laptops are actually getting very smart, with some help from the OS to help with the erasure problem. But they still cost substantially more, I suspect. I think most home routers currently use bare flash, though it's not clear to me if this will continue or not since the volume market may make the economics change. In any case, with flash of any sort, you don't want to sit there and demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime, for example). All this being said, storing state at the rate of machines/routers appearing or disappearing on a home network, or your ISP going down, isn't likely to cause a problem. You just have to be careful enough to not do anything really stupid; e.g. you map daemons with chatty logs to run their logs to /dev/null, or to tempfs in RAM. And you might take a big latency hit if you have to guarantee the write is stable before continuing an algorithm (if you run into needing to erase a block for some reason). And obviously you don't write tons of data when you don't half to. And update in place may be a bad idea relative to other techniques (which is why journaling file systems such as jffs2 are so desirable). - Jim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
On Oct 12, 2011, at 8:46 AM, Ole Troan wrote: I think we can figure out a way of pairing devices. whatever layer that ends up being done at. it will be much more difficult to protect against hostiles injecting default routes, or pretending to be DHCP servers and so on. I think pairing and general network security are largely the same problem. Of course if someone is granted access to the network, they can then inject routes or pretend to be a DHCP server, but that's not the issue I'm concerned with. I'm more concerned with the scenario Jim Gettys talked about in a subsequent message, where a bunch of things clump together and start talking to each other essentially accidentally. And of course I'm also somewhat concerned about attackers, although I think that's probably going to happen less often than accidental clumping. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
In message 17350.1318379...@marajade.sandelman.ca Michael Richardson writes: We may all be in violent agreement. Erik =3D=3D Erik Nordmark nordm...@cisco.com writes: Erik, I really don't know how many support calls are just the consumer plugging the computer into the wrong Ethernet port on the NAT box and the uplink on the other port and then not being able to figure out what is wrong. All the cables fit in the connector. It should work! Erik It sure would be good to try to find some data on this. But, for many many years, ISPs did not support having a sharing device. Not that they do, ISP insist that the box be *their* box, and as that box is sometimes broken, limited, etc. the customer has to provide their own. Again, if the ISP is called, it's not their problem. The ISP often has a dumb box that gets a DHCP allocation when turned on and then does NAT. For small business service, it may also get a fixed single IPv4 address, or less often a block and have the ability to accept an ARP from the customer side in that range (no DHCP). By default it does NAT and DHCP for everything else. If the ISP is an MSO and doing VOIP, their staff usually plugs it in. Otherwise if left to the customer, they would get the call. If it Vonage or similar VOIP provider, then they get the call. Erik While I can see that we can build the internals of the home Erik network with devices without a designated uplink Erik (automatically configure prefixes, the routing protocol etc), Erik what I don't understand is how the connectivity to the ISP Erik would happen. Erik How do you see that working? Will each router try the Erik protocols it would use against the ISP (PPPOE, DHCP PD, etc) Erik on every port? Or on every port where it doesn't find a OSPF Erik (or whatever home routing protocol we choose) neighbor? Or Erik does the user have to configure the Customer Edge Router to Erik say port eth0 is the WAN port? Basically what you suggest. For Cable and any access link that uses DHCP and Ethernet directly, the fact that you get a DHCP with a PD is a clue that this is the WAN link. For DSL using PPPoE (those who pay a bit more can have DSL without PPPoE), then a username/password is required, and yes, the user has to configure this. This is generally the case. A router should not start handing out PD or even IPv4 NAT space until it gets and address from elsewhere. If it gets a real address (not a PI), then that should be preferred over some device that handed out a NAT address with a default route to itself even though it had no uplink. Case in point: DHCP is not a routing protocol. You have one shot to hand over a default route. If its wrong it can be bandaided with ICMP redirects for hosts that don't have a zero config routing protocol running. But that is the best that can be done with the NAT and DHCP kludge that is in place today. We can whine about it or we can define something better with sufficient backwards compatibility. However. in many cases, this is pre-configured by the ISP, as the router and DSL modem is combined into a single box. Often this also means that you can't plug it in wrong, as the uplink is an RJ11 rather than RJ45. This is true only where where it is a VOIP product giving you an RJ11 and it is integrated into the same box as the DOCSIS or DSL modem and home router. Erik I don't think arbitrarily stupid way can possibly work, since Erik that doesn't ensure that the home network is internally Erik connected. If the user connects three routers in the den Erik together, but those are not connect to the rest of the house, Erik then no protocol we come up with can fix that. a) That's okay, because the three routers in the Den plugged in that way won't affect the router in the basement which is doing fine. b) Actually, the three routers in the Den might see the wifi from the basement, and might join it. That would be nice. I think Erik's point is that the audio system should still get a DHCP address and a (bogus) default route so that it can talk to the wireless speakers in the room which also get addresses. Michaels point about going through the WiFi is interesting in that in the current model this wouldn't work. An access point doesn't talk to another access point over the radio by default. They usually pick different channels specifically to avoid each other. If the access point was integral to or hanging off the routers by a Ethernet, in the uplink model, it wouldn't help even if they did talk to each other. Erik Supporting arbitrary topology (as opposed to just trees) is Erik good in that it enables redundant internal topologies. But Erik getting to a redundant topology requires a deeper knowledge by Erik the users than mandating a tree. More rope. Doesn't mean it is Erik
Re: [homenet] Thoughts about routing - flash/stable storage constraints
In message 4e95c231.5030...@freedesktop.org Jim Gettys writes: On 10/11/2011 12:05 AM, Jari Arkko wrote: Home routers would also have MAC addresses, but again, if we need a 32-bit quantity then shortened 48/64 bit identifiers may (theoretically) have collisions. That being said, if the home routers have to discover their IPv6 prefix through a protocol and store it in flash, they could probably do so also for a router ID. Unless there was some chicken and egg problem that required the router ID for all this discovery to work... As to storing in flash, since most in homenet have not typically worked on embedded systems, worse luck... There is typically a read/write file system that can store state on a current Linux home router (e.g. OpenWrt); it may or may not mapped over the entire flash (which is desirable, as you'd like wear levelling to use all blocks on the flash). The bulk of the firmware is likely contained in a read-only file system called Squashfs, which does LZW compression on a per file basis; overlayed on top may be a read/write file system. Most commonly the read/write file system has been a file system called jffs2 over bare flash, originally implemented on the Compaq iPAQ handheld, a project I helped lead after I got sick of HTTP. And OLPC had a gigabyte of flash (which pushes jffs2 to/beyond it's design limits). There are later flash file systems under development, but I don't have first hand experience with any of them. Flash has the characteristic that write is relatively slow, and erase is generally glacial. Most interesting flash file systems try to do lazy erasure (erase freed blocks when they have a chance later, rather than at the time you may free a file). Since you don't want to wear out the flash, the jffs2 does journaling; one write will commit (potentially) a bunch of changes to multiple files, rather than each write generating one write. How many writes you get depends on the flash technology, whether the flash is bare or has some smart controller, and the wear levelling technology (if any) in use, along with whether all blocks participate in the wear levelling or not (jffs2 does good wear levelling; but using a big squashfs file system + a very small jffs2 file system will reduce the effectiveness; some cheap USB storage devices only do wear levelling on the free blocks, and try to hide the fact it is flash from the system above. I put smart in quotes, because they've often been hideously stupid, with their smarts limited to looking like IDE with a very lame flash translation layer. The most recent smart flash disks for laptops are actually getting very smart, with some help from the OS to help with the erasure problem. But they still cost substantially more, I suspect. I think most home routers currently use bare flash, though it's not clear to me if this will continue or not since the volume market may make the economics change. In any case, with flash of any sort, you don't want to sit there and demand to do lots of periodic writes (on Linux/UNIX you'd mount -atime, for example). All this being said, storing state at the rate of machines/routers appearing or disappearing on a home network, or your ISP going down, isn't likely to cause a problem. You just have to be careful enough to not do anything really stupid; e.g. you map daemons with chatty logs to run their logs to /dev/null, or to tempfs in RAM. And you might take a big latency hit if you have to guarantee the write is stable before continuing an algorithm (if you run into needing to erase a block for some reason). And obviously you don't write tons of data when you don't half to. And update in place may be a bad idea relative to other techniques (which is why journaling file systems such as jffs2 are so desirable). - Jim Jim, Nice reminder on the limitations of flash and some of the workarounds. Some neat hardware does erase on write and buffers the write itself, and can store enough energy in a small battery to flush the writes on power down. Its faster and maximized flash life. Its essentially a RAM front ended flash. I think it was expensive for consumer use. For provider equipement it makes logging to flash feasible thereby avoiding spinning media which may object to a 65 C ambient. Routing protocols are even less stateful than DHCP in this regard. There is no lease to be preserved between boots. The configuration (today in non-zero-config situations) is not sufficiently immuatable to put in a squashfs but may not be changed for months or years. Any old filesystem over bare flash is OK for that. Everthing else in a routing protocol is acquired at run time and therefore should be in RAM (ramfs or in application space RAM). With a zero config routing protocol at worst there would be a small amount of information that would generally be updated only once if at all on a
Re: [homenet] Homenet strawman slides
On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote: A router should not start handing out PD or even IPv4 NAT space until it gets and address from elsewhere. Some routers need to do this, i.e. home routers where service providers charge prohibitive rates for always-on Internet dial-tone and expect subscribers to connect on demand and disconnect after an appropriate idle time. For IPv4 today, these routers typically use PPPoE on the WAN and they often handle this by assigning RFC 1918 address to the LAN hosts and using DNS queries to signal PPPoE to establish the WAN link. For IPv6, I'm not sure what they should do, but I have some ideas. Basically, the router should advertise as a default router with a single ULA prefix and a DNS server at the router's ULA interface address with RFC 6106 and optionally RFC 3736. When the DNS query signals PPPoE to establish the WAN link, the DHCPv6 client will ask for a IA_PD and update the prefix advertised on the LAN accordingly. I'm not sure this model can be made to work with IPv6, but I wouldn't put it past the telcos to try. -- james woodyatt j...@apple.com member of technical staff, core os networking ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
In message 4e94829e.2010...@cisco.com Erik Nordmark writes: On 10/10/11 5:33 PM, Curtis Villamizar wrote: In message4e93358f.7050...@cisco.com Erik Nordmark writes: On 10/8/11 6:13 AM, Jari Arkko wrote: I like this, with the possible exception of using ULAs and your desire to deprecate prefixes as soon as connectivity goes down. (Speaking as someone whose prefixes got invalidated two months ago but who hasn't been home long enough to fix the problem, but my devices still happily communicate with each other using the old prefixes :-) I also agree with Erik that loop and arbitrary topologies is not really required. But the people in the interim at least seemed to say yesterday that we want to go there. I think there are different scopes being discussed. The one I put forth is how to enable existing IPv4 NATting consumer home routers (which all have a designated uplink port, and support multiple home routers by nested NATting) have a way to support IPv6 without requiring any IPv6 NATs. That doesn't seem to be a difficult problem (which perhaps makes it uninteresting for some of us), but to me it seems like an important short-term problem to solve. The larger scope is around arbitrary topologies, no designated uplink port, and perhaps also multihoming. Plenty of problems to solve around autoconfiguring routing protocols, stable prefix assignment to links, multihoming, etc. Erik, I really don't know how many support calls are just the consumer plugging the computer into the wrong Ethernet port on the NAT box and the uplink on the other port and then not being able to figure out what is wrong. All the cables fit in the connector. It should work! It sure would be good to try to find some data on this. If all the ports are the same, no designated uplink, that is better. While I can see that we can build the internals of the home network with devices without a designated uplink (automatically configure prefixes, the routing protocol etc), what I don't understand is how the connectivity to the ISP would happen. How do you see that working? Will each router try the protocols it would use against the ISP (PPPOE, DHCP PD, etc) on every port? Or on every port where it doesn't find a OSPF (or whatever home routing protocol we choose) neighbor? Or does the user have to configure the Customer Edge Router to say port eth0 is the WAN port? On a DOCSIS or DSL router the provider connection will always (maybe always) need some configuration, if for no other reason the provider wants to see an account name and password. If the provider ships out the DOCSIS or DSL router or installs it, then they would do that configuration. Everything *on the homenet side* would be autoconfig and would never have a need to run certain protocols such as PPPOE. If the user chooses to set the SSIDs and enable security on WiFi, that would have to be optional if we wanted true zero config. FWIW I haven't seen any discussion to try to automate this. The manual configuration would be just as error prone as making the distinction between the yellow WAN port and the blue LAN ports on current home gear. The goal is to get zero configuration on the homenet side of homenet/provider demarc. If the provider supplies equipment, then the demarc is that equipment with the homenet side of the homenet/provider link configured ethernets the ethernets and any routers/hosts on the homenet side zero config. If you get an IP address via DHCP on one and none of the others, it may be the uplink and try doing NAT. What may be needed is a IPv4 equivalent to the IPv6 IA_PD and a provider DSL or docsis modem/router that knows how to respond to it. The other routers ask for a IA_PD and the provider modem/router responds with part of 10/8 on each interface (and does NAT). Presumably DHCP could be used within the home for address (and potentially prefix) configuration, thus I don't think we can assume that just because some neighbor on some port responds to a DHCP packet that it is the WAN port. For all we know, the neighbor might be a DHCP relay for the home network. The reason that a routing protocol is needed is DHCP is quite dumb about this and DHCP proxy and ARP proxy, and ND proxy provide at most very limited kludges. Let us separate DHCP6 from DHCP4 for the moment. In DHCP4 the assumption is that the client is always a host (excluding proxy) and returns a single address. In DHCP6 link local communication is possible without an uplink. With link local and a routing protocol, a default route can be discoverd if there is one (or more). Only when one of the routers on (or adjacent to, depending on demarc style) acquires a globally routeable prefix (IA_PD or configured, doesn't matter) can it begin responding to DHCP6 IA-PD requests. Since IPv6 hosts and routers add aliases (or are supposed to) in the presence of multiple
Re: [homenet] Thoughts about routing - trends
In message 4e9494a9.4030...@freedesktop.org Jim Gettys writes: Having said this, I do note the following technological trends: 1) As soon as we get real plug and play routers that don't need manual configuration that work, we'll see a lot more routers in a home environment. Other radio technologies (e.g. zigbee) may encourage this trend. It seemed like the working group agreed that getting to the point that just hooking things together would really just worked was a fundamental requirement (and I agree entirely with this sentiment, as it reflects reality of what already happens in the homes of hackers and non-hackers alike). 2) wireless is much cheaper to implement than wired networking, particularly in most houses where pulling cable is hard. I know this first hand, where I've pulled a lot of cat 6 and wish I could get it to places I don't have it. Unless power line networking really works, I believe that this trend isn't going to change. Is there any progress in this area? I've seen many promises, and few reliable working products. 3) As soon as you have two routers, you have at least two paths; the wired connection between them and the wireless. You may have 3 paths, if you have both 2.4 and 5ghz radios. Frequency diversity routing becomes immediately interesting, along with using your ethernet when it's available in preference to wireless. 4) an apartment building look like a mesh, and possibly with multiple backhauls possibly with multiple ISP's. One should at least think about what happens when you have homes, in such a building, and make sure nothing breaks. Wireless is messy: it isn't limited to where a wire goes. Taking down an entire apartment building/blocks/city would not be fun. I know, I've been there (at least to the point of taking down buildings, and came within a week of a much larger scale disaster). If you believe 1 + 2 + 3 +4 (as I do), then if you look a few years out, you end up with something in the home that begins to resemble very strongly what the community mesh networking folks are doing at a higher scale geographically and in terms of # of nodes today, with many/most of the same concerns and solutions. Understanding the problems they've faced/are facing is therefore worth a bit of investment; Radio diversity is one of the concerns, and interference (of various sorts). Very good points. Much of the discussion has been focused on the single home in isolation. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 4e94bf91.4060...@cs.tcd.ie Stephen Farrell writes: Hi, I've been reading the list with interest and have a question. When various devices in the home figure out which does what, and do that periodically to handle changes, there's clearly the potential that a zombied host tries to try take over stuff with undesirable consequences. My question is whether this group are planning to think about that now, or later, or never? (Or don't even think there's a problem worth attempting to address.) Note - I'm not trying to argue for any particular level of security and certainly not for some unachievable fort knox everywhere, I'm just asking what's the plan? S. Watch out for autoconfig of microphones and cameras. :-) I call it bonding. Some ritual has to be performed before specific types of devices trust each other. Like the garage door opener and the clicker thingie. Same should be true of the audio system and the wireless speakers. The TV and remote use IR. The routers just route, but they need to be a bit more picky about who can configure them. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
In message 17786.1318379...@marajade.sandelman.ca Michael Richardson writes: Russ =3D=3D Russ White ru...@riw.us writes: Russ You need a unique identifier at the equipment level for Russ anything you intend to auto-configure --autoconfiguring Russ uniqueness is a very hard, probably impossible, problem on a Russ global scale. So we need to count on this one thing, no matter Russ what else we might need to back in to. Russ Now, it might be possible to some hash over a GPS location for Russ a base, and then add on MAC addresses, or some such, but We've assumed a unique MAC, which is 48 bits long.=20 But OSPF router-id is 32 bits.What is the likelyhood of a collision=20 in the bottom 32-bits of the MAC?=20 Each organization has one or more unique OUI which includes one of the bottom four bytes. The next three (of those four) are unique only within the OUI which is the top three bytes (but with two bits given special meaning). So what are the chances that two organization start numbering the bottom bits at zero and work their way up until the bottom three bits are filled. Since there are way more than 256 organizations that have an OUI, collisions, while rare, can happen. If there is a way to recover from a collision, then its a complete non-issue and a random number can be used. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Does ND Proxy useful for homenet?
Victor == Victor Kuarsingh victor.kuarsi...@gmail.com writes: Victor These devices (in such operating modes) are however not Victor likely to participate in a home network (as the gateway Victor device or a router) and it's very unlikely to be the head of Victor home network. I STRONGLY DISAGREE. Not only will smartphones be pressed into use whenever the primary ISP is down (I've done this three times in 18 months since I got a smartphone), but whenever there is an ad-hoc gathering of people who need network, they will insist that their smartphones be smart. I expect my smartphone to provide network to my Personal Area Network (whether via Bluetooth PAN or Zigbee), and I further expect that PAN to have an alternate exit via my HAN. I want to further point out that 3GPP and the mobile operators are no longer in control of what phones do. They are network devices. The only thing they can control is the protocol on the wire, and if they piss of the consumer, the consumer will simply tunnel. It's good that 3G will have PD in the future. I know that new versions of SIXXS AICCU now include it. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 159dbf45-107c-4c12-ae01-9bb494e8e...@fugue.com Ted Lemon writes: On Oct 11, 2011, at 9:03 PM, Michael Richardson wrote: However, I am thinking that we can perhaps bootstrap equipment that has never been configured (or has been factory reset) in some fashion such that if the equipment is virginal that it can essentially always try some default keys, and bring up enough networking to let all equipment be discovered and identified. There would be strong nag screens to get the user to up a network password. A pre-shared key that is pre-shared to every device is the same as no key. So you might as well not bother with that complexity. Conceivably CGA could be used to publish public/private key pairs allowing devices to automatically recognize each other and present their relationships in a UI for the end user to approve, but that's not precisely plug and play. Agree completely on this. For example, having bumping the factory default button on a wireless camera open access to everyone would really be a bad idea. I think the simplest thing would be to require that each device be able to talk to a USB drive. Each device collects all the public keys on the USB drive, and stores their own there. Devices then share their public key with other devices identified on the USB drive, so that as each device joins the network, the other devices learn about it. This isn't bulletproof=97an infected PC that's configured with these keys could be used to gain access to the keys, for example. But it's a lot better than a well-known key. Of course, this isn't quite as plug and play as you seem to want, and it requires that each device have a USB port, which might not be acceptable. Plus, it would mean that the IETF would have to talk about hardware, which seems like a bit of a non-starter. But I think it's the right way to solve the problem. Mandating USB is not practical. For example I have a set of DECT phones with a single SIP base station. You can bond the phone to the base station but you have to enter a menu on the phone and do something on the base station (through the web interface or otherwise) within 10 seconds. Not perfect, but it works. There are too many cases like bonding the garage door opener to the clicker, or bonding the speakers to the audio system, etc, don't need to store keys on a USB as a boot strap. For some things USB would be fine. And my water heater, as facinating as it might be to the electrical utility, need not have the key to my garage door opener or my audio speakers, even though I might want to turn the hot water up or down a few degrees through a remote device some day. I would say that reinventing the kerberos KDC with ticket granting tickets and service tickets is probably overkill and should be out of scope. But it would be a truly wonderful thing if the interface could be made simple enough for a consumer to set up. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
In message 4e95096e.5020...@herberg.name Ulrich Herberg writes: Jari, On 10/11/11 12:05 PM, Jari Arkko wrote: Home routers would also have MAC addresses, but again, if we need a 32-bit quantity then shortened 48/64 bit identifiers may (theoretically) have collisions. That being said, if the home routers have to discover their IPv6 prefix through a protocol and store it in flash, they could probably do so also for a router ID. Unless there was some chicken and egg problem that required the router ID for all this discovery to work... I agree. Since we need to configure unique prefixes to each router in the home anyway, it should not be any problem to do the same for a router ID (or even just use an address from the configured prefix as router ID, which should then be unique). A while ago, there were some plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop network for configuring prefixes in the network. As in a home network, I assume there is always at least one border router with the global prefix, specifying something like that seems to be reasonable for me (in a MANET, that can be more difficult, because there is not necessarily such a central entity as the border router). Regards Ulrich Ulrich, Whatever ends up being specified should require no configuration and work when there are: zero border routers providing a prefix (outage and/or partition) one border router providing a prefix (the easy case) multiple border routers providing a prefix For the large apartment building example that Jim gave, we really should consider scaling behavior when there are a large number of border routers providing a prefix within a given mesh. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
While talking about hardware. These these devices all need a battery backed clock or all the crypto will be broken. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
In message 669f4202-6fd4-4f13-ae7b-e725d53ad...@gmail.com, Jim Gettys writes: Or you solve the time problem some other way... Batteries die too... Jim Indeed. It should be a user servicable part. As to solving it other way, leap of faith springs to mind. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message 78ce7d95-48c9-4de4-9707-f11ac2a05...@cisco.com Ole Troan writes: I've been reading the list with interest and have a question. When various devices in the home figure out which does what, and do that periodically to handle changes, there's clearly the potential that a zombied host tries to try take over stuff with undesirable consequences. My question is whether this group are planning to think about that now, or later, or never? (Or don't even think there's a problem worth attempting to address.) Note - I'm not trying to argue for any particular level of security and certainly not for some unachievable fort knox everywhere, I'm just asking what's the plan? can we explore some fundamental principles of how and what we need to secure? Yes. Please do. using the electricity network as an analogy, can we make a distinction between safety and security? the electricity network in the home is somewhat self protecting with breakers and earthing. a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks and so on. I don't think it is the networks job to control who has access to the pictures of my grandmother or who can print to my printer. that's application policy. Exactly. This is a multi-decade old debate. Should the applications be insecure and rely on a firewall? (Microsoft advocated this in the 1990s and it has stuck to a large extent). Or should the network be open and the applications secure? I'm strongly with you on this. The applications should take care of any security that is necessary *for that application*. is it the networks job to control who has access to the network? no, I think that is a layer 2 function. No. No. No. Security is not a layer-2 function. Security is an application function. You had it right the first time. Key exchanges and certificates are not layer-2 functions. It is entirely possible that the same computer has pictures of Grandma that I'm OK with you seeing and has a printer hanging off it that I don't want anyone in the world to be able to print on. Same MAC address. So that can't be a layer-2 function. And port filtering at a firewall is a lame excuse for security. The bug in relying on a firewall in an enterprise (a little less so for a home) is that once any one user downloads malware, that malware has access to everthing behind the firewall largely because of the assumption that security is not needed because there is a firewall. Lets not enshine the dumbest practices of the IT world. I think homenet should focus on L3. (and be clear on what it expects from the other layers with regards to security). cheers, Ole Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing - trends
On 10/12/11 7:51 PM, Russ White wrote: [...] While I wouldn't want to rule OLSRv2 completely out, I think it should compete head to head with an extended OSPF and an extended IS-IS, or even other efforts afoot. I'd rather see requirements first, and a good solid evaluation of what's available against those requirements, rather than choosing technologies out of the gate. Hi Russ, I fully agree. There should be an evaluation against the requirements. My point was just not to rule out OLSRv2 (or other protocols) based on the fact that a protocol is used, amongst other, in mesh network deployments. Ulrich ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing - trends
In message 4e957f43.1060...@riw.us Russ White writes: You are absolutely right that pulling cable is hard and expensive. Pulling cable is indeed hard and expensive. In my experience, it is the right thing for some applications, such as TV and my home office. Personally, I have both wired and wireless throughout the house; my personal rule is that I use the shared wireless network for activities that move around, to provide convenience at the expense of consistency and bandwidth, and wired for things that stand still, to provide stable bandwidth at the price of a one-time wiring effort. I do the same --I pull cable for televisions, and even for locations where a desktop or laptop is going to be sitting on a regular basis. So I think we should expect wired and wireless as the norm, rather than expecting wireless all the time. While I wouldn't want to rule OLSRv2 completely out, I think it should compete head to head with an extended OSPF and an extended IS-IS, or even other efforts afoot. I'd rather see requirements first, and a good solid evaluation of what's available against those requirements, rather than choosing technologies out of the gate. :-) Russ Russ, At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted pair. [Well someone pulled it, but not me.] Anyone remember vampire taps in 10base2? What a reliability headache! I pulled 10base5 coax at home before I pulled twisted pair and before trying the early DEC Wavlan stuff that preceeded WiFi (again, at home). Too bad I moved and had to pull wire again (but I like the result). Back on topic: I do think we should consider OSPF (not so keen on ISIS, but OK) and should not rule out OLSRv2 or other LLN related work and MANET work (though I'm far from an expert on LLN or MANET). We will have to extend OSPF to make zero config possible. The extensions should be completely backwards compatible if at all possible. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
In message 4e95836d.4020...@riw.us Russ White writes: Russ You need a unique identifier at the equipment level for Russ anything you intend to auto-configure --autoconfiguring Russ uniqueness is a very hard, probably impossible, problem on a Russ global scale. So we need to count on this one thing, no matter Russ what else we might need to back in to. Russ Now, it might be possible to some hash over a GPS location for Russ a base, and then add on MAC addresses, or some such, but We've assumed a unique MAC, which is 48 bits long. But OSPF router-id is 32 bits.What is the likelyhood of a collision in the bottom 32-bits of the MAC? Ah, I see the problem... There is a pretty high likelihood of a collision, actually, at least as long as you use multiple vendors in your home network. It's bound to happen to someone, someplace. So, a suggestion to resolve this: 1. Use the lower 32 bits of one of the mac addresses on the box as the initial id. 2. Add a new field to the router capabilities that carries the full 48 bit mac address, or even some munged together longer id, based on multiple mac addresses on the device, or some such. Not backwards compatible. The older OSPF routers will see only the non-unique 32 bits and the network won't work. 3. During initial setup, if you receive a capability that appears to be from yourself, you open this secondary id section to find out if it's really you, or someone else who happens to have the same 32 bit id. 4. If it's really you, discard the packet. 5. If it's not really you, and if the other router's large id is lower than yours, choose another mac address from which to take your local id, and restart your ospf process. 6. If it's not really you, and the other router's large id is higher than yours, then send a router capabilities LSA unicast to this other router, so the other router knows to change its id. I don't think IS-IS would have this problem. :-) Russ If the other router doesn't implement the extension you've described, the network is hosed forever. If you have more than one link you should receive the LSA (or LSPDU) that you advertised. If you have one link, you won't. If you receive a LSA (or LSPDU) that clearly you didn't advertise, then you have a collision. *Both* routers should pick a new router-id if this condition is detected and they implement this extension. Don't even bother using a MAC address for the router-id. Use a random number. If a collision occurs, use a different random number. This should also work for interfaces without a MAC (not that many homes run POS today, but maybe some layer-2 in the future). Here is where it if fuzzy if one router is a legacy router. It may not look at LSA (or LSPDU) apparently from itself or may just log a problem and continue. When backing off, the bogus advertisements need to be withdrawn. A possible backward compatibility wrinkle exists if the legacy router does not readvertise (being legacy it will not pick a new router-id). The problem could persist for maxage. Better than forever but still not good. Don't use a non-configured router-id if you don't support this ability to back off. (Routers today don't pick a random router-id and they shouldn't unless they can backoff). Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] security question for zeroconf stuff inside the homenet...
In message ede9b41f-4de6-4e01-a4fc-ac03aff5f...@fugue.com Ted Lemon writes: On Oct 12, 2011, at 4:48 AM, Ole Troan wrote: using the electricity network as an analogy, can we make a distinction between safety and security? the electricity network in the home is somewhat self protecting with breakers and earthing. a home network must protect 'itself', i.e. handle any device plugged into it, in any topology, external and internal attacks and so on. I am highly sympathetic to the desire not to try to solve this problem. However, unfortunately network topology isn't the same as electrical topology, for a couple of reasons. The first reason is that electrical systems are generally set up by professionals. Yes, you plug devices into the electrical wiring of your house, but someone skilled set it up (or if not, I hope you sleep in asbestos pajamas). The devices we are talking about are more analogous to circuit distribution panels than to toasters. The second reason is that electrical systems are essentially topology-free. Any point on the system is essentially equivalent to any other. This is not true of a home network with routing. What we are talking about is essentially the possibility of rogue distribution panels intentionally or accidentally being connected to your distribution system. =20 The electricity analogy is not very useful. Maybe best to drop it. Which is a result of the third reason: home networks are typically wireless, or partially wireless, and so there is no physical security, unlike an electrical network in a house, which is secure by virtue of being entirely enclosed by the house. I think what you are getting at is that we cannot be responsible for securing the network. And that is probably true. But if the system doesn't have a built-in mechanism for distinguishing between friend and stranger, the autoconfiguration mechanism will create topologies that aren't desired, either by accident or because a stranger wants access to the network. If applications are secure, the only threat to a wide open network is theft of service. WPA provides a knob to stop that. The only question is whether WPA or any WiFi security should be enabled by default. Is it better to leave the possibility of theft of service or is it better to have the device unusable by default (until configured)? For provider equipment that is always configured, the latter (unusable until configured). For home equipment where the customer wants to unpack the box, plug it in and use it, the former is better (make it usabled but allow possible theft of service). Every WiFi product I ever bought was open WiFi as shipped. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Does ND Proxy useful for homenet?
In message cabb3019.101ff%victor.kuarsi...@gmail.com Victor Kuarsingh writes: Mark, A few points on this topic. As noted, the Cell system will have PD capabilities until a future 3GPP release (Rel-10) as noted. Although, even when the functionality is in place (generally), small devices like Smartphone and the mini gateways (3G/LTE devices which allow for 4-5 hosts to attached to Cell system) - PDs may not be used. Many of these devices (I.e in the case of the smartphone) have modes of operation where they tether, which turns them into a mini gateway. They are not likely to be be full blown gateways equivalent to what you see common CPEs. In the IPv4 case, these devices NAT the IPv4 private addresses used by hosts behind the device to the network assigned address. In the case of IPv6, it will have access to the network assigned ::/64. PCs (maybe other devices) behind such devices will need access to the IPv6 network, but may not have access to PD space. This was one of the specific use cases I was eluding to before. These devices (in such operating modes) are however not likely to participate in a home network (as the gateway device or a router) and it's very unlikely to be the head of home network. With this explanation, I am not sure if this should/would be considered as such in HomeNet. These devices technically become gateways/bridges to the Internet. And the hosts that use them are often the same type of devices which connect to common home networks. Regards, Victor K Victor, And if I'm at home with WiFi at home and my laptop plugged into the Internet and plug in the USB (or other tether) to update my contacts list on the phone, because its easier/faster, we have the situation described, even though the intent was not to use the phone as an IP gateway. This gets back to users plugging things in in seemingly arbitrary way that made sense to them at the time for some reason. Curtis On 11-10-10 4:51 PM, Rajeev Koodli rkoo...@cisco.com wrote: Hi, The smartphone will only get a /64 in the current 3G/4G releases (rel-8, rel-9). Prefix delegation is specified in Rel-10. -Rajeev On 10/10/11 1:01 PM, Mark Townsley towns...@cisco.com wrote: Or are you saying a mobile device (a smartphone) will only ever get a /64 to share? My (limited) understanding of the various 3/4G standards are that a PD for a phone is something that is very, very, recent. Perhaps Rajeev (cc'd) or someone else here can elucidate. - Mark ___ 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] Does ND Proxy useful for homenet?
On Wed, Oct 12, 2011 at 8:41 PM, Michael Richardson m...@sandelman.cawrote: Victor == Victor Kuarsingh victor.kuarsi...@gmail.com writes: Victor These devices (in such operating modes) are however not Victor likely to participate in a home network (as the gateway Victor device or a router) and it's very unlikely to be the head of Victor home network. I STRONGLY DISAGREE. That's fine. My statement was based on an aggregate set of behaviors over millions of endpoints. Corner cases always exist (and perhaps not so corner in the future). Not only will smartphones be pressed into use whenever the primary ISP is down (I've done this three times in 18 months since I got a smartphone), but whenever there is an ad-hoc gathering of people who need network, they will insist that their smartphones be smart. Sure, a number of people seem to do this and tether their phones for Internet Access. Although performance is somewhat degraded as Smartphones don't seem to make very good routers (performance wise - but this may change). Notice I did not say never, I said not likely. I expect my smartphone to provide network to my Personal Area Network (whether via Bluetooth PAN or Zigbee), and I further expect that PAN to have an alternate exit via my HAN. Understood. However is that what most people will expect? Perhaps one can argue yes. I want to further point out that 3GPP and the mobile operators are no longer in control of what phones do. They are network devices. I guess this is true to some extent. There is value in having standards in this area which make things work in a relatively complex environment. The only thing they can control is the protocol on the wire, and if they piss of the consumer, the consumer will simply tunnel. I guess some may tunnel. Not sure if most would. It's good that 3G will have PD in the future. I know that new versions of SIXXS AICCU now include it. PD is in the spec. But when it sees the light of day in actual deployments (network + devices) is the key. regards, Victor K -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ 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] Does ND Proxy useful for homenet?
And if I'm at home with WiFi at home and my laptop plugged into the Internet and plug in the USB (or other tether) to update my contacts list on the phone, because its easier/faster, we have the situation described, even though the intent was not to use the phone as an IP gateway. I can see your point. So in this case.. I guess your computer/laptop would belong to two networks (wired USB and Home Network over WiFi). Not sure if this example shows how the two networks join - unless the computer bridges/routes traffic. This gets back to users plugging things in in seemingly arbitrary way that made sense to them at the time for some reason. Would you say this example adds merits to ND for the smartphone gateway function, or the opposite? regards, Victor K Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
In message 4c6c6fc3-d1a9-4663-a1e1-802d1a6d0...@apple.com james woodyatt writes: On Oct 12, 2011, at 1:52 PM, Curtis Villamizar wrote: A router should not start handing out PD or even IPv4 NAT space until it gets and address from elsewhere. btw - the valid point about serving the site needs was brought up, so some assignment would be needed in absense of an uplink. Some routers need to do this, i.e. home routers where service providers charge prohibitive rates for always-on Internet dial-tone and expect subscribers to connect on demand and disconnect after an appropriate idle time. For on-demand routing, it makes sense for the router to hand out an address while not being connected. I personally haven't seen that since 56K modems, but OK. (And I had FR back then). For the DSL and MSO services I've used, the service was always up, unless of course you powered down the CPE. For IPv4 today, these routers typically use PPPoE on the WAN and they often handle this by assigning RFC 1918 address to the LAN hosts and using DNS queries to signal PPPoE to establish the WAN link. OK. Client does DNS and that is the on demand part. Fine. In in absence of DNS, a ping or TCP SYN would bring it up. For IPv6, I'm not sure what they should do, but I have some ideas. Basically, the router should advertise as a default router with a single ULA prefix and a DNS server at the router's ULA interface address with RFC 6106 and optionally RFC 3736. When the DNS query signals PPPoE to establish the WAN link, the DHCPv6 client will ask for a IA_PD and update the prefix advertised on the LAN accordingly. I'm not sure this model can be made to work with IPv6, but I wouldn't put it past the telcos to try. With IPv6 there is no reason that the CPE can't be assigned a persistant address but bring the connection down. On power up it could connect and get it, then bring the link down in the absence of traffic. Usually if it is powered up it is because someone want to use it, so this would be fine. There is no reason not to hold the IA_PD assignment at the CPE when an on demand link is down. That prefix can be requested in the IA_PD request when there is demand again, just to refresh it and confirm. The same DNS query can be used as the trigger in on-demand IPv6 as well. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
In message 20111013011929.1f7051527...@drugs.dv.isc.org Mark Andrews writes: While talking about hardware. These these devices all need a battery backed clock or all the crypto will be broken. Having a clock is not hard but I don't think your statement is true. Some crypto does not require time, but rather just entropy (a nonce or challenge). For crypto that does require time the former can be a bootstrap of sorts, possibly to get ntp going if very accurate time is needed (for some reason). For example ssh with rsa or dsa does not require time. You need to know what month and year it is to be good enough as far as checking certificates. A lot of the KARP work does require knowing the time to prevent replay attack. Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Does ND Proxy useful for homenet?
In message CADiurz38Hq4+xxYhx+s7XDOOv5rsaKxGnNj=0w68p3zg4jm...@mail.gmail.com Victor Kuarsingh writes: And if I'm at home with WiFi at home and my laptop plugged into the Internet and plug in the USB (or other tether) to update my contacts list on the phone, because its easier/faster, we have the situation described, even though the intent was not to use the phone as an IP gateway. I can see your point. So in this case.. I guess your computer/laptop would belong to two networks (wired USB and Home Network over WiFi). Not sure if this example shows how the two networks join - unless the computer bridges/routes traffic. Good point. The computer would have three ways to pick from. Maybe the phone acting as a WiFi was a better example. This gets back to users plugging things in in seemingly arbitrary way that made sense to them at the time for some reason. Would you say this example adds merits to ND for the smartphone gateway function, or the opposite? ND just finds the link local addresses. Figuring out which way to go with packets is another story. You need a routing protocol if there is a loss of connectivity more than one hop away. At that point the addresses are still valid, but the path to the default route has changed. There is no fast withdraw in ARP proxy, DHCP proxy, ND proxy. In a routing protocol, the flooding of bad news is fast. Plus arbitrary topologies can be supported. And as Jim pointed out, we need to be careful about the scalability of flooding for WiFi networks that may be come dense. regards, Victor K Regards, Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
I agree. Since we need to configure unique prefixes to each router in the home anyway, it should not be any problem to do the same for a router ID (or even just use an address from the configured prefix as router ID, which should then be unique). A while ago, there were some plans in AUTOCONF to specify how to use DHCPv6 (-PD) in a multi-hop network for configuring prefixes in the network. As in a home network, I assume there is always at least one border router with the global prefix, specifying something like that seems to be reasonable for me (in a MANET, that can be more difficult, because there is not necessarily such a central entity as the border router). I think there will be, by default, multiple border routers. In my house I currently have 6 devices that provide internet connectivity, and I assume that number is going nowhere but up. Each of these devices could, in theory, be a border router, in some way. What saves the day is that I don't allow 4 of them to talk on the internal network, and the other two are carefully segregated. But there's no reason for any of this --there's no reason I shouldn't be able to use all of them, especially as some of them might be able to reach outside networks in addition to the Internet at large that others might not be able to. :-) Russ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Does ND Proxy useful for homenet?
+1 -Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Michael Richardson Sent: jeudi 13 octobre 2011 02:42 To: homenet@ietf.org Subject: Re: [homenet] Does ND Proxy useful for homenet? Victor == Victor Kuarsingh victor.kuarsi...@gmail.com writes: Victor These devices (in such operating modes) are however not Victor likely to participate in a home network (as the gateway Victor device or a router) and it's very unlikely to be the head of Victor home network. I STRONGLY DISAGREE. Not only will smartphones be pressed into use whenever the primary ISP is down (I've done this three times in 18 months since I got a smartphone), but whenever there is an ad-hoc gathering of people who need network, they will insist that their smartphones be smart. I expect my smartphone to provide network to my Personal Area Network (whether via Bluetooth PAN or Zigbee), and I further expect that PAN to have an alternate exit via my HAN. I want to further point out that 3GPP and the mobile operators are no longer in control of what phones do. They are network devices. The only thing they can control is the protocol on the wire, and if they piss of the consumer, the consumer will simply tunnel. It's good that 3G will have PD in the future. I know that new versions of SIXXS AICCU now include it. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ 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] Thoughts about routing - trends
Curtis, At about same time you were moving/re-wiring your new house, I've started to use Ethernet over power and have been using it since then :) Regards, Jeff -Original Message- From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of Curtis Villamizar Sent: Wednesday, October 12, 2011 19:29 To: Russ White Cc: homenet@ietf.org Subject: Re: [homenet] Thoughts about routing - trends In message 4e957f43.1060...@riw.us Russ White writes: You are absolutely right that pulling cable is hard and expensive. Pulling cable is indeed hard and expensive. In my experience, it is the right thing for some applications, such as TV and my home office. Personally, I have both wired and wireless throughout the house; my personal rule is that I use the shared wireless network for activities that move around, to provide convenience at the expense of consistency and bandwidth, and wired for things that stand still, to provide stable bandwidth at the price of a one-time wiring effort. I do the same --I pull cable for televisions, and even for locations where a desktop or laptop is going to be sitting on a regular basis. So I think we should expect wired and wireless as the norm, rather than expecting wireless all the time. While I wouldn't want to rule OLSRv2 completely out, I think it should compete head to head with an extended OSPF and an extended IS-IS, or even other efforts afoot. I'd rather see requirements first, and a good solid evaluation of what's available against those requirements, rather than choosing technologies out of the gate. :-) Russ Russ, At various jobs I pulled 10base2 coax, then 10base5 coax, then twisted pair. [Well someone pulled it, but not me.] Anyone remember vampire taps in 10base2? What a reliability headache! I pulled 10base5 coax at home before I pulled twisted pair and before trying the early DEC Wavlan stuff that preceeded WiFi (again, at home). Too bad I moved and had to pull wire again (but I like the result). Back on topic: I do think we should consider OSPF (not so keen on ISIS, but OK) and should not rule out OLSRv2 or other LLN related work and MANET work (though I'm far from an expert on LLN or MANET). We will have to extend OSPF to make zero config possible. The extensions should be completely backwards compatible if at all possible. 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
