Pascal Thubert wrote: > 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.
I've thought about this in the context non-RR RO security schemes. We can already do this, by adding a new mobility option to be carried by hoti and then returned by hot if the peer supports it. > 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 Good. > '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 ??? Do we really need this kind of negotiation just to figure out whether the receiver can support HAO or not? If yes, I think it would be much better to have the RO and HAO support together. That is, the peer supports HAO if and only if it supports RO and RR. > 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 Uh... that's not right. > 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 Yes. > ShOuLd at least replace all occurrences of MUST by SHOULD in 8.1. > > Does that make sense? Yes. Jari -------------------------------------------------------------------- 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] --------------------------------------------------------------------
