On Mon, Nov 24, 2008 at 3:21 PM, Brian E Carpenter <[EMAIL PROTECTED]> wrote: >> 1. In strategy B, communication sessions survive the loss of any of >> the locators. This is a new requirement on layer 4. > > It was introduced (as a goal) by the MULTI6 WG in RFC 3582. > I don't see it as new.
Hi Brian, Some of the best new ideas are old ones whose time has finally come. >> Neither TCP nor >> any of the common UDP protocols handle this. The dynamic map updates >> serve two purposes: first to let the remote endpoints know that a new >> set of locators is available to reach you and second as a lightweight >> authentication mechanism so that the remote endpoint knows which >> locators are valid as sources in the packet. > > That's a very good brief description of SHIM6, which does not need > a global dynamic map as it works purely end to end. It also hides the > dynamics from the transport layer, so TCP and UDP are unaffected. > Soa global dynamic map, and changes to the transport layer, are not > necessary properties of strategy B. You say Shim6 doesn't need a global map. I say it can't make effective use of one. A shim6-enabled host has trouble initiating connections to hosts where the first chosen address is inaccessible. It also runs into a number of corner cases where its behavior is either broken or ambiguous. For example, what happens if: 1.2.3.4 starts talking to 5.6.7.8 which is also 8.7.6.5. 5.6.7.8 dies. 1.2.3.4 starts talking to 8.7.6.5 instead. The app still thinks its talking to 5.6.7.8. 5.6.7.8 is assigned to a new machine unrelated to 8.7.6.5. The app at 1.2.3.4 asks for a new connection to 5.6.7.8. Does 1.2.3.4 connect to the new 5.6.7.8 or does it connect to 8.7.6.5? With a map, the answer is straightforward: 1.2.3.4 starts talking to example.com (currently 5.6.7.8 and 8.7.6.5) 5.6.7.8 dies. 1.2.3.4 keeps talking to example.com, now at 8.7.6.5. 5.6.7.8 is assigned to a new machine unrelated to 8.7.6.5. The app at 1.2.3.4 asks for a new connection to example.com (currently 8.7.6.5). That having been said, ubiquitous deployment of Shim6+DNS combined with the kind of dynamic address assignment I described could reasonably form a strategy-B protocol. I don't think it forms a particularly good one, but I doubt I could do better under Shim6's mapless design constraint. With a map I can do better. Much better. >> 2. In strategy B, locator assignment is dynamic. > > Why is that a necessary property? Because we want to optimize the network for hierarchical aggregation in the instant topography with whichever link sets are currently working. We've already learned that administratively optimizing a static "best case" view of the network for hierarchic aggregation is burdensome and dysfunctional because the network state isn't static. And we want the addresses to change regularly enough that no one makes the mistake of writing software which assumes otherwise. We won't achieve either goal with administrative assignment. > Whether that works or not gets quite complicated. > draft-ietf-6man-addr-select-sol-01.txt > draft-baker-6man-multiprefix-default-route-00 Thanks for the refs! >> Would you suggest changes to the strategy B description that make this >> more clear? > > Well, either include the multiple administratively assigned LOC case > or add a new strategy which is actually the original IPv6 > strategy. The original IPv6 strategy was: Make everybody attach to only one ISP using IPv6 and a subset of the ISP's single set of PA addresses. That may not have been the original hope, but that's what popped out of the process. Okay, maybe I see your point. Let me repeat it in my words to make sure before I commit it to the document. I think what you're saying is that if we make sure that the layer-4 protocols properly continue the communication session as layer-3 addresses are added and removed and we deprecate and remove variants of the layer-4 protocols which don't achieve this, we should be able to use multiple statically (aka administratively) assigned subnets with IPv6's layer 3 to achieve an acceptable reduction of the routing table size. Theoretically, IPv6's deployment is meager enough that deprecating the non-compliant variants of the layer-4 protocols now wouldn't be too painful. How close did I get? Regards, Bill Herrin -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
