> On Mon, Nov 03, 2003 at 10:45:07PM -0800, Alain Durand wrote: > > > > As I explain in a previous message, this last property is not verified > > by the hinden/haberman draft, as when those addresses leak, > > they would create untraceable problems, very similar to the one > > caused by RFC1918 leaks today. > > But could we ever stop leakage? > > And would it not be more dangerous if hijacked or randomly picked prefixes > leaked instead of well-known (probabilistically unique) prefixes?
Let's assume that the need won't go away. We have de facto three local addressing proposals: use the existing site local prefix, hijack a prefix in the 2000::/3 space, or draft-hinden. Site administrators who perceive this need will pick one of these three proposal. How do they compare from a "leak" point of view? My take is as follow: - using site local is roughly equivalent to using net 10 in IPv4. The address range can be filtered in routers, but it is ambiguous. Ambiguity prevents tracing the source of the leaks. - hijack a prefix is roughly equivalent to the pre-RFC-1958 situation in IPv4, e.g. alumni reusing the MIT address space. The address range can be filtered in some routers, but not in all of them. Leaks are difficult to even notice, and result in misdirection of traffic to an unsuspecting party. Leaks in the routing protocols result in routing disruption. - the addresses proposed in draft-hinden appear to be strictly better than either the existing site-local or hijacked addresses. They can be filtered in routers. Attempts at uniqueness give us a reasonable hope of tracing the source of leaks. They don't conflict with existing addresses, so the leaks don't affect the connectivity or the traffic load of third parties. In short, the proposed addresses cannot eliminate application level leaks, but they can definitely reduce their consequences, and do a much better job at that than the alternatives. -- Christian Huitema -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
