* Just as an FYI, I replied to the earlier mail because I am > trying to sort this out for the node requirements. I think > that in MIPv6, it is OK that MIPv6 makes this recommendation (given > working group consensus, IESG approval, etc.) but the Node Requirements > document is the final word on the issue (assuming WG consensus, > IESG approval, etc.).
This issue seems to delay MIPv6 till the node requirement is out; so could we not just recommend that the Mobile Node SHOULD use the reverse tunnel till some part of the RR test is complete? If we do so, then a potential CN that fails to respond to the CoT test would be considered as a legacy device and we would not perform RO at all. My initial proposal is to negotiate the RO the following way: Cot Fails : The MN MUST use the reverse tunnel for all traffic Cot works, Hot Fails : The CN accepts the HaO but is not willing to manage a Bind Cache -> triangular routing (E.g. a clustered web server) Both work: The CN is willing to receive bind updates. What do you think? Pascal -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 18, 2002 2:14 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Hi Mike, > Vijay Devarapalli writes: > > RO is a SHOULD, it is not a MUST in the current draft. we were > > not talking about route optimization. we were talking about > > processing a HAO. in the current spec HAO MUST be processed but > > not accepted if it cant be verified. verification can be in the > > form of checking for a valid BCE (created securely), IPsec > > protected data session, same trusted domain (where you dont > > expect people to do reflection attacks), the tagging proposal > > from Rajeev and Charlie, smart ingress filtering from Francis > > Dupont, etc... > > Oh, OK. Sorry about that. Still if the code > isn't in the CN, the MN should still be able > to operate correctly, right? That still seems > to me to be a SHOULD rather than a MUST for the > same reasons in my reply to John. > > I guess the long and short of this is that I'm > somewhat skeptical of putting general node > requirements in the MIP draft since it's > probably not the first place one would be > looking to figure out if they were an IPv6 > compliant node. If it's really, really vital > for the health of the net, yadda, yadda, it > would be better to put it in a general v6 node > requirements RFC, don't you think? Just as an FYI, I replied to the earlier mail because I am trying to sort this out for the node requirements. I think that in MIPv6, it is OK that MIPv6 makes this recommendation (given working group consensus, IESG approval, etc.) but the Node Requirements document is the final word on the issue (assuming WG consensus, IESG approval, etc.). John -------------------------------------------------------------------- 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] --------------------------------------------------------------------
