Re: [homenet] walled garden DNS
Peter == Peter Koch p...@denic.de writes: example.com NS reachable by the world. garden.example.comNS pointing to record, where IPv6 address is only reachable from garden. television.garden.example.com returned from garden.example.com name server (above) This solution works perfectly in IPv4 land, but due to lack of IPv4 Peter it works, but nowhere near perfectly. Whenever a querying system Peter changes its intended name space (resolution context) from $local Peter to the global one, resolution of names in garden.example.com Peter will just time out. Encoding this user experience in the design looks Peter like a suboptimal choice to me. yes, but what is being asked for now, is that the host equivalent of /etc/resolv.conf be extended with a list of suffixes. We are told that mobile operators (who still think they own the handsets) will be deploying various application layer systems whereby the application will always do some DNS requests over 4G, and some content will only be available that way. So, this failure you describe will still occur, but instead of timeout the user will get host not found It seems to me that we just don't need anything else in IPv6, except easily *available* non-connected PI address space (whether it's ULA-C, some recognized part of 2000::/3, or an entirely new space). Peter While ULAs would reduce collisions, the general issues would be the same Peter as with RFC1918 space. Thus why I said ULA-C. -- ] 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. pgpnZBbKxosgF.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
Curtis == Curtis Villamizar cur...@occnc.com writes: Curtis If it is zero config and its persistent store is DHCP leases, then Curtis they will expire. OSPF advertisements would have aged out long ago. Curtis It might be worth redoing the router-id selection if it is well past Curtis the maxage limit and there are no adjacencies. So, I think you are right in general... the IA-PD might last more than a week. -- ] 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] Multilink subnet routing (MLSRv2)
Having missed the meeting, anything more recent on MLSR than this: draft-ietf-ipv6-multilink-subnets-00 Multi-link Subnet Support in IPv6 (2002-07-08, Expired) draft-thaler-ipngwg-multilink-subnets-02 Multi-link Subnet Support in IPv6 (2001-11-29, Expired) The only reference to MLSR in an RFC is in an IAB RFC, RFC4903: There was also a proposal to define multi-link subnets [MLSR] for IPv6. However, this notion was abandoned by the IPv6 WG due to the issues discussed in this memo, and that proposal was replaced by a different mechanism that preserves the notion that a subnet spans only one link [RFC4389]. Note that there is a subset of the multi-link subnet problem that can be solved using an off-link model as described in RFC 5942, and is currently deployed in DOCSIS networks. - Wes ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-chown-homenet-arch-00.txt
We would like to get plenty of review and comment. Rather than dealing with individual edits, I'd rather start with a general philosophy question. I understand that the IETF thinks NATs are evil, but I also think there shouldn't be so much emphasis on homenets are not NAT, in an architecture document. Can we sideline the entire discussion over NATs. They're going to be there no matter what. My second concern is that while I understand the end-to-end principle, I also know that it's not realistic in many situations --and the home is one place where it's probably not. I know, I know, this is all heresy, but hear me out for a second before you hit reply and tell me how stupid I am being. This one line illustrates the entire concept in a nutshell: Security perimeters can of course restrict the end-to-end communications, but it is easier to block certain nodes from communicating than it is to re- enable nodes to communicate if they have been hidden behind address translation devices. Is this really true? When I want to secure a physical space, I block off all access, then put in carefully thought out access control points. I don't pile all my goods in the middle of the street, and then actively monitor every person who walks by, hiring more people to do the monitoring as needed. And I would point out that the problem is even worse in the network world --it's a large risk to come into my house and try to rob me, because of the physical danger involved. There is physical risk for the person breaking and entering, in other words. Breaking into me network has no risk whatsoever, and the gain could be huge --larger than stealing what I have in my living room. Instead of stealing my television, could steal my identity --and all at no physical risk, with trivial effort (you don't have to actually go to my house, etc.). So my posture on the network side is actually stronger, and more suspicious, than it is on the physical side. I think we should be a little more realistic about network security. We'd all like to live in a world where there are no identity thieves, and there are no viruses, and there is no-one trying to harm you, or invade your privacy. But that's just not real. And I know I'm about to get all sorts of stories about how someone has had their computer connected to the internet for x number of years, no nat, no firewall, and they've never caught anything, nor had anyone steal anything. Maybe you just need to lead a more interesting life if that's the case. And I'm happy for you, but when I actually administered a large network, I had virus incidents constantly --and I know I face it all the time in customer networks. So, IMHO: 1. Stop the screed against NAT. 2. Set out positive requirements, rather than negative ones. 3. Be realistic about security --the default should be _nothing_ reaches into my home, and I should have an easily managable way to allow what I want to allow. The default should not be an open door to anyone from anyplace at any time, and then we'll put in advanced monitoring to block activity. Just my 2c. :-) Russ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Homenet strawman slides
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. -- ] 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. pgp4UUxmLTGaE.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
Fred == Fred Baker f...@cisco.com writes: Fred On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote: 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... Fred (z)ospf requires the router to have a router id in order to Fred join the network, which it has to do before it can receive the Fred LSAs from other routers in the area to inspect their subnet Fred prefixes. So making the router id dependent on the prefix Fred doesn't make a lot of sense to me. Fred While a MAC Address is not guaranteed to be globally unique, Fred it is intended to be; places where duplicates have been seen Fred tend to be manufacturing errors. From that perspective, Fred grabbing the least significant 32 bits from a MAC address as a Fred first guess seems reasonable. What one would then need to do Fred is What do we do in that rare case where the bottom 32 of the MAC are duplicated? Also consider that virtual switches (VMware, XEN, etc.) all pretty much use the same set of MAC addresses. VMware has a 50: prefix that they use, XEN has another, and did you know that 10:00:00 (curisously like 10/8) is reserved for private use... So, it would be good for zospf text to say something about this. I think that we can use 32-bits of MAC address in most cases. Fred One obviously doesn't actually announce any LSAs using the Fred router ID until a unique router id is established. okay. -- ] 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. pgpmCSM7cpPzu.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
On Oct 11, 2011, at 10:27 AM, Michael Richardson wrote: Fred == Fred Baker f...@cisco.com writes: Fred On Oct 11, 2011, at 12:05 AM, Jari Arkko wrote: 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... Fred (z)ospf requires the router to have a router id in order to Fred join the network, which it has to do before it can receive the Fred LSAs from other routers in the area to inspect their subnet Fred prefixes. So making the router id dependent on the prefix Fred doesn't make a lot of sense to me. Fred While a MAC Address is not guaranteed to be globally unique, Fred it is intended to be; places where duplicates have been seen Fred tend to be manufacturing errors. From that perspective, Fred grabbing the least significant 32 bits from a MAC address as a Fred first guess seems reasonable. What one would then need to do Fred is What do we do in that rare case where the bottom 32 of the MAC are duplicated? Pick a random number. Note that we agree it is a rare case. If it's a router, it probably has more than one MAC Address... Also consider that virtual switches (VMware, XEN, etc.) all pretty much use the same set of MAC addresses. VMware has a 50: prefix that they use, XEN has another, and did you know that 10:00:00 (curisously like 10/8) is reserved for private use... Yes, and homes frequently use virtual switches. To be really honest, yes, it would be good for zospf - if we recommend that - to make some suggestions. That said, there is no reason for the suggestions to be normative. What OSPF requires is that the RID is unique in the area. It does not require that it be derived from any given datum. So, it would be good for zospf text to say something about this. I think that we can use 32-bits of MAC address in most cases. Fred One obviously doesn't actually announce any LSAs using the Fred router ID until a unique router id is established. okay. -- ] 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] Homenet strawman slides
Erik, 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? 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. this is the problem we named border discovery during the interim. there were a few ideas of how that could be done. either implicit or explicit. nothing concluded, and I agree this is an important problem to tackle. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
What do we do in that rare case where the bottom 32 of the MAC are duplicated? Also consider that virtual switches (VMware, XEN, etc.) all pretty much use the same set of MAC addresses. VMware has a 50: prefix that they use, XEN has another, and did you know that 10:00:00 (curisously like 10/8) is reserved for private use... So, it would be good for zospf text to say something about this. I think that we can use 32-bits of MAC address in most cases. Fred One obviously doesn't actually announce any LSAs using the Fred router ID until a unique router id is established. okay. You need a unique identifier at the equipment level for anything you intend to auto-configure --autoconfiguring uniqueness is a very hard, probably impossible, problem on a global scale. So we need to count on this one thing, no matter what else we might need to back in to. Now, it might be possible to some hash over a GPS location for a base, and then add on MAC addresses, or some such, but IMHO, homenet should start with the assumption of having some sort of unique id in every device deployed, available through some sort of local API, and work from there. Let's solve problems that can actually be solved... :-) :-) Russ ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing - trends
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 reality of how wireless works, with just works automatic configuration, with fail safe behaviour. - Jim ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
On 10/10/2011 7:18 AM, STARK, BARBARA H wrote: The subset of tree topology where a consumer places ones router behind another router is *extremely* common. Statistics I saw several years ago suggested that probably about 60% of ADSL customers in the US use this topology. The most common cause for this topology is where the service provider supplies a free ADSL router with a single port to a subscriber, and the subscriber then puts their own multi-port router behind that router. The ADSL router is configured to do the PPPoE, and is also configured to automatically provide whatever public IP address it gets to whatever is behind it (via DHCPv4, as a sort of automatic DMZ function -- the ADSL router also uses that public IP address for its needs). The ADSL router is often set to provide only that one address, and not to support a full network of devices. Which is why consumers are forced to use their own router. ... They also do this commonly to introduce or upgrade their WiFi service at home without needing to reconfigure the subscriber access box. To a lot of consumers, IF things can be plugged together, then they WILL BE. This also tends to be how VoIP router + consumer's wireless router topology works. That too... Joe ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] security question for zeroconf stuff inside the homenet...
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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] draft-chown-homenet-arch-00.txt
Hi, On 12 October 2011 00:50, Russ White ru...@riw.us wrote: We would like to get plenty of review and comment. Rather than dealing with individual edits, I'd rather start with a general philosophy question. I understand that the IETF thinks NATs are evil, but I also think there shouldn't be so much emphasis on homenets are not NAT, in an architecture document. Can we sideline the entire discussion over NATs. They're going to be there no matter what. My second concern is that while I understand the end-to-end principle, I also know that it's not realistic in many situations --and the home is one place where it's probably not. I know, I know, this is all heresy, but hear me out for a second before you hit reply and tell me how stupid I am being. This one line illustrates the entire concept in a nutshell: Security perimeters can of course restrict the end-to-end communications, but it is easier to block certain nodes from communicating than it is to re- enable nodes to communicate if they have been hidden behind address translation devices. I think you are quoting from the Transparent End-to-End Communications section on pages 14/15 which is to do with communications _within_ the home network. Is this really true? When I want to secure a physical space, I block off all access, then put in carefully thought out access control points. I don't pile all my goods in the middle of the street, and then actively monitor every person who walks by, hiring more people to do the monitoring as needed. ... Generally speaking, I want open access within my home network, but may add specific rules to stop e.g. guest wi-fi getting to certain servers. I don't want layers of NAT within my home network, which is what you can get if you plug the WAN port of a IPv4 network device into the LAN port of another device. So, IMHO: 1. Stop the screed against NAT. 2. Set out positive requirements, rather than negative ones. 3. Be realistic about security --the default should be _nothing_ reaches into my home, and I should have an easily managable way to allow what I want to allow. The default should not be an open door to anyone from anyplace at any time, and then we'll put in advanced monitoring to block activity. See Security, Borders, and the elimination of NAT section on page 5. --- [RFC6092] provides recommendations for an IPv6 firewall that applies limitations on end-to-end transparency where security considerations are deemed important to promote local and Internet security. The firewall operation is simple in that there is an assumption that traffic which is to be blocked by default is defined in the RFC and not expected to be updated by the user or otherwise. The RFC also discusses an option for CPEs to have an option to be put into a transparent mode of operation. It is important to distinguish between addressability and reachability; i.e. IPv6 through use of globally unique addressing in the home makes all devices potentially reachable from anywhere. Whether they are or not should depend on firewall or filtering behaviour, and not the presence or use of NAT. ... --- Does this address you concerns? John ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
Russ == 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. But OSPF router-id is 32 bits.What is the likelyhood of a collision in the bottom 32-bits of the MAC? -- ] 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. pgp73LroPJsXJ.pgp Description: PGP signature ___ 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 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. 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. 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
Re: [homenet] security question for zeroconf stuff inside the homenet...
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. 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
Re: [homenet] Thoughts about routing - trends
Hi Jim, I fully agree with you. Declaring OLSRv2 etc. out of scope just because a home is not a mesh network seems simplistic to me. As you explained in your mail, many of the problems that mesh networks already solve successfully today, can be very similar in a home: dynamic topology, no skilled network operator centrally managing the devices, wireless and wired devices, limited resources on the routers etc. These were exactly the motivation for developing such protocols in MANET. Best regards Ulrich On 10/12/11 3:10 AM, Jim Gettys wrote: 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 reality of how wireless works, with just works automatic configuration, with fail safe behaviour. - Jim ___ 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
Hi, On 10/12/11 8:38 AM, Michael Richardson wrote: Russ == 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. But OSPF router-id is 32 bits.What is the likelyhood of a collision in the bottom 32-bits of the MAC? It seems to me that this discussion about duplicate addresses / unique MAC tool already place in the IETF a number of years ago, e.g. as reflected in RFC 4862 (IPv6 Stateless Autoconfiguration, section 5.4), where duplicate address detection is mandatory. It wouldn't have to be if the assumption holds that all MAC addresses are unique. Even though the probability of collisions may be low, because of manufacturer errors / virtual interfaces and virtual machines / reduction from 48bits to 32bits, there could be collisions. I am not convinced that we can make Russ' assumption that we need unique identifiers at equipment level (or at least that seems inconsistent with previous IETF decisions, so we would need to make a strong case what has changed since then). I do agree with Russ, though, that verifying uniqueness is hard. Regards Ulrich ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Thoughts about routing
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
