On Mon, 31 Mar 2003, Tony Hain wrote: > Pekka Savola wrote: > > Route advertisements with long-enough lifetimes and > > fast-enough _deprecation_ (when reconnecting) seems one > > approach to look at more > > closely, IMO. > > Rather than continue to send this nonsense, please look closely at it > because you will find that it is a seriously broken model.
Wow -- wait a second, you threw the first rock.. :-) > Deprecation > at reconnection will cause internal connections to drop. Wrong. "deprecated" in RFC2461 terms basically means "address is still assigned, but don't establish new connections with the address" Deprecated addresses can be used juuuust fine for existing connections. deprecated != invalidated > If you delay > the deprecation, connections to the site with the valid allocation will > not be possible. True, to an extent. The big thing is the window between getting new addresses and deprecating old ones; that is, ensuring that packets are not sourced with the old, broken addresses to the _Internet_. Which is why such windows must be minimized or eliminated, as above. However, you could implement a source address check in the border router -- like as proposed in host-centric multihoming -- so the nodes could pick the right address, even in circumstances like this. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
