Robert Elz wrote: > Date: Fri, 31 May 2002 19:54:03 +0900 > From: [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > > | then we will have two separate set of IPv6 nodes - without mobile-ipv6 > | and with mobile-ipv6, and they cannot even ping each other. > | do you feel it acceptable? > > No, but that means that the way the technical work has been done is > wrong, and it should be fixed so we don't have that problem. As I said > I wasn't commenting on whether what is being offered technically is > adequate or not, I haven't been paying attention to it at all. > > But whether that is correct or not, it certainly can't be the case that > simply changing a MUST to a SHOULD in a doc will fix it. If there's > a problem like that, it will take a more serious fix.
Just for the record... the current MIPv6 drafts do not have this problem. A "new" IPv6 node can ping an "old" one and vice versa, even if the older node doesn't implement RO, HAO, or anything related to MIPv6. Sure, the communications would be smoother if both parties used RO and overall the Internet would have to carry less traffic, but nothing breaks horribly if they don't. This is a change from the old versions. Also, draft 16 was the first version that we can think of as being globally deployable for route optimization. This is because the requirement in the old versions about PKI or pre-configured security associations would have, in practice, severely limited the use of RO even if implemented in every node. In conclusion, we are free to a decision in this WG about what to mandate for all IPv6 nodes or for new nodes, as far as interoperability goes. The decision should be based on the technical benefits to the Internet and the nodes themselves and the meaning of keywords as specified in RFC 2119. And, perhaps I'm naive but I'm actually hoping good features sell themselves by being useful. I don't buy the argument that CNs do not care. A CN exists in the Internet because it wants to offer something, such as a news service. It should want to offer this in a manner that its clients get the best possible service, including minimal RTT. Jari P.S. John: I believe the current drafts do describe how to use RO. They even describe how to survive the situation that the peer does not implement RO. So in this respect I don't think we need anything new. See e.g. MN state machine 'WaitHC' state and the ICMP action. Please let us know if something additional is needed. At the moment I don't see it. P.S. Mike: Yes, we do need the administrative disable feature on this. The draft already talks about an automatic disable for situations where the node is under a DoS attack but a manual disable would be necessary as well. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
