In message <caestavvjazomppfgoigtaranueokeb5hhmkfgnae-v31+ro...@mail.gmail.com> Mark Townsley writes: > When a host connects to a different link covered by a different subnet, > indeed it will require a new IP address. That's pretty fundamental to what > a subnet is. Hosts are getting better and better at handling multiple > addresses, of both versions, coming and going. MPTCP should continue to > help in this regard. I'm a big fan of seeing more and more MPTCP, and I've > been impressed at the ability of modern devices to upgrade their host > stacks in the past 4-5 years (vs. the decade or so before). I'll remain > cautiously hopeful here for the long term. > > In the mean time, I fully expect that to support seamless wifi roaming from > one AP to another there will have to be some sort of bridging or tunneling > (capwap, et. al) taking place to keep the single ethernet wifi subnet alive > for IPv4 and less modern IPv6 hosts. That doesn't mean there will be no > room for routing in the home, as one of the primary motivations for IP > routing is to support diverse media types. i.e, it's much easier I think if > wi-fi only has to worry about roaming within wi-fi, and not MOCA, EoPL, > 802.15.4, Bluetooth LE, etc. as well. > > One day if/when hosts and apps finally become fully resilient to IP address > changes, then it could become much easier on APs as they will have the > chance to simply hand out a new IPv6 address and route, avoiding bridging > and/or tunneling tricks. That could be a nice win for wifi scalability, but > to be honest is shrouded in so many operational practicalities and moving > parts that it's best not to try pretend that this will come to pass even if > we are successful in providing the world with zero-touch IP routing > technology in the home. It could be a very nice bonus, and I hope it > happens, but I wouldn't want to set the bar that high in the near term as > something homenet can make happen on its own. > > - Mark
The way this was solved circa early-mid 1990s (with configuration required and a bit of code hack) involved putting a fixed address on the loopback interface. For incoming TCP connections, only an ifconfig lo0 was required. For outbound TCP connections, no MPTCP was needed, just an ability to favor binding to the loopback address on critical applications where an outbound connection is made. This was the code change needed back then (and was tupically done to klogin, and the other kerberos enabled r-commands). Today, with address selection policy (ie: ip6addrctl on BSD), no code changes are needed for outbound TCP connections as well. This type of allocation would work if moving from one AP to another within an administrative domain (within a homenet or from an office to a conferance room at work) but not when roaming from home to the coffee shop wifi AP. Here is one way it might get done. It might be worth considering a multiple means to hand out addresses for lookbacks. For example extensions to DHCP, SLAAC, DHCPv6, would require only minimal host changes. Hosts could also run OSPF and be stub routers (can be dual or multi homed, but no transit). A router can use OSPF link local addresses as it does today and make an implicit request for a loopback address. The implicit request is made by its existance in the topology with no routable address. Allocation can be by the CPE at a provider border for the router itself, mapping OSPF or ISIS router-id to the requested prefix. Explicit requests can be made using a TLV with a MAC associated with a DHCP lease. Together these two TLVs imply a /32 or /128 stub. If a host is dual homed and gets information from DHCP, then when making a request on a second interface, its already allocated /32 and/or /128 or its other MAC can be included in the DHCP request to avoid a second allocation. The router could then advertise an alternate way to reach that loopback. The host would now be a stub reachable via two routers. For the benefit of older OSPF or ISIS implementations if there were such a thing in the home, any /32 or /128 stub can be explicitly advertised into the LSDB. I don't expect a homenet to get overrun with /128 addresses in the OSPF or ISIS LSDB. Hosts with a /128 on its own loopback would use the default route to get to other stubs within the same /64 as its loopback. This would only be updated hosts, so it would be safe to assume they won't make the /128 into a /64. Note that hosts then don't require routeable interface addresses, only an address on the loopback. This works within an administative domain and doesn't require that the other side of a TCP connection to be upgraded (as is the case with MPTCP). There are no TCP stack changes required, but also implementing MPTCP won't hurt when wandering to the coffee shop. Old hosts works as they did before. They get two interface addresses. As long as they send traffic to an interface that is up and gave it a default route things should work. Switch over based on lease expire would be bad with long lease times (ie: AP is a switch but router/dhcpd behind the AP went down). Old routers work as before except for some reason they see a lot of IPV4 /32 and/or IPv6 /128 stubs. Old dumb routers work as long as the WAN port is not used since they act as NAT from the WAN side but act as a switch on the LAN side. Switches are tolerated. If wifi APs are not used for transit and the APs are routers rather than switches, then there is no reason to run OSPF over wifi in broadcast mode. If the APs are dumb switches, the WiFi hosts look like Ethernet hosts to any router attached to the AP with Ethernet, therefore the WiFi subnet might see OSPF multicast packets intended for other OSPF routers. Curtis _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
