> MN's are the only IPv6 hosts that need it right now, AFAIR. > > All hosts would also be good, but I'm not sure if there's any _need_ to > burden IPv6 implementations that don't support MIPv6 at this point.
But if there is a security issue with mobile hosts forwarding packets with RH (that contain them as a destination) why doesn't that concern extend to hosts that don't implement MIPv6? > > There is other use of routing headers such as being able to remotely > > do a traceroute from the other end by source routing the packets > > through that host. > > I'm not sure if that is all that useful, but you're right. There might be > an exception (as is noted in RFC1122 IIRC) about "local routing headers". > The check would be made stricter by e.g. requiring to-be-swapped address > must equal the source address. But that wouldn't allow 3rd party traceroute (such as the NOC doing a traceroute from A to B by source routing packets to B through A). I have no idea if this is used operationally... > If one is able to spoof the source address, this could be used for > anonymous reflection by spoofing source address to be that of the final > victim. Therefore I don't think this kind of use should be encouraged. But it is a bit different than reflection ... in subtle ways. My brain can't tell if these differences are significant... > > Of course there are some details e.g. on how the MN discovers that the CN has > > garbage collected the BCE but I think an ICMP error can handle that (but > > I haven't thought enough about that). > > I don't see security issues with that. > > I was worried about the same thing too -- as Michael Thomas also pointed > out. This could lead to rather unpredictable behaviour. Getting this > robust enough (packets discarded until ICMP is received to notify about > this might not be enough) may be challenging. A possible addition would be allowing the CN to sending "binding nack" when deleting the BCE. Then the ICMP error would occur e.g. when such a message is lost or the CN crashes and reboots (i.e. doesn't have the ability to send a nack). Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
