Re: [homenet] Thoughts about ipv6 routing (babel AHCP)
Hello David [David] Now, in reviewing this thread, I was disappointed to see that my ipv6 routing protocol of choice (babel) has not been discussed so far to any extent. While this protocol is somewhat new, an rfc and working code both exist, and working code has existed for several years. [Pascal ] I can only confirm from almost 10 years of implementing and experimenting the principles used in Babel that they are very sound (I started using them with nested networks of mobile routers, see http://tools.ietf.org/html/draft-thubert-tree-discovery ) And if you look at it, you'll find that BABEL builds its routing tree towards a destination using the same base principles as RPL builds its DODAG towards its root, DV operations with the same feasibility conditions and sequenced updates. After that RPL provides a number of optimizations: - RPL recognizes that most traffic goes through a limited number of gateways and only builds DODAGs off these gateways. This fits the classical wiring in a house, which is mostly hub/spoke and in any case a tree, simply because that's what electricians learn at school. From there, the default route can be heavily used, which saves states and more importantly states updates. - RPL has triggered updates dampening for large / dense configs (based on trickle); you'll note that there is no global triggered update (RPL looks more like DSDV than BABEL for that matter), only local. These local updates allow quick local repairs that avoid impacting the whole network when the use plays with the wireless settings in its stereo gear. - RPL has tunable elasticity on the feasibility conditions, which, when used, may create loops. This is compensated by an in-band packet validation. This adaptation is specialized for operations such as WSN where there are very few packets and battery conservation is critical, which is true for home automation, and can be turned off for more classical operations. - RPL has another inheritance from DUAL which allows poisoning a sub-DODAG by detaching it and then later reattaching it to the main DODAG. The shape of the sub DODAG can be retained and routing is maintained within, a feature that users might appreciate should a home gateway reboot, which in my experience happens quite often. - With RPL, all routing inside the DODAG that is built for a given root (gateway, backbone router) exploits the DODAG topology so there is only one topology to maintain for all nodes in the DODAG as opposed to one topology per destination. Routing might be stretched as packets have to go up to the common parent and then down, but this allows a heavy utilization of the default route which in turn saves states maintenance and improves mobility. Users actually wear devices, move through the house, and expect that we maintain enough connectivity to stream media. - Instead of having different topologies per destination, RPL allows multiple instances that build their own topologies for their goals and constraints, and enables routing along those topologies. This solves in particular the walled garden problem we already discussed in this list, for instance for routing Utility packets from/to the Utility gateway which happens naturally if the utility packets are placed onto the RPL topology that is associated to the Utility. - RPL is partially autonomic, in that it distributes its own configuration as the DODAG builds off the root. If configuration is required to indicate a certain optimization, then that configuration can be pushed by the service provider onto the gateway, and it will be passed on by the protocol. But I'd think that being autonomic is quite critical. Interestingly, there's also intense research around that subject in Europe, see for instance AFI at ETSI. - RPL is designed for multilink subnets, and in particular it distributes the information that routers will need of they need to form RAs, though the exact operation for doing it was taken off the spec. MLSN is quite useful to avoid renumbering devices that move inside the house, and it is seen as a MUST in industrial environments. - RPL is designed to be complemented by a task-specific plug-in called objective function, which understands and adapts the operations to the metrics and constraints. Built-in OFs are quite abstract because they are very generic, but this group and others are free to define their own OF to map their needs. I have yet to understand which of the points above are required as opposed to nice-to-have for the HOMENET as the groups sees it. [David] The future inside the home is mostly wireless, not wired... and as many of the assumptions built into ipv6, dhcp, dhcpv6, ra announcements, etc completely predate the rise of wireless everywhere, they tend to be, well... wrong. [Pascal ] I agree, with a twist that IPv6 is provenly quite capable to adapt and survive. The work at 6LoWPAN on ND is ample demonstration of that, isn't
Re: [homenet] Thoughts about ipv6 routing (babel AHCP)
On 10/19/2011 03:43 AM, Ole Troan wrote: you aren't helping things work better by doing 6to4. please disabled by default, if you absolutely want to support it at all, hide it somewhere under the Wizard menus. Actually, 6to4 works really well on Comcast since they installed production 6to4 relays that are geographically dispersed. Whether 6to4 should be on by default, given the lack of decent relays in many parts of the world is a different question we can discuss. I don't think hiding it entirely is a good idea, given that this is the largest ISP in the U.S. (world?). This is, of course soluble by ISP's; not having much IPv6 traffic is a self fulfilling prophesy if it doesn't get tested, and it won't get tested unless there is traffic, etc And without relays, 6to4 sucks, and so on... - 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 10/19/2011 12:30 PM, Curtis Villamizar wrote: In message28269.1318994...@marajade.sandelman.ca Michael Richardson writes: Curtis == Curtis Villamizarcur...@occnc.com writes: Curtis A WiFi AP will not connect to another AP and wireless Curtis routers are typically AP by default. So if two wireless Curtis routers autoconfig to being AP and using open routing, then OUT OF THE BOX: not every device plugged into a home network have no prior configuration. For instance, someone bringing a newsed device to grandma's house. He who configures it needs to fix it. Or press the factory default button (if there is one). The example is two AP. Most AP can be restored to factory default with a button press. What happens if you have two of them and they're BOTH configured to boot as the master home access point? ... Curtis there is only a risk if something that is an WiFi client is Curtis also a configured to be a router. Yes, but we want to assume that at least one of these will be configured as a router as a default, which means we KNOW someone will turn on two of them On BSD and I suspect Linux as well, the default for: net.inet.ip.forwarding net.inet6.ip6.forwarding are both zero. Right, but that cannot be the default for a homenet box. Joe ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] is this what homenet are trying to achieve? (was Re: Thoughts about routing
In message 4e9eb8fd.2060...@riw.us Russ White writes: 1. No built in assumptions about whether a router has an uplink port and if so, which port it is. d. assumptions about uplinks may be learned (zero config) or configured. The biggest problem with determining what's an uplink and what's not is simply what the word uplink actually means. One of the things we've been thinking about here is walled gardens, networks which serve a special purpose, and hence don't have connectivity to the world at large. There are probably only two solutions here: 1. The provider's device needs to tell you this information. 2. You need a set of magic destinations, that the internal devices can use to orient themselves to the network topology around them. Its easy to detect a walled garden if you are expecting a default route from a full uplink. Use the route to the whole Internet if one is available. Otherwise, use the walled garden connection if that is all you have. Walled gardens really suck. They suck even worse when they are sold as having access to the Internet when they don't. We have to get rid of long lease times. If a connection goes up, its The problem here is that you're working against the rest of the world, which assumes an IP address is pretty much a permanent feature of a device, like a MAC address. I don't know how to change that mentality. Yes. If plugging things arbitrarily and rearranging them without powering any of it down is going to work, handing out long leases to legacy devices can't be done. If a device supports taking back a lease, then that is better. Note that I had a perfectly fine workaround, which was to NAT for any device that wouldn't give up on using an old address if that address became stale. #4. security a. No filtering should be done on a link that is not identified as an uplink. As long as you're okay with multiple layered devices each filtering on their uplinks (not necessarily a bad thing, by the way). I tend to think more in terms of domains, which included possible vertical divides as well as horizontal ones. An uplink is a connection to the provider. It is discovered, not identified as the port with the yellow connector. Reread the very first sentence you quoted: No built in assumptions about whether a router has an uplink port and if so, which port it is. b. By default strong filtering should be enabled on any uplink. c. Filtering can be weakenned, holes punched through, or disabled by configuration. Agreed. OK a. DV and LS routing can mixed within a domain. DV routes can be In fact, OSPF already does this... What I hate is this entire idea of redistribution. A single protocol that does both DV and LS in the right places would be ideal --but I also think the existing DV protocols can be modified to provide this sort of thing. I was trying to help come to a compromise on the grand unified routing protocol problem by stating that we don't need a one size fits all routing protocol. We can have one for wired, one for AP style wireless, one for mesh wireless. For (a) we should recommend one. OSPF is full standard and is cleaner but we have v2 for IPv4 and v3 for IPv6. ISIS has NSAPs as router ID (even uglier than IPv6 addresses or MACs and must be unique), sends around really big packets even for small changes, but supports both IPv4 and IPv6 in one instance and is (strongly) prefered by some. I would argue that the router ID situation in IS-IS is actually easier to deal with than the one in OSPF. With fragmented LSPs, I don't think the packet size in IS-IS is any worse than OSPF, either (?). On packet size: OSPF doesn't have a requirement to round every hello packet up MTU which ISIS does. OSPF can send only the LSA that changed. ISIS has to send the whole LSPDU fragment which contains the change and then the receiver has to check every TLV in the packet that didn't change and find the one that did change. Perhaps there can be a negociation with the zero config default being a slight preference for X where each vendor gets to pick X and the slight preference could be overridden by a configured (strong) preference. Perhaps distance to any router with a configured preference can be a tie breaker to switch over (with *lots* of hysteresis on the switch over). If we can't pick one then we have to make a network interoperate in a zero config situation with vendors that had different slight preference choices. It means two routing protocols with the increase in executable image and memory footprint. :-) Russ 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 4e9f3e69.90...@isi.edu Joe Touch writes: On 10/19/2011 12:30 PM, Curtis Villamizar wrote: In message28269.1318994...@marajade.sandelman.ca Michael Richardson writes: Curtis == Curtis Villamizarcur...@occnc.com writes: Curtis A WiFi AP will not connect to another AP and wireless Curtis routers are typically AP by default. So if two wireless Curtis routers autoconfig to being AP and using open routing, then OUT OF THE BOX: not every device plugged into a home network have no prior configuration. For instance, someone bringing a newsed device to grandma's house. He who configures it needs to fix it. Or press the factory default button (if there is one). The example is two AP. Most AP can be restored to factory default with a button press. What happens if you have two of them and they're BOTH configured to boot as the master home access point? Master home access point? What is that? We are not talking about today's primitive NAT boxes that pretend to be routers. They either have a default route to the Internet or they don't. If they have a defailt route and they are at equal distance to that default route, then there are some arbitrary tie breakers. Worst case for AP might be if they are hard configed to the same channel and are very close to each other so they have about the same S/N and hosts can't decide which one to associate with, plus the interference with each other. In any case a press of the factory settings button should fix it. ... Curtis there is only a risk if something that is an WiFi client is Curtis also a configured to be a router. Yes, but we want to assume that at least one of these will be configured as a router as a default, which means we KNOW someone will turn on two of them We want to assume that *all* AP are configured as routers except the legacy ones that want to be a dumb bridge with NAT to one port. On BSD and I suspect Linux as well, the default for: net.inet.ip.forwarding net.inet6.ip6.forwarding are both zero. Right, but that cannot be the default for a homenet box. You are mixing the discussion of what we want in routers with what we don't want enabled by default in every *legacy* PC, toaster and coffee maker. If the coffee maker is a competent IPv6 router with extensions to let it autoconfig, then let it be a router. I really don't want my dumb old kitchen appliances trying to NAT for each other. But that new IPv6 espresso maker that knows how to act as a router - that would be OK. :-) You lost the context. You snipped out the statement I was replying to. A little too much trimming on the response. It happens. Joe Curtis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
