Mike,
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... processing a HAO is simply replacing the source address with the contents of the HAO. earlier it is used to be a MUST without the verification step. IPv6 WG was okay with that. but people indentified some reflection attacks that are possible if you blindly accept unverified home address option. so now, it is a MUST with the verification step. regards Vijay Michael Thomas wrote: > > [EMAIL PROTECTED] writes: > > > Given that MIPv6 will interoperate without binding > > > code in CN's, it looks pretty much like a SHOULD > > > to me. Indeed, the protocol would not be robust if > > > it didn't consider the case of a non-conformant CN. > > > > I think we want to ask is, is it the right thing to do? For > > proper protocol functioning, will this lead to the correct > > behavior. If we think it is important, the MUST is OK. The > > spec does contain a mechanism to support existing implementations > > of IPv6, which means the protocol designers are doing their > > jobs. > > I think we're straying into a "good" as in > "good for the overall health of the Internet" > kind of good, rather than a "good" as in will > the protocol operate correctly. For the former, > I think you need to have extremely compelling > motivation, as well as a lot of evidence that > the health of the net will be imperiled if *all* > nodes don't implement a particular function, which > is what is at issue here. > > Frankly, I don't think that there is any evidence > that the net would be substantially harmed if RO > wasn't widely implemented and/or enabled. Indeed, > I think there's good reason to believe that many/most > nodes will not enable RO even if their kernel > implements it. In some cases, it's likely to be > a nice and useful optimization, but I really > don't see it as a "if we don't do this the net > will fall apart". As such, SHOULD seems like it > strikes the right balance. > > Mike > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
