I think the notion of "local-use" address conflates several different things that are better treated as separate subjects. Even if one accepts all of these as valid problems (which I don't), it's not clear that they should all share the same solution.
If you want to argue that (managed or self-organizing) networks that are not connected to the public Internet need to be able to get address blocks easily, which allow them to connect with other networks by private agreement, I agree entirely.
If you want to argue that networks need stable addresses for internal use that allow local applications to survive renumbering and/or moving the attachment to the public internet, I agree with this also.
If you want to argue that nomadic networks (whether "personal area networks" or on a larger scale) need stable address blocks, which can be used to communicate within the network, and which allow them to be connected to and/or merged with other nomadic networks, and which also allow them to intermittently connect to stable networks with or without public internet connectivity, I agree entirely.
(I prefer "nomadic networks" to "active sites", since "active networking" has been used to mean something else. And I think the notion of "site" is semantically loaded in a way that is not productive to this discussion - in particular, the scope of a network does not necessarily coincide with a single administrative entity or boundary. Also we need to consider both auto-configured/ad-hoc networks and managed networks, which seems to be inconsistent with the notion of "site".)
However if you want to argue that the boundary of a network using a particular kind of prefix is something that hosts or applications should inherently or automatically recognize as a boundary for trustworthiness or as a limit to the range of the services they provide, I strongly disagree. The host or app can detect that a potential peer is using a different network prefix, but that says nothing about "who it is" or even "where it is". It is not appropriate for the host or app to assume anything about the relative trustworthiness of either "local" or "nonlocal" peers. This certainly isn't something we should support as part of the addressing architecture. Long experience indicates that addresses are poor indicators of trustworthiness.
So it is NOT the job of an addressing scheme to protect "private" assets from exposure to the public Internet - because the notion of "private" is arbitrary and the policy governing external access can and in many cases should not be based on the address prefixes in use. A nomadic host may move from one address to another, from a local address (e.g. home network) to a global address (public dialup or mobile access network) and then to another local address on a different network that still connects with the first one. The fact that the host moves should not inherently affect its ability to access services, and it's not desirable for the architecture to support an assumption that this is even desirable.
If you want to argue that network administrators will filter traffic to sets of hosts, I agree entirely. However they should realize that this technique is not sufficient to ensure the security of those hosts from attack - as experience indicates. Filtering can be useful as part of a defense-in-depth but should not be considered a substitute for authentication.
If you want to argue that network administrators will prefer to filter traffic on the basis of network prefix rather than listing specific hosts, I agree entirely. However they should be aware that this approach is somewhat inflexible in several ways, and thus of limited applicability.
If you want to argue that it therefore makes sense to encode policy into addresses, and to expect hosts and applications to use the "right" source or destination address for a host in order to negotiate a path through the network to the destination that is consistent with policy, I strongly disagree. This is a far worse overloading of the IP address than say, using the IP address as a host identifier. In general, hosts and apps cannot be expected to be aware of the policy governing use of particular IP address prefixes in particular environments. Nor is it reasonable to expect multi-node applications to implement policy-based routing through such networks. Nor is it even reasonable to expect address selection algorithms to cope with such apparently arbitrary distinctions.
Can a network, under some conditions, use filtering of address prefixes as a crude policy mechanism for enforcement of crude policies without doing much harm? Probably, but that's a far cry from claiming that it's generally desirable to encode policies into IPv6 addresses. Nor is the desire to use this as a policy mechanism justification for harming the flexibility of the IPv6 network to support diverse types of applications.
Similarly the notion that a designated address prefix provides a "hint" to applications regarding filtering is a dubious one - for a variety of reasons. It conflicts with the desire to be able to interconnect with other private networks. It assumes that the same policy applies to all applications on a network when it's much more realistic for that policy to vary from one host or application to another. Even if the app has a clue that its traffic might be filtered, this really is not useful as a policy indication - should this be taken as an indication that the app cannot communicate with that host at all, or instead as an indication that the app must route its requests through an intermediary? Even if it did not create undesirable conflicts over address assignment, the idea that what is essentially a single bit of policy indication is useful to all hosts and all apps on a network is ridiculous - certainly not something that we should provide for in the architecture.
Regarding stability of addresses - a certain amount of stability is necessary for long-running applications, though perhaps indefinite stability is too much to ask. Any network will from time to time be re-organized, hardware will be replaced, etc. An app or host that relies on infinite stability - even in the presence of GUPIs or PUPIs - is probably being unrealistic. There is certainly a need to provide stability during such transitions - in order that they can be handled gracefully - but that's not the same thing as expecting addresses to last forever. Regarding the example of the alarm system, is it really reasonable to expect an alarm system to communicate when external monitors without being able to tolerate changes to the external monitors' addresses?
Another problem with encoding policy into IP addresses is that it makes it considerably more difficult to handle interconnections between various types of networks (self-configuring vs. managed, core-connected vs. private) and the transitions between some of those states that occur as the result of new connections or disconnections. Coping with transitions between PA, PI, and 6to4 addresses is already difficult enough; overloading those addresses with policy makes it infeasible.
So - yes, we need addresses that can be easily allocated for local use (and perhaps for other purposes also), but they should not carry with them any assumptions about the degree of locality or proximity, trustworthiness, filtering, or policy.
Keith
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
