Re: Removing features

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 10 Oct 2003 11:34:04 PDT, Fred Baker said:

> The site-local proposal says that there is an assurance that a particular 
> block of addresses is available to a network administration to use in 
> whatever way it chooses within the confines of its own network, on the 
> proviso that it neither advertise those addresses outside its network in 
> routing nor trust announcements of the block by others, and presumably also 
> ingress filters for the address prefix. Removing the concept removes that 
> capability. YMMV as to whether you want the capability, but you cannot 
> accurately say that the capability still exists once it has been removed.

On the flip side, the biggest basis for removing the feature is the fact that
RFC1918 contains essentially the same provision for IPv4, and 1918 addresses
are continually leaking like sieves, and nobody (to my knowledge) was able to
point at magic router filter dust that would prevent it from happening on IPv6.

So the basic concept is (in my opinion) broken and needs to be euthanized.

> outright. Deprecation doesn't prevent people from using them, but outright 
> removal can be dangerous. And in this case, the assertion that one can 
> still use the address prefix in a local manner is simply incorrect; it can 
> be assigned at the whim of IANA, and network administrations need to plan 
> accordingly. 

And in fact, we've seen this effect in operation recently, when the 69/8 address
space was allocated but often unreachable due to bogon filters....

All in all, however, I think outright removal, although short-term more painful,
will be less troublesome than many years of debugging problems caused by
1918-style leakage of addresses for a "deprecated" feature.



Attachment: pgp00334.pgp
Description: PGP signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]