I think I've been a little cryptic: Some devices such as a fridge may be happy to have a minimum set of requirements for IPv6. Other devices such as clustered servers may not be able to maintain a BCE at all because the cluster IP address is shared among all the members of the cluster -- unless they perform a new protocol to distribute the BCEs-. Furthermore, if the cluster uses a dispatcher that is not on the return path, then the dispatcher cannot provide the MIP termination, either. However, if that same dispatcher terminates an IPSEC tunnel, or by other means to be defined later such as piggy backing, it could be possible to trust a Home address option and perform triangular routing.
Using a Binding Cache as opposed to piggy backing the BU with each packet assumes that memory scales better than CPU. This seems a reasonable approach, so does delaying the support of piggybacking. But still, we must allow for the case where this trade-off does not apply. Say the dispatcher I just mentioned has a hardware accelerated crypto engine; say it can cache some recent computations in a LRU fashion; say it has limited memory capabilities to keep many BCEs long term; and say it needs to serve requests for a huge amount of unrelated users; in that case, the trade-off is the wrong choice, and triangular may be the best can do, unless the client sources its requests with its CoA, which leads to more open issues. MUSTing a Binding Cache in IPv6 outlaws this configuration de facto. If we agree that there can be several levels of support by the CN for RO, then we could define what the behaviour is for each level and how to negotiate that between the CN and the MN. My suggestion was to do that negotiation at RR test time so that no bind support would be necessary unless both parties agree upon bi-directional route optimization. A way to perform that negotiation is to give a meaning to the response to HoTi and CoTi. This may be achieved by adding negative Return Code to Hot Cot, and mostly by accepting an ICMP error as a 'no' response. So 'No' to Both HoTi and CoTi means no bind updates, and usage of the bidir MN-HA tunnel, which ensures compatibility with minimum and legacy stacks, as per the draft 'Yes' to both HoTi and CoTi means let's go with the bind update, as per the draft 'Yes' to CoTi only means support for Home Address option but not for Bind Cache 'Yes' to HoTi only does not make sense to me at the moment ??? This is not exactly the way the draft presents things, mostly for the triangular part. Also, the draft is heavily biased (e.g. 8.1) in such a way as to let the reader believe that MIP could not work without support of the Home Address option by all nodes, "since otherwise communications may be impossible". I believe that this is misleading, and that we should rather explain the different scenarios and pro/cons of each level of support by the CN. I believe we ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1. Does that make sense? Pascal -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Keiichi SHIMA / "?Oc^e Sent: Thursday, July 18, 2002 7:19 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [mobile-ip] Re: summary of HAO, BE processing discussion Let me add one thing. From: Jari Arkko <[EMAIL PROTECTED]> > * IPv6 WG has in the past accepted the HAO as a mandatory > feature for all IPv6 nodes. Arguments have been made, > however, that the processing of the HAO has been changed > and the situation may now be different. In addition, the current draft requires not only HAO but also BE. This means all IPv6 nodes must implement a new extention header (mobility header). I never say that such a mechanism is bad at all. It is good of course. But from the view of the fast deployment of both IPv6 and Mobile IPv6, I personally think it better not to require additional requirements... This is not the view of the protocol designer, though. I'm probablly a bad designer and a bad scientist. I just want a real IPv6 and a Mobile IPv6... Best Regards, --- Keiichi SHIMA IIJ Research Laboratory <[EMAIL PROTECTED]> KAME Project <[EMAIL PROTECTED]> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
