In message <dcc302faa9fe5f4bba4dcad4656937791451335...@prvpexvs03.corp.twcable.com> "Howard, Lee" writes: > > -----Original Message----- > > From: Curtis Villamizar [mailto:cur...@occnc.com] > > Sent: Friday, October 21, 2011 11:14 PM > > To: Howard, Lee > > Cc: Samita Chakrabarti; homenet@ietf.org > > Subject: Re: [homenet] routing requirements > > > > > > In message > > <dcc302faa9fe5f4bba4dcad4656937791451334...@prvpexvs03.corp.twcab > > le.com> > > "Howard, Lee" writes: > > > > > Can you describe some scenarios which would cause a prefix to change, > > > in which applications break in ways that are unacceptable? All of the > > > ones I can think of would be cases where I would expect a session to > > > drop, but I'm sure that's a lack of creativity on my part. > > > > > > Lee > > > > > > Most IPv4 hosts can't tolerate their IP address going away. For IPv6 > > its slightly easier because they can add a new address in a new > > prefix. Only think is the host need to ask for an address and today > > if its lease has not expired it won't ask. Some older DHCP code won't > > take a change in address or default route when the lease expires. > > The case we were talking about, I think, was a link or device failure. > One expects an outage in those cases.
If you have two uplinks, you shouldn't need to reboot everything your house to get connectivity back up because hosts and routers are using a prefix that is no longer globally routable. > > One thing that would break is any open TCP connections. The open > > connections use the already selected address. This has been a problem > > for mobility for quite a while but those heavier solution can't be > > applied to this problem. > > TCP is not expected to be resilient to outages. We're not building a > carrier network, we're building a home network. Bounce the > connection. No one is suggesting we try to avoid dropping an open TCP connection on a down transition from the uplink that provided the address the host is using. > > Concievably a TCP extension could support alternate source addresses > > (such as SCTP does). Until then, a TCP connection can't change > > addresses. > > > > If you switch from one provider uplink to another, you should be able > > to keep talking to your content provider. Currently you can't. For > > web users, hit the stop and the reload. > > Web, p2p, gaming, VPN. . . I'm okay with the session dropping in case > of failure. Yes. This is not a TCP ng WG so we don't try to fix TCP here. There are cases like two uplinks to the same provider (same /64 prefix) that would work without any effort. This would be rare in the home though not unthinkable in a home or small business and not uncommon in medium and large businesses. We should make it possible for multihoming scenarios such as this to work, preferably with no configuration, except at the provider. For example, an extension to IA_PD essentially saying "use X/65 which came from X/64 and has no firewall enabled yet" would allow the provider to do all the configuration needed to make this workable with zero config on the customer side. > Lee Curtis _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
