Sri Gundavelli <[email protected]> writes: > Hi Thomas/Ed:
> (I was not really expecting Thomas to respond to this thread, I want > support from folks :), now they are gone). > 1. We don't have any experience with MIPv6 RO, I agree. But, if we > don't enable this function in every IPv6 node, we will never ever > have the opportunity to turn this feature on. Mobile IPv6 is the > only global mobility protocol, that we have standardized in IETF, > ignoring PMIPv6 which is a local mobility protocol. When MIPv6 > was designed (when you were the AD), it was always viewed a base > feature of IPv6. The choice of MH, as supposed to using a > transport layer ports, or the support for RO, was inline with > that thinking. I've been around the IETF a pretty long time, and at one point, I was also pretty sympathetic to the idea that if we require something, it would prod industry in a positive direction. Having been burned by many non-deployments, I recognize the limits to this approach and am now much more cautious. As the classic example, think about security. We used to think If we just require strong security in our specs, great things will happen. I think it's pretty safe to say that we have a pretty uneven record here (at best). We even seem to have come to the (surprising!) agreement that we should downgrade the requirement of IPsec in every node to a SHOULD. Requiring IPsec just hasn't resulted in IPsec being widely deployed (other than in VPNs) and hasn't resulted in it being used as the security technology of choice. Please carefully re-read Raj's posting. MIPv6 doesn't even appear to be the right mobility technology to recommend these days. That pretty much says it all... > 2. When Mobile IPv4 was specified in 90's and even after CDMA > adopted the protocol, there was always a comment on the lack of > RO support. This is a protocol that suffered from "triangular > routing", at least the perception, if anchoring is the right > model and if operators liked it, is another topic. But, we never > had the capability to support that feature in IPv4, we can > specify a solution for MIPv4 RO, but any solution that requires a > change in every IPv4 node in the internet, implies the feature is > useless. We have an opportunity here to make that change here. I will be at the front of the line championing RO technology once there is demonstrable community support for a particular approach and we have enough operational experience to give us confidence it is ready for broad use. > 3. I can understand that we have to be careful what we mandate in > the node requirements document. If feature-x makes sense, useful, > easy to implement, inline with Internet architectural > direction. This protocol is specified, analyzed, implemented and > studied in universities for number of years . Most Linux/BSD > kernels have support Type-II RH, I remember some Linux > distributions have included the RO feature by default. Its not a > whole lot of code, or complexity that one needs to deal with. Its > matter of including that package in all distributions. Making > that mandatory. Support for the RH headers is a minor issue. The real complexity in RO is in the signalling and management of the local Destination Cache. It is lack of experience here that is one of my big concerns. E.g., we don't even know when to recommend initiating RO. After 10 packets? After a thousand? Every connection? Only certain ones? Without experience, we just don't know if this stuff is fully baked. And there was a thread a while back from big content providers that had pretty serious concerns about putting RO in their servers (i.e., increased state and complexity for all their short-lived TCP connections). There are legitimate concerns with RO that still need to be worked through. Hence, again, we need real, substantive experience with it. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
