In message <4e94829e.2010...@cisco.com> Erik Nordmark writes: > On 10/10/11 5:33 PM, Curtis Villamizar wrote: > > In message<4e93358f.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 routeable prefixes returned via IA_PD, if one demarc goes down, there still should be a route to the rest of the world, even for the prefix that provider demarc provided. IPv4 becomes a big kludge because it doesn't have the tools to do this right. DHCPv4 and NAT were successful, but to some extent made mistakes so lets not reuse the parts that didn't work for IPv6. For IPv4, you'll likely have to give out PI space in the absense of a clear uplink. A cycle with no true uplink can end up being a NAT loop without some changes. A path vector addition can at least break the loop (an allocation with no uplink in mind has no path). If there is a possible uplink (another router provided a DHCP response), the subnet of that uplink can go in the path. If the response came with a path, the subnet is added. If your subnet is already in the path, don't accept it as an uplink. A big improvement would also be an IPv4 equivalent to IA_PD and a routing protocol. At least the loop could end up with a different set of subnets of net 10 such that routing could work and no NAT. Then if a real uplink comes along it will already know what PI subnets are allocated in the routed portion. If there are dumb routers that want to reNAT, then they can't be part of a loop. Its no worse than now. > > The idea is that the consumer can plug things in in arbitrarily stupid > > way and it will all still work well enough to not require a support > > call. It might work better if set up right, but good enough if set up > > wrong. Perhaps GbE can be preferred over 100baseT over 10baseT and > > somewhere between 100baseT over 10baseT or after 10baseT fits WiFi. > > Beyond that metrics for multiple WiFi hops can be channel aware. > > I don't think arbitrarily stupid way can possibly work, since that > doesn't ensure that the home network is internally connected. If the > user connects three routers in the den together, but those are not > connect to the rest of the house, then no protocol we come up with can > fix that. Link local addresses and a routing protocol works. Age out the link local advertisements when allocated a routable prefix. Routers can fake proxy ND (just like proxy ARP today) for host that need to think the link local addresses really are local. > If the user wants to have sufficient redundancy (e.g., so that their > teenagers can power off all the gear in the game room with breaking the > Internet connectivity for half of the devices in the home, then clearly > there is a need to understand the topology (wired or wireless) to know > where there are potential single points of failure. Its more common than that. The scope is also supposed to be home and small home office. > Supporting arbitrary topology (as opposed to just trees) is good in that > it enables redundant internal topologies. But getting to a redundant > topology requires a deeper knowledge by the users than mandating a tree. > More rope. Doesn't mean it is simpler for the users. > > Erik Supporting arbitrary topology with zero config is not hard for IPv6 but if you start out making it a non-goal for no good reason it won't be accomplished, at least by this WG. I do agree though that right now configuring today's two main LS routing protocols is way too onerous to ever be successful in the consumer market. But I think it is a solvable problem. Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
