I think we're missing the point. There is a perceived need by "many" operators for an address space that can be used for 'local' use, where 'local' is 'not part of the global internet'. We can argue until the cows come home whether any given possible use for such a space is good or bad, but the fact remains that there is demand for such a space and that it is thus better to allow for it's allocation in a managed manner rather than have it snatched from whatever ad-hoc place the network manager decides.
Fundamentally, there are 2 requirements: - Free (both financially and administratively) - Approximately unique Operationally, we impose an additional requirement: - Using such space should not add to the size of the global routing tables. An unadministered PI scheme that generated unique prefixes would satisfy the first 2 requirements. However, allowing such addresses to be globally routeable has two drawbacks: - affects global routing tables, possibly badly - raises 'approximately unique' requirement to 'unique' Introducing compulsory filtering outside whatever administrative boundaries these addresses have removes these two drawbacks. These addresses become unusable for global communication, but then they are not intended for global communication. Assuming the 'unique enough' mechanism is unique enough, the only difference between a 'local' address and a 'global' address which is administratively filtered is that EVERYBODY is filtering the local address, so if it slips past one filter someone else will probably throw it away. This is NOT a security argument. Local addresses are neither more nor less secure than any other filtered address. Rather, local addresses are intended to provide an easily accessible PI space for people wanting easily accessible PI space, without risking address space conflicts with global addresses. So what changes are needed: - To applications? None. A local address may be treated as a global address, and will function identically to any filtered global address. The only difference is that the local address prefix provides a strong hint that the address WILL be filtered, thus increasing the ability of an application to make address selection choices if it so wishes. - To routers and infrastructure? Many of these devices SHOULD have filters configured to discard local addresses. Those that do not may suffer some increased traffic. Nothing breaks that wont break already. The cost to those that don't want to use these addresses is minimal. And some people gain functionality they particularly want. Where is the problem? I'll offer one comment on the Hinden/Haberman draft. Although I'm generally in favour of it, the draft completely partitions the space into that which is registered and that which is allocated using the provided random algorithm. No space is left for alternative mechanisms, such as MAC based allocation presented in draft-white-auto-subnet-alloc or draft-hinden-ipv6-global-site-local. -- Andrew White -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
